has_many :thoughts

The theme of the first two talks I attended at RailsConf today was more business-y and less technical. There was a chat called “Teascript: A Homesteader’s Story” and one called “The Business of Rails”.

The former was a case study by a developer who decided to make his own niche web app and start selling a service around it. The content was interesting, however the talk itself was frustrating as he took all manner of questions all the time and there were zillions of interruptions with dull questions.

1. Get the idea out there fast and start getting feedback. This has always been my view, as opposed to bottling it up fearing that someone will steel your idea.
2. Read 37 Signals book, Getting Real. Apparently this is the bible of developing web apps the Rails way. I was ashamed when a show of hands indicated nearly everyone had read this book except me.
3. Start small. The speaker discussed the benefits of starting your application small with only essential features to get it out there. I’ve been thinking more and more this is the way to go so I was glad to hear this point.

The latter was a panel discussion with open questions from the audience and a panel of owners of Rails development shops large and small. This one was a bit dry because a lot of it was about how to quit your job and take the plunge. Which I did 6 years ago now.

Believe it or not there was actually a talk about how to read code. There’s more to it then I realized and there were some interesting handy tips presented, although there wasn’t as much actual substance to this talk as I had envisioned. Here’s some tips:

When reading ruby or Rails code beginners often might not even know where to start. Here’s a pretty good track to follow:

1. Read the URL of the page in question. In simple apps that aren’t using fancy routes, the URL will tell you the action/controller.
2. Check out the routes.rb file for any fancy route configurations to find the controller/action.
3. Open the controller and find the method. Read through it.
4. Look for any filters on the controller. Usually declared at the top. Find them and see if there is stuff running before or after your method.
5. See what methods on the model are invoked and read through the model method.
6. Look for callbacks on the model. Stuff like before_create can add functionality that you might not have realized was there.
7. Application controller and application helper files often contain other stuff you should look through before doing any spelunking.
8. Seek out observers. Often declared in environment.rb and residing in the models folder, these are callbacks that often attach themselves to multiple models.
9. Plugins and libraries in /lib are good to look at, too.

1. Check for normally defined methods
2. Find any method_missing implementation
3. Grep through files for any metaprogramming like define_method.

This talk was excellent and provided some insight as to how we can start writing tests on the apps we haven’t done jack with when it comes to testing. Since this is one of my main goals for our team in the coming months, I found this talk quite informative. Some tidbits:

1. Having no tests at all doesn’t mean you can’t start writing them.
   • It’s really not that hard to get started writing tests. Rail scaffold will actually generate tests out of the box although the speaker implied they are not very good and might actually even break.
2. Write a test every time you refactor
   • If you are following the principal of putting that extra 10% of effort in to refactoring or improving some other portion of code at every single check-in, you have ample opportunity for writing beginning tests.
   • Simply create a test that passes under the current code, then refactor the test, and ensure the test still passes.
3. We should use RSpec to write tests
   • Since we’re just getting started with TDD and writing tests at all, we should start with a tool that of people seem to think is superior to Test::Unit.
   • RSpec allows people to write tests in a domain specific language that makes the tests read better and make more sense.
4. There are some really handy tools available to help us test and help us test our tests.
   1. rake stats
      • The rake stats output will show you a ratio of lines of code to lines of tests. You want to have a higher ratio because that means you’re writing a lot of tests.
   2. rcov
      • Rcov is a neat tool that will run your tests and show you lines of code that were not tested.
      • With an output similar to the cvsspam diff output that highlights lines of code that the whole body of your tests didn’t run.
   3. Heckle
      • Heckle is tool that sounds pretty damn cool. Basically, it fucks up your code and then tells you if your tests failed like should have.
      • Essentially, it changes variables, swaps if statements, and generally wreaks havoc on your code, one item at a time, running your tests each time.
      • At the end, it tells you what tests still passed after stuff was changed and shows you what it changed. By examining this, you can determine what stuff might be tested properly.

I’m pretty anxious to start testing and I think I’ll try out some of these techniques on Find Mini Golf tonight.

I just saw a talk by Robert Martin called “Clean Code” that was pretty eye opening. He walked through the process of coding a small app that parsed command line parameters. He demonstrated a rather common process of creating a small application with a specific function that, when requirements change, can quickly and easily morph into a mess of unmanageable code.

