The Hippy Hacker

Write the first one ugly

Mon, 26 Jul 2010 15:17:28 GMT

The desire for perfection can paralyze software developers. Sometimes we know the gist of what we want to write but not which names to use or the constructs to define. So we stare at our blank screen and cogitate. We ponder, pondering our pondering, and ponder our pondering of our pondering.

To overcome paralysis, for small chunks of code, it is often better to just write whatever comes to mind – no matter how awful it may seem at the time. Give yourself permission to let the first version suck. You may even *gasp* not TDD (“Test Driven Development”) it. Just make it work. Just do it. You’re only pushing bits around on a screen. You can change it later! For those of you who always always always test first, this may even feel a little liberating (while feeling a tad naughty in a good way).

This is not software development technique. This is a productivity technique, pure and simple, straight from the writing of David Allen of Getting Things Done.

Also this is not just spiking. Spiking is, essentially, prototyping a small problem area for learning purposes. We’re not going in planning to throw code away – only our standards but only for a few minutes.

At the very least, this approach will serve the same purpose as a spike. You’ll better bound the problem, you may have a partial or working solution, but you have concretely captured the problem at hand. It sure beats the alternative of having an amorphous concept bouncing around your noggin.

How often do I do this? All of the time. For every piece of code, blog post, or email that I write, I blurt out whatever comes to mind first then I refactor (although, yes, I often, but not always TDD it when writing code). And when I refactor, yes, my standards come back into play. It works. Try it.

Recruiting freelance help for your startup with equity

Sun, 18 Jul 2010 15:24:06 GMT

If you’re reading this, you’re probably looking for a few hands to work on your startup. You’re probably also tight on funds. And, so, you’re considering giving away a stake in your possibly yet-to-be-realized vision.

Since I’ve begun offering freelance services about a year ago, I’ve had several customers offer to compensate me with equity. I have yet to meet a single freelancer who took an engagement with a customer offering equity. Most of us won’t. I never have.

Once I hear “equity”, I’m typically turned off like a switch.

Freelancers, in particular, are in business for themselves. Most of us don’t want to be tied down to a single startup unless its ours. We may even be looking to develop our own products.

Instead of payment, you’re offering equity as compensation; effectively, you’re asking us to invest in your startup. Most startups don’t have successful exits. The common perspective, then, is that your equity offer is worth only the paper or electrons it’s printed on.

You may be able to retain neophyte developers who are looking to build up their portfolio but you probably shouldn’t. Some of them will work, effectively, for free. However, typically, you get what you pay for. A novice developer is just as likely to give you negative productivity than a usable product.

Before spending an hour telling us all about your glorious idea, first determine if you can possibly close us. Pitch us as you would a real investor. But you ought to be sure that we’re at least open to the idea. You’re almost certainly wasting yours and your prospective developer’s time if you don’t first. Again, most of us aren’t interested. You’ll save yourself a lot of time by asking the simple question of “will you work for equity?” first. Feel free to ignore this if you enjoy spending a lot of time pitching people and having nothing to show for it.

Remember, you are asking us to become an investor. Sell us on you. Sell us on your idea. Coffee is for closers!

Maybe, just maybe, you’ll get a quality developer out of the process. But you have to remember that you’re asking that developer to be an investor.

"Business is business" is a dirty excuse

Fri, 16 Jul 2010 07:10:47 GMT

Over the past several months, while attempting to develop my previous business and now a new one, I’ve immersed myself in books about entrepreneurship and marketing. Most of them promote ideals that I already adhere to: authenticity, honesty, building trust, and the value of relationships. I don’t adhere to these principles out of a desire for fiscal success. I adhere to them because it is who I am, win or lose.

If you are the least immersed in popular culture then you have undoubtedly heard the phrase “Business is business.” During my career, I’ve encountered this phrase more often than I would like.

I am frustrated to occasionally see seemingly otherwise decent people descend to morally questionable depths when money becomes the issue at hand. It is as though business is this separate world where Machiavelli is welcome even though in this other world that we call “life” he is not.

If you’ve seen the HBO series “The Wire”, “Business is business” is the sort of utterance that one of the corner drug dealers may say after ratting out a pal to save his own skin or gunning down a comrade who earned the ire of the kingpin. It is an excuse for breaking social contracts in favor of financial gain. It is a rationalization for what, in otherwise friendly company, is selfish and often unkind behavior. It is a dirty excuse for blithe indifference.

Instead, I prefer to say “Business is personal” – because it is.

