Book Review: What Got You Here Won't Get You There

The premise of this book is the cut-throat no-mercy end-justifies-the-means killer instinct that got you where you are today (upper management) is paradoxically going to prevent you from climbing that final rung of the ladder to becoming a successful top dog CEO. The author preaches - with anecdotal parables cherry picked from his vast clientele - once you reach the pinnacle of your career you need to change your competitive ways and be more nurturing to and supportive of your staff rather than using them as stepping stones to success. He builds a nice long list of traits and behaviors to be cognizant of changing, such as taking credit for the work of others, always adding your two cents just to assert your authority, showing favoritism to employees, etc. He outlines his technique for breaking potential executives of these habits, interviewing the subordinates to determine which areas need the most attention, and making the 'patient' actively participate in the exercises of periodic self review. It's one of those books where each chapter you read you think, "Ha, I knew a guy like that!" but you rarely think, "Ooh he's talking about me here." If you're in upper management and you're having trouble reaching the next level or you've got turmoil with your peers and employees, it might be worth cracking this book and doing a little self evaluation.

Book Review: The 4-Hour Workweek

I added this book to my reading list a long time back but kept bumping it down in priority because I expected it to read like one of those get rich quick infomercials you see in the wee hours of the morning when most sane people are sleeping. I was pleasantly surprised to discover I was dead wrong, and the timeliness was uncanny as I was "downsized" from my employer of nine years shortly after I cracked the book (metaphorically speaking - I read it on my Kindle).

The general gist of the book is retirement is a scam; you're saving money for when you're too old to spend it and too feeble to enjoy spending it on adventures like traveling around the world. The author recommends you start taking mini-retirements right now, while you're young and energetic enough to carpe diem.

He expands on this by pointing out that living like a millionaire doesn't require being a millionaire. Instead of focusing on making a million dollars over the next twenty years, focus on making just enough money to take the adventure you desire as soon as possible, like three-thousand dollars to spend a month in Berlin studying the tango. Rinse and repeat.

How is this possible? The author goes to some pretty impressive extremes insisting that most of what you do during the day is bullshit busywork and if you quit it all cold turkey there would be practically no consequences. He preaches that you can start by answering e-mail twice a day, then work your way to once a week, spending just an hour on the task. You can send all phone calls straight to voice mail and hire by-the-hour personal assistants in India to handle all the minutiae of your day to day responsibilities, both personal and business. In short, it's delegation on steroids.

The end goal is to own a business and not run the business. The former gets to jet set around the world and party while the latter punches the clock and works themselves to an early grave. The author insists it's easier than it sounds and the hard part it just making the leap - I'm dubious, of course.

Regardless of the fantastic stories and extraordinary claims contained in the book, I still consider it a worthy read as at the very least it makes you think. It makes you reconsider what you do at work on a daily basis and reevaluate how much of it really makes a difference and how much of it is masturbatory. It also makes you wonder "what if" I did make the leap?

iPhone RDoc Template

I just made public my GitHub repository for a pet-peeve project: an RDoc template that looks good on the iPhone browser.

I used this template to generate the Rails documentation and you can check it out at http://pocketrails.com (visit it from your iPhone).

Articles that were never written

I was doing some spring cleaning of my filesystem this morning and I came across an old list of "potential article topics" from seven years ago when I was writing for JavaWorld. Many of them I eventually blogged about over the years, but here's a few gems I never got around to polishing:

"why linux guis are doomed; gui standards from apple, microsoft, sun, etc."

Having worked closely with Linux this past year, I can sadly say this still holds true.

"20 things about Java you never knew (or cared) about: the short datatype, goto keyword, int.class, java.lang.Void, etc. (re: craig)"

Apparently this stemmed from a discussion with my old friend and former colleague Craig.

"the big picture"

That's all I wrote. Apparently at the time I had "the big picture" but not enough time to write about it. Over the years I lost it.

"asp servlet follow-up (registry classpath, com object)"

Perhaps my proudest achievement as a bright-eyed ambitious young programmer was a bridge that let you run Java Servlets in IIS; no third-party engine required. I wrote about it in JavaWorld and the article was republished on IBM's developerWorks site (but was eventually deprecated, hence no link). Apparently I had a few follow-up topics worth discussing.

"array reordering trick"

I have no idea what the trick was; should have been a tad more detailed in my note.

"ejb abstraction layer (entity beans)"

This was referring to an abstraction layer I'd developed at my first dot-com for the original EJB spec in the late 90's. It's all long moot now.

I'm going to leave the list alone. Perhaps it will be twice as amusing when I read it again in another seven years... and by then I'll have forgotten about this blog post and I'll probably wax nostalgic all over again.

DIY Home Media PC Mac on the Cheap (free if you already have the hardware)

Last week, a friend of mine (wink wink) finally bit the bullet and cancelled her cable TV service and switched to entirely on-line content delivery for her viewing entertainment. Here's how she pulled it off.

Hardware

Mac Mini

She had an old Mac Mini (PowerPC) sitting in her closet collecting dust. Now it's sitting under her TV collecting entertainment.

Remote Control

I think all Macs now come with built-in infrared (IR) remote control support, but her old Mac Mini predated that standard. She already had an apple remote that came with her not-quite-as-old laptop, so she just needed the IR receiver. A quick Google suggested that Twisted Melon's Manta TR1 was the popular choice, so she picked one up.

