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
Posted by Doug
Thu, 13 Oct 2005 21:36:14 GMT
I thought it was a one off, but I’ve got several data classes in my Rails projects that aren’t derived from ActiveRecord. I’m using these to encapsulate some data and logic that doesn’t necessarily need to be it’s own table associated with some ActiveRecord model. Let me give a concrete example.
I now have three models that need to record a time. It’s not a DateTime or a Date. It’s just a time: “7:00 am”. I need to be able to sort these models based on that 12 hour time. I suppose I could have just stored the time as a 24-hour time integer. Even if I had done that, there still would have been some helper methods needed to convert to a 12 hour clock string. So, this approach seems as good as another.
WARNING: I’m proving to be pretty bad at naming classes. This example illustrates that point.
So I have a TimeString class. It’s got hour, minute, and ampm accessors. It also knows how to dump and load itself to/from YAML. My ActiveRecord models have special accessors to contain one of these TimeStrings. I have a before_save filter to convert the contained TimeString to a YAML string and save that in the database. In essense I have a column in my database that acts_as_object. I think a component to implement this feature would be generally useful.
The code looks like this:
class TimeString
attr_settor: :hour, :minute, :ampm
# some class implementation details
def dump
YAML.dump(self)
end
def TimeString.load(string)
YAML.load(string)
end
end
And it’s used like this:
class MyClass < ActiveRecord::Base
attr_accessor :time
before_save :save_time
def save_time
self.time_obj = self.time.dump
end
def time
@timex ||= TimeString.load(self.time_obj)
end
def time=(obj)
self.time_obj = obj.dump
end
end
This assumes you have a database column called time_obj. That column contains the YAML dump of the object. The time method is an accessor that returns a real TimeString object. The time= method takes a TimeString object and dumps it to the database column.
The technique is both neat and hackish at the same time. It’s proved to be useful. The pattern is fairly generic. This example uses my TimeString class that you may or may not think is necessary, but could really apply to any class you wanted to contain. The only thing that’s proved to vary is the obj= method on the ActiveRecord model. That varies based on how you want to be able to set the contained object. In some cases I want to pass in an already instantiated object. In others I want to be able to pass in some parameters to create the contained object.
I’m not exactly sure how to go about doing it, but I like the idea of converting this into an acts_as_object class method that would set up the appropriate stuff.
Posted in Programming, Ruby on Rails | Tags Rails | 2 comments