If it’s truly not about whether you win or lose but how you play the game then how we do business may provide the ultimate example of ourselves. At stake is no less than the welfare of ourselves and our loved ones but also who we are: our moral character.

What says more about who you are than how you treat other people when the stakes are high?

How do you want to be seen by the world? How do you want to be remembered?

Why you should work with me

Mon, 21 Jun 2010 09:12:56 GMT

I believe in candor.

I always give a straight answer. Sometimes that answer isn’t the one that you want to hear. However, I believe that hiding the bad news from you only weakens our relationship and your project.

I want to see you succeed.

To that extent, I will help guide you through the process, providing my insight to add value to your business. At any given time, if you’d rather that I do it your way, I’m open to it, because….

I want my customers to be happy.

Few software developers and consultant realize it, but the software development consulting business is, first and foremost, a customer service business. If you’re not happy then our relationship will not be mutually beneficial. And I always seek the WIN-WIN.

I ship.

At the outset, we will agree on a release date/window for your product. We will together prioritize the features that you need for your Minimum Viable Product. This is part of the agile development methodology that I loosely follow. This will also likely define your first release. And it will ship on schedule.

I believe in forging meaningful long term relationships.

Engaging me alone, or with several of my peers, is not engaging a business but forging a relationship. Good business is built upon the understanding and trust in that relationship. The better that we understand one another, the better we will work together. From day one, I am trying to understand you and your needs to better add value to your business. Trust comes with everything else that I’ve already cited above (e.g., candor, shipping).

Please do feel free to contact me with opportunities at sleight42 AT gmail DOT com. Subsitute the “AT” and “DOT with “@” and “.” for the actual email address.

One-off/user-customized products in Spree

Sun, 21 Mar 2010 19:43:58 GMT

One of our clients sells customizable products. He contracted us to write a webapp to facilitate the process for his customers. We decided to go with Spree for the integrated eCommerce and order fulfillment capabilities. Having written eCommerce implementations before…

… Spree sounded like a much better option.

The trick then became how we would represent these user customized products. As it turns out, Spree supports this in the model out of the box. In Spree, products are represented by instances of the Product class. However, they can also be represented by Variants of a Product. That is, a Product has many Variants. Variants can vary by price but they also can vary by OptionValues.

I know: OptionValues is quite a mouthful of generic stuff.

But they’re useful! Let me explain.

In Spree, a Product can have multiple OptionTypes. Each OptionType describes what amounts to a container for an enumeration. The OptionType then has OptionValues. These OptionValues are the values in that enumeration. And Variants have many OptionValues.

When you put it all together, it looks something like this:

Now that is one tasty burger!

The only downside that I see is that, for one-off/user-customized products, at a minimum, you will be creating a Variant with permutations of OptionValues for each line item in a user’s order containing a customized product resulting in a cluttered products table. If you’re willing to do a little extra work, you could probably elaborate upon the Spree model to determine if a Variant already exists with your desired permutation of OptionValues before going off and creating one.

So there you have it.

RVM + Bundler + RubyMine

Fri, 29 Jan 2010 14:09:27 GMT

On my current project, we needed to be able to use RVM with Bundler but we want access to our bundled gems from Rubymine.

You’re going to want to write an alias in your .bashrc/.zshrc/.whatevershrc for this one. You can use most of the below:

export PROJECT_PATH=the_path_to_your_Rails_project_using_bundler_goes_here
alias rubymine="rvm ruby-1.8.6-tv1_8_6_287 ;\
export GEM_HOME=#{PROJECT_PATH}/vendor/bundler_gems/ruby/1.8;\
export GEM_PATH=${GEM_HOME};/Applications/RubyMine\ 2.0.1.app/Contents/MacOS/rubymine"

What we’re doing here:

We then override the gem repo to point to our bundled gems (which are conveniently formatted as a gem repo)
Then we fire up Ruby Mine with the above environment (Thanks to Brennan Dunn here).

Now close and reopen your shell.

From there, you go into RubyMine’s settings, click on “Add SDK”…

… unhide the hidden directories like so…

… then navigate to your Ruby VM and hit OK:

Voila!

Mocking mocking (or "Why I am learning to hate isolating the unit under test")

Mon, 25 Jan 2010 20:47:11 GMT

Mocking basically sucks.

There. I said it.

Using mocks in your tests almost always results in fragile tests.

Why?

A case against mocking

Let’s say that you’re working on a hypothetical (simplified) financial application:

class AccountTest < ActiveSupport::TestCase
  setup do
    @balance = 42.00
    @account = factory_to_create_a_test_account :with_balance => @balance
    @mock_bank_manager = mock(BankManager)
  end

  def test_overdrawing_account_sends_notification
    @mock_manager.expects(:notify_of, :overdrawn_account, :amount => 1)
    @account.withdraw(@balance + 1)
  end
end

The above example is attempting to illustrate how mocks can be useful for specifying a causal relationship. “Overdrawing the account” results in “notifying the bank manager of the amount over balance”.

Mocking seems like such a natural and even expressive way to design an API. It’s, quite literally, behavior driven development: your tests/specifications, where you are mocking the API, are helping you design the API itself! That’s terrific.

So let’s pretend that, like a good TDDer, I’ve gone and implemented the BankManager class.

class BankManager
  def notify_of(event_type, options = {})
    case event_type:
    when :notify_of
      # send the notification
    when ...
      ...
    end
  end
end

Perhaps I even wrote a test/spec for BankManager. But, then, in a fit of refactoring rage, I decide that I must have a second argument to BankManager#notify_of:

class BankManager
  def notify_of(event_type, account, options = {})
    case event_type:
    when :notify_of
      # send the notification
    when ...
      ...
    end
  end
end

Our old friend AccountTest above will still pass because it’s using a mock. However, the API to BankManager has changed; we want AccountTest#test_overdrawing_account_sends_notification to fail!

So, in short, mocking an internal API is a recipe for pain and (Ni!) woe.

After you implement the API, you still have mocks lying around in the test that helped you mock out the API design in the first place. This test is now fragile. If the API changes, the tests containing the mocks will still pass!
You can double back and replace those mocks with actual calls to the API but you just made more work for yourself

Where mocking makes sense

In my experience, the only place that mocks have served me at all well is when I’m interfacing with an external service from a unit test. I certainly don’t want my unit test invoking services beyond my own system. I usually write an interface layer between my business logic and the external service. In my unit tests, I then mock the interface layer only. Testing integration with the external service, predictably, becomes a chore solely for the integration test.

We have the technology. We can rebuild it.

I believe that there is a better path: one that will let us have our mocking cake but now force us to eat brittle tests. I’ve had some ideas about this on the back burner for about a year now. However, I hope to have something concrete to discuss in a few weeks.

On Craftsmanship and Practice

Mon, 11 Jan 2010 23:26:06 GMT

Reading a passage from the “E-Myth Contractor” got me to thinking about how we practice (when we practice) our skills that we apply on a regular basis.

When we practice our craft, performing “katas” as they have come to be called, why do we perform them on arcane problems such as Langdon’s Ant or Conway’s Game of Life?

You don’t encounter these problems in your day-to-day work.

I agree that solving these problems a few times over may improve your overall problem solving skills. But that’s only true until you settle on an optimal implementation.

Given the above then there seems to be greater value in routinely exercising what we consider routine.

If I can build a signup, login,and forgotten password capability, a text-based search across multiple model objects, or a recurring payment ecommerce system rapidly and reliably, isn’t that more valuable to most customers than finding clever ways to move a hypothetical ant around a grid? These are the sorts of tasks that we routinely encounter in our work. Or perhaps not. Maybe you typically employ a CMS to expedite these chores. This is because craftsmen use tools to work in their craft.

So you should be practicing with those same tools.

If you have a good toolbox, full of tools ideally suited to solving problems your typical problems, then these tools are your weapons. Each tool probably does certain things better than others. You should then practice “weapon katas.”

You should master your tools.

Let’s assume for a moment that your current project/product/service du jour is not a unique and special snowflake. If what we do is a craft, then repetition and understanding of the routine tasks should enable us to deliver faster, more reliably, and more consistently.

Perhaps studying Langdon’s and Conway’s, ultimately, is a study of basic forms, i.e. this is how I BDD something different. Once we grasp these basic forms, it is then time to move on to how we employ our tools, i.e., our favorite plugins and gems, until we’ve mastered those as well.

Doesn’t this make us better craftsmen?

… that is, until someone introduces a better weapon.

I freely admit that this is not how I currently practice. I feel that my basic form is solid. Howver, I admit, I do need to better acquaint myself with my weapons. As of now, this is what I intend to practice. I will try to report on how it goes.

Shouldn't developer tools be for developers first?

Mon, 04 Jan 2010 22:45:18 GMT

As (I believe) Jonas Nicklas pointed out in response to ThoughtBot’s post on integration testing, Cucumber is largely ineffectual in a project until you build up a library of domain-specific matchers and their respective code blocks.

