Intellectually, I am a big fan of all the "new" and cool lean startup and customer development methodologies. To be honest, I am more into the underlying principles and patterns and ignore most detailed "step-by-step" blog posts in favor of my own common sense.

For example, at first I was pretty annoyed by the Erik Ries's release of this "The Lean Startup" because I thought it was a write-down of all the basic common business sense and after-the-fact reasoning when looking back at the Dropbox and Intuit cases. I thought I had learned nothing new from it apart from some tips & tricks on metrics and stuff.

Now, however, I think it is a great book because it shows you examples and best practices to point you where the underlying principles and patterns might be implemented for your business. It also does not try to shove a certain way of working into your face like most of the customer development and lean startup resources I am seeing nowadays. A fireside chat with Steve Blank a few weeks ago made me realize this even more.

What I think seems to be the case is that all "lean startup implementers" are so busy trying to implement the guides, best practices, video tours, books, blog posts and step-by-step guides that they are actually forgetting how to develop a wider range of "common business sense".

When failing, most people that I read about seem to think: "Oh, bummer, I am not implementing these best practices good enough. I should do more interviews! I should set up better experiments! My landing page isn't designed correctly and I should A/B/C/D/E/F/G-test more!"

Because, of course, Erik Ries said that entrepreneurship (or entrepreneurial management) is something that can be taught and is not something your mum and dad put in you on that cold wintery night with that bottle of wine in the lake-side cottage.

Obviously, those detailed best practices and guides to launch A/B-tests, designing landing pages or how you can do better experiments instead of just doing "something" are very helpful on an operational level. I think however, that they are definitely not the critical things of why you are failing or succeeding.

The cause for failing or succeeding on a personal or entrepreneurial level is something that's much deeper and probably takes years of practice, working hard and studying to get to the sweet spot.

If you truly deeply figured out how to run a business (may it be your current one or many after failing 20 times) you are never ever doing "just something", even if you think you are. Your brain is made for making both conscious and unconscious decisions based on a lot of factors you might not even realize and you can train and develop these skills by practice and study.

Seeing numbers that over 80% of businesses fail (startups or no startups) and that a lot who actually succeed have never done an A/B-test or followed a lean startup book makes me wonder and intuitively support the (developing) opinions in this post. I do believe however, that most succeeding companies and teams intuitively follow the underlying principles.

I think that what we can all agree on is that most of these methodologies (correctly) focus on one big aspect: who actually is my customer and how can I try to understand my customer better. Eventually resulting in creating a great product/service/organization that they love, use and hopefully want to pay big time for.

What I think the big problem actually is that most lean startup practitioners think that you can understand and empathize with anyone as long as you use those a/b-tests, interviews and canvasses.

Bull shit.

Truly, deeply coming onto a level with someone to understand the motives is very hard and isn't just fixed by using some tools or spending a few moments with them. To truly understand people you need to be either one of them, or you need to be in close contact with them on a more than formal level. (Friends, family, colleagues, exercising mates)

You need to observe and participate to suck in all the intricate details that make up someones mental model. There may be a lot of very important unknowns that you probably don't even realize at the start and you cannot frame in just a few interview questions.

Following the trends and hearing the stories for the past few years I think I am coming to the understanding that there are only two groups you can build a successful product for by focusing on the problem they are having:

• Yourself.
• Friends, families, close relatives and members of associations or organizations you are a part of or stand close to you on a daily basis.

For any other external group that "seems nice" to build a business on because you think it's big $$$ or that you are the coolest guy if you pull it of are a waste of energy, even if you succeed. Not only for yourself - since making something for someone you don't know or don't really care about is emotionally unrewarding.

But also because there is actually someone else out there who is already in that group and already meets those people on a day-to-day basis and is probably a 1000 more capable of empathizing with that customer group than you are.

Please focus your energy on building a business for people that you absolutely love already. Don't go looking for some group in the next village that has a different language, culture or problem than you think they are having.

There's a guy in that village just like you who can probably help those people with way less energy and more passion than you have to spend.

I love learning new things. Yesterday I started picking up guitar practice again. When I was in my teenage years (true, only four years ago) I played the piano a lot and DJ't around as a hobby so I have always been interested in playing (musical) instruments.

