Why Ruby and Rails?

"Why should we use Ruby and Rails?" has been popping up at work over the last month. Managers are worried about retraining the Java developers. And the Java developers are worried about wasting their time on some fad. Here are my reasons why you should be using Rails to build a web site.

First, Rails is a web framework, nothing more or less. It claims to do nothing but allow developers to easily create websites. It makes hard problems trivial and impossible problems doable. It claims a 10x improvement in development time. That claim is VERY DIFFICULT to believe, so I will address it later with examples from my current project. Rails should be thought of as a Domain Specific Language (DSL) for web applications. Writing templates or views of web pages is eased with many helpers.

Think of scriptlets in JSPs, but terse code that makes sense. The helpers range from creating links to creating whole forms. All of this goodness is packaged up in an MVC pattern. Unlike Struts, which also claimed to be MVC, there is a single layer for Controllers; each layer is contained in its own directory. Another benefit is the directory layout is standard. If you know the directory layout, every Rails application will be familiar to you. This is a big benefit after you have switched to your upteenth Java project which has it's own directory structure, completely different from all of those that came before it.

Second, you get RESTful web services for free. I can't stress this benefit enough. When you use the generators for Rails you get the server side of a the web service. Building the client is trivial. Remember I said I would prove the 10x improvement in developer time? We are building an application which will have many clients. The clients are mostly Java, so a developer was assigned to write the client for the RESTful Rails application. He decided to write a parser in Java. This took a couple of weeks to write and test. And from time to time we find new bugs in the code.

However, we could have written three lines of Ruby that would have done the same thing. I literally implemented the same thing he had been working on for two weeks in 10 minutes. 8 of those 10 minutes were trying to find the documentation on what needed to be written (sadly when I showed him the Rails way he shrugged and said, I know how to do it this way and I already have this time spent on it. Maybe I should have explained sunk costs). 10 minutes vs 2 weeks, 10x improvement in speed might be an understatement. This isn't the only way Rails improves implementation speed. Writing database queries are a breeze.

Rails comes with its own Object Relational Mapping (ORM) tool called ActiveRecord. Similar to Java's Hibernate in functionality, ActiveRecord improves development by making complex is easy. Rails provides generators to create scripts to create tables in your database of choice (support for many databases is provided including MySQL and Oracle). The generator also creates a Model class for each table you have in the database. The Model class is where you write the code for business logic and any methods needed to access the data. Except, you don't need to write much because Rails provides many access methods without the developer needing to write any code. Rails also helps by providing helper methods to create relationships between objects. ActiveRecord provides support for one to one, one to many and many to many relationships with just a single line of code in each Model class or two lines of code in each Model class for many to many relationships (technically you can do many to many with one line of code in each Model class in the relationship, but that method has been deprecated in favor of the more flexible two method approach).

The last time saving feature of Rails is that you can use Ruby gems in your web applications. Gems are like Java's jar files, they are packages of code that can be thought of as a library. Gems easily support dependencies so having a Gem that requires ActiveRecord is easy to create, which means you can create Gems that natively work in Rails applications. Need a User object in your application? Download one of the many authentication gems available on the web. Find the one that suites your need, install it and you are ready to go. Need to upload files? Install a file upload gem. This capability is available in Java applications too, but for some reason they are more complex.

Finally, Rails is a simple and easy way to get a web application up and running. A developer can finish a week long Rails course with enough fundamentals to be ready to go write a Rails application.

Product Development Lesson: Abigail's Purse

A little over a year ago I sat with my daughter after dinner one night and we chatted about entrepreneurship. She was 13 going on 14 but she understood the concept and started to run with it. We talked about what would be a good product. She was going through a very crafty phase. Not crafty as in mischievous, but crafty as in she was painting, building origami, and making artsy things. She enjoyed it and I suggested we should find one of those craft projects that other people might like and turn it into something people would like to buy. We decided one particular project had promise. The craft project was a handbag woven with plastic strips.

