Cloudy, Cold and Hip – Two Weeks of Training in Portland

I’ve really enjoyed the last two weeks. My new employer, recently acquired Analog Analytics flew me out to Portland, Oregon for training. Portland is quite an amazing place. Skateboarders, cyclists, and runners abound, but with a laid back attitude. Its the greenest city I have ever visited. Stores seem to only dispense recyclable materials including paper bags, and foods in waxed cardboard containers. The entire city is very walkable without much danger of personal harm. The food was amazing, and the drinks even better. This city knows its coffees, teas, and beers. It has to be home to the most microbreweries of any city. Needless to say I have probably gained 5 pounds, and I am super caffeinated. Also, the proximity to all these hip restaurants is giving me second thoughts about living so far outside of the city limits. No lie, I even glanced at Portland housing prices.

It took me a few days to get oriented to the city and the work environment. The company runs out of the Ford Building, in the heart of quite a few cool restaurants and bars in the Southeast side of the city. In fact, it left me a little jealous considering the hotel is only surrounded by fast food joints.  I got a shiny new MacBook Pro (which I am currently battling to make it as “boring” as possible). I can’t talk too much about the work, but it does hit the sweet spot of what I was looking for – a small team feel with deep pockets, and a launch date.

Kristin and Morrigan joined me for the second week and did their own thing, and they had a blast. They visited OMSI, Powell Books, Finnegans, several parks, and malls, and some tasty food joints. I’m happy they got to experience some of what makes this city awesome.

I’m enjoying several aspects of the job in particular: A remote driven environment, and pair programming. Training isn’t the best test run of this environment, as I am in the office everyday for now. Once I am setup, I pick the hours. People hop online and offline, according to their time zones, availability, etc. Every piece of communication, and workflow is centered around remote teams.

Pair programming makes programming social. Despite the image that telling someone you are a programmer conjures, I really enjoy interacting with people. I remember teaming up with James, John and many others at Clayton State to tackle some large issues with our portal and other systems. Since Clayton State, I have worked on a couple teams, and it was almost always in isolation, save for 5-10 minute high level meetings. The best part is, its actually kind of fun.

Pair programming was a tough adjustment for me. I’m used to presenting a final product and defending its implementation. I have all the answers. I know what the talking points are up front, and I am comfortable because I am the authority on the subject. Pair programming is letting your guard down, and conceding as much as contributing. You are two people working on a problem together, with neither party starting off knowing the complete solution. The work is certainly slower than solo programming, as incorporating input, early refactoring, and general discussion takes up time. This team takes an interesting approach to combat some of the time drain; You can either pair program and merge directly, or work solo but your code requires a peer review before merging. The choice is yours. The solo programming option will probably act as a safety value for those days when I just want some time to myself. They also encourage “switching drivers” to vary the work. Interestingly, being the passenger requires more focus than driving, as you are trying to proactively find issues with the current approach.

I’m still struggling to embrace TDD. I don’t like the zealotry in the community when the topic comes up; presenting the only two options as either you test first, or you are just ignorant, undisciplined, or apathetic to the code you write. The truth is far from it. I figure things out by moving the pieces around – not by staring at it from a distance. That is not to say that there aren’t times when testing first is extremely useful, like when clarifying requirements. The test assertions (even with missing test bodies) is often enough to help solidify an attack plan. The amount of code coverage can be a hindrance though, as real world tests always end up being more tightly coupled than you ideally want them to be. If you make seemingly small code changes, you can end up with quite a bit of the test suite failing (all though with the same few errors repeating). If you mock and stub too much, you aren’t testing much that is useful. Even worse, the workflow doesn’t seem realistic: Write the tests, verify the tests fail, write the code, verify the tests pass. The reality seems to be write the tests (heavily guessing at the exact implementation), verify they fail, write the code, refactor almost all of your tests, and verify they pass. Given the choice, I think I’d still rather write code, then test the code to verify it does what I want in all scenarios. I’ve yet to meet a dyed-in-the-wool TDDer that sees any fault with this extra refactoring step. The subject of pre-written tests needing to be refactored seems to be glossed over. Maybe my opinion will be changed yet.

Things are looking awesome for this next step in my life! I’m keeping my fingers crossed for Railsconf tickets, since they are in my employer’s backyard. There are also a few missed restaurants I am meaning to visit next time I’m back up this way…