What I like about practicing the guitar is that for me as a beginner, so much depends on getting the hold of the strings right against the frets. Every minor change of my palm, my wrist and the angle in that I keep my finger tips down has an effect on the vibrations when I pick the notes in the accord I am practicing.

No one can tell me how to hold my hand exactly or how much pressure I should use to press down on the strings. It is only I who can feel and hear when I've got the right vibration. By picking the same chord 50 times in a row with a minor change of my palms and fingers each time I can improve my play.

I think a lot about learning an instrument can be applied to software design and development as well. Or any craft for that matter. You can only know what you need to change when you've tried it and you can only get better by practicing over and over again.

How are you getting better at your craft? Whatever it is.

Today, I wanted to test a synchronization script we have running between two apps that uses an Active Resource.

It's a script that runs in a DelayedJob worker that gets queued when a user pushes a button. The job synchronizes new products from one backend application to a web shop frontend.

In the test that I was going to write I didn't want to make a call to some test server so I was looking for some way to mock ActiveResource.

Two resources to get started

Luckily, you get that out of the box as described in a the post ActiveResource and Testing by ThoughtBot. Also, there is some info about it in the API docs for ActiveResource::HttpMock.

Testing my new feature

A bit simplified the job does the following:

• Fetch all the products using the ProductResource from /products.xml
• Walks trough them, see if we have them in the local web shop database.
• If not, create it. Otherwise, update current info and descriptions.

The new thing that I am adding today is a way to check if current products have been archived (deleted) in the backend warehousing system and to disable and hide them in the shop frontend with the synchronization job.

For this, I created the following test case. Be sure to explicitly require active_resource/http_mock since it isn't loaded by default.

require 'test_helper'
require 'active_resource/http_mock'

class SyncTest < ActiveSupport::TestCase

  def setup

    archived_product = { :id => 1, :archived => true, :ean8 => "12345678" }.to_xml(:root => "product")
    regular_product = {:id => 2, :ean8 => "11111111"}.to_xml(:root => "product")

    ActiveResource::HttpMock.respond_to do |mock|
      mock.get "/products.xml", {}, "<products type='array'>#{archived_product}#{regular_product}</products>"
    end
  end

  test "an archived product should be set to deleted" do

    product = Factory(:product, :external_id => "12345678", :state => "available")

    Sync.perform

    assert_equal "deleted", product.reload.state

  end

  test "an available product should not be set to deleted" do

    product = Factory(:product, :external_id => "11111111", :state => "available")

    Sync.perform

    assert_equal "available", product.reload.state

  end

  test "a currently deleted shop article should be set to inactive when not archived anymore" do

    product = Factory(:product, :external_id => "11111111", :state => 'deleted')

    Sync.perform

    assert_equal "inactive", product.reload.state
  end

end

And here is the code for the actual job. I have left out all other code that does not reflect those test cases for simplicity in presentation:

class Sync

  def self.perform
    products = ProductResource.find(:all)

    products.each do |product_from_api|
      if product = Product.find_by_external_id(product_from_api.ean8)
        if product_from_api.archived?
          product.state = 'deleted'
        else
          if product.state == "deleted"
            product.state = "inactive"
          end
        end
        product.save!
      end
    end
  end

end

Need help with testing your app?

If you want some help testing stuff like this on your own app please let me know. I would be very happy to help you in a comment on this post or just get in touch!

This short post is inspired by a @coreyhaines tweet: One mark of a good developer is the ability to conform to the style of an existing codebase.

I agree with this. One of the most important skill of every programmer is the willingness and ability to confirm with an existing codebase.

If you want to even be more awesome as a developer I think it is also important that you are always looking to improve the current code bas and state of the product.

Every little detail you notice that can be improved, you should improve it even if it's not officially part of the task you are working on right now.

Some simple examples:

• Fix some spacing in CSS.
• Refactor code or move code over to better methods.
• Rename some variables in a method so they are easier to read.
• Look for opportunities to create indexes in the database if you feel a query is just too slow.
• Write some new tests or get rid of old or obsolete ones.

37signals posted a few blog posts about how they made their upcoming Basecamp (Next) product so blazingly fast.