Software

BitTorrent

If you want to download shared media you need a peer-to-peer client. She chose Transmission as it seemed to be the simplest and cleanest alternative for OS X and it has an option in the Preference panel to "Ignore unencrypted peers" which means any nosey gnomes in your pipes aren't going to be able to see what you're downloading.

Torrent Episode Downloader

Now that you have the means of downloading torrents, you need a way to find them. Enter TED (great name, by the way) which goes out and finds your shows for you, and keeps up on them, grabbing new episodes as they are released. Keep in mind that shows don't usually appear on the torrents until the morning after they air so you're not going to be able to participate in the water-cooler conversations at the office.

DivX

Most of the shows are encoded in a video format called DivX, which Quicktime doesn't natively support, so you'll need to download and install the freely available codec. Unfortunately it includes a lot of other crap, like its own proprietary player, but you can ignore or delete it.

Hamachi

One of the reasons she could no longer justify her cable bill is she's rarely home; she travels a lot. When she's on the road she likes to check in on her media Mac so she needed some means of communicating with it. If you've got the time and ambition, you can get yourself a hackable router and some open-source firmware and register a domain with a dynamic DNS provider and... blah, blah blah. She wanted something dirt simple. Hamachi is the right tool for that job; it's an idiot-proof virtual private network (VPN) system. You install it on your target machine and on any other machines you wish to use for remote access and you're golden.

Front Row

Your Mac comes with Front Row. You can use it to listen to music and view photos but what you really care about here is watching shows. If you configure the aforementioned torrent downloading tools to save their files into your Movies folder, Front Row will automatically find them. And, of course, you can use your remote control to run the show from the comfort of your couch.

Miscellany

Security

For the sake of preventing herself from inadvertently screwing anything up on her system, she created a separate non-administrator account on OS X named "tv" and configured it to automatically sign-in. So when the box reboots after a power outage or a patch install, it goes right back into the "tv" account.

Convenience

She also added TED and Transmission to the start-up items list for this "tv" account so they run automatically.

Disk Space

Her old Mac Mini has a very small hard drive so disk space is an issue. The first thing she did was grab Monolingual and remove all the non-English resources files she wasn't ever going to need. This cleared up a good bit of space. But she also has to regularly go in and delete old/watched shows before the disk fills up - sadly you can't delete shows from Front Row.

Podcasts for Ruby and Rails Aficionados

I love podcasts. A two-hour daily commute will do that to you, or an eight-hour drive every few months to the "big city" for a conference or barcamp. Unfortunately I've had a hard time finding my fill of good Ruby and Rails focused podcasts. Listed below is what I currently have on my list; if you have some I've missed please leave a comment.

Audio

Rails Envy Podcast

A very short weekly newscast. Gregg Pollack and Jason Seifer - of the infamous gag videos shown at the last couple Railsconf gatherings - read through a list of highlights from the preceding week in the Ruby and Rails community. Unfortunately there's rarely any in-depth discussion of the items, just a smattering of corny jokes which may not be everybody's cup of tea.

http://www.railsenvy.com/podcast

raleigh.rb

Recordings from guest speakers at the Raleigh Ruby meet-up. Unfortunately months pass between episodes, and without the accompanying video/slides some of them are hard to follow, but many are timeless so don't be afraid to listen to the older ones.

http://feeds.feedburner.com/raleighrb

Ruby on Rails Podcast

Geoffrey Grosenbach - the most distinctive voice you'll ever hear - interviews the who's who in the Ruby and Rails inner circles, often ambushing them at conferences, which sometimes results in less-than-stellar audio quality. Episodes aren't regular in schedule, but frequent enough to avoid disappointment.

http://podcast.rubyonrails.org/

Rubyology

This podcast started out rough with more of a tutorial focus but thankfully host Chris Matthieu switched to an interview format and has since managed to catch some good movers and shakers in the Ruby and Rails field. Unfortunately there's no regularity to the schedule of episodes.

http://www.rubyology.com/

Video

Obviously I can't watch video podcasts during my long commutes... well technically I could on my iPhone, but that wouldn't be wise while driving... so when I get to the office and find a few minute to myself these are the ones I watch.

Railscasts

You must live under a rock if you haven't heard of Railscasts. Ryan Bates continues to amaze me with his clockwork release of high-quality tutorials on Ruby on Rails tools and techniques. His podcast has been the number one contributor to my personal knowledge advancement in the field. If I were running a Rails development team right now these would be required viewing.

http://railscasts.com/

Ruby Banter

Developers from the company Fingertips pair up to demonstrate clever Ruby programming concepts in a live coding session; they type in the code and run it while explaining it, often evolving the program over time to ease the viewer into a complex concept. Unfortunately there hasn't been a new episode in six months, but there's nothing stale about the back log.

http://media.fngtps.com/rubybanter/

Peripheral

Some podcasts out there aren't declaratively focused on Ruby and Rails but most of their content is undoubtedly so.

The Web 2.0 Show

Yet another podcast that tries so hard and fails so well to keep a regular schedule of releases. Josh Owens and Adam Stacoviak (and formerly Chris Saylor) corner the founders of successful and/or popular Web 2.0 start-ups and try to pry their secrets from them.

http://web20show.com/

Pivotal Labs Tech Talks