What this represents is external domain-specific language design via regular expression.

The reasonable use of this is to facilitate the expression of desired behaviors by non-developers. For example, I have tell of organizations where QA people, for instance, write automated acceptance tests using Cucumber.

I share the Cucumber team’s belief that customer communication is essential. That’s facilitated, in Cucumber, by writing features in plain text (Gherkin). Cost is saved when issues are addressed in specs versus code – likely why the waterfall model was so popular at first. It’s just common sense.

It’s a form of risk management.

Every feature goes hand in hand with the risk that it will fail to be implemented to meet customer expectation. A risk becomes an issue, in this case, when a feature is implemented in a fashion differing from the customer’s expectation. The earlier that risk is mitigated, the less money/effort/time is wasted on the project handling risks that manifest into issues.

One way of mitigating that risk is to communicate to the customer how that feature will behave in the language of the customer’s domain.

Coulda solves the same problem. It has a rake task for marshaling the Feature, contained Scenarios, and all of the statements (Givens/Whens/Thens) into plain text.

However, Coulda shares many of the considerations Dan cites above:

“Features” are just Test::Unit::TestCases
“Scenarios” are just tests
“Statements” (Given/When/Then) are just steps taken within a particular test

When I use Coulda on a project (I’ve used it on the job at this point), I don’t start with the intent of building a language. I know that I probably will, because I have, as my work progresses. I start by writing pending Features, pending Scenarios, pending Statements, and then I begin putting flesh on the bones. I refactor my tests. When I encounter duplication within a Feature, I Extract Method. When I encounter duplication across Features, I Extract Module (I’m guessing that’s in Ruby Refactoring but you likely get the intent: I create a module, move my method into the module, and include the module in my Coulda Features), and so on.

What bothers me so much about so many libraries, in general, is that they try to solve all of my problems.

That’s great but I don’t want that. Just like I don’t want to buy a car with a 500hp engine because I simply won’t need it. I just need a car.

So I kept Coulda simple. If you need more, great, then write it! If you find that you need the same thing repeatedly, great, make a new gem from it!

Automate what you need to do often. If you have an edge case, keep it out of your libraries, thank you! My brain has a hard enough time absorbing the ever-increasing size of the Rails API (and this from a guy who worked in J2EE hell for years).

Remember, these are the kinds of practices that gave us Rails. Don’t try to solve everyone’s problems. Focus on the frequently recurring problems. Scratch your own itch (I did!).

"Grid" layout in Android

Sat, 28 Nov 2009 15:09:25 GMT

You know how your mother (or, in this case, your front end developer friends/colleagues) always say “never use a table for formatting unless you’re really making a table”

That may be true for HTML. However, it doesn’t seem to hold when you’re working with Google’s Android.

You see, now that I have a shiny new Motorola Droid (see my previous post), I’m now working with Android in my spare time.

I was struggling with using Android’s UI XML to layout a simple login page. And I was going nuts.

I was trying to use A LinearLayout containing several RelativeLayouts, one for each row. “Row” should have been the clue.

After poking through the PragProg Hello, Android book for a bit, I found an example later in the book that used a TableLayout.

That was my aha moment.

TableLayout is pretty simple to use. It is designed to contain several TableRow (a ViewGroup child as are other *Layouts). A TableRow looks thus:

<TableLayout
  android:layoutwidth="fillparent" 
  android:layoutheight="wrapcontent"
  android:stretchColumns="1" 
  android:padding="10dip" >
  <TableRow
    android:layout_marginBottom="10dip">
    <TextView
      android:id="@+id/login_label"

      android:layoutheight="wrapcontent" 
      android:text="@string/login" />
    <EditText
      android:id="@+id/login_field" 
      android:layoutwidth="fillparent" 
      android:layoutheight="wrapcontent" 
      android:lines="1" />
  </TableRow>
  <TableRow
    android:layout_marginBottom="10dip">
    <TextView
      android:id="@+id/password_label" 
      android:layoutheight="wrapcontent" 
      android:text="@string/password" />
    <EditText
      android:id="@+id/password_field" 
      android:layoutwidth="fillparent" 
      android:layoutheight="wrapcontent" 
      android:lines="1" />
  </TableRow>

</TableLayout>

The android:layout_marginBottom attributes on the TableRows are entirely optional. However, odds are that you will want to add some sort of formatting to your TableRows.

Incidentally, there may be DRYer ways of representing rows in Android XML (i.e., something similar to a Rails partial); however, admittedly, I’m still very much learning Android.