Amongst other things, an important factor is using their caches to THE MAX (as @dhh puts it). Which basically means: cache every representation of some state (a to do item, a todo list, a project page, etc).

The technique they are using is key-based cache expiration. Meaning, that you keep caching every fragment based on the updated_at timestamp of the object that might change.

With this comes an advantage: you will never have to expire caches since your views will always look for the fragment with the most recent updated_at timestamp of the underlying model. Your memcached server will then take care of expiring by popping the oldest key out if memory runs out.

It's really that simple

So just to illustrate how simple it is, I wanted to show you how I implemented this today in the custom-build blog engine we're using to host some of our own and other people's blogs. This is an app that runs on Heroku and you are looking at it right now.

Every post you see on this blog is a fragment that gets cached using the free 5mb memcached addon from Heroku.

To install the addon, run the following command in your app:

heroku addons:add memcache

It is recommended to use the Dalli gem for using the memcache server in your app. So add the gem to your Gemfile:

gem 'dalli'

And add this to your config/environments/production.rb so Rails knows you're using Dalli for the cache:

config.cache_store = :dalli_store

For all the posts on the blog I have a _posts.html.erb partial that renders a single post. So, in that partial I can include the line:

<%= cache post do %>
  <h1><%= post.title %></h1>
  ... etc ...
<% end %>

The cache method will use a key like "posts/3-20071224150000" for the object based on the updatedat method. Under the hood, the *cachekey* method is used.

So, when I would fix a typo in the post the updated_at column will have been updated, hence the cache key will also be updated and the cache will generate the updated post partial with the new cache key.

But what if I change the contents of the partial?

If you change the actual code in the partial the posts that are already in the database won't have a new updated_at so they will keep using the cached old generated partial.

I am currently solving this by adding a prefix to the cache key like so:

<%= cache ["v2", post] do %>
  <h2><%= post.title %></h2>
<% end %>

This way the next time someone opens a page with posts, the new partial is going to be used since the key that is now requested includes "v2".

I found this method a bit tedious for now since it is easy to forget to update the prefix cache key for the version of the partial. Would be great to have some kind of automated thing for this based on if the partial is changed or something.

But for now, manually updating the prefix seems easiest.

Questions or comments?

I hope this post illustrates how easy it is to use this method on Heroku for some substantial speed improvements. If you need help implement this for your app or on non-Heroku environments please let me know and I'll see if I can help or answer questions!

We have several apps running in our EC2 hosting environment. Inspired by Engine Yard, I decided to make our database backups a bit more accessible.

Previously, we trusted AWS RDS to take care of database backups with their promise to be able to roll back when something might go wrong. Of course, this doesn't help you much if you need to easily get some data from a few weeks ago without booting a new instance. Also, backing up the databases in an AWS RDS instance offsite is impossible without some conversion step (like a SQL dump) in place.

Since I want to sleep at night I decided to create a periodic snapshotter utility script that would be able to upload a SQL dump to an S3 bucket in Europe.

You can find the code for it in our GitHub organization.

Because our DB instance is in it's own security group with the rest of our apps I wanted the script to be able to tunnel the dump over SSH. But, if you have direct shell access to your MySQL server the script can also run without the ssh option.

Automatic 60 days bucket retention

The script creates a S3 bucket with a file retention of a configured number of 60 days. Every file older than those 60 days will be removed. This is great since this way our S3 bucket with the database backups will not outgrow to enormous sizes without us knowing about it.

Server-side encryption

S3 supports server-side encryption nowadays. This might seem a lot cooler than it is, because it isn't that good of a solution for backup security. What it does is that it encrypts all the data dat is stored on S3's internal file systems with a key that is stored offsite in some other part of the S3 infrastructure.

So, in the unlikely case that bad people break into AWS' Ireland bunker, steal some harddrives and are able to put all the chunks together into actual files, the data is at least encrypted.

Accessible backups and no single point of failure

The Cron job will run the backup script for the configured databases every night and store them into our S3 bucket.

This way, all members of our team will be able to access the backups when something might go wrong with the data or in the case that we need to move to another hosting provider and I'm on vacation.

This is also quite handy for testing new features and updating our staging database and local development databases.