The almost-self-explanatory name gives it away, they just need to throw the word "Guest" in there and it's all summed up. Pivotal records (video) presentations by guest speakers to their staff and selflessly publishes them for the betterment of the rest of us. Insert broken-record complaint here about the regularity of releases.

http://pivotallabs.com/talks

Synthetic Load and Coal Mine Canaries

I was watching the Pivotal Labs video of their luncheon with New Relic and the speaker, CEO Lewis Cirne said something that struck me as really odd yet kind of clever.

As he was describing the architecture of their system, Cirne revealed they they run a constant "synthetic" load on their production system. He referred to the faux load agents as their "canaries in the coal mine." The purpose of these canaries, as he explained it, is so that when they reach a dangerous level of traffic - when performance begins to suffer - they can kill off the fake load, freeing up resources and consequently giving them a gauge as to how much breathing room they have before they are really in trouble.

Right off the bat this ingenious ruse throws up two warning flags to me. First off, is all this fake load unnecessarily reducing the lifetime of the hardware, such as thrashing the disk drives, generating excess heat, sucking electricity, etc.? And secondly, how sure are they that this fake load is representative of real load, and hence a true measurement of spare capacity once it's removed?

What do you think?

Bootstrapping GitHub Access on a Fresh EC2 Instance

If you'll recall from my last post, I've spent an extended weekend getting a mature Rails application running on Amazon's Elastic Computing Cloud (EC2). Yes, I took two vacation days off work (where I suffer with Java and ATG) to spend some quality time with Rails and EC2, and more accurately Capistrano.

My short-term goal was to get the application running (which I did), then to automate deployment. Since EC2 affords you the luxury of conjuring up fresh severs on a whim, I wanted to make sure I had a simple single Capistrano task that could take a virgin machine and impregnate it with my application. (Wow, that metaphor kinda strayed into the inappropriate zone, eh?)

Out of the box, the EC2 on Rails gem gives you some handy recipes for setting up a fresh instance and deploying to it, but it misses a couple little chicken-and-egg bootstrapping niggles. One of those is GitHub access.

In order to pull your repository off GitHub, you have to have your SSH keys set up. This is generally a manual and slightly tedious process. The GitHub guides do an excellent job of walking you through it. However, I don't want to run through that rigamarole every time I christen a new server; I want that chore to be automated.

This certainly isn't the most elegant way to solve it, and I don't recommend it for a long-term large-scale operation, but here's how I handled it...

I generated the SSH keys on a single machine then copied the "id_rsa" and "id_rsa.pub" files into my "config/deploy" folder. So I now have a copy of the super secret files necessary for accessing my remote repository in the repository itself. I'm aware of how dumb this is from a security perspective, and you should be too, so just put down the flamethrower and back away from the keyboard. I'm keeping things simple and practical here; this isn't the source code for an electronic voting machine after all.

Next I created a Capistrano recipe to copy the SSH key files from my "config/deploy" directory up to the target server (being deployed to) into its "~/.ssh" directory (where the remote ssh command expects to find them). Note that this puts the same keys on every server.

namespace :spumco do
  namespace :ec2 do
    desc "copy the GitHub keys"
    task :copy_github_keys do
      upload "config/deploy/id_rsa", "~/.ssh", :via => :scp
      upload "config/deploy/id_rsa.pub", "~/.ssh", :via => :scp
    end
  end
end

I then used the "after" hook to ensure this recipe runs after the EC2 on Rails gem completes its native "setup" recipe.

after "ec2onrails:setup", "spumco:ec2:copy_github_keys"

Now every time I create a brand-spanking-new instance on EC2 and I run the "cap ec2onrails:setup" command it does everything it needs to do to prepare that server for receiving the only other command that needs to be run, "cap deploy".

Rails on EC2: A Tale of Perseverance (Part One?)

One of my pet projects has been getting a lot of "yeah but can it really scale?" naysaying of late so I decided to find out if my on-paper theory translated to a real-world infrastructure. Essentially I need to take my all-on-one-server Rails application and split it up into several segregated modules across several servers: the main web site, main database, slave databases, web services layer, caches, queues, workers, etc. I'm not mister moneybags, so I opted to use Amazon's Elastic Computing Cloud (EC2) service to virtualize all the servers.

Uploaded with plasq's Skitch!

Up until Friday morning the only thing I knew about EC2 was what I'd read in blog posts. The first thing I had to do was RTFM. I can't stress enough how phenomenal is Amazon's documentation. Everything I needed to know to get started was spelled out step by step in the Getting Started Guide. It walks you through setting up your account, configuring your local environment for communicating with the cloud, then setting up your first virtual server. It all worked as advertised and I didn't hit any of those "oh crap I'm going to have to ask on IRC or the Google Groups WTF this means" speed bumps.

Once I was proficient with the basics of EC2, I wanted to get Rails on it, and I was pretty sure somebody out there had already done all the hard work for me. I was right, of course, and that somebody was the EC2 on Rails project. It was a bit confusing at first as there seems to be some stale information over on RubyForge but apparently the project moved to GitHub; at least that's where the most recent activity and updated documentation can be found.

EC2 on Rails is simply a Ruby gem - accompanied with an EC2 image pre-configured for hosting Rails applications - and a toolbox of Capistrano recipes for deploying your application to the cloud. Like Amazon's documentation, EC2 on Rails walks you through the process of installation and configuration pretty well. However, I did run into a plethora of thorns. The first and most painful of which was the Capistrano incompatibility - it insists on version 2.4.3. I tried at first to hack it to work with the latest, but after falling down far too many rabbit holes I gave up and conceded to downgrade my copy of Capistrano.