She got to work trying to change a craft project into a product. The first discussion was the materials. I told her we were never going to be able to find plastic strips, but we looked on the internet anyway. Nothing was available. I thought we would have to have the strips made for us specifically. So we started talking about alternatives to plastic strips. She came up with using ribbon instead. I liked it because I thought it would make the purse soft and warm vs the cold hard plastic. So we made a trip to Michael's and purchased a ton of ribbon. Problem number two, we had to find a better supplier of ribbon, Michael's was expensive.

She started making the purse out of ribbon and quickly found the next problem. Ribbon doesn't stand up like plastic does. Being the trooper that she is, she tried to make that work as hard as she could. Finally she mentioned that she was having a problem. She needed some kind of support system to allow her to weave. We spent a week or two thinking about this problem and talking about solutions. We tried a couple and failed and some how ended up ruining the ribbon.

This time we went to Joanne's for the ribbon. Who knew ribbon would be so expensive. We got a couple of blocks of styrofoam from Michael to serve as the support system. We cut the styrofoam to the size of the purse, wrapped it in plastic wrap and off Abigail went to build another purse.

This time it was a success. We talked about the fit and finish, it needed a liner, and some kind of tough base. What we ended up with was the purse you see above. I thought it was pretty awesome. She started using it to carry all of her dance gear. And then we stopped working on the purse.

Yesterday we were walking through Wal-Mart and we saw rows and rows of woven bags. A year has gone by since we started working on the purse. But the first thing Abigail said to me when she saw the purses, "They found the plastic strips." The bags are bigger. They are for going to the beach. They are rugged and cold. And they are $7. Each of Abigail's purses were in the $30 range just in ribbon.

The night before the trip to Wal-Mart Abigail mentioned she was ready to do the purses again. That night I searched for ribbon again and I purchased a ton of ribbon that I had found very cheap, 1/40th the cost of Michael's and Joanne's. The ribbon will show up some time soon, and we will make a couple more purses. Hopefully someone on eBay will find them as wonderful as we do and pay a decent price for them.

Lessons:
* Someone always has the same idea
* Get your product out as quickly as you can
* Keep searching for lower cost materials (without sacrificing quality of course)

Skinny User Stories, Fat Unit Tests

One of my colleagues is continuously trying to improve the processes on his project. It is a large enterprisey project with requirements people, testers and a few developers. My friend places high value on knowing exactly what needs to be done and therefor has strived in the past to have very detailed user stories that includes expected behavior and constraints as well as test criteria. He and I had a conversation that restarted his consideration of the user stories. He likes that they are defining the "truth" in only two places, the user story and the code.

While you are defining the truth in two places, I would say that only one of those places has any long term value. The code. As soon as the sprint is completed, your requirements, especially if they live in a tool like Rally, only exist for the sprint where the code is written. After that sprint, it is doubtful that documentation will ever be read again. This is why specs should be light weight. They are only used for a moment in time. Any time that you begin talking about the specs again, you will have to repeat yourself because invariably one person in the conversation will not have a full understanding of the requirements and you won't have the time to send them the requirements to read. Now is a developer going to go through Rally, or any other tool for that matter, to read the requirements for code? No.

The best place to store requirements is in the Unit Tests. Theoretically, you hope to only have one truth, and that one truth has to be the Unit Tests. Every other type of spec is disposable or maybe a better word is perishable. The specs will go away. The contract will go away. The shall statements will go away. The tasks in Rally or JIRA will go away, but the tests will always remain. "Why does this code do
this?" Should always be answered by "look at the test." This doesn't mean leave comments in the test, it means make the test methods the spec.

I've never really been able to put a finger on why I am so against requirements. It seems irrational and crazy. But I think I understand it better now. I have known subconsciously that the requirements are perishable. That they change. They change as soon as you put it in front of someone and show them how it works. The requirements are never absolutely correct. And if they are right, have you put to much time into managing them?

Lessons Learned:
* Requirements are perishable, their shelf life is the length of a sprint.
* Tests are the ultimate "truth" of the requirements of a system.

Happiest Now

I can say that I am the happiest right now than I have been in a long time. How long? Since I got married long. Don't get me wrong, I have been happily married, but right now things are just awesome. Why? Some people say that happiness is related to community. Right now my community is pretty spectacular.