When you are creating software or other online products it might sometimes be hard to sleep at night. You might worry about the next thing that might go wrong such as a failing database, lost files or a web app being unavailable.

Things like that are always going to happen sooner or later. You really can't expect to always be running on the happy path. Some things will go awry. Maybe tomorrow, maybe next year.

You have two options here:

Control every change to the environment you are working on. Having fixed release dates, single access control or pre-approving every small thing your team does. Or, checking something 10 times before actually making a decision or taking action.

The other path you can take is to make sure tools and systems are in place so you can solve problems when they arise. Those problems might arise due to a mistake from someone in your company or they might just happen because life and nature decided it did.

Best results come out of companies and teams where people can do their work without having someone watch over their shoulders all the time. Personal responsibility and the freedom to try things that might go wrong often bring the most creative results.

What I'm doing right now? I'm trying to make our database backup system more easier to use for the team and more fail safe when someone needs to do a change on the production environment.

This is a small thing that will make me sleep better at night. Because I know when someone makes a mistake with typing some commands on the production environment, we can fix it within a few minutes.

I have been searching and Googling for this the past few days and after a very nice support chat with Engine Yard I found out:

It is possible to run multiple applications in the same environment on Engine Yard AppCloud. So, you can add an application to an existing environment.

I knew this was possible before, but I couldn't really find it in their documentation, hence this blog post.

You can just create your first application and create a single-instance, cluster or custom environment for it and than add other applications to it by pressing this button:

If you want DelayedJob, Resque or Sphinx for one or more of the applications in that environment you will need to do some manual Chef configuration and I will write about that soon.

This blog post is a quick story of some paths I took to make some of my routes translated. I ended up with a pretty creepy solution for now (still in search for a better one) so bear with me because there is some crappy code in this article.

The thing is that I want the following to work:

http://siteinenglish.com/competition/some_custom_slug
http://siteinenglish.com/competition/some_custom_slug/new

http://siteindutch.nl/competitie/some_custom_slug
http://siteindutch.nl/competitie/some_custom_slug/new

Every site has it's own "top level" model that is named Challenge in my case. On the challenge, an admin can configure the locale that should be used on that site, which in this case can be en and nl.

Gems I tried

I tried the rails-translate-routes and the i18n_routing gems.

The first one didn't work for my Rails 3.0 app.

The second one kind of worked but resolved into some stack level to deep error when trying to apply it to the following resource:

get "competition/:phase_slug" => "phases#show", :as => single_goal_phase

^ Worked!

resources :contributions, :path => "competition/:phase_slug", :as => single_contributions

^ Stack level to deep on some I18n method

Creepy solution with a routing Constraint

The workaround I came up with was to create a route such as:

get ":competition_translation/:phase_slug" => "phases#show", :constraints => TranslationConstraint, :as => single_goal_phase

resources :contributions, :path => ":competition_translation/:phase_slug", :constraints => TranslationConstraint, :as => single_contributions

The TranslationConstraint looking a bit like this (I've simplified a bit to show the example):

class TranslationConstraint
  def self.matches?
    challenge = Challenge.where({:default_domain => request.host}).first
    if challenge && request.params[:competition_translation] == I18n.t('routes.competition')
      return true
    else
      return false
    end
  end
end

But, since I'm now using a parameter in the route for the resource I also have to override the method that generates the url for the named route and the resource. Like so:

def single_goal_phase_url(options)
  options[:competition_translation] = I18n.t('routes.competition')
  super(options)
end

Dirty to the bone

All of this feels so super dirty and I have no idea what direction I should go to solve this in a nicer way. My knowledge of the Rails router stops at routes.rb and some advanced Constraining.

Is there anyone out there who's smarter than me?

Just a quick note for the people (like me) for seeing an error like this in their exception notifications and to save you some Googling:

ActionView::MissingTemplate: Missing template challenges/show with {:handlers=>[:haml, :rjs, :builder, :rhtml, :rxml, :erb], :locale=>[:en, :en], :formats=>["*/*;q=0.6"]} in view paths 

This is an issue in MIME::Type.parse and has been fixed in Rails master 8 February, 2012 according to this pull request.

There is a patch in the comments on the pull request page you can use to fix it for your current app until a new Rails is released.