Once the Capistrano conflict was resolved I ran into problems with the eyecap gem and some of my app's recipes (too many definitions of the "symlink" task), then configuring the virtual server to talk to GitHub was an outside-of-the-box somewhat-convoluted experience (which I might detail in a follow-up post), and I wasn't able to initialize the database due to an issue with migrations and a bad model name conflicting with some native libraries, so I ended up scp'ing a dump from another host and importing it. But most, if not all, of those issues were related to the quirks of my Rails application and not necessarily issues with the EC2 on Rails package. After everything was ironed out, I could deploy to the cloud with a single command.

Although it spanned three calendar days I only clocked in six hours on the project; from EC2 noob to a live Rails application. Not too shabby for a weekend.

But, I've thus far only replicated what I already have: an all-on-one-server environment. My next step is to start up a half-dozen other virtual servers and start breaking off pieces of the application to see just how well it can scale up and out.

Book Review: Purple Cow

Hated it. I knew nothing about the author (Seth Godin) before reading the book, it was just a title I had heard tossed around at a conference or on a podcast, I can't recall. After reading the book and asking myself how could it be so widely heralded, I did some research on Godin. According to the good old Wikipedia, he has "one of the most popular blogs in the world" and "is the author of 11 bestselling books." I've not read any of his other books, nor do I read his blog, so my initial theory is that Purple Cow is simply riding the coat tails of his other successes. Of course, I'm not completely blind to the possibility that I just might not get it. But back to the book...

The book is short, and the chapters are really short. Each chapter averages maybe two or three paragraphs. It reads very much like a blog, and I'd guess it's essentially a scrapbook of Godin's posts. If I hadn't been privy to the blogging phenomena, I'd probably have described this book as The Art of War for marketing, a collection of quips and anecdotes.

Again Wikipedia sums up the book's premise pretty well:

"...marketers no longer have the power to command the attention of anyone they choose, whenever they choose. ... Godin asserts that the only way to spread the word about an idea is for that idea to earn the buzz by being remarkable."

It struck me as a lot of armchair quarterbacking. The author builds some pretty big bridges over the chasm between cause and effect with bold and broad statements along the lines of "product X was crazy successful because of tactic Y," glossing over any possible nuances of the relationship between the two or other possible external market factors. As I read it, my mind kept conjuring up the image of Andy Rooney and his rants at the end of every episode of 60 Minutes.

In summary, I don't regret reading the book, I just didn't enjoy it. Now I know who Godin is and what he preaches so the next time I encounter his name I'll be able to better participate in the conversation. The book also made me think; unfortunately it made me think the author is more about braggadocio than pragmatism.

Stack Overflow is open; Experts Exchange can suck it

How any times have you run into some obscure problem with a piece of software, you copy and paste the cryptic error message into Google, and the first match that comes up is a link to Experts Exchange, the site that supposedly has all the answers but wants you to pay to see them? Yeah, me too. Well their business model took a pretty big hit this morning...

Joel Spolsky of Joel on Software fame and Jeff Atwood, who I'd never heard of before the Stack Overflow podcast, have finally opened up the doors to Stack Overflow, which is essentially a free version of Experts Exchange. I've been in the beta for a few weeks and I've got to admit it's pretty damn slick!

So here's my call to arms: all you Ruby on Rails fanatics, get on over there and start contributing the knowledge, it's very .Net and Java heavy so far.

Interview with eBay architect worth a listen

Normally I'd save something like this for my Twitter feed but I think the latest espisode of Software Engineering Radio is worthy of a dedicated blog entry. In episode #109 Markus interviews Randy Shoup about his role as a Distinguished Architect at eBay. The interview plays like a scripted version of a conference presentation - you can see the slides and bulleted lists in your head - but that doesn't distract from the excellent content. Randy goes into detail about the architectural compromises eBay has to make in order to value performance, stability, scalability, and up-time above traditional "best practices" of software development like referential integrity, transactions, etc. It will either enlighten or infuriate you; either way it's worth a listen.

Book Review: Predictably Irrational

The author artfully tells the tales of a dozen clever experiments in human behavior demonstrating the power of suggestion, sexual arousal, the placebo effect, dishonesty, and peer pressure. As the title suggests, the book asserts that human behavior is sometimes irrational but completely predictable. For example, humans are prone to think more expensive products are more effective simply because they cost more, such as with name brand drugs versus generic. This might be a tale of psychology but it hit more as a little black book of marketing tricks, not just between products and consumers, but between consultants and clients, perhaps even between bosses and employees. It opened my eyes to the ways I might be, or have been, persuaded to make illogical decisions. I'll be a lot more skeptical and wary in future dealings with salesmen and managers. It's a relatively short book - a quick read - and the author does a fine job of explaining everything in layman's terms. Check it out.

On Second Thought: Interfaces

Continuing my reexamination of past opinions...

Five years ago, and about one month, I wrote that interfaces in Java were essentially useless, mainly because I almost always have a modicum of generic logic I want to have associated with the classes that implement the interface, so I always end up using an abstract class instead. Over the years, however, my tune has changed on that topic, primarily due to my work with Ruby. I've seen the light of duck-typing and mixins and the closest you can get to that in Java is via interfaces rather than inheritance.