This is a problem we encounter often and was one of my main complaints the ASP applications that we were churning out. We can’t do anything about clients changing requirements, but we can do something about how we keep up with them.

A few points to take a away:

1. Writing clean code is more important than you think.
   • It often seems like a better choice to just get the app done, and worry about the details later. But later almost always requires more work.
2. Test-first development is the way to go.
   • The speaker is an agile development consultant and so he advocated test-first development, of course.
   • It was pretty clear to me that refactoring becomes a lot easier, because you can do it with confidence, when you have tests that can ensure that your code still works.
3. Improve code every time you check in.
   • When you add some functionality to an app, make it a habit of always improving something else at the same time.
   • A small investment of say, 10% additional work, every time you commit code, of improvement and refactoring of other code will go a long way to improving the app overall. Again, you can do this more confidently when you have tests.
4. Reading other people’s code is a great way to learn.
   • It was pretty interesting to read someone else’s code and learn how they would approach a problem. This is why things like Ruby Quiz are so helpful.

The moment all Rails fanboys have been waiting for has come and gone: Rails inventor David Heinemeier Hansson has just concluded his keynote speech. Among topics covered, was the various enhancements to Rails that will emerge in version 2.0.

Of particular note to me was his statement that the pace of releases for Rails will continue to decelerate. As I’ve noted on this blog before, I’ve been concerned about the frequency of releases and deprecations.

Here are the highlights:

1. Debugging is fixed
   • The Ruby breakpointer stuff has been fixed. You can now type “debugger” anywhere in your code and it will dump you into an IRB session where you can inspect objects and more.
   • New to this version is the ability to inspect code right from the irb session, jump up and down the call stack, and view stack traces.
2. Focus on HTTP performance
   • An increased focus on HTTP performance will bring a few features.
   • javascript_include_tag :all, :cache => true will take all your javascript files and combine them into one, gzipped.
   • Some simple code in your environment.rb can allow your app to use multiple host names (www1.yourdomain.com, www2.yourdomain.com) which increases performance because browsers only download 2 resources from the same host simultaneously.
3. ActiveRecord query caching
   • ActiveRecord can now optionally cache queries. For instance, if you do a select from a database and no updates or edits happen to that record before another similar select is requested, ActiveRecord will pull that record from the cache.
4. View file naming conventions
   • .rhtml now becomes .html.erb.
   • The idea here is that the first extension is the form (.html, .xml, .atom, .text, etc.) and the second extension is the templating provider. (.erb, .haml, etc.)
5. Environment.rb consolidation
   • Some junk about uncluttering stuff in environment.rb that I didn’t full understand.
6. Migration changes
   • Migrations have historically ended up rather repetitive, especially, when you have a lot of columns in a table you are creating.
   • The declarations now get flopped so you now do t.string :first_name, :last_name, :company rather than t.add_column :first_name, :type => :string x3.
7. Authentication upgrades
   • Rails 2.0 embraces HTTP authentication a bit more.
   • Although HTTP auth sucks for a lot of stuff, it is useful for clients that are pulling XML, etc.
   • An app could now allow authentication over HTTP for retrieving data in certain formats, and require application-level authentication for other resources.
8. MIT license
   • Just more “opinionated software” stuff showing through: The plugin generator will now include the text of the MIT license by default.
9. Cleaning up shit
   • Stuff that’s been deprecated for a while will finally be axed.

I was searching for a brew pub out here at RailsConf last night and the hotel concierge pointed me to a place at Broadway and 15th. I started in that direction and realized that it was about 10 blocks away and I was hungry. When I happened upon a place called BJ’s that had pizza and beer, I walked in, expecting to mosey up to a bar and plant myself for a little while.

However, two smiling people in Rails shirts said “Welcome! You’re just in time! The buffet just opened up and here’s your free drink ticket.”

Wow, okay, cool. Free pizza and beer. I thought about questioning it, but there were dozens of other Rails fanboys seemingly enjoying free pizza and beer. I had a few slices and an okay IPA, and was on my way with free dinner.

I later googled around and discovered it was a Pragmatic Studio Alumni Dinner for those that have attended their Rails Edge and other seminars.

So, sorry, Pragmatic Studio. And thanks. Maybe you should have had a sign? Or a ticket to get in? Or something preventing any joe from walking in off the street and steeling your food like I did?