One Month Perspective On Working From Home

Today marks one month of being a remote worker for my employer. I’m still learning on how to be the most effective with this new environment, but I wanted to reflect on my experiences for anyone else considering this working arrangement.

Lets get this out of the way: its not all unicorns and rainbows. I think that was the biggest surprise to me. It seems like a dream to wake up, walk into another room of your house, work a few hours, and already be at home when 5 o’clock hits. For those expecting instant happiness – you will be slightly disappointed.

The reality is that, like most things in life, working from home is a mixed bag. For those looking to make the transition, consider the following issues:

Isolation can be a big problem, depending on your personality. I think this blow was softened because I am a software developer, and I am used to working with a computer more than people already. I have already cut my teeth on reduced interaction. What I do miss is the comradery in working in a team environment. You often have lunches with your co-workers, entertaining side conversations, and a million other things that contribute to the work culture. When you are working remotely, you exclude yourself from most of that, and it can be frustrating to feel like your avenue for interaction has been reduced.

Reduced visibility in the company is another disadvantage. I feel that I need twice the participation in communications just to prove that I really do still exist. You aren’t in the chatter loop anymore, so information may come to you seemingly out of the blue. Its important to remember that the company isn’t just swinging at things to see what sticks – they are in discussions that you aren’t part of anymore. There is something to be said for that office grapevine. I also get the feeling that I am quietly passed over when it comes to opportunities. The “online” indicator in a chat room isn’t the same as being a warm body in the room when it comes to picking a person for a job.

Getting into a rut in your routine is something that you have to constantly work against. While it seems so simple to sleep in one room, and work in the next, my mind craves more experiences in a day than the walls of two rooms of my house. Like it or not that soul-sucking commute, and those bleak off-white painted walls in the office provide some stimulation. I think it is key to be mobile. Work from a coffee shop for a day, or visit a local university, or other facility welcoming of guests, and providing free wi-fi.

Take your lunches out a few times a week, just to stay connected with the outside. You will be amazed to know that the rest of the world isn’t in a stasis. Things on the outside change. New restaurants open, roads get built, technology improves, books get published. Partake in the changes by going outside your house.

Join a meetup group for fun, or for professional development. In addition to providing networking, and keeping you up on the times, it is also and excuse to go have a few drinks with some peers.

Its not all gloom and doom, as there are some really positive things about working from home. Some of these you probably already know (and maybe even dream about!):

You will have a lot more time. Simply commuting is an average of two hours a day – 10 hours a week that you instantly get back. Also, if you cook at home for lunch, often you can use the remainder of your time to complete tasks mid-day instead of waiting until the end of the day when you are tired. I often do some laundry, or vacuum, take the dogs for a walk, sit outside and read my book, etc. My wife and I have a seven month old daughter, and every minute is precious to me. Having more time to spend with her is priceless.

There are cost savings to remote work, including reduced wear and tear on your car, and fewer fill-ups at the pump. I actually got to reclassify my vehicle as as “for pleasure” on our auto insurance, since it is no longer used for commuting and falls under the cap for average miles per year. Other savings include cheaper lunches (unless you go out) since you have a full kitchen at your disposal, and a thus are able to prepare a range of foods. You may find other savings including no more mid-day dog-sitters, saving on a parking spot, or public transit (just kidding – this is Atlanta!).

You will be hyper-focused. A co-worker once told me “an office is a great place if you don’t want to get anything done”. I understand what he meant by this now. Co-workers can be lots of fun, but when you are trying to buckle down and squeeze something in on a deadline, the office is the least likely place that is going to happen. I often get “in the flow” for 3-4 hour straight in a day when working from home. Its important that you recognize the speed you are working at, relative to your output before to understand how productive you are. The first week, I felt like I was moving in slow motion trying to adjust to the new environment, only to find that I had increased my work output. I would wager I am twice as productive in a day at home relative to a day in the office.

That being said – take frequent breaks. Your coworkers aren’t there to give your brain a break – so its up to you. I find it the most ethical to take breaks doing tasks I can relate to my work. I read HackerNews, read a technical book, or use the time to test out some new technologies. I have already been able to fold some of this exploratory knowledge back into the projects at work.

