Oh yeah, I produce a podcast now!

For some odd reason, it didn't dawn on my until now to pimp my podcast on my blog. It's called The Anachromystic Podcast and we've already got four episodes out. It's just me and my old friend Craig Walker talking about software development philosophies, techniques, technologies, and news. It's sorta half-way between Drunk & Retired (but not as salty) and StackOverflow (but not as much self fellating). It's on iTunes and plain old raw RSS. Please give it a listen and let us know what you think over at podcast@anachromystic.com. Thanks!

A better progress meter for your (Rails) scripts

As a follow-up to my post a couple weeks back on putting a progress meter in your long-running migrations, I've whipped up a more helpful and re-usable tool.

I've called it simply "Progress" and here it is in its entirety:

class Progress
  require 'action_view/helpers/date_helper'
  include ActionView::Helpers::DateHelper
  
  def initialize(total, interval = 10)
    @total = total
    @interval = interval
    @count = 0
    @start = Time.now
  end
  
  def tick
    @count += 1
    if 0 == @count % @interval
      sofar = Time.now
      elapsed = sofar - @start
      puts "been running for #{distance_of_time_in_words(@start, sofar)}"
      rate = elapsed / @count
      puts "at a rate of #{distance_of_time_in_words(sofar, (sofar - rate), true)} per item"
      finish = sofar + ((@total * rate) - elapsed)
      puts "should finish around #{distance_of_time_in_words(sofar, finish)}"
    end
  end
end

Usage is pretty simple. Here's an (slightly-abridged) example from a Rake task I wrote to clean out bad references to removed YouTube videos:

namespace :videos do
  desc "Remove videos from SpumCo if YouTube also removed them"
  task :purge => :environment do
    videos = Video.find(:all, :order => 'created_at asc')
    progress = Progress.new(videos.size)
    videos.each do |video|
      progress.tick
      video.destroy unless video.still_on_youtube?        
    end
  end
end

And what you see in the console as the script runs is periodic updates like so:

been running for less than a minute
at a rate of less than 5 seconds per item
should finish around 14 minutes

Scratching my own itch again leads to a new iPhone app

Several weeks back I was down at Barcamp Miami and I wanted to send a quick tweet from my iPhone. I have several Twitter clients on my phone - there's a bazillion of them out there - but most of them are very slow to start as they have to load all their fancy views and suck down all your friends tweets and blah blah blah. I wanted a small simple fast app that just let me post a quick tweet and be done with it. I couldn't find one, so I decided to write one.

Later that afternoon I discovered there was already one out there, for free no less, but I'd decided that this was a great entry-level application for me learn how the whole iTunes store process works, so I pressed on, determined to reinvent that wheel. I'd been dabbling with the iPhone SDK for months but things really kicked into high gear when I picked up Beginning iPhone Development; it's the book to get if you're new to iPhone and Cocoa development.

I wrote the app one Saturday evening, spent a few hours here and there afterwards rounding off the rough edges or applying things I'd picked up from the book (I'm still working my way through it). I asked an old designer friend and colleague if she'd create an icon for me and she agreed. I knew it would take her a bit to find the time to get the creative juices flowing, so I was in no hurry. It was time to start the red tape with Apple.

It's not a fun process. It's not a pretty process. But by gawd I have to give Apple credit for providing documentation that quite literally holds your hand and walks you through every last step of the grueling process. There were articles of incorporation to fax. Bank account routing numbers to supply. Certificates to be generated and signed. First born children to by sacrificed. It was hairy. But one glorious morning I opened up my inbox and found the "you may start uploading apps and selling them in the iTunes store" e-mail, and it was good.

I'd heard the horror stories of developers waiting months for their applications to be approved, and the stores of applications being rejected and resubmitted ad infinitum, so I had prepared myself for a long period of trepidation capped off with disappointment. When the shiny new icon arrived from my designer friend, I compiled my "release" build and uploaded my baby, praying everything would be fine. To my shock and awe, it was exactly one week later I received the "OK your app is on sale" e-mail. I was giddy.

