Halogen Labs

Just futzing with the layout of the site. Not that anybody reads this thing anymore :)

Not a lot going on. I had a very busy spring. The house almost burned down. Summer was busy too, as well as fall. Hopefully I can relax this winter :)

Scope me on Twitter.

More later.

One of the first things I’ll do when working on a new project is to automate the build ASAP. Starting a new job a couple weeks ago, I took the opportunity to get CruiseControl.rb up and running and getting the tests running reliably.

At my last job, we had automated the build by having CC.rb run rake db:migrate followed by rake test. This worked out fairly well, and we made it a practice to peer-review all migrations before committing them.

This technique had a few drawbacks, however. One thing was that we were testing our migrations. If someone committed a migration that broke, the build would fail. Likewise, if someone committed a migration and then needed to change it later, we would have to manually roll back the database and re-migrate up, which was a pain in the butt.

Having the build run the migrations was nice, since other developers would be alerted to a potentially bad migration, but it ended up being more trouble than it was worth.

At my new job, there’s an established practice of using migrations to add static data to the database (which is the subject for another post). Migrations are an easy way to do this, but you run into trouble if the data being added depends on other data in the database, or if the migration was bad.

I’m of the opinion that you should avoid hitting the database as much as possible during tests, and by running migrations during the build (especially ones that depend on static data in the database), you end up coupling yourself even more tightly to the database.

After thinking about it for a while, I’ve decided that the schema.rb file is, after all, the de facto source of the database schema (big DUH here). Therefore, each build should wipe the the test database clean of tables and then load the schema.rb file from the repository.

Our new rule here now is that if you check in a new migration, you must also check in the new schema.rb.

By doing this, we consider migrations a tool for communicating small changes to developers over time, and we have a reliable, repeatable way to load a fresh db schema into a new development environment.

Google Analytics can help you in a lot of interesting ways sometimes. Recently I noticed my traffic had dropped to zero:

What does this mean?

1. Nobody’s visiting the site
2. Web server died
3. Google stopped indexing my site and stopped referring links to the site.
4. Sky is falling

I knew the first option wasn’t the case since I usually have a low level of “background radiation” traffic even when I’m not posting. I knew for a fact my web server was up. I checked my robots.txt file and it was fine, so WTF?

Well, after checking my page source, realized I blew away my old Google Analytics code in the Wordpress Template, and the only thing that Google Analytics was reporting was the fact that I didn’t even have it installed!

Two weeks ago this past Wednesday, I gave notice to my former employer that I had accepted a job from a local company as a Software Engineer. It was a hard decision to make; just over eighteen months ago I had written about getting the job which basically amounted to a “dream job” situation. I was working with Rails, doing cool stuff with weather and mapping.

The only catch was that it would be 100% telecommuting.

After eighteen months, I pretty much had it firmed up in my mind that telecommuting, and the lifestyle associated with it, wasn’t for me. Before accepting the job, I had done a ton of research into what it would take. Telecommuting isn’t for everybody, and when I would tell people that I telecommute, the usual response was something along the lines of, “Wow, that must be nice!”

It was nice, but the drawbacks didn’t really become apparent after the third month.

If you’re considering telecommuting, there are a lot of things to take into account, especially if it’s going to be 100% of the time.

Keep work and personal space separate.

This is probably the most important item here. Dedicate a room to your home office. Don’t share it with existing space if you can. Keep work and personal space separate. Resist the urge to be in the office space “after hours” if you’re doing casual web browsing, email-checking or whatever.

You never really leave work.

It’s too easy to walk into your home office after-hours and work. Bored? You can sit down and work.

You never really leave home.

The flip side of this is that you’re always around the house. Bored working? It’s almost too easy to go play some Guitar Hero or fire up the Wii. You’ll have to be immensely disciplined to get work done.

Don’t become a hermit.

Socialize. You’re around the house more, which means you don’t have a lot of people around to talk to. Not long after I started telecommuting, I noticed a shift in my personality. I’m already an introvert, but being isolated from people seemed to make it worse. I generally felt more awkward around people, and it was harder to socialize and relate to people in general.

Be aware of time shifts.

Because the home office was in Denver, I generally got started one hour later than if I were working locally. This also meant that I worked an hour later as well. Sometimes this would throw off things like eating dinner or going to bed. This can obviously affect your family, so make sure they understand why you’re getting up late and staying up late if this happens.

Get a separate phone line, and use it.

If your home phone line (or cell phone) becomes your lifeline to the office, it’s even more important that your coworkers understand this setup. They shouldn’t be calling you at home on Saturdays.

One of my bigger challenges with telecommuting (especially as a software engineer) was that much of my communication with my coworkers and colleagues was over email or IM. Looking back, I wish I had a separate, dedicated work line, and that I used it more. It’s much, much easier to communicate complex thoughts and ideas over the phone, compared to email or chat. Don’t be afraid to fire up the phone.

Get a headset for your phone.

We would have weekly engineering meetings, and status meetings with our client quite often. Having a headset that I could plug into the phone was very useful, mostly because it kept my hands free for typing on the computer.

Make your employer pay your bills.

Ideally, your employer should be paying your landline or cellphone bills. They should even be paying your cable or DSL bills. After all, they are saving quite a bit of money by not having to maintain physical office space an other facilities for you. I made the mistake of not getting my phone and ISP bills expensed, and wished I had gotten it taken care of from the start.

Investigate the tax benefits of a home office.

If you have a room dedicated to office space, I believe you can write off a percentage of your taxes based on what percentage of the house is being used. I’m not a tax expert, but I highly recommend looking into writing off what you can.

Jem Matzan has a damning article entitled Subject to shill: tech books as corporate marketing in which O’Reilly and Adaptive Path are panned for producing.. well, crap:

The book’s primary content reads like a marketing pitch for Adaptive Path services. It’s packed with enthusiasm but entirely devoid of substance. There are whole paragraphs that meander around non-specific subjects, one leading into another until you’re pretty sure you’ve got the gist of what the authors are trying to say, but you have no idea how to apply it to your business.

It’s too bad that the book comes out as a fairly transparent marketing ploy. Several of my friends and colleagues agree with me in the opinion that the quality of O’Reilly titles has gone down over the past few years. The last book from O’Reilly that I have bought was the Information Architecture book, but that was fairly recent.

I am also reminded of the Adaptive Crap image from 2001.

I’m a huge nerd for books, and Amazon only makes it easier to obsess.

Amazon’s “Search Inside” feature is pretty handy, but once you page through a few pages, you get stuck, so it makes it hard to get a good sample of the book before they cut you off.

More often than not, you can page through the Table of Contents, find a section you want to look for, and then search for that page number.

Once you page through a few pages, you can search for the page you left off on, until you hit their hard limit of page views for the day.

Ok, all the kewl kids are using hg or git these days, but I just stumbled across an awesome plugin for TextMate called SVNMate.

One of my biggest problems moving to FT Rails development with TextMate was a lack of status icons that told me what I had modified. Coming from using Eclipse, I felt like my commits were sloppier and I was more prone to break the build due to missing a file checkin.

SVNMate gives you file status icons in your project drawer, so you can tell at a glance what has changed.

Recently, my MacBookPro decided that the only way I was allowed to open .DMG disk image files was by manually starting Disk Utility.app, and opening the DMG file from there.

I finally discovered the solution: Simply do a “Get Info” on any DMG file, and set the default application to DiskImageMounter.app, and your problems will be solved.