So, on second though, interfaces are good.

Top 3 ways I stay on top of Rails

Rails has been an off-hours hobby of mine for the last three years (and one month, to be exact). Since I get so precious little time to work with it each day, I need my Rails juice in quick and concentrated doses, and here's how I get it:

#3 What's New in Edge Rails over at Ryan's Scraps. When the fancy new features get added, Ryan gives you the straight dope, no fluff.

#2 Railscasts by Ryan Bates. Nothing gets the point across better than seeing somebody actually do it. Ryan serves up quick little screencast hors d’oeuvres demonstrating The Right Way to handle a multitude of Rails-related tasks, from development to deployment to testing to documentation.

#1 Reading Jack Danger's commit diffs on GitHub. I have the distinct pleasure of overseeing a (private, sorry, no links) project on which Jack is the lead developer. Jack's commits are always clean and concise bite-size chunks of refactorings or new functionality and his commit messages are always descriptive and explanatory, none of this "fixed stuff" or "made changes" crap that drives me bonkers. Reading his commits are like paging through a book entitled "Step by Step Rails Development, The Right Way, By Example." By far, watching the code of another more-seasoned developer evolve over time has taught me the most about good Rails coding.

On Second Thought: Naming Conventions

About five years ago, I wrote a rant about naming conventions inspired by my pet peeve of the redundancy between package names and the names of their contained classes. Essentially, I didn't like seeing things like recipe.RecipeList and proposed that recipe.List was a better choice.

The problem with this convention rears its ugly head in Java. If you need to reference two or more different classes with the same names in a block of Java, you have to fully qualify all but one of them. For example, you might be declaring variables like com.spumco.recipe.List recipeList = new com.spumco.recipe.List(). That's a tad verbose.

Dot Net made this a little more elegant, only requiring you to provide as much prefix as necessary for the compiler to differentiate the classes. For example, if you had com.spumco.recipe.List and com.cyberdyne.exercise.List you only need to reference them as recipe.List and exercise.List.

Therefore, on second thought, I have changed my spots when working in an environment that doesn't make it easy or elegant to differentiate between same-named classes, such as Java.

On Second Thought

On the drive into the office this morning, I was listening to one of the bazillion technology news/interview/round-table podcasts to which I subscribe, and the gentlemen on the microphones were going on and on and back and forth about an age old tech topic that has been beaten to death and then some. The particular topic isn't pertinent to my story; what matters is that I thought to myself, "I was dealing with that issue ten years ago, and I'm sure I've blogged about it long ago." And as an afterthought I wondered to myself, "What was my stance on the issue so many years ago? And, has it changed?" That inspired me to pull up some old posts from long ago, re-read them, and reconsider their tone. I was surprised to find that I had indeed changed my tune on an issue or two, so in the unforeseeable future I hope to pen a handful of "On Second Thought" posts where I revisit my former younger self and try to analyze the rhyme and reason of my flip flops.

Book Review: Secrets of the Rock Star Programmers

Not many secrets revealed in this book, more-so just a collection of formulaic interviews. The author sits down with a little over a dozen industry celebrities and presents them with a thematic collection of questions, which are conveniently cataloged and charted by interview in an appendix. Admittedly I didn't know half the subjects in the book - I knew of their accomplishments, their companies, their products, but this was my first exposure to the people behind the curtain. The author peppers each interview with side notes comparing and contrasting one subject's response with another's - I liked that. It kept things more grounded to see that even though some two guys are considered experts in their field and they both speak very authoritatively, they completely disagree on some matters, reminding the reader that some topics are quite subjective and simply a matter of opinion or personal experience and not necessarily the law of the jungle. The questions asked and the people selected for the asking weren't entirely my cup of tea, but I enjoy a good interview with a smart person as much as the next programming geek, so I would recommend this book. My only major gripe is that it's not available in e-book form; I would have gladly paid for a digital copy but instead had to borrow the dead-tree version from the local library.

Hamachi on OS X, redux

A few days ago I raved about my revitalized love for Hamachi with my discovery of OS X support and the HamachiX GUI. But after I got Hamachi re-installed on all my personal and business machines (including a couple Windows boxes), I realized that I had no practical use for the GUI. Once you get everything configured, it's "set it and forget it." Any administration you need to perform is pretty simple and intuitive via the command-line interface.

The only caveat is that you need to ensure Hamachi starts on boot so that you don't have to manually log-in and start it (which presents a pretty tough chicken-and-egg issue for headless remote servers).

The free/unsupported version of Hamachi for Windows has the "run as a Windows service" feature disable, but there's a dirt simple work-around. Create a scheduled task for the Hamachi executable (Start -> Control Panel -> Scheduled Tasks) with a schedule of "at system start-up". That's it!

On OS X it's a little more hairy. You need to create a create a special folder in a special directory with a special script and a special configuration file and blah blah blah. It took me about half a day to figure out and get working reliably, and I've shared it over at GitHub, so grab it, read the README file, and enjoy!

Dirt simple personal VPN (Hamachi) on OS X

Uploaded with plasq's Skitch!

I was a big Hamachi fan back in the day when I was shackled to Windows, but when I broke loose into the Linux and OS X days I had to graduate up to OpenVPN. I'm still a huge fan of OpenVPN but it has two drawbacks:

1. You need a place to host the server, and that place needs to be up and accessible 24/7.
2. You need to configure the server and generate and distribute keys for the clients. Not for the feint of heart.

In light of needing to add a couple more clients and machines to one of my OpenVPN networks I had to ask myself, "surely there's a better way by now!?" I saw that OpenVPN has a Windows GUI slated for it's next release, and that's a step in the right direction, but a far cry from the elegancy and simplicity I desire. So I was elated to stumble across some OS X support for my old friend Hamachi. I decided to devote my Sunday afternoon to trying it out and to my surprise I was done in a matter of minutes... and it's an awesome as ever.

Unfortunately it's not as simple as most OS X installs; you can't just download it and drag it into the Applications folder. There's three essential steps:

1. Install the tun/tap drivers.
   1. Head over to http://www-user.rhrk.uni-kl.de/~nissler/tuntap/ and grab the drivers for Leopard (assuming you're running Leopard).
   2. Untar it and run the package installer.
2. Install the OS X command-line version of Hamachi.
   1. Head over to LogMeIn and accept the "Conditions of Use" to download the OS X universal binary
   2. Untar it
   3. Run sudo ./install
   4. Run sudo /usr/sbin/tuncfg
3. Install the OS X GUI for Hamachi.
   1. Grab the latest version from the download page. As I'm writing this, the links on that page are broken, but you can find working ones here and the latest (that I'm using) is 1C6.
   2. Run the package installer.
   3. You should be rocking now. Click the "Add" icon (the plus sign) to create or join a network.
   4. Repeat this on each machine you want to be accessible on the VPN, joining the same network on each of course.
4. 
   Uploaded with plasq's Skitch!
   Optionally, and recommended, you can set up a hot-key for VNC. By default HamachiX maps some hotkeys so you can click on a server name and immediately jump to FTP, AFP, SMP, but of course I wanted VNC so I had to set that up myself. Just go to HamachiX -> Preferences -> Proxies and hit the "+" icon; it creates a pre-populated one for you, just replace the protocol with "vnc" and you're done. If you set the priority to zero it will act as the default when you double-click a server name in your list of peers.

Git for Idiots (and Java developers)

Uploaded with plasq's Skitch!

Sorry, I couldn't resist the little jab. This is actually a quick reference cheat sheet for a team of Rails developers (myself included) about to make the leap from Subversion to Git...

Your first time?

1. Head on over to github.com
2. Create an account.
3. Generate a public key.
4. Get a copy of the repository:

git clone git@github.com:trak3r/rss2twitter.git

5. Move into the new directory:

cd rss2twitter

6. You're ready to go!

Business as usual...

1. Say you're assigned ticket 222.
2. Make sure you have the latest code:

git pull

3. Create a branch to work in (named after the ticket number):

git branch 222

4. Switch to that branch:

git checkout 222

5. Make your changes (and write lots of tests).
6. Add the file(s) you've changed:

git add somefile.rb

7. Make sure you didn't miss any:

git status