I announced it to my friends and followers on Twitter and bless their hearts a lot of them bought the darn thing. Unfortunately I've not yet deciphered the financial section of the app store back-end so I have no clue how many copies were sold or how little I've made off it. The morning it went on sale, I received a support e-mail from a gentleman in Denmark who wasn't able to get it working. I haven't yet resolved his issue, and thus far he's the only person to report the problem, but I'm not one to rest on my laurels - last night I hacked up a few improvements and uploaded version 1.1 for review.

This isn't the iPhone application that's going to make me a zillionaire, but now that I've gone through the process and I've cut through all the red tape, I'm ready to start working on the real killer app.

Oh yeah, if you're feeling curious or just generous, please grab a copy for yourself. They're cheap while supplies last!

Laptop recovery with Twitter? Scratching another itch...

One morning last week a curious idea popped into my head:



... and that afternoon I had accomplished this:



The premise is simple:

1. I set up a private Twitter for just my laptop status, and subscribe to it from my personal Twitter account.

2. I set up a cron job on my laptop to run ever hour, tweeting the geographical location of my laptop to the private account.

The theory is that if my laptop were ever stolen and the crook for some reason didn't format it before connecting it to the 'net again, I might have a fart's chance in a whirlwind of recovering it. Yeah, probably not, but it was fun to build, and on the coolness factor I'll have an automated journal of my travels.

As an added bonus, Twitter automatically rejects duplicate tweets, so the account doesn't get spammed every hour if the laptop hasn't moved (since the updates would be identical).

So how did I do it? Well the first thing I did was realize that I couldn't get my public IP address from the laptop when it was behind a NAT router, so I had to reach out to find a service that could provide me that information. My initial Google attempts came up dry and I was about to resort to scraping the IP Chicken page (blech) when a helpful Twitter follower came to my rescue:



That service is exactly what the doctor ordered (thanks @nu2rails). I used HTTParty to parse the response and Jeweler to turn my little library into a gem and tossed it up on my GitHub account for the world to enjoy.

So please check it out, try it, fork it, improve it, and let me know how you like it. Oh, and extra brownie points if you get the name of the gem!

Twitter2RSS: Scratching my own itch at Acts As Conference 2009

The beauty of RSS is that I can aggregate all of my information sources, read them at my leisure without worry of expiration, and organize them however I desire. It's always bugged me that I couldn't have that luxury with Twitter. Sure Twitter has RSS feeds, but they don't include the avatars, and they don't include direct messages, and they commonly truncate the tweets (blech). There are some pretty slick clients out there, sure, but why would I want to run yet another application for just another information feed? Why can't I have my cake and eat it too?

Last week, while I was up in Orlando for Acts As Conference, I did the same thing I do at most conferences, I started another damn pet project. Except this time I also completed it during the conference. Thanks to my bud Bryce Kerley from the Miami Ruby Meet-up for giving John Nunemaker's Twitter gem a little massaging, I had all the tools I needed to alleviate myself of the aforementioned headaches and get my Twitter goodness piped right into my RSS reader.

It's a proxy server, running on Rails (perhaps a bit overkill of a framework for such a simple application, but it's what I know best) that sucks up your Twitter business using their API and spits it back out in a consumable RSS feed, with avatars, and without truncation.

If you want to run it yourself, I've opened up the source over on GitHub at github.com/trak3r/twitter2rss

Or, if you're too lazy or don't have a cheap hosting provider, you can use mine over at twitter2rss.anachromystic.com

Enjoy!

How to Launch 2 Sites in 20 Hours

Since I "became independent" exactly two months ago to the day, I've launched two pet project web sites: Pocket Rails and Rate Marina's Outfits. I tracked my time on each, just like I would for a billable client, and oddly enough they each took about twenty hours from inception to launch. Turns out it's pretty damn easy, and cheap too. Here's how I did it.

Get organized

I'm a "to do" list guy. Everything I do on a daily basis centers around "to do" lists. Whenever I think to myself, "I need to..." it goes straight on to the list. For these two projects I used Ta-da Lists. I created a new list for each project, and started adding "to do" items as I thought of them, and checked them off as I completed them. It's a great way to ensure you don't forget anything, nothing falls through the cracks, and it gives you a decent visual representation of your progress and how much you have left to do.

Get a domain

The first thing you need is a domain name for your site so people have a way to surf to it. You don't necessarily need a separate domain for every site; you can can host several sites on a single domain via sub-domains. For example, I registered anachromystic.com for my company then hosted one of my projects at marina.anachromystic.com.

