There are running notes on Bob Martin's talk (Clean Code)... it was great and the room was packed. There were literally people sitting in the floor for this one.
----
We always get more done at the beginning of a project because the code hasn't gotten messy yet... so how do we 1) keep our code from getting messy? Or 2) clean it up when we realize it gotten messy?
When a project is late, what does management do? Add developers... who tend to do what? Make more mess!
Write your tests first, or you probably won't. When you change your code, add a test. When you create new code, Test First.
The open/close principle... a program should be open to extension but closed to modification. This is powerful.
In school, when we're learning to write, we're taught to write a first draft, then a second draft, etc. Then we try to write code and do it perfectly the first time. And for some reason we fail. Plan on retooling and refactoring when doing the creative act of coding.
Sixty percent unit test code coverage means that you've forty percent unkown code. What does the untested code do again? You don't know. (Actually, a unit test doesn't tell you what you're code does in the context of the application anyway... this is why you should use more than just unit tests. Integration tests are vital. -jared)
The principle of least surprise... create your programs with this in mind.
Make tiny changes... add/change the tests. Then RUN them. Some IDE tools run them in the background continually. (I'm surprised he didn't mention having a continuous integration system running in the background. -jared)
I love how often he keeps telling us how the one page Ruby example was 8 pages in Java (or some variation on those numbers). One of the reasons to use something like Rails is to get the pre-written, pre-tested code. Don't write tons of code when you can have a generator create clean code for you or when you can use an existing library. The generated or existing code is clean, debugged, etc.
Bad code gets harder to clean as time goes by. You want to clean it up, but you're so busy maintaining it, you don't have time. Don't rewrite, focus on incremental improvements. If you don't clean up a little bit today, you never will. Start today.
Dinner parable... the quickest way to end dinner is to walk away. But when you come back to dinner and the old food has dried to the plates, it'll take you much longer to prepare the next meal. Instead, we clean up the dishes as we go. We don't use up every plate then try to clean up. Do the same w/your code. Make a meal. Eat the food. Then clean up the dishes.
Nothing has a more profound and long-term degrading effect than bad code. Bad code rots and ferments. It becomes an inexorable problem that drags your team down.
Professionals write tests first. Professionals clean their code. Professionals know the only way to move fast... is to go well.
This was a great talk!
This conference is huge... there are 1,600 Rails coders here... it's a bit bigger than my more familiar No Fluff symposiums. I'm fairly certain I prefer the smaller conference, but this place is a Who's Who in the community. I've already run into Mike Clark, Glenn Vandenberg, Justin Gehtland, Erik Hatcher, Dave Thomas, Chad Fowler, Nathaniel Talbott, Matt Bass, and more. I stood three feet from DHH. :) I'm running into people I met at RailsEdge in Reston and tons of people from my local Ruby User's group... the concentration of smart people here is just mind boggling.
Last week I was talking to a friend and was reminded how many people who work for companies that won't send anyone to a technical conference. Let me say that if you think your team members know everything they need to know, then by all means, keep them chained to the desk. But if you want your developers to get some new ideas, to learn what's coming next and prepare your product to take advantage of the new innovations, if you want to them to get excited about working with Ruby or Rails (or whatever your language of choice is), then get your team out and at the conference. Give them a chance to get new ideas and get excited. Then they'll bring those ideas and that energy back to your shop.
Anyway, I got a cell phone snapshot of Chad Fowler with his ukulele and a guy on the accordion... They were rehearsing a song they did for the evening keynotes. :) I'll try to post it later if anyone is curious.
The Grails guys posted a quick and dirty benchmark showing that Grails was a lot faster than Rails. I don't think they did anything intentional, but they missed a key point about Rails.
When your application creates a new instance or thread for every new request, it's easy for a server to get overwhelmed. Rails takes another approach. The Rails developers want you to make a conscious decision about how many resources you want an application to have.
So when you deploy a Rails application on Mongrel, you need to decide how many instances are available. This is completely different from the traditional Tomcat model, which looks something more like "spin up threads until the machine stops responding." You can read more about configuring Mongrel on the Mongrel clustering page.
If I've read the page properly, this benchmark is running against a single Mongrel instance, which is the equivalent of creating a Java singleton servlet and testing against it. Of course it's going to be quite slow.
For a real comparison, I'd try using the Apache load balancer plugin or my personal favorite Pound).
It doesn't sound like the benchmark was intentionally flawed. The single threaded application server is a paradigm shift that many people aren't aware of until they move their Rails application to a production environment. He missed it, and it would be interesting to see how it would perform if he installed a "pack of Mongrels" and ran again.
