/dev/mull

A review of Leancamp

2010-05-12T10:24:00+01:00

A couple of days ago I attended an Unconfernce called Leancamp.

My main reason for going was that David Heinemeier Hansson - the creator of RubyOnRails and co-author of Getting Real and Rework was speaking.

First, some definitions: Lean is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. It is currently trending in the world of software as a way of furthering the principles of agile development as a methodology to connect software development with business.

An Unconference is a gathering of people around a theme or purpose, but without a defined schedule. The schedule develops from conversations amongst the attendees, on the day. Low fees (my ticket cost £10) and a lack of sponsorship are features of an unconference, and the concept has grown out of science fiction conventions.

The introductory speeches were a slightly confused jumble of the principles of Lean development, and how they apply to making profitable software in 2010.

Next up was a piece by the CEO of Seedcamp, Reshma Sohoni. Key points for me were:

It is crucial to connect with your customers to make sure that you are building something that people want to buy, and that they want to buy it from you. Consultancy can really help your business to do this.
Care must be taken to find a balance between customer-driven features and using your own expertise to develop features which the customer wouldn’t have thought of, but that they love when they get to use it.
The key difference between geek-preneurs “playing with” VC funding and actual successful businesses is finding and building something that people will pay for.
Hire passion, not experience.
Scale your team vertically.

The first proper unconference spot I went to was a session from John Williams, the author of “Screw work, lets play”. He drew up a chart of the ideal roles he felt you should have in a creative team, using slightly outlandish titles such as:

Mechanic
Creator
Star
Supporter
Deal maker
Accumulator
Lord
Trader

The discussion centred around how these characters need each other to create a successful product, and around the process flow between them. By asking questions such as: “What aspects of your work are you most enthused about?” you can work out which role you really are. We talked about playing to your strengths: there’s little point in trying to be a mechanic if you just aren’t good at it; but also you need generalists or polymaths if you can’t afford to hire more people.

One point that stuck with me was: “Lords are prone to over-researching - if you have more than one Lord you move very slowly.”

Moving onto the main event of the day. The dark prince himself: David Heinemeier Hansson. DHH was basically there to pimp Rework, his recent book. I’d estimate that a good percentage of the attendees had read the book, and that almost all attendees were fully on board with Getting Real principles. Unfortunately DHH didn’t bother to find this out with a quick straw poll, but instead ranted through the cartoon world of Rework, bashing out the familiar, simplistic views in a reedy, tense tone.

Particularly galling opinions were:

A financial plan is nothing more than a financial wish.
Plans are a waste of time - the sooner you realise that, the sooner you can forget them.
Plans are worth no more than a 15 min pres, but they get much more credence than that in business.

There was also some common sense:

A plan that doesn’t change your behaviour is worthless.
Plans promote an illusion of agreement.
Decisions are temporary.
You get real feedback from real software.
People think they want a ton of features, but they actually buy simple solutions to clear problems.

Other points:

When building Basecamp, DHH and Fried didn’t want to compete with other forum providers, or CMS providers, or (shudder) Sharepoint - they only wanted to create something which is “slightly better” than email. Which is interesting, because I’ve always thought Basecamp is “slightly worse” than email.
Making your app modular or optional will result in the quality of the user experience degrading.

There then followed a question and answer session, via skype from San Francisco with Eric Ries. Eric did a masterly job in engaging with DHH’s confrontational style without being drawn into it, and provided some much needed balance to the assertion that all VC funded companies are bad.

A review of Rework.

2010-04-12T11:44:00+01:00

Rework by Jason Fried and David Heinemeier Hansson.

ISBN-10: 0307463745

ISBN-13: 978-0307463746

I first read Getting Real in 2006. At that time, I was working as a software contractor for a large corporate defence contractor. I was bored and frustrated - trying to find ways to introduce Rails projects into the department without anyone from “IT security” noticing. Before Getting Real, no-one had addressed the problems faced when delivering software in a corporate culture, and the lack of understanding around this brave new discipline. Suddenly, we had a manual for tackling the problem head on.

These days I’m working in a very different environment - in a Rails-focused software house of around 16 people who have all read Getting Real. We’re all so into Getting Real, I’m worried some colleagues will take 37Signals’ new book: Rework like drops of echinacea, to be be regurgitated ad nauseum in meetings over the next few months.

That’s if we’re actually allowed to have any meetings.

Rework is largely a rehash of Getting Real, but with the focus moved away from people who write software, onto people involved in all aspects of running a business. The refocussing allows Fried and DHH to reach a far wider audience with their opinions. Their wisdom, gained by experience, of how to deliver software will be read by people who would have never considered reading Getting Real. That’s pretty savvy market positioning and something that wouldn’t have been achieved by a series of blog posts on their website.

However, having a target reader of a business everyman has the flip side that this reader won’t know, or particularly care what impact the Rails Framework has had in software development; or about the godlike status of the authors in the transitory world of Web 2.0.

This means that when the authors go beyond messages on delivering software, and venture into the more subtle and delicate aspects of what makes business work, they quickly expose a naivety - probably the result of having done little in business outside 37Signals. This trait is especially noticeable in the chapters which address more “human” issues. They veer from blindingly obvious common sense:

A good apology accepts responsibility.

…to the most ridiculous assertions

Culture is the by-product of consistent behaviour.

Policies are organisational scar tissue.”

Those are direct quotes, but my personal favourite is this opinion snippet, paraphrased from page 208.

The only reason you’d go to a dinner party is if you thought you were going to get something out of it.

Sorry, what?

Their writing is naive because it only caters for the easy stuff, where you’ve got a team of people with great skills and who get on well. Every day in Rework is a sunny day. What about handling some difficult situations? For example: an employee is making strange decisions in the workplace because they’ve just lost a family member - but they haven’t told anyone at work about their loss. An employee is having second thoughts about their career and is becoming disruptive for the team, but hasn’t yet the self awareness to talk with the team about it.

I suspect that 37Signals simply hasn’t been around long enough to have had to deal with that stuff yet. As they say, they’ve been around for 10 years - as if they think that’s a long time.

There’s another aspect to Rework: How lucky have these guys been? Is their success purely down to skill and effort, or did they just hit a remarkable piece of timing with RubyOnRails, and have marketed themselves well off the back of that? I’m reminded of Paul Graham’s advice on how to run a startup. All good advice, but really, I would have felt it was more genuine if he’d just acknowledged he was damn lucky to get bought out.

All told, I enjoyed the book, and it hardly takes up a huge portion of time to get through it. Parts of it made me uncomfortable because its provocative style made me question my approach to my work, and that’s no bad thing.

DHH is visiting London next month. I’ll be interested to hear his talk.

A quick post on a new theme

2010-04-03T22:30:00+01:00

Nesta CMS has recently introduced theme support.

It is showing up on the “themes” branch, but there isn’t a write up yet.

I had recently spotted the penguin classics tumblr theme by Max Wheeler and thought it would be cool to convert it.

Definitely a WIP for me, but so far I’m liking it.

Thoughts on MongoHQ pricing

2010-02-27T14:34:00+00:00

I was lucky enough to be a beta-tester for MongoHQ, the hosted MongoDB service.

I am really enjoying using the service - the web interface is sweet, but it is really the performance which has been outstanding. How do they make a network based data store faster than my local copy?!?

Yesterday (20100226) they came out of private beta, and launched their pricing options to the world.

The results, as MongoMapper author John Nunemaker tweeted, were surprising.

Firstly, there’s no free Heroku-like option. The cheapest option is actually more expensive than a budget virtual private server - on which you could set up MongoDb and whatever else you desire.

Secondly, each price point only allows a 2Gb database out of the box. The cheapest plan stipulates $2 for every extra Gb.

Document stores such as MongoDB are ideal for feed trawling and the like where there isn’t a massive amount of relational structure in your data model. Lets imagine you’ve got a side project which is harvesting a bunch of feeds. You’ve no idea whether this is a monetisable project yet, but you’d like to try it out and play with it. Such a project could easily grow to a 10Gb document store.

MongoHQ want you to pay for the last 8 of those Gb. That’s $41/month on the cheapest plan, and $107/month on the most expensive plan. The most expensive plan gives you more databases and more user accounts, which is obviously not much help on a single project.

I expected a MongoHQ to go with a strategy which would tempt developers to try this emerging technology and move away from traditional RDBMS such as MySQL, which are offered for free in the basic Heroku plan. After all, what is to stop Heroku from offering Mongodb support themselves?

MongoHQ seem to believe they are offering a premium product, especially given the fantastic performance, but from an open source data store.

I’m not convinced it’ll work, but I’ll continue to watch with interest.

Using Chowder for Simple Rack-based authentication

2009-12-01T22:30:00+01:00

I have been searching for some time for a simple rack based authentication system.

Something just complex enough.

A key requirement for me is that I’d like it to work with the data storage mechanism of my choice (which this week is MongoDb/MongoMapper).

I spotted a post on the sinatra mailing list which mentioned a fairly new contender for this sort of thing, called chowder.

It was really easy to get things going, although I found the parameters to ‘use’ needed to be wrapped in {} - at least when using ruby 1.8.7 - I wonder if the chowder developers are on ruby 1.9 where that kind of voodoo is acceptable..?

I’ve also put up a branch to a fledgling sinatra app which uses Chowder, complete with some cucumber features which test sign up and log out with a MongoDb/MongoMapper document store. That’s here on the basic-chowder-features branch.

Getting useful information out of git log

2009-10-28T10:30:00+01:00

A couple of weeks ago, this snippet was hitting the software twitterati in a big way

git log --graph --pretty=format:'%an: %s - %Cred%h%Creset %C(yellow)%d%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative

It produces a very pretty tree view of the git log, piped into less.

It got me wondering what you could do with git log in terms of viewing the total number of commits by each author working on a repository. A league table of commits, if you will - although that isn’t a metric of competition or status in any way. :)

Here’s what I came up with:

git log | grep 'Author:'| sort | uniq -c | sort -nr

Here’s the output of that command on the github rails project (abridged)