I get all my domain names through GoDaddy. It's usually the cheapest, and it's convenient to manage them all through a single central service. If you plan on sending/receiving e-mail through the domain, I strongly recommend Google Apps for Business. It's dirt simple to set up, their tutorials cover every major registrar, and requires no maintenance.

Get a host

As the name "pet" project implies, these sites are hobbies. They are not generating any money, and it's not critical that they be up all the time and fast to respond. So I went with the cheapest host I could find, DreamHost. Pull up Google and search for DreamHost promo codes and try all the ones you find. I ended up getting an entire year of hosting for about $20 (that's for the entire year, not a monthly rate).

Choose a platform (Hint: Use Rails, dummy)

Not only is Ruby on Rails the best platform for getting a site up and running quickly, you can get a head start with a "base" application like Bort which comes with a plethora of pre-shaved yaks including registration, e-mail activation, log-in, password reset, pre-configured routes, deployment scripts, etc. It's not perfect - I had to tweak it a bit - but it saved me hours of laying the groundwork and let me get to the meat of the project quicker.

Use hosted source control

Why hosted? First of all, it's essentially a cheap back-up of your work. Secondly, it makes it a lot easier to collaborate if you're working with other developers. There's a billion to choose from, and if you're willing to let other people see your code, they're free. I decided to make the source for Pocket Rails open but keep the source for Marina private (for now). I'm a huge git fanboy so GitHub was the natural choice for me. My open-sourced projects are hosted for free and I pay a measly $7 per month for the privilege of keeping some of them private.

Test all the fscking time

If you aren't test infected yet, it's time to wake up. Testing demonstrates that what you've written works, and testing ensures that when you modify or enhance it you don't break any of the old stuff. Don't let yourself fall into the quagmire of, "I'll add testing later after I get everything working." You'll waste endless hours of debugging issues that could have been prevented with preemptive testing. But don't take my word for it, take the word of Bryan Liles.

Also, on a somewhat related note to testing, use one of the plug-ins and accompanying services like Hoptoad or Exceptional to track and alert you when something breaks on your site.

If you want to get hard core, and why not, install the New Relic plug-in which will track and report on the performance of your application, so you can find out where the bottlenecks are.

Automate deployment

Get automated deployment working from the get go. Don't save it for the end. You should be able to deploy your site from your hosted source control to your hosting provider with a single command. Capistrano is the tool for the job if you're using Rails. Open up a terminal window and type "cap deploy" and watch it all unfold. If that one command doesn't do everything you need it to, make it! For example, I deploy a lot, and Capistrano doesn't clean up after itself automatically, so I hacked it to run the "clean" command after every "deploy". It also doesn't run database migrations by default, so I added the "migrate" task to "deploy" as well. When you can update your live site with one command, you'll sleep better at night.

If you build it, they will come

Well, they wont actually come until you promote it, but that's a later section. Once I had all the aforementioned steps in place, I buckled down and coded. My Ruby and Rails skills were a little rusty, so I'd occasionally have to visit a documentation site like APIdock or search for an issue on Google or as a last resort post my problem on gist then tweet the link on Twitter (thankfully I have quite a few smart and helpful Rails guys following me).

Package your dependencies

Don't expect your hosting provider, or the next developer to work on your project, to have all the necessary third-party dependencies for your project. Package them up with your application if possible. In Rails this is pretty simple, just declare the gem dependencies in your environment.rb file then rake gems:unpack to extract them locally. Do it for Rails itself too, and don't forget to add them all to source control.

Track it

If you want to know how many people are visiting your site, how many pages your site is serving, which page is the most popular, etc., you need to track it all. The quickest, easiest, and cheapest way I know of accomplishing that is Google Analytics. Create a profile for your site and they will generate a little snippet of JavaScript code to paste into your pages. Assuming you have a template that's common to ever page on the site (like a header or footer), that's the logical place to put it. Google will track everything for you and give you some super slick reports.

Tell people about it

