ReinH Blog

Ch-Ch-Ch-Changes

2009-09-21T13:41:16-04:00

A couple months ago, I resigned my position at Hashrocket. This was not an easy decision for me. Working with the rocketeers has been a very fulfilling and edifying experience. The people at Hashrocket are passionate about what they do and extremely competent. I was given challenging and rewarding responsibilities. Hashrocket was a great job and I would recommend it to anyone. Why, then, did I chose to leave?

In the end, it came down to a need for personal growth. At Hashrocket, I have had the opportunity to work with interesting clients on interesting projects, to lead a number of talented development teams and to consult on Rails development and Agile methodologies to large businesses. Thanks to Hashrocket, I have expanded my core competencies and matured as a developer. Certainly I could have stayed with Hashrocket and continued this process. There was more to do and more to learn. In the end, though, I felt that it was time to for me to take on a new set of challenges. My friend and former boss, Obie Fernandez, has been wonderfully supportive of me in this and I owe him a great debt of gratitude. I am happy to say that my departure from Hashrocket has been entirely amicable. They are a great bunch, one and all, and I am fortunate to have worked with them.

As a consultant for the past eight years, both freelance and with Hashrocket, I have worked with many clients. This work has been more or less successful, my clients have been more or less happy, and the work has been more or less satisfying, but there is a common factor in its transient nature. I work on a project for weeks or months, provide as much value as my abilities allow, and then move on to another project once my role is complete. Consultants rarely experience the satisfaction and sense of accomplishment of a job well done, the rewards of the successful completion of a long and often arduous project life cycle.

So, to make a long story short, I wanted to find a project that I could call home. I wanted to feel a sense of ownership in the project and its outcome. I also wanted to learn new skills and develop new competencies. The problem is that I didn't yet know where home was, so I decided to start by taking some time off and then sort of figure things out from there. This was risky, especially in our current economic climate. Luckily, I've never been shy about making such decisions. After all, I love a good adventure, and adventures always entail a certain amount of risk.

During my vacation, I spent a lot of time playing piano and writing music. It felt good to give my creative muscles some much-needed exercise. I assessed my career and my goals. I read a lot. I played some video games. I quickly found, however, that living without a "dedicated purpose" was less than satisfying. I was not happy leaving my tools in the corner to gather dust: they needed to be used. So, how best to use them?

I decided, after some consideration, that what I wanted was the opportunity to shape the destiny of a project that I believed in. I wanted to do more than sit behind a desk and code. Luckily, I was presented with just such an opportunity only a few weeks after leaving Hashrocket. Rick Bradley, a good friend of mine and an excellent developer, had a client who was looking for a full-time hire. I was reluctant to become Yet Another Developer but I decided to look into it. I'm sure glad I did: the position turned out to be just what I was looking for.

The client was Reductive Labs, the company behind Puppet, the Ruby-based configuration management tool. This in and of itself was interesting. The Puppet codebase covers a large area both topographically and conceptually. It has a significant installation base and a large open source community. It would be a challenging project to work on and a welcome test of my abilities.