You are free to travel (and for extended periods!). Lots of people binge vacation, one or two weeks a year. When working remotely, you aren’t tied to a particular location anymore. As long as you have a laptop, access to the Internet, and power, you can be anywhere in the world. My wife and I are gearing up to spend a month in St. Augustine, Florida. I will work during the day most of the time, taking only a few PTO days. After 5pm, or when the weekend hits you are already in the middle of vacationing. The best part is that the month long vacation schedule is one you can physically sustain, with plenty of rest between the activities.

The final benefit I will mention is being able to set your own schedule. You can’t get carried away, especially if your employer enforces office hours. But if you need to take lunch earlier, or later, you can. If you need to step away from the computer for a few minutes to handle something, you can. There is trust that has to occur between employer and employee, but in my experience, your employer is most concerned with work output. It is a loaded gun to know that you are being entrusted to operate with almost total autonomy. You no longer have the eye of an overseer watching your every movement, which is a liberating feeling. Just get what you need to get done, and don’t go crazy with power!

So far, I am loving it. I have heard mixed reports of people adapting to working remotely. Some people crawl on hands and knees begging to come back to the office, and some people work remote the rest of their career. I think it comes down to your particular personality. If you are like me, you just have to try something to know if it works for you. This is one gamble I am glad that I took.

For anyone seriously considering a teleworking gig, I would highly recommend a few resources that helped me get started. First first is a short post like this one from Kyle-Kulyk. I don’t touch on it, but he makes a great observation about how working from home will affect your relationships with significant others. Benefits of, and managing your new teleworking lifestyle can be found in the 4 Hour Work Week. This book contains lots of great resources for how to negotiate a remote work arrangement, and tips for extended travel. Finally, Joel Gascoigne has some great pointers for keeping yourself mentally happy during this big transition.

Configurable Javascript In Place Editor

Why do we need another in place edit library for Javascript? This one is different of course! This library allows for a high degree of customization due to its modular nature. Each action on an in place edit object (submitting on blur, adding a class on focus, toggling a label on click, etc) is complete isolated and designed to stack with each other. This allows for one library to accomplish a wide variety of in place edit functionality in the same project. You can even have different functionality on the same page if you wish.

Setup is a breeze. Just grab the latest copy of the Javascript library from https://github.com/bsimpson/in_place_edit. You will need to be using jQuery in your project, since this plugin depends on it to work. Once you have include both jQuery, and in_place_edit.js, you can initialize it like this:

  $(function() {
    $('.in_place_edit').inPlaceEdit();
  });

The argument passed is the CSS selector that contains the form on which you wish to use in place edit.

Next, we need to configure the form to tell it what actions we want it to perform. If we want basic edit in place functionality, we can add “submit_on_blur” to have the form submit when a blur event is received. Note that this only occurs if the contents of the form have changed, in order to save on the number of server posts.

<div class="in_place_edit" data-in_place_data="submit_on_blur">
  <form action="#" method="post">
    <input type="text" name="foo" value="foo" />
  </form>
</div>

The options are simple, and the combination are many. Check out the following options to see what you can do with your form fields on the DEMO page.

Happy in place editing!

Update: This plugin has been updated to be a jQuery plugin. Thanks to jsumners for providing lots of help!

Google Music: What Not to Do

I was mildly interested in the launch of Google Music as a platform to purchase music, with some integration into the Android platform. From the Google Music launch page, Google promises that you can both stream, as well as download content to both your computer and your Android devices. I figured to try it out with my wife’s purchase and see what it was made of.

Unfortunately, the launch page introduction was the last cool thing we saw of this product. We made our purchase quickly enough, but then we were stumped. The music would play in the browser, but the launch page promised we could download the music to our computer. After clicking every button in the UI, we resorted to doing a search for how to download music. Google Music Manager (no direct link) kept coming up as the way to download our music. Not having been prompted to install this utility during our checkout process, we then had to hunt it down.

I found it on a different computer while searching at http://music.google.com, as I had yet to register for an account. My wife already made a purchase, so her default page had been replaced with her music library. There is seemingly no link to the Download Manager once your first purchase is made.

I decided to send the link the file from my computer, however Gmail will not allow attaching .exe files. I even tried to .zip it, but it still informed me that it detected an .exe file. That is a different story however…

