This is a discussion my team had regarding some lessons learned during one of our recent projects.
Stuff in my office
My desk:
Story Board:
We are going to start really implementing some Agile and XP Programming practices. It will probably end up being some crazy hybrid of pure XP and awesome Agile (and, no they are not the same).
Books:
Who else spends Friday nights at Barnes? And, no I have not completely, 100% read through all of them. But, yes, I have read through most of all of them.
As you can tell, I love me some Pragmatic books.
Story Board:
We are going to start really implementing some Agile and XP Programming practices. It will probably end up being some crazy hybrid of pure XP and awesome Agile (and, no they are not the same).
Books:
Who else spends Friday nights at Barnes? And, no I have not completely, 100% read through all of them. But, yes, I have read through most of all of them.
As you can tell, I love me some Pragmatic books.
Top 5 Rails Misconceptions
I have been working with Rails for almost 3 years now in a professional setting. During that time, I have had to convince many people of the merits of Rails. Here are the Top 5 Rails Misconceptions I have come across.
5. Rails is some sort of WYSIWYG editor for web pages.
This one has always baffled me. But, it is true. Every once in a while, I will meet someone that thinks Rails is like Dreamweaver. Huh? My best guess is that they read some buzz article about how "Rails makes building websites easy". Notice I said "websites". There really is no way to combat this misconception other than to just educate this person.
However, do not discount the fact that to many technology people the following is true.
web sites == web pages == GUI == web applications
In other words . . .
index.html == web page
amazon.com also == web page
And, it was probably developed with Dreamweaver.
4. Rails is AJAX.
Web 2.0 is AJAX. And, Rails is AJAX. So, make it AJAX'y. Maybe, this is because Rails started to get popular around the same time AJAX started getting popular. There might be some direct relationship between the two. But, regardless, I hear this one all the time.
Again, you really can't do anything about this except to try and educate. Usually, I try to explain that AJAX is a way to enhance the user's experience, and can be implemented with any number of web frameworks.
Hmmm . . . but, that explaination might be too "Web 2.0".
3. Rails can't scale.
You might be surprised to see that this is not #1. In all honesty, I almost never hear this argument from the people who matter to me (customers, clients and my bosses). I alway hear it from the IT/Ops team, or the DBA's, or the old school Perl/Java/C/C++/insert_whatever_lang_here programmer that sits down the hall.
How this is still an issue is beyond me. In any case, these are the arguments I usually use:
* There are really large Rails sites in production. Twitter (although be ready for the Twitter can't scale arguments), yellowpages.com, scribd.com, all the 37signals products.
* Scaling is usually a much larger architectural issue than just the web framework. Scaling involves hardware, OS's, caching, DB's, proxies, etc. Usually, the language matters very little in scaling.
* And, this is my favorite . . . every (I really mean EVERY) enterprise Java based web application I have ever worked on or implemented was slow as hell. Anyone want to back me on this one? So, what's the argument?
2. You don't need to learn Ruby to do Rails.
I think this early screencast of Rails almost did more harm than good.
http://media.rubyonrails.org/video/rails_take2_with_sound.mov
So, in this screencast, you see a young DHH creating a blog application in 15 minutes with Rails. Lot's of scaffolding and stuff.
Don't get me wrong. This screencast was one of the reasons I got into Rails. But, I thought the same thing. I just need to learn Rails. This is so false. Maybe, if you are creating a 15 minute Blog application, you just need to learn Rails.
This misconception is directly related to my #1 Rails misconception.
1. Rails is not programming.
This is definitely my #1 Rails misconception. I hate this one! Everyday, I have to fight this one.
So, how do I fight these misconceptions?
* Credibility. Be really good at what you do. As a Rails developer, don't be that person who just read the "Agile" book and thinks they can deliver. Read the "Agile" book. Then, you have to do much more . . . usually, this is in your free time.
* Productivity. Deliver quality faster than anyone else. Rails is great for this.
* Adaptability. Sometimes, you just have to make it work. So what if your company's legacy database is SQL Server with some jacked up composite-non-surragate primary keys? Make it work.
* Be nice. This one works all the time. Ruby, and Rails is threat to people. Don't come on like a threat.
5. Rails is some sort of WYSIWYG editor for web pages.
This one has always baffled me. But, it is true. Every once in a while, I will meet someone that thinks Rails is like Dreamweaver. Huh? My best guess is that they read some buzz article about how "Rails makes building websites easy". Notice I said "websites". There really is no way to combat this misconception other than to just educate this person.
However, do not discount the fact that to many technology people the following is true.
web sites == web pages == GUI == web applications
In other words . . .
index.html == web page
amazon.com also == web page
And, it was probably developed with Dreamweaver.
4. Rails is AJAX.
Web 2.0 is AJAX. And, Rails is AJAX. So, make it AJAX'y. Maybe, this is because Rails started to get popular around the same time AJAX started getting popular. There might be some direct relationship between the two. But, regardless, I hear this one all the time.
Again, you really can't do anything about this except to try and educate. Usually, I try to explain that AJAX is a way to enhance the user's experience, and can be implemented with any number of web frameworks.
Hmmm . . . but, that explaination might be too "Web 2.0".
3. Rails can't scale.
You might be surprised to see that this is not #1. In all honesty, I almost never hear this argument from the people who matter to me (customers, clients and my bosses). I alway hear it from the IT/Ops team, or the DBA's, or the old school Perl/Java/C/C++/insert_whatever_lang_here programmer that sits down the hall.
How this is still an issue is beyond me. In any case, these are the arguments I usually use:
* There are really large Rails sites in production. Twitter (although be ready for the Twitter can't scale arguments), yellowpages.com, scribd.com, all the 37signals products.
* Scaling is usually a much larger architectural issue than just the web framework. Scaling involves hardware, OS's, caching, DB's, proxies, etc. Usually, the language matters very little in scaling.
* And, this is my favorite . . . every (I really mean EVERY) enterprise Java based web application I have ever worked on or implemented was slow as hell. Anyone want to back me on this one? So, what's the argument?
2. You don't need to learn Ruby to do Rails.
I think this early screencast of Rails almost did more harm than good.
http://media.rubyonrails.org/video/rails_take2_with_sound.mov
So, in this screencast, you see a young DHH creating a blog application in 15 minutes with Rails. Lot's of scaffolding and stuff.
Don't get me wrong. This screencast was one of the reasons I got into Rails. But, I thought the same thing. I just need to learn Rails. This is so false. Maybe, if you are creating a 15 minute Blog application, you just need to learn Rails.
This misconception is directly related to my #1 Rails misconception.
1. Rails is not programming.
This is definitely my #1 Rails misconception. I hate this one! Everyday, I have to fight this one.
So, how do I fight these misconceptions?
* Credibility. Be really good at what you do. As a Rails developer, don't be that person who just read the "Agile" book and thinks they can deliver. Read the "Agile" book. Then, you have to do much more . . . usually, this is in your free time.
* Productivity. Deliver quality faster than anyone else. Rails is great for this.
* Adaptability. Sometimes, you just have to make it work. So what if your company's legacy database is SQL Server with some jacked up composite-non-surragate primary keys? Make it work.
* Be nice. This one works all the time. Ruby, and Rails is threat to people. Don't come on like a threat.
"Site Under Construction" sessions (or SUC sessions for short)
During my quarterly reviews with each of my team members, I am discovering some commonalities in what people would like to learn.
A common goal seems to be “to get better at application design”.
Good design is a great goal. But, like anything worth accomplishing, it is difficult. Good design can be difficult to learn and teach. And, is more experiential than anything else.
One of the reasons is because “design” encompasses so many disciplines. Also, the most difficult thing about good design is that a lot of attributes of good design are in conflict with each other.
- Copy vs. Graphics
- User vs. Non-user
- Usefulness vs. Stickiness
- Art and Color vs. Transparency
- Functionality vs. Simplicity
- Consistency vs. Flexibility
How do you learn that? How do you teach that? You can read books. You can attend some classes. There are certainly “official” ways to master this.
Just think about it.
I think another way is to just be mindful of it. Think about it all the time. When you log onto Gmail every morning, think about why it is good or bad. When you use Finder, think about it. Why does the Dock work the way it does?
Just think. You don’t have to be correct. But, at least, you are analyzing. You don’t have to write it down. But, you should file it away in your cloud brain for use later.
So, to help accomplish this, my team is going to start doing "Site Under Construction” sessions. I like to call them "this (insert whatever here) SUCs". We will put up a website, applications, or device or whatever. And, we will just discuss it. The good and the bad. There is no correct answer.
What you need in order to become a Ruby on Rails developer
I often get asked and see forum/blog post asking this question (or some variation of it):
"What do I need in order to start Ruby on Rails development?"
The following may not apply to all. But, face it. Admit it. There can be only one way. So, just follow this simple step to more joy and bliss. Here is the step to take. Yes, there is only one step.
Grow some balls
You need . . . To leave your crappy job. To admit that the technology platform you committed the last 5 years to is crap. To be happy about what you do everyday. To realize that the boss you hate really deserves it and doesn't deserve to continually make money off your efforts. To wake up and smell the Ruby.
Also, you need to stop drinking with your worthless "buddies". And, start spending some time learning Ruby, and Rails.
"But, but, but . . . those are my budz, my free time, my weekends . . . wha, wha, whahaaa".Forget that! Those bums aren't going to help make you great. If that is your concern, then just stop reading now.
So, tell me about your balls growthage
"But, that's easy for you to say. I am in (insert some worthless excuse here) . . . blah, blah, blabbity, blah, blah . . ."
So, before you start thinking that I am just blowing smoke, here is my testimony.
I started in Java development. Became an expert in the IBM WebSphere stuff (when I started with it, it was all MQ this, MQ that). Grew into "Systems Architect", "Project Manager" . . . (insert whatever title you want here). Discovered it was boring as heck keeping track of people's hours and arguing over requirements with a client. Start to learn Rails. And, here's the key part. Wait for it . . .
I LEFT my job to do Rails. I took a pay cut (about 12%). I left all that "expertise" that I built up behind. I did all this with a wife, a one year old daughter (at the time), and a mortgage, and school debt.
That's some Rambo-esque courage! But, you can do it too!
What's the technology that you left behind?
Java. No, wait. More specifically, J2EE enterprise software integration. That means taking some stupid vendor software, like (insert stupid enterprise vendor software here . . . I'm looking at you Documentum), and making it fit into the business no matter what.
What to read
Ok, after you have done Step 1, you can read ALL of the following. Then, send me a 2-page report.
I am too lazy to provide links. So, you just Google it. Also, this list is current as of this date. It is what I would recommend someone to read as they start with Rails. Some of them are coding books. But, others are not.
- Getting Real
- The Ten Faces or Innovation
- Beyond Java
- From Java to Ruby
- Extreme Programming
- Rails Way
- Ruby Way
- Web Standards Solutions
I left off the two "Bibles" of Ruby and Rails. I have those. Both are good. But, I do not regularly use them. So, they are left off the list.
There are only two blogs/podcasts to subscribe to that are worth the time:
- RailsCasts
- Rails Envy
It's not code, it's passion
Enough said. If you want to discuss, you know where to find me. Out!
Why Apple was correct in pulling "I am Rich"
If you do not know what "I am Rich" is, just Google it.
There are a lot of people talking about how Apple was wrong to pull the application. I have seen a few, all stupid, arguments for not pulling the application, such as . . .
It's art. Huh?
Buyer beware. Whatevs!?
Dumb arguments.
Apple was correct in pulling it.
It is a stupid application. At a stupid price. And, it isn't even funny as a joke. It doesn't even do anything. Make it rotate or sparkle or anything! Apple should continue to pull these dumb-ass applications. In fact, Apple should pull all applications that are just plain bad.
Why? If Apple is going to act as the gatekeeper for iPhone applications (whether I like it or not), then Apple has an implied duty to remove these types of applications. This is key: Apple is the gatekeeper for ALL iPhone apps.
It is all about trust. I think of it as sort of how we all trust Google to return fair search results. Google works hard to remove crap links and sites that try to "game" the system. We trust them.
We need to trust Apple. A developer needs to know that Apple won't allow these dumb-ass applications through. It just dilutes the space, and ruins it for legit developers. A buyer needs to know that they are not going to get jacked.
Editorial: A few statements on what I think about the App Store.
I do not agree with Apple's decision to require all iPhone applications to be distributed via the App Store.
No trial period for applications sucks. How do you get a refund? Apple has unilateral power "approve" it or "reject" it? Huh? So, I have this awesome idea. I work on it for months, and Apple can just reject it? That's really encouraging me to start working on my iPhone application.
The worst part is that the App Store is full of junk. If Apple is going to act as gatekeeper, then they need to do a better job. Some of the apps are not even iPhone applications. A whole bunch of the applications are just SSB's, which you could do already.
If the iPhone applications does not leverage the SDK, then it is NOT an iPhone app.
An iPhone app, in order to be an iPhone application, must use the phone's hardware, or integrate with a native service or application. Otherwise, it is just crap and useless as an iPhone app. You wouldn't call Gmail in Safari a Leopard application?
So, either be The Gatekeeper or don't.
If Apple is going to be gatekeeper, then do a better job of it. Don't let these dumb apps through. Make sure the apps are legit iPhone applications. Trial periods. Refunds. All the stuff that makes any customer experience good.
Or, don't be the gatekeeper. Let the developers deal with it. That's how it is now with Mac applications. What's the diff?
Even MORE Scrum-esque
Scrum is an "agile" process for software development. Part of the Scrum methodology is The Scrum Meeting.
My team uses Scrum, but we do it even more scrum-esque
At first, we held daily meetings at a consistent time. The purpose of these short meetings were to:
- Inform the team of your status
- Help you organize and prioritize your tasks
- Overcome issues. An issue is not a bug or problem. An example of an issue would be something like, “My ssh access to the QA server stopped working.”
When Scrum meetings work, it is like a well-oiled machine. You should be able to determine the project's status just by listening to everyone else.
Scrum meetings eliminate the cruft, and focuses on the important issues.
But, for my team, we needed to be even MORE Scrum. Meeting everyday was too tiresome, and boring. And, we often discussed other interesting topics, such as "Why Iron Eagle is such an awesome movie."
So, we do our Scrum meetings like this:
- No meetings.
- Just email.
The emails look like this:
- What you did yesterday
- What you will accomplish today
- Issues
The scrum email should answer the following:
- Does it inform the team of your status?
- Does it help you prioritize your tasks?
- If you were doing the wrong thing, does it let others know that you are doing the wrong thing?
So far, it has been working out pretty well.
Posted at
on
8/5/08
by
|
0
comments
|
Filed under:
management
Show & Tell Sessions
We have implemented what I am calling "Show & Tell Sessions".
Here are a few guidelines:
Teaching something is the best way to learn something. My hope is that these sessions will expand our knowledge.
Posted at
on
7/30/08
by
|
0
comments
|
Filed under:
management
Self-Training
A while back, I implemented "self-training" for my team. So far, I think it has been a success.
This is a mandatory task for the team. “Mandatory” as in it counts towards your performance. “Task” as in you do it. “Team” as in the team.
Here are the rules:
- Must do at least .5 hour per day
- Can not roll it over until you do it all in one day (i.e. 5 hours on Friday)
- You can use as many hours as you want towards a particular subject
- Any topic that is related to what we do is fair game
- If you want to buy a book or something, let me know. I will get it expensed.
- I can ask you to change it, expand it, or focus it if it seems like it does not accomplish number 5 or if you are spending too many hours on it.
So, Why? What's the point?
- To become more awesome
- To save Vail time and money
- To master your craft
I am sure that we all do some of this on our own. However, I wanted to structure it so that we will be accountable to one another for it. In other words, you can’t say you are learning something and not do it because one of us may ask you about it.
Some of the self-training subject matter will overlap with something you are assigned to do. For example, I don’t know much about implementing a central authentication systems. And, I want to implement it at Vail. I may self-train on it.
If that is the case, I would suggest approaching the self-training hour from an objective point of view.
“How does it work?” As opposed to, “How can I get it to work for Project xyz?”
It is a subtle difference and may not matter in practice. But, I don’t want to be biased in what we are learning towards some project timeline, or limitation.
In the end, it is all about being better. What we do is our craft. We should master it.
Posted at
on
by
|
1 comments
|
Filed under:
management
Subscribe to:
Posts (Atom)