I don't have a Computer Science background. I've never taken any courses in programming. I am entirely self-taught. Puppet, on the other hand, has a lot of Serious Business going on: a parser-compiler, a graphing library, client-server systems, and so on. I have experience in some of these areas, but in others I have only a basic theoretical knowledge gleaned by way of an intense curiosity and a love of reading. I had read the Dragon Book, for instance, but I had no experiential background in language design or writing parsers and compilers. Luckily, my lack of a formal education was not a barrier to entry (nor should it be if you have the skills needed to execute or the ability to acquire them, but that's a topic for another post).

I spent a week in Portland getting to know the code and the company. While Puppet is older than Rails, the code has until recently been under the sole stewardship of Reductive founder and CEO Luke Kanies. As a company, Reductive is small and young, but the technology is relatively mature. This is an interesting combination of both the pioneering spirit of a startup and the stability of an established open source project.

During the day, I spent my time pairing with Luke and talking with the founders about their plans for Reductive Labs and Puppet. Luke has a piercing intelligence and a compelling vision for the future of both Puppet and Reductive Labs itself. I quickly saw that I would not just be yet another a developer, rather that I would also have the opportunity to lead teams, collaborate with a large and active open source community, and even more importantly, to help Luke and the rest of the Reductive team make design and strategy decisions that would inform the growth of both Puppet and the company. Plus, I would be "forced" to relocate to Portland, one of my favorite cities. Bonus.

Apparently my visit was a success: I'm pleased to say that Luke offered me a position immediately after my trip and I accepted just as quickly. As I grow into my new responsibilities at Reductive, I find that they scale well with my abilities. Luke seems happy to let me do what I'm good at and I enjoy the opportunity to carve out my own role within a growing company. Most importantly, I feel like I have the opportunity to accomplish something significant. Nothing matters more to my sense of fulfillment and satisfaction.

My faithful readers have most likely been lamenting this blog's recent lack of content. Hopefully my little story helps explain this conspicuous absence. Expect more posts in the near future. I've got plenty to talk about.

Custom FiveRuns TuneUp Instrumentation

2009-04-21T11:30:23-04:00

TuneUp is a development performance monitoring tool from FiveRuns. It can help you catch poorly performing actions and queries early and is a great tool to add to your performance monitoring toolbelt. TuneUp also makes it very simple to add custom instrumentation to your Rails app, which came in handy when we needed to report on web service queries made by our Endeca client.

A brief chat with Bruce Williams helped point the way to TuneUp’s FiveRuns::TuneUp.step, the jumping-off point for its instrumentation of your model, view and controller activity. We were able to write a simple plugin that adds instrumentation to calls made by the Primedia Endeca gem (a gem used to consume Endeca’s RESTful JSON bridge API).

The plugin takes advantage of alias_method_chain to add instrumentation to the Endeca query methods. This solution is very clean and is idiomatic to Rails itself as Rails uses alias_method_chain to “embellish” many parts of the request response cycle for things like benchmarking and caching, as David mentions in a blog post from his Rails Myths series

If you want to look at the code, you can find the plugin at its github repo. All the code is in the init.rb but I’ll reprint it here for convenience. Note that we could have refactored these similar method definitions using metaprogramming techniques but chose not to do so for reasons of simplicity and clarity.

if defined? FiveRuns && defined? Endeca && defined? Endeca::Document
  # Tuneup instrumentation
  class << Endeca::Document
    def all_with_tuneup(*args)
      Fiveruns::Tuneup.step "#{name}.all", :model do
        all_without_tuneup(*args)
      end
    end
    alias_method_chain :all, :tuneup

    def first_with_tuneup(*args)
      Fiveruns::Tuneup.step "#{name}.first", :model do
        first_without_tuneup(*args)
      end
    end
    alias_method_chain :first, :tuneup

    def by_id_with_tuneup(*args)
      Fiveruns::Tuneup.step "#{name}.by_id", :model do
        by_id_without_tuneup(*args)
      end
    end
    alias_method_chain :by_id, :tuneup
  end
end

Simplify Your Dev Environment With Passenger Pane

2009-04-17T10:04:11-04:00

On OS X? Develop web applications with Rails? Or Merb? Or Sinatra? Or any other Rack compatible framework? Want drag-and-drop and point-and-click development server management? Then you need Passenger Pane. We’ll walk you through the installation process and show you how to get a simple Rack application up and running. Thanks to Jason Noble for his help getting everything working.

Passenger Pane is an OS X preference pane designed to work in concert with Phusion Passenger and your OS X Leopard's default Apache2 installation (the same one that serves your Web Sharing). Setup is pretty simple and will probably take about 10 minutes. Here's what we're going to do:

Install Phusion Passenger
Install Passenger Pane
Serve a "Hello World!" Rack endpoint
Profit!

Install Phusion Passenger

Phusion Passenger is the (not so) new hotness in the Rails deployment world. Phusion is great for serving Rails applications via Apache in production (especially in concert with Rails Enterprise Edition, which provides a 33% memory savings over standard MRI Ruby), but it's also great for simplifying your development environment.

The Phusion team have done a great job on the passenger install. Here are the official installation instructions. We'll repeat them here for the sake of convenience.

Open a Terminal window.
Install the passenger gem:
```
sudo gem install passenger
```
Install the passenger apache2 module:
```
sudo passenger-install-apache2-module
```
Include the module and some supporting configuration settings into an apache conf file. The code will be provided by the passenger install script.
Finally, add a Directory directive to your apache2 config that allows access to the directory where your app source codes are located. You can put this at the bottom of your passenger.conf file (replace my source directory with yours):
```
<Directory /Users/reinh/code/>
  Order Allow,Deny
  Allow from all
</Directory>
```

Note: We put the passenger apache configuration in /etc/apach2/other/passenger.conf (a file we created). The default apache2 httpd.conf imports all .conf files in /etc/apache2/other.

Install Passenger Pane

Passenger Pane gives you a Preference Pane that lets you add, remove and manage apps deployed on Phusion Passenger. Drag-and-drop to serve a new app and restart with a single click — it even provides host entries for each app so you don't have to mess with virtual hosts or your hosts file. This is great for serving multiple applications simultaneously or just generally being awesome.

Installation is simple. Download the preference pane from their homepage and double-click to install. If you installed Passenger correctly (as above), this should just work. If not, look for errors in Console.app or a helpful notice in the preference pane and ask for help on the Passenger forums or in the #passenger channel on irc.freenode.net.

After installing Passenger Pane, you will need to restart Apache. The simplest way to do this on OS X is to open the Sharing preference pane and uncheck and recheck Web Sharing.

Serve A "Hello World!" Rack Endpoint

Let's test that everything is working by creating a simple Rack "Hello World!" endpoint.

Install rack:
```
sudo gem install rack
```
Create a new directory called rack-hello-world.

Add a file inside it called config.ru with these contents:

run lambda{|env| [200, {"Content-Type" => "text/plain"}, ["Hello World!"]]}

Create a public directory inside rack-hello-world (you'll see why later).
Drag the rack-hello-world folder into your Passenger Pane panel (if you're using TextMate, you can drag it from the project panel). You will probably need to click the lock first to allow modifications.
Browse to http://rack-hello-world.local and behold the awesome!
Profit!!!

If you've done this correctly, your Passenger Pane should look similar to this:

Your browser should be showing you your glorious "Hello World!" homepage.

Now you can drag in the app folders of any Rails, Merb, Sinatra or Ramaze applications and have them instantly served by Passenger. In fact, any Ruby web application that can run on Rack can be run in Passenger Pane. How's that for a painless local development environment?

Note: Why (I hear you asking) did we create a public directory? The answer is that Apache expects to serve a public directory and will fail if one is not found under the root of the app you're serving. If you had not created the directory, you would have to look at your apache error log (usually located at /var/log/apache2/error_log) to find out what went wrong.

Simple Git Continuous Integration

2008-02-21T16:16:28-05:00

Update: It looks like Chris Wanstrath (of Github fame) beat me to it. Clearly, the git is strong with this one.

Preventing your developers (and yourself) from breaking the build is as simple as putting this in your .git/hooks/pre-commit and making it executable (chmod +x .git/hooks/pre-commit).

#!/bin/sh
rake spec 2> /dev/null

This will stop the commit if the specs don’t pass.

This isn’t a replacement for a more robust CI system but it does make it a lot harder to do something stupid. Redirecting STDERR to /dev/null is optional but recommended since the STDERR output of failing specs isn’t useful. It you use Test::Unit instead of RSpec (for shame), use rake test instead. Likewise, anything that returns proper error codes (0 for success, > 0 for failure) can be used.

This is mainly useful if your specs take under a minute to run, otherwise it becomes tedious. If you have long-running specs, I suggest using a special task that runs an abridged set of core specs instead.

REST & Rails

2007-11-13T12:29:16-05:00

I am giving a presentation on Rails, REST, and the Resource Oriented Architecture today entitled “REST & Rails: Web Services for the Rails World”. Check out the slides.

Custom Textile Tags For Great Justice

2008-04-09T20:56:01-04:00

fig. 1.1 | elem-typo-style.png

Taking some inspiration (and code) from the quirky but lovable _why’s original post on adding yer custom blocks to RedCloth and the inimitable Geoff Grosenbach’s foray into the world of custom textile figure tags, we’ve build a custom tag (or prefix) for this blog’s own figures, like (Fig. 1.1) there on the right.

RedCloth’s textile implementation uses some simple metaprogramming to create its own tags, which allows you to (more or less) easily create new tags to suit your own needs. The basic formula is: write a textile_#{ tag } method, where tag is the name of the tag you want to create. This method takes four arguments, tag, atts, cite and content, which are parsed from the textile by the RedCloth engine.

For our purposes, we’re only concerned with content and atts, so I’ll leave the rest as an exercise for the gentle reader. The html we’re trying to create looks like this:

<div class="img" id="figure-1-1">
  <a class="fig" href="/images/image.jpb">
    <img src="/images/thumbs/image.jpg" alt="Figure 1.1" />
  </a>
  <p>Figure 1.1</p>
</div>

The tag we want to use to create it looks like this:

fig. 1.1 | image.jpg

That’s quite a bit shorter and more elegant. Jumping right in to the good stuff, the method definition for our new tag looks like this:

def textile_fig(tag, atts, cite, content)
  span_class = "img "
  if atts =~ /class="([^\"]+)"/
    span_class += $1
  end
  (figure_number, img_url) = content.split("|").map { |w| w.strip }
  figure_name = "Figure #{figure_number}"
  figure_id = "figure-#{figure_number}".tr(".", "-")

  %{
  <div class="#{span_class}" id="#{figure_id}">
    <a class="fig" href="/images/#{img_url}">
      <img src="/images/thumbs/#{img_url}" alt="#{figure_name}" />
    </a>
    <p>#{figure_name}</p>
  </div>
  }
end

Let’s break that down.

span_class = "img "
if atts =~ /class="([^\"]+)"/
  span_class += $1
end

This adds any classes in atts (in the form of class="foo") to the base class, img.

(figure_number, img_url) = content.split("|").map { |w| w.strip }
figure_name = "Figure #{figure_number}"
figure_id = "figure-#{figure_number}".tr(".", "-")

This breaks “fig 1.1 | image.jpg” down into two parts by splitting on the “|” and then normalizes them a bit to be used later.

Finally, the relevant parts are jammed into the html prototype and spit back as the method’s return value for insertion into your textile document (and for great justice, of course).

fig. 1.2 | ReinH-07.png

A later post might show the way __END__, DATA and if __FILE__ == $PROGRAM_NAME were used with the TextMate Ruby Bundle’s ⌘R command to preview the output of the textile tag as it was being written for a faster workflow or the jQuery used to activate the thumbnail’s hover effect while an inline link like (Fig. 1.2) is hovered. But I wouldn’t hold your breath.

To Design A Blog (act 1)

2008-02-25T15:22:24-05:00

Your blog’s role as personal soapbox is obvious; its role in establishing identity is often overlooked. As a designer, your blog speaks volumes not only by what it says, but also by how it says it. If you can’t design your own blog – they will say – how can you design anything else? It was with this in mind that I set out to redesign my own blog.

As an entry point for colleagues and potential clients, your blog’s first impression is crucial. Snap judgements will be made that you may never be able to escape. Your design must inform your readers as to your abilities with grace and flair. It must establish your visual style distinctly and succinctly. It must be both well orchestrated and well rehearsed. It must, in short, be great.

The Design Process

Before setting pen to paper, hand to mouse or fingers to keyboard, I began by thinking about what kind of response I wanted to elicit from my readers. I decided that want it to be warm and inviting, rich in information, and clean and elegant; it should be visually consistent, easy to read, and easy to navigate; most importantly, it should look like me.

This lead to a few clear design goals:

Strong, consistent typography
Simple, uncomplicated layout
Minimal but effective use of color

The design itself went through a number of iterations, beginning with simple pen-and-paper sketches. At the beginning, I imposed a few constraints to help focus my efforts: Single column, 800px width, gridded layout, three fonts. The content would reign supreme. Consistent typography would establish a visual hierarchy.

In The Beginning Was The Typography

(Figure 1.1)

Sorting out the typography goes a long way towards giving your design a strong, cohesive style. It is important to chose two or three fonts (and no more) and to use them consistently. It is also important to use consistent font sizing to establish a visual hierarchy.

I decided on Helvetica (specifically Helvetica Neue when available) for headers and Verdana for body text. Helvetica was chosen for its readability at medium to large point sizes and flat out gorgeousness. Verdana was chosen for its ubiquity and readability on screen at small to medium point sizes.

Rock Out With Your Layout

Most blogs use a two-column layout with a sidebar on the right to display subordinate information. Here, I choose a more minimal approach: a single column with information presented serially according to importance. The home page is streamlined to encourage the reader to discover subordinate content, as will navigation links at the top.

Also, the typography was further refined. A serif font is added for subtitles and meta information (like post date). Finally. the main heading font is pumped a bit to help the major sections pop.

(Figure 1.2)

A quick look at Figure 1.2 will reveal that the initial read is much improved. The main content sections (the latest post and the list of recent posts) stand out as clearly differentiated. There remain, however, some issues with the font sizing and the spacing of elements. Also, the footer’s columns appear rather haphazardly placed.

Coming up in act two, the layout and typography get cleaned up and we add a splash of color. Don’t miss it!

To Design A Blog (act 2)

2008-02-26T21:28:16-05:00

fig. 1.1 | ReinH-02.png

In our first installment, the typography and layout of the blog were mostly decided. With this ground work in place, it’s time to start focusing on the details. But first, it’s time to give our eyes and brain a chance to relax and reset. Staring at the same design for hours tends to give you tunnel-vision and we want to be able to look at the site afresh.

Now that we’re ready to continue, the most obvious issue is the arrangement of the sections in the footer. The rest of the design follows a strict grid system but the haphazard placement of the bottom columns is jarring to the eye and the whitespace between them is also problematic. (Fig. 1.1).

fig. 1.2 | ReinH-03.png

A third column is added and the columns are properly aligned with the grid layout once again (Fig. 1.2). Great success! The remaining changes are all relatively minor and mainly involve tweaks to font size, color, and spacing. Bonus points if you can spot them.

Now then: Welcome to the new blog! Enjoy your stay.

Git It, Got It? Good!

2008-02-19T17:07:08-05:00

Last week, I gave a presentation on the git version control system. Apparently it went pretty well. The slides are available for those who are interested.

A Retraction

2008-12-05T13:10:30-05:00

The folks over at Woobius have offered their sincere apology over what I believe was a simple misunderstanding and have made several changes to their blog design in response to my last post. I appreciate the professional way that they have handled the situation and have decided to retract said post in response to their request.

I am not changing my stance on whether or not my design and content are open source and open to reuse (they are not). I will include a more explicit license to try to prevent such issues in the future. I would very much like to keep my blog’s source publicly viewable on Github. I may need to discuss with the Github team the legal implications of their TOS for public repositories.

I would also like to find a licensing solution that would allow me to open certain parts of the source (my customizations of Webby and the various helpers and tools in my lib directory, for instance) but still allow me to keep the design and content proprietary. I welcome any suggestions in the comment section below.

I wish the Woobius team the best and look forward to seeing the direction that they take with their blog now that this misunderstanding has been cleared up. I hereby officially remove their evildoer status and downgrade them to unfortunate-misunderstanding-doers. I have also called off my Lawyers of Justice.