Posted by Doug
Mon, 21 Jan 2008 13:49:00 GMT
Friday was my last day at the company that won’t let me blog about them. I am very excited to be 100% independent freelancing! This has been a goal of mine for many years and it’s finally come true.
This morning Mark Windholtz is coming over to pair with me on a contract we share. It’s his good for not making me commute on my first day of independence. I’m looking forward to working with him and several other independent developers.
Hopefully now that I’m not under corporate thumbs I’ll be able to blog more about the types of problems I’m seeing and methods for overcoming. I’ve specifically been asked to write an article on my experiences working remotely on a Scrum project.
In addition to writing more, I’m also hoping to be able to contribute back to the open source community. It’s tricky when your family depends on your billable hours to also give your work away. However, I think it’s good balance to work on things my clients require as well as things I’m interested in. At first, this is likely to be helping Phil Hagelberg shape up Emacs for ruby development.
So, there you go. I’m going to be working with some good guys; doing more writing; and working on more open source. Wish me luck!
Tags consulting, emacs, family, Rails, Ruby | 4 comments
Posted by Doug
Wed, 08 Mar 2006 13:43:13 GMT
At last night’s XP Cinci we did an interesting exercise called “The Fishbowl”. Mark Windholtz setup his powerbook with a terminal, Safari, TextMate and a time tracking application he had been working on. We then each took turns pair programming on the big screen. While there were two of us “at the console” all the time, we swapped one of them out every 10 minutes.
The exercise was interesting for several reasons. Mostly it turned out to be a good example of what test driven development looks like in Ruby on Rails. The skill level of xp-cinci is split pretty evenly. About half of us have done significant RoR development and the other half is either just interested or just learning. Regardless of skill level though, no one was going to code in public at an XP meeting without writing tests. The best way to learn TDD is by doing. Until you’ve lived through the development cycle of TDD it’s hard to really grasp what it feels like.
The other benefit from the exercise was a fairly lively discussion on “this is how we do it in Rails” versus “this is what I’m used to in Java.” Most of xp-cinci comes from a strong Java background. Even though about half of us are “ruby nubies,” pretty much everyone has a very strong developer background with one technology or another. Here’s a for-instance. I coded up a method that used MyModel.find_by_id(params[:id]) and was asked why I used find_by_id rather than just find. I said that I liked how find_by_id returned nil so I could use it as a false value when doing error checking. As a long-time Java smart-guy, Ed Summerfield was pretty quick to jump on this as a bad practice. He demonstrated how his Rails controllers looked using begin and rescue. I’m not entirely convinced that assigning nil to an object as a fail condition is bad, but his code looked fairly neat with all his error trapping in rescue blocks.
While the skill levels of various members varied, our application we worked on wasn’t really the typical “hello world” style application of tutorials. We started with a working application. Mark and Scott are actually using the application as part of their consulting work at Rails Studio. This gave us the chance to work in a more “normal” fare. We had an existing database we were migrating; we had existing code we had to live within; and we had a “real” customer looking for “real” improvements to their application.
Last night’s meeting was different from our usual fare. It was back to a hands on style where we actually wrote code. While we didn’t get very far in terms of feature points, I think we made a lot of progress in general understanding of both coding practices and Rails development. I hope we continue doing more and talking less.
Posted in Programming, Test Driven Development, Ruby on Rails, Community | Tags Cincinnati, Rails, Ruby, testing | 5 comments
Posted by Doug
Thu, 02 Mar 2006 15:00:00 GMT
If you’re a one hacker shop doing Rails development it’s no big deal to store all your database usernames and passwords in config/database.yml. When you’re part of a team all hacking on the same code it becomes a little more complicated. This is my humble solution that I’m sure dozens of folks have already thought of.
This is the ugliness of the default generated config/database.yml:
development:
adapter: mysql
database: rails_development
username: root
password: my super secret password
So let’s say we have one master config/database.yml checked into svn and each developer modifies the file with their own username and password. Now we’re stuck with the risk of each developer accidentally checking in their working modification of that file. Also, do you really want your production database username and password stored in svn?
This morning I had an epiphany. Thanks to Rails 1.0 we can embed ERB into the config/database.yml. Usually I only think of doing things like outputting environment variables and the like. It occurred to me this morning you can put arbitrary Ruby inside the config/database.yml.
First we have to restructure the yaml:
login: &login
username: defaultuser
password: defaultpassword
development:
adapter: mysql
host: localhost
database: foo_development
<<: *login
I learned that syntax from the Typo guys. It basically lets you name blocks and then reuse them later in the yaml file. You probably see where I’m going with this…
login: &login
username: defaultuser
password: defaultpassword
<%= file = File.join(RAILS_ROOT, "config", "dblogin.yml")
IO.read(file) if File.exist?(file) %>
development:
adapter: mysql
host: localhost
database: foo_development
<<: *login
What this will do is insert the contents of config/dblogin.yml if it exists. This allows each developer to have a separate file in their working dir with their personal db login information. Further, you can svn propedit svn:ignore config to tell svn not to complain about the unknown file dblogin.yml.
Posted in Ruby on Rails | Tags Rails, Ruby | 8 comments