So finally, I got the file to my wife’s computer, and we install the application, thinking we are in the home stretch. It turns out that in order to DOWNLOAD your music, you first have to UPLOAD your personal music library. This step is not optional. It cannot be skipped, and you cannot access your downloaded content until you have upload your personal music. My wife even canceled at the prompt that asked her if she wanted to upload, and it started the process anyway, leaving us to force close the application.

After all this, we were left with the only solution of downloading the album: TRACK. BY. TRACK. You only get two downloads per purchase, so we have burned through half of them already. One of the tracks got “stuck” during download, so we crossed our fingers that the last download would be successful. Fortunately it was.

So my question to you Google, is why make the process for downloading our music purchases so painful? I am sure millions of people helped beta test this product, and I don’t believe that I am the first to notice that downloading content is far from easy. What is to be gained by making the process so difficult then? Are you pushing a cloud service that not every wants? This seems to be a copy from Amazon’s playbook, however Google has failed to execute on the critical piece – a solid way to download your purchase, a la Amazon MP3 downloader.

I think I will be directing future purchases to Amazon’s music store until Google makes some corrections.

PostgreSQL for Ruby on Rails on Ubuntu

My new desktop came in at work this week, and the installation was painless thanks to the great driver support of Ubuntu 11.10. For anyone setting up a Rails development box based on Linux, I have some tips to get around some pain points when using a PostgresSQL database.

Installation:

Postgres can be quickly and easily installed using apt-get on Debian or Ubuntu based distributions. Issue the command:

apt-get install postgresql

Ruby Driver

In order for Ruby to connect to PostgreSQL databases, you will need to install the pg gem. This gem will need the development package of PostgreSQL to successfully build its native extension. To install the PostgreSQL development package, issue the following command:

apt-get install libpq-dev # EDIT: postgresql-dev was replaced by this package on Ubuntu 11.10

Setup A PostgreSQL Role

You can configure PostgreSQL to allow your account to have superuser access, allowing your Rails tasks to create and drop databases. This is useful for development, but is strongly discouraged for a production. That being said, we can create a PostgreSQL role by logging into psql as postgres as follows:

su postgres -c psql

This will open a PostgreSQL prompt as the database owner postgres. Next, we need to create an account for our user. This should match the response from “whoami”:

CREATE ROLE <username> superuser login;

We can now exit from psql by issuing “\q“. Try to connect to psql directly by issuing the following command from your shell account:

psql postgres

This should allow you to connect to the default database postgres without being prompted for credentials. You should now be able to issue the rake commands for creating, and dropping the database:

rake db:create

Rspec Prompts for Credentials

I was being prompted by Rspec for credentials when running my test suite. If you would like to remove this credential prompt, please read the following:

There are differences in how the PostgreSQL package is configured in Homebrew on OS X, and how it is packaged in the Ubuntu and across other distributions. One difference is in the level of security configured in the pg_hba.conf file. This file is responsible for identifying which sources using which authentication mechanisms should be allowed or denied. By default, Rspec will cause a prompt for a password even if your shell account has trusted permissions. This is because Rspec connects not as a local process, but to localhost. To allow connections to localhost to be trusted, you will need to modify the pg_hba.conf file.

Next, we can modify the pg_hba.conf file located at /etc/postgresql/<version>/main/pg_hba.conf

Comment out the lines any lines at the bottom of the file and append the following:

local   all             all                                      trust
host    all             all              127.0.0.1/32            trust
host    all             all              ::1/128                 trust

This will allow connections from the shell, as well as connections to 127.0.0.1 (localhost) using both IPv4 and IPv6.

You will need to restart PostgreSQL for the changes from this file to take affect:

/etc/init.d/postgresql restart

PostgreSQL Extensions

If you want to make use of any of the additional extensions to Postgres, including fuzzystrmatching, you will need to install the postgresql-contrib package:

apt-get install postgresql-contrib

The extensions will install to /usr/share/postgresql/<version>/extension/

Using the Postgres version 9, you can create these extensions in your database by using the new CREATE EXTENSION syntax. In the case of the fuzzystrmatch extensions, you can issue the following command from inside a PostgresSQL command prompt to load the extensions:

psql <database name>;

Once inside your database:

CREATE extension fuzzystrmatch;