8. Commit often (it's cheap):

git commit -m "a clear but brief summary of the changes"

9. All done? Make sure all the tests pass!
10. Switch back to the "master" branch.

git checkout master

11. Merge your branch:

git merge 222

12. Publish your changes back to the central repository so everybody else can get them:

git push

13. You're done! (...as soon as you deploy to staging and assign the ticket back to the creator for validation.)

Interviewing the Interviewer

Uploaded with plasq's Skitch!

I get lots of job offers via e-mail, as I'm sure we all do. If your e-mail address appears anywhere near a blog or forum related to programming, you're guaranteed to be on a few dozen spam lists for head hunters. Most of these offers get filed in the bit bucket. However, one landed in my inbox the other day and it had enough of the right words and phrases to pique my interest. It was intriguing enough that I had to stop and ponder how I would follow up on it if I were genuinely interested. I've only applied for a job once in my entire career; every venture since has been through networking. So I started building a list of questions I might ask a prospective employer. I've listed them here for future reference, and so that you might find them helpful or offer up your own...

The Business:

- Give me your elevator pitch.

- What is your product/service?

- Why is it unique or better than the competition?

- Who is your customer?

- What is your revenue model?

- How old is the company? Give me a summarized history.

- How are you currently financed?

The Management:

- How many employees do you currently have?

- How many do you plan to have a year from now?

- How many of those employees are in my department?

- How many of those employees will be reporting to me?

- Who do I report to?

- How many layers are there between me and the CEO?

- What does your org chart look like?

- How much turnover have you seen in the last year?

- What's the overtime situation? Is it a necessary evil you suffer a couple times a year, or is it standard operating procedure?

- Is there a dress code?

The Technology:

- Can you build the system in one click/command?

- Can you deploy the system in one click/command?

- Which source control tool do you use?

- Do you leverage branching with your source control? How?

- Do you use Test Driven Development and Defect Driven Testing?

- Do you have code coverage?

- Do you use continuous integration?

- What tool(s) do you use for project management, bug tracking, documentation?

- Walk me through the process of a new feature from conception to delivery.

- Walk me through the process of a bug fix from discovery to resolution.

- Explain your software architecture.

- Explain your network architecture.

- Which brand of database are you using? Why?

- Where are you hosted? If is fully managed or colocation?

Looking out for Number One:

- Will I have my own office? Will it have a door to close when I need some privacy or peace and quiet? A window for some sunlight? A comfortable chair? A dry-erase board on my wall? Wi-fi, or enough network jacks on the wall that I don't have to have a hub and a rat's nest of wires?

- If telecommuting, what will be our primary means of communication? Skype or cell phone? If I'm using my own account/phone, will I be able to expense our calls?

- Is there travel involved? If so, how often, to which common destinations, and what general duration?

- What's the process of requesting and receiving newly required tools (e.g. replacing a dead hard drive)? Do I buy it myself and submit an expense report, or do I have to file paperwork with somebody and wait for delivery?

- How many vacation/personal days am I afforded? How are they calculated (e.g. set number per year or accrued over time)? Does that number increase with my tenure?

- Assuming this is an on-site job, will I be allowed to telecommute on occasion, at my discretion, when I need to attend to personal matters and schedules that preclude a trip to the office?

- Will I have a budget for books, software, travel, conferences, other educational materials (e.g. Peepcodes)? If yes, what will that budget be?

- Is conference attendance at my discretion (which and how many to attend)? Will the be covered as company expenses?

- When I travel on company business, may I expect my expenses (travel, food, lodging, entertainment) to be reimbursed in full? May I expect to have my own room for overnight stays (no roommates)? May I expect to get "decent" flight schedules (no red-eyes and no there-and-back in a single long day)?

- What will be the schedule for my reviews and raises, based on my date of hire, or first of the year?

- Will I be awarded stock options? Performance bonuses? Quarterly, yearly, or some other schedule?

Brains, Brawn, Charm, and the Checkbook

Uploaded with plasq's Skitch!

Last night I was pondering my tangential relationship with the latest start-up of an entrepreneurial friend, and I harkened back to my history of start-up involvement (roughly a half-dozen in twice as many years) and it dawned on me that there's consistently been four key players at the beginning, each with a pretty clear personality stereotype. As you might have gathered from the title of this post, those people represent the brain, brawn, charm, and checkbook.

The Brain is the mastermind that knows how to turn an idea into reality. He's not necessarily the founder, and in most cases I've seen he's "the tech guy". The founder comes along and asks, "Wouldn't it be cool if we could do X?" and the Brain says, "That's possible, and I can architect it!"

The Brawn is the guy that actually builds it. He's the guy that works eighteen hours a day pumping out mountains of code. In many cases, the Brain and the Brawn are the same person, but eventually, and sometimes pretty quickly, the Brain gets too busy with other business matters and the Brawn title gets passed on to another.

The Checkbook is the guy with the money. I'm not talking about the bootstrapping of the company; the founder usually foots that bill. Eventually the business needs to "step it up" and that requires some big money. That's when the wealthy friend-of-a-friend comes into the picture and writes a nice fat check.

The Charm is the wheeler and dealer. He's the cheerleader for the Brain and the Brawn. He's the seducer of the Checkbook guy. He's the "demo" guy; the sweet talker for partners, clients, and customers. In my experience this is always the founder. He's the guy the brings the other three together, gets the ball rolling, and keeps it going.

Rails Doesn't Scale?

[Originally posted to the AdPickles blog.]

Last month, an old entrepreneurial colleague dropped me a note regarding some speed bumps he's hit while courting potential investors and partners...

"I've heard a few people mention that they heard that Rails doesn't scale [...] any suggestions on how we might alleviate their doubt?"

So I rallied the troops (his two contractors) and we set out on a little informal fact-finding mission. Here's what we've come up with thus far...


How 7 Mongrels Handled a 550k Pageview Digging

Not a lot of in-depth analysis here, just an impressive scaling success story with a pretty bar chart of the traffic load and an itemization of the hardware and software involved along with costs.


It's boring to scale with Ruby on Rails

Granted, this one is written by the man himself, Mister Rails, so you have to take it with a grain of salt, but he hits upon the common themes, which are caching, load balancing, and:

"Scaling the database is the `hard part'"

Unfortunately he gets a little off track in the second half of the essay and goes into the cost analysis of productivity and happiness, which is where you'll lose the attention of most investors.


Scaling Twitter: Making Twitter 10000 Percent Faster

I love the High Scalability blog; it's the dessert of my weekly reading. Granted Twitter still has its problems to this day, but you can't deny its monumental achievement in wide-spread adoption and ungodly levels of traffic. In addition to the aforementioned staples of caching, load balancing, and database optimization, they add partitioning and queueing to the mix.


Engine Yard Bets Big on Rubinius

What does this have to do with the scalability of Rails? Well nothing explicit in the article, but it supports two important movements that will eventually lead to a greater good.

First of all, Rubinius is one of three now mainstream Ruby implementations (the other two being Matz's original and Sun's JRuby). Competition here is good. This means better, faster, more stable Ruby environments, which will translate into a faster and more stable Rails.

Secondly, Rubinius is eventually going to lead to mod_rubinius, which will lead to even more scalability of the Rails platform by allowing us to leave separate single-process servers (like Mongrel) on the wayside.

Personally my money is on JRuby (and Glassfish) for the long haul; if you haven't checked out Glassfish yet, you're doing yourself a disservice!


Benchmark Invests in RoR Provider

Pretty much a no-brainer here. Benchmark Capital invested $3.5 million into Engine Yard, whose main business is Rails hosting.


Riding the Rails with WebSphere

If Glassfish is a little too cutting-edge for you, and you're all about being "enterprisey", then IBM's WebSphere is probably right up your alley.

At this point, between IBM and Sun's support of Ruby and Rails, and the multi-million dollar investments other Rails-based ventures are receiving, I'm beginning to wonder how savvy are these potential investors my friend is getting flak from.

But we're not done yet...


Can Rails Scale? Absolutely!

This article is a pretty good round-up of the more recognizable names using Rails, such as Yellow Pages, Basecamp, and the infamous Twitter, as well as a rehashing of the same old story: caching, spreading the load, and tuning your database.


Friends for Sale Architecture - A 300 Million Page View/Month Facebook RoR App Todd Hoff's picture

Here we are again at my favorite feed, High Scalability, with another Rails scalability success story. This time it's a Facebook app, and a rather popular one at that. I won't spoil the surprise for you, because their is no surprise -- it's the same old story: cache, distribute, and:

"The most important thing we learned is that your scalability problems is pretty much always, always, always the database."

So in summary, there's plenty of good ammunition out there against the naysayers.

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]

