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
Posted by Doug
Tue, 03 Jan 2006 16:56:01 GMT
I am so excited about this New Year! I was diligent about learning Ruby on Rails in 2005 and getting some practical experience. In 2006 I’m ditching my current gig as a Unix Systems programmer and taking a new job as a full-time Ruby on Rails Web developer!
As of this week I’ve gotten two production sites running with Ruby on Rails. One is a significant effort of more than 3000 lines of code. It took me most of the year working part-time hash out all the requirements and deliver the finished product. I know there’s more to come on this site, but I’m glad to finally have something in production.
The other one I cheated on. A client wanted a new feature added to an old site. I was loath to go back into that code because it was so messy. So, I re-wrote the whole site in RoR and added her new feature. Time “lost”? About 25 hours and 350 Lines of Code. That is exactly what Ruby on Rails is all about!
Now for my big news. Let’s talk about my ideal working conditions:
- Company that uses agile methodologies.
- Company that sanctions and uses Ruby on Rails.
- Mostly telecommute that doesn’t require me to relocate my family.
- I get to use a Mac with no questions asked.
- I get to work on a project that closely aligns with my hobbies and passions.
Check, check, check, check, and check. I’m not going to divulge all the details right now. The company hiring me hasn’t really made a public announcement about their use of Ruby on Rails. What I can say is I’ve always wanted a job like this but felt like it was beyond my reach. When you’re young and just out of college it’s much easier to make sacrifices to take the “dream job”. The further out of college you get, the more responsibility you have and the harder to just Do It.
This job allows me to follow the dream without sacrificing my family. I truly feel this is a gift from God. I realize many of my readers don’t believe in God and just got a sour taste by my saying that. However, I feel strongly that I need to give Him public credit for this job.
I have tried for years to find a job like this without success. Honestly, it’s been quite discouraging. Since early Fall I have been actively pursuing some way to work with Ruby on Rails full time without success. In fact, my best prospect was a job about 30 miles away doing Perl application development. Two years ago I would have loved full-time Perl. Now I was feeling “resigned” to taking it. Then out of the blue came this position. Two weeks later and I have an offer.
I’m not going to try and explain how or why God orchestrated this. I do want to give Him thanks though. All good things come from God. I’m very excited about this job. I know I can do a good job. One of my top goals for 2006 is to “go above and beyond” to demonstrate why I’m exactly the guy they wanted.
Posted in Internet, Christianity, Ruby on Rails | Tags jobs, Rails, Ruby | 10 comments
Posted by Doug
Wed, 30 Nov 2005 16:46:51 GMT
This Slashdot article made me laugh.
Should I write comments? What is a good comment? ... I instead suggest commenting in haiku.
I’ve actually been thinking about code comments lately. For starters, I hate those long journals in the top of source code that say what’s been done by whom; learn to use source control! Second, bad comments tend to live a long time. I recently went back to a project I had worked on five years prior. All my old comments were still scattered around the code like little essays on why I was doing what I did. Five years later, that stuff was meaningless. Comments typically don’t age well.
What I like about commenting in haiku is that it really makes you think about what you write before you do. You have to boil the essence of what you’re doing down to a few words. Of course, writing haiku is a good mental exercise in general.
So which is worse: comments about the code that don’t reflect all the changes that’s been made or unit tests that don’t pass?
I once dealt briefly with a development team that had an outstanding test environment. The lead programmer had a continuous build system that reported complete system test status. At the time that was pretty forward thinking and I was impressed. I recently visited with the same team and was disappointed the tests were being neglected. The new lead programmer had a printout pinned to his cubical wall from the last time all the tests passed like a trophy.
Maintaining tests can be cumbersome. I’m not going to deny it. I sympathize that the pressure of deadlines can tempt you away from tests. It can also be pretty annoying to have to make a bunch of tedious changes to bring your tests in line. I think of it like double-entry accounting though. All code has a test, all tests have code and the two should be in agreement. An accountant wouldn’t think of adding a credit to an account without adding a debit to the appropriate account. It’s how you know everything is in ballance. It’s comforting and reassuring to have a good test to code ratio that all passes. It gives you confidence to keep moving forward. When you leave tests that don’t pass, what’s a new guy to do? How’s he supposed to know which is right: the code or the test? I guess he needs to hope there are good comments about what the code is supposed to do. Of course, with my luck all three would be out of agreement.
I’d say about half of my debugging time on my Ruby on Rails projects is spent fixing tests. It’s an investment that pays off. I’m able to easily isolate the problems. Having the tests automated gives me pre-defined data to work with. I don’t have to spend a lot of time in setup to reproduce the bug; it’s right there in my test. Keep in mind that my overall debugging time with Ruby on Rails and TDD is much less than working non-TDD. I attribute my success with TDD and RoR to the high level assertion helpers. I find it much easier to write my tests in RoR because of the testing helpers.
For me, tests are better than comments. They properly demonstrate how the code is supposed to work. Tests make it easy to tell when they are out of sync with the code. Reading comments that disagree with the code can be a real stumbling block when trying to maintain systems. Sometimes comments and code are only subtly out of sync that may not show up for a while.
My suggestion is to always keep your tests at 100%. Don’t check in any code while tests pass less than 100%. If you have tests that don’t pass and don’t have time to fix the test I believe it’s better to delete the test. At least then a new guy can assume the code is correct until proven otherwise. I could be wrong about the deleting part. I just said that to be inflammatory! ;-)
Posted in Programming, Test Driven Development | Tags Rails, testing | 1 comment