Family is near by. I talk to my dad daily, my little brother at least once a week, usually more. My kids and I have daily conversations. And my wife and I have been growing as a couple for the last 5 years, the relationship just keeps getting better every day.

I have a bunch of close friends. This is actually a new thing for me. My wife and I talked about moving back closer to our families, and I ended up not wanting to. Why? Primarily because my friends are here. I have work friends and gaming friends and old friends and new friends. And most of the world doesn't understand that this is a new thing for me. It is almost like Christmas every day. Growing up we moved, alot. We moved so much that in 12 years of school, I went to 9 different schools. Which means I had new friends pretty much every year. The years that we didn't move just happened to coincide with the years that I would change schools (going from elementary to middle school). So now, I have friends that I can say, "remember that time ** 9 ** years ago?" and they can say, "Yeah, that was great". Most people in this world have experienced that by the time they are 18. It took me until the age of 36 to have that happen.

My work life is stabilized as well. I am with a good company, that I trust, and that appreciates me. This is new as well. Looking back at that last paragraph I wonder if there was something wrong with me that caused me to jump companies every other year, because that is exactly what happened. The longest I was ever in one place was 2 years. I was never taught how to be planted. The people at my company are great. The company isn't just stable, it is growing. In this economy that is huge.

So, between my family, my friends and my work relationships, my community is pretty strong right now. Which means, I am a happy man.

Don't change my code!

Dear developer peer,

May I bring up a delicate subject? You were offended because I changed code that you had written. You got upset because there was some sense of ownership of the code. You put time and energy into the code. You had to sweat to get the code to do what you wanted it to do. You pressed CTRL+C and CTRL+V six times to get the code in the right place, and write some very funky if statements to get it to work correctly.

All of that was lost to your wailing about lost code is that now TWO people have had to spend time trying to understand what the code does. Your time and mine. I needed to alter the behavior of your code in some minor way, but before I could do that I had to go through and figure out the twisted logic. What gets lost is that I am offended when I find in your code of 60 lines of nested ifs (4 deep). I am offended when after spending 45 minutes trying to understand the intent, I can, in 10 minutes, convert said atrocity to 20 lines and 1 if.

You yelled at me because I wanted the code to be "my way". And that "there is more than one right way". But when your way is 9 if statements and mine is 1 then, well, I don't feel bad. I changed your code because I was offended. I never got a chance to tell you that because you were so pissed, so, now, 10 hours later, I am telling you. If you don't want me to change your code, then write clean code that doesn't offend me. Write code that doesn't offend the compiler. Write code that won't put the CPUs at 100% for 25 seconds. Write code that lets the database limit the dataset instead of returning everything and then looping through it to discard what isn't needed. And for sanity's sake, don't have the exact same code copy and pasted six times in the same method/function.

And don't take this as me thinking that my code is great. I know my code sucks. I look at the code of other developers that I know are smarter than me and try to mimic their style. I try to improve my code every day. The difference between you and me is that I know my code can be improved and would love it if someone came in and showed me how.

Don't hurt your spleen!!

Son (via chat): Mom says you have to feed me today.
Me: I promise to feed you, but if you start feeling a little light headed, feel free to feed yourself. (He's 15 afterall...)
Son: Alright, but if I die, it is on your head.
Me: If you die it will effect more than my head. I will hurt in my head, my heart and in my spleen too.
Son: Your spleen?!?! I'd better not die in that case. Don't want you to have a hurt spleen.

Getting Creative

My son and I were having a conversation about some of his writing the other day. I told him that he needed to be more creative in his writing, and one of the best ways to do that is to give yourself constraints. Here is a great article about why constraints are a great way to get creative:

Next, creativity is all about connecting things. It is about knowing x and knowing y and then figuring out that if you put x and y together you will have something awesome. Often x and y are completely unrelated, but just knowing them helps. That means you have to start to learn lots of x's and y's. And they don't really need to be anything in particular, just... learn.

Open your mind to consuming information. And practice. Then put yourself in a position to create something and then CREATE! And do it by giving yourself constraints and using things that you already know.