Once you've got your new site coded, tested, and deployed, it's time to draw people to it. People aren't likely to find it on their own, so you need to announce it. With Pocket Rails I first started tweeting about it on Twitter. This attracted a few visitors and provided some initial feedback. Once I'd ironed out a few kinks I shot an e-mail over to the guys as the Rails Envy Podcast explaining what I'd built. They seemed to like it and mentioned it on their show. That drove a sizable burst of traffic which quickly died off. A week later I posted the link to reddit for ruby hackers and holy macaroni the site was deluged with visitors, and I began to see other people talking about it and linking to it thanks to tools like Google Alerts and Twitter Search. I added their RSS feeds to my news reader so I can keep on top of the chatter.

Finally, blog about it

Hey, my blog post about launching your site is recommending you blog about launching your site. How meta is that? It makes my brain hurt a little. But seriously, share your story so others may learn from it, as I hope you've learned something from my story. I'd love to hear your comments and criticisms, perhaps you'd have done something differently.

Rate Marina's Outfits

Yesterday I soft-launched my latest pet project, which I wrote on New Year's Eve of all nights, with graphic design graciously contributed by Allan Branch of Less Everything.

What is it? Well, for those of you too lazy to click the link, it's essentially a mash-up of YouTube and the Ajaxful Rating plug-in for Ruby on Rails that lets you rate the outfits worn by Marina Orlova on her popular webisode sensation HotForWords.

Why did I write it? To get rich and famous, of course, right? Ha, no. I wrote it because I've been interviewing for new gigs the last couple months and I keep getting asked for sample code that I've written. All the projects I've worked on for the last decade have been private and proprietary code bases, so I can't share them. Now I have something to share. For now I'm only sharing the code with potential employers, but I do plan to release it to the public in the very near future.

If you like what you see and you're looking for a solid developer (remote only, sorry, no relocation) please give my resume a peek. Thanks.

How Awesome is it to Work for Me?

WARNING! Gratuitous and shameless ego stroking below...

With my current employer, there are two formal events that call for an employee to comment on my performance as a boss: the end of their hiring probationary period, and their exit interview. Here's a collection of excerpts from both events - recorded by the human resources director and reported back to me - that keep me coming into the office day after day no matter how bad things get:

"Ted runs department smoothly"

"Likes that Ted is a manager but a developer too"

"He would recommend this as a place to work because of Ted"

"Likes the once per week meetings with Ted re[garding] the knowledge of the system"

"Thought Ted was the best in caliber and by far the most knowledgeable person he has every worked with/for" [I swear that's verbatim!]

"Liked when Ted moved on the floor – brought humor and direction" [referring to a time when I voluntarily left my comfy corner office to join my team in cubicle land]

"Said he preferred the B2B team – likes the structure of the B2B build – more cohesive and easier to work with" [referring to the time when I was running the B2B team while somebody else was running the B2C team]

1 is a Beautiful Number

1 Machine
1 Person
1 Day
1 Document

That's all it takes to deploy a large commercial web-based application I designed seven and a half years ago which today is still running and serving millions of pages a day for a dozen of clients so large and well-known I'm contractually prohibited from disclosing their names.

Every time I hire a new developer, their first day on the job is spent building the system from scratch on their workstation: 1 machine, 1 person, 1 day, 1 document. The most recent hire set a new record and had his system operational by lunchtime.

I attribute this accomplishment to mainly two mantras: "no fringe tools", and "the build document must stand alone".

No fringe tools means we don't use the latest and greatest one-offs or widgets just because we can. The old cliche of "the best tool for the job" breaks down when you have thirty jobs and thirty tools to master and maintain. If one tool does five jobs "good enough" then you've saved yourself a headache in staffing and training and documentation and licensing and on and on and on.

The build document is the bible in my organization. My colleagues know that I'm not one for formal documentation in most cases, but the build document is the exception. That sucker is kept up to date (the responsibility of each new hire that has to follow it) and it's kept simple. It doesn't gloss over any details and it doesn't defer to other documents. When it starts getting too long, too verbose, including too many diagrams and appendices, it's time to simplify.

So what inspired this burst of braggadocio?

By contrast, a friend's organization is currently deploying, or attempting to deploy, a web-based application with a nearly identical feature set which thus far requires nineteen separate physical servers for operation. Configuring this beast has required the consultation of three separate agencies (including the vendor). And, the grunt work of actually installing it, setting it up, and getting all the pieces to communicate and play well together has required the coordination of a half-dozen people from five different departments.

As I type up this rant, it's late into the evening, and the e-mails are still flying, and the system is not yet churning, and all I can think of in the back of my mind is, "1 is a beautiful number."

Ted Driven Development

Earlier this year, I was helping an old friend weed-out candidates for his latest Ruby on Rails venture, adPickles, and in the interest of cutting to the chase and letting the potential hires know what they were getting themselves in to, I sent them the following manifesto:

I just wanted to drop you a note to give you a little heads-up on the way they run development teams, so you can comment, inquire, or run screaming for the hills :-)