Stupid .Net Tricks: Visual Studio and Subversion

This post isn't just another homage to my old friend's series of posts but also happens to involve him. How's that for irony? Or would it be serendipity? Whatever.

It just so happens that Craig has inherited an old project of mine and the first issue he ran into is one that I had to smash my face against about a year ago: Visual Studio hates Subversion.

Before Craig came to me, he went out and researched it on his own (Amen!) and discovered this thread, which pretty much sums it up. The .svn folders cause Visual Studio to barf.

The solution? As with most of the Windows projects I've worked on, a big fat ugly hack.

I have two working directories. One of them is a legitimate Subversion checkout, the other is just an export. What's the diff? Well, the former has the .svn files and the latter does not. So I point Visual Studio to the export version and use it for development, and when I need to commit my changes, I xcopy the export directory to the checkout directory. This copies just the modified files.

I do this so often I went ahead and threw it into a BATCH script:

@echo off
set SOURCE=C:\Inetpub\wwwroot\cyberdyne
set DESTINATION="C:\Documents and Settings\ted\Desktop\Cyberdyne\Subversion Working Copy"
xcopy %SOURCE% %DESTINATION% /d /e /v /r /y

Amusing anecdote: The order of the xcopy parameters "/d /e /v /r /y" is no coincidence, Devry is the name of the fine institution that Craig attended.

Please don't mug me

My mind was wandering this morning and it dawned on me that I carry a ridiculous wealth of electronics in my backpack when I travel:

+ Take.TV, 4GB, $100

+ DS Lite, $150 (with at least $100 in games)

+ PSP, $170 (with at least $100 in games)

+ iPod Nano, 4GB, 2nd gen., $250

+ Amazon Kindle, $400

+ Macbook Pro, 15", refurb. w/ram upgrade, $2500

Unless my math is wrong -- and keep in mind my degree is in music composition, so it's well withing the realm of likelihood -- that sums up to nearly $4,000, not accounting for depreciation.

Lest you get the wrong impression that I'm mister moneybags, all but the laptop were gifts.

Here's to hoping none of my faithful readers are tempted to mug me at the next convention.

Book Review: Dreaming in Code

I'm probably not the first (or the last) person to say Dreaming in Code is the Soul of a New Machine for my generation. The author chronicles the trials and tribulations of a fledgling start-up struggling to develop a piece of software that will change the world. Sound familiar? Yeah, that's pretty much the mission statement of every software start-up I've come across in the last decade and a half.

Unfortunately, these guys have it all messed up right out of the gate. Where most companies start out with a gung-ho entrepreneur and investors and profit expectations, this company starts out with a "socially responsible" "thought leader" philanthropist who has enough money from former successes (Lotus 1-2-3) to fund the venture himself and whose primary goals are to be open source and leverage peer to peer technology. The founder rounds up a few like-minded geniuses from his past endeavors and they start thinking about what to develop.

What happens when you get a bunch of "thinkers" in a room together? You have endless hours of thought-provoking intellectually-stimulating conversation and debates and draw lots of neat diagrams on the white board, hypothesizing solutions to the problems with software design which have have plagued the industry for decades... then you poke your head out of the conference room one day and realize a couple years have passed and you haven't written a single line of code. Been there, done that, have the worthless stock certificates framed and hanging on my office wall as a reminder of a hard-learned lesson.

The company eventually has to come to terms with developing and delivering software, meeting deadlines, making compromises, dealing with feature creep, and the whole gamut of "business as usual" debacles, and that's where things start to get interesting. But, sadly, the author's seemingly self-imposed three-year deadline for going to press came a lot sooner than the launch of the product he was chronicling. On an amusingly serendipitous note, the project in question popped into the news while I was writing this review. The article notes, "It's still very early beta, and there's a lot of polish missing from the current builds." So there's sadly no closure in the book.

Nevertheless, it's a good read. It starts strong, and the author peppers the biographical chapters with tangents on the philosophies of other big wigs in the software industry, trying to tie them all together into a sort of moral tale on how "software is hard" and we're doomed to never really master it. I don't agree with those sentiments, but he covers the topics well in an unbiased manner.

Quotables

In a tense meeting late last night, I had to stifle a laugh when the quality assurance director asked the president, "Which one do you want to control: requirements or delivery date? I control the other one."