3045 Author: David Heinemeier Hansson <david@loudthinking.com>
2647 Author: Jeremy Kemper <jeremy@bitsweat.net>
 732 Author: Joshua Peek <josh@joshpeek.com>
 519 Author: Michael Koziarski <michael@koziarski.com>
 425 Author: Rick Olson <technoweenie@gmail.com>
 346 Author: Jamis Buck <jamis@37signals.com>
 345 Author: Pratik Naik <pratiknaik@gmail.com>
 301 Author: Marcel Molina <marcel@vernix.org>
 267 Author: José Valim <jose.valim@gmail.com>
 231 Author: Nicholas Seckar <nseckar@gmail.com>
 181 Author: Emilio Tagua <miloops@gmail.com>
 179 Author: Yehuda Katz + Carl Lerche <ykatz+clerche@engineyard.com>
 178 Author: Yehuda Katz <wycats@gmail.com>

Using curl -I to detect the MIME type of a URL

2009-08-01T14:47:00+01:00

curl is a command line tool for transferring files with URL syntax.

The -I option retrieves just the header information

e.g.:

$ curl -I http://google.com
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Tue, 25 Aug 2009 00:24:38 GMT
Expires: Thu, 24 Sep 2009 00:24:38 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219

and lots of other interesting tidbits too:

curl -I http://farm4.static.flickr.com/3562/3829865330_c2d6012c99.jpg
HTTP/1.1 200 OK
Date: Tue, 25 Aug 2009 00:26:12 GMT
Content-Type: image/jpeg
Connection: keep-alive
Server: Apache/2.0.52 (Red Hat)
Cache-Control: max-age=315360000
Expires: Mon, 28 Jul 2014 23:30:00 GMT
Last-Modified: Mon, 17 Aug 2009 10:10:16 GMT
Accept-Ranges: bytes
Content-Length: 124866
Age: 12
X-Cache: HIT from photocache408.flickr.ac4.yahoo.com
X-Cache-Lookup: HIT from photocache408.flickr.ac4.yahoo.com:81
Via: 1.1 photocache408.flickr.ac4.yahoo.com:81 (squid/2.7.STABLE6)

Customising the JVM memory allocation using MAVEN_OPTS

2009-03-05T10:30:00+01:00

A while back, I kept getting

java.lang.OutOfMemoryError: Java heap space

…type errors, working on a large Java legacy system. There were some files in there with over 3000 lines of code! It was a bit of a death march project, to be honest.

Anyway, I messed around for a little while with different attempts at setting MAVEN_OPTS to give the JVM a decent amount of memory, here’s what i ended up with:

MAVEN_OPTS='-Xms256m -XX:MaxPermSize=1024m -Xmx1024m'

JRuby Cookbook published

2008-12-15T12:45:00+00:00

I’m very happy that my contribution to the O’Reilly JRuby Cookbook has been accepted!

Got my copy through in the post this morning from O’Reilly!

V. nice.

It is only a little bit on making SOAP calls from Ruby (JRuby) using the Mule ESB Client library, but it is still really nice to see my name inside a book :)

Excerpt here

Calling SOAP Services from JRuby

2008-02-28T16:28:00+00:00

This blog post has been published as a chapter in the JRuby Cookbook by O’Reilly.

I have been working on a project which uses the Mule ESB, and a JRubyOnRails app.

Part of this means calling SOAP services from within the JRuby app.

Ola Bini sets out a couple of approaches in his JRuby on Rails book,but I thought I would blog the success I’ve had using the mule-client libraries.

I am passing “complex” Java objects around in these SOAP services, not just primitives - always more difficult when it comes to SOAP interoperability.

Here is the call:

include_class 'org.mule.extras.client.MuleClient' 
include_class 'org.mule.impl.MuleMessage'
def make_soap_request(soapurl, request) 
	c = MuleClient.new 
	begin
		message = MuleMessage.new(request)   
		m = c.send(soapurl, message , nil)   
		return m.getPayload() 
	rescue Exception => e   
		logger.error e 
	end
end

The return value is the object returned by the soap call. Nice and easy.

Here are the required jars: (add to /lib/java)

activation-1.1.jarasm-2.2.3.jarasm-commons-2.2.3.jaraxis-1.3.jaraxis-jaxrpc-1.3.jaraxis-saaj-1.3.jarbackport-util-concurrent-3.0.jarcommons-beanutils-1.7.0.jarcommons-codec-1.3.jarcommons-collections-3.2.jarcommons-discovery-0.2.jarcommons-httpclient-3.0.1.jarcommons-io-1.2.jarcommons-lang-2.2.jarcommons-logging-1.0.4.jargeronimo-j2ee-connector_1.5_spec-1.0.1.jarjline-0.9.9.jarjug-2.0.0-asl.jarlog4j-1.2.14.jarmule-core-1.3.3.jarmule-module-client-1.3.3.jarmule-transport-axis-1.3.3.jarmule-transport-http-1.3.3.jarmule-transport-soap-1.3.3.jarmule-transport-tcp-1.3.3.jarwsdl4j-1.5.1.jar

Then you can use:

include javaDir["lib/java/*.jar"].each { |jar| require jar }

…at the top of your class, and make SOAP calls until the cows come home! :)

Hope is helpful!