* TDD

First of all, they're a huge proponent of Test Driven Development (TDD). They aren't always faithful, but they enforce it as much as they can, and when you see the code that has been written so far, you'll see that there's a veritable butt-load of tests.

They haven't yet incorporated any sort of test coverage metric, but they do rely on autotest, which re-runs all of the appropriate tests every time they change a line of code. This tool is invaluable for catching all those "oops I didn't expect this to break that" moments.

If you commit code to the repository that fails a test, your humiliation will be merciless :-)

* DDT

Likewise they are adamant about Defect Driven Testing (DDT). Whenever the Big Boss Man shoots a developer an e-mail saying "hey I think I found a bug" the first thing the developer does is write a test to reproduce the issue. That test becomes a permanent part of the application test suite so that particular bug will never again sneak back into the application without unnoticed. They will expect you to do the same every time you are asked to fix or change something.

* Branching

If you don't know how to handle branching in Subversion, now is the time to figure it out :-)

Every time they take on a new developer, they insist that the new hire perform all of his development in branches rather than directly in trunk, until such time as they trust them to interact directly with trunk, or until the team grows so big that working directly with trunk is simply taboo and they all work in branches. This ensures the purity of the code base.

* Commits

One commit per change. If you have three items on your TODO list, you do one then commit, then another and commit, then the last and commit. You don't do all three at once and commit one big chunk of changes. Why? Code reviews...

* Code Reviews

They use Trac for code reviews. If you've every poked around the Rails core site you've seen this tool. The changeset feature gives them a nice purty color-coded "diff" of every change you made for each commit. This is why they insist on one change per commit. This allows them to review your work on a clean per-ticket basis. Your work will not be merged back into trunk until they have code reviewed and approved it.

* Referential Integrity

Just a side note here. I believe in foreign keys. If you've dug deep enough in my blog you'll see that DHH and I disagree on this issue, and if you saw/heard the keynotes from RailsConf last year [ED: referring to RailsConf 2006 in Chicago] you'll know that I'm not alone in my disagreement. This project has referential integrity in the database, which they achieve through a plug-in. You'll see this if/when you come on board. [ED: I later changed my stripes on the matter, during RailsConf 2007 in Portland as a matter of fact.]

* Deployment

They use Capistrano for deployment, and for now only the lead developer performs deployments.

When you finish up some work and it needs to be reviewed by the president, you'll let the lead developer know (through Trac). He will then code review it and (if he approves it) merge it into trunk. He will then deploy from trunk.


That's the basic gist of it. If you have any questions, comments, or concerns, please let me know. Thanks for your time.

How do you become an Architect?

During an interview yesterday a candidate told me he had aspirations of becoming a software architect and asked me how he should pursue it. That question caught me off guard. I considered my personal career history and came up with this little nugget:

Always be the guy in every meeting with the best design idea.

That's pretty much how it worked for me. When you're sitting in a room with your colleagues and peers, discussing and debating how to solve a particular problem, and you consistently present the best ideas, the ideas that get implemented, you start to build a reputation and credibility. The next thing you know, you're The Architect. I expanded on the idea with this:

Be able to recognize and vocalize the pros and cons of every idea.

Not just your own; other people's ideas as well. If you can tell them, in a polite and constructive manner, what's wrong with their idea and how it might hurt them in the near or far future, they will [if they're not a complete jackass] thank you for it, and come to you the next time they want a Sanity Check.

But how, you might ask, do you become the guy with the best ideas? Read, read, read! I am a bookworm. I read books on design patterns, frameworks, methodologies, programming languages, antipatterns, usability, etc. If you can grok it and regurgitate it at the appropriate times, you'll be The Idea Guy.

That's how it worked for me. Your mileage may vary.