Reading The Four Steps to the Epiphany

Steve Blank's the four steps to the epiphany has established itself pretty solidly on the must-read list for entrepreneurs. It's also one of the hardest books in the space to read. Where other authors have spent their  time creating pithy lists and easy to apply snippets of information, Steve has written a book that is dense and not particularly suited to skimming.

As a book there are all sorts of problems with it: it's self-published in a somewhat inconvenient format, the proof reading is poor, the writing hasn't had a fine tooth applied to it and organisation is such that while sections may be possible to read on their own you'll often miss something that Steve had defined separately in another section. However, the book is full of really good information backed up by a huge amount of experience and good reasoning.  That's why so many start-up people who have read the book recommend it so highly, it talks about the things they do or have done in a practical fashion that's easy to compare to your own endeavors if you can grasp the ideas.

It's a book that gets easier to read the more time you've spent around start-ups as you start to recognize the occurrences presented in it more easily. But that isn't when it's best to be reading it, you'll get the most benefit by reading it as soon as you possibly can so that you can better recognize the situations it applies to in your company when you hit those problems the first time. Entirely too many people premise their opinion of the book with "I wish I'd read this before my first startup" and entirely too many people say something along the lines of "The first time I picked this book up I put it back down again".

One of the central and most valuable themes of the book is the idea of market type. Are you in a new, re-segmented or existing market? Many of the sections of the book are broken down into shorter pieces dealing with each market type for that topic. For example, Steve suggests you should enter an existing market with with a direct assault of marketing while a new market requires a much slower grass roots process of convincing people they need the solution at all.

The breakdown of market types is great and covers a wide variety of differences in how you should work in different markets. Unfortunately, it also encourages a mistake when reading the book, which  is to skip the sections of the book that don't relate to the particular products you're involved in. The book hasn't been written to allow for that though, these small sections remain closely intertwined. When the book examines business development for the first time it defines it in a section regarding existing markets, but it then assumes it for the other markets when it talks abou them.

There are two sets of ideas to focus on in the book: the iterative customer focussed portion of the customer development model and the collection of smaller topics that appear throughout the book when there's some particular thing that Steve points out.

The basic customer development model relies on: iteration, metrics and feedback. Throughout the book the models of finding customers and then improving your relationships with them come back to this pattern. Talking to people, recording their responses in a way that aligns with what you business needs to achieve and then updating how you're talking to them and what you're talking to them about until you feel comfortable at that stage. In the early stages of the startup talking means finding out if they like your ideas and respond positively, in later stages it means generating sales at appropriate cost.

If all you get out of the book is taking an iterative approach to each stage and measuring it then you've easily got your money's worth. But there's a lot more in there, everything from pre-tested strategies for dealing with various types of enterprise sales to working out if you're CEO is still the right fit when you go from startup to business. Indeed, the last chapter covers the rocky time that comes when you find yourself growing past the size that the entrepreneur can control everything and how that can be managed.

If the thought of reading the whole thing is still too daunting then perhaps the best choice is to only read chapters as you start approaching the stage that they talk about in the company. You'd be better off reading it all at once, but you'll get a lot of value out of reading the relevant bits as well. In addition, Steve suggests that a good mental task is to think about what your competitors  are or could be doing, so if they're at a different stage read up on what they're likely to be facing as well.

This book isn't an easy read, but it is a valuable one. No matter how hard a book is to read, if it can make the difference between learning some of this stuff by reading versus learning it by having a startup fail then reading is the much more pleasant option. This book is definitely in that category.

Code School's Rails Best Practices Review

The guys at Envy Labs have created a really great new set of learning materials over at Code School.
I've been teaching some people Rails recently and sitting them down in front of Rails for Zombies really worked for them. The idea of mixing short screencasts with convenient practical exercises has been a great way of teaching and the web based format is really quite slick.

I wanted to try out some of their stuff myself so I went and bought their Rails Best Practices course. Honestly, the course was a little bit too easy for me, but it was something I wished had existed a couple of years ago when I was just picking up little Rails idioms here and there.  

Inside of this, the format of very dense screen-casts with quick practical excercises meant that the familiar stuff didn't really get in the way and bore me like a slower intro would have. Overall the full run through took less than two hours effort, while I know newer devs would probably find themselves skipping back and forth between the exercises and the videos.

While I knew most of it there were a few small things that for some reason I wasn't familiar with. The .presence method for example is a little thing that is easy to miss but has quickly made its way into my everyday coding after having seen it. The usage of delegate is something that I hadn't really been familiar with beforehand but now really like. A couple of other things were also new to me but don't seem so helpful, Memoizable and Nested Layouts come more under this heading.

The only drawback of the whole thing is the price really. If you're already confident that you've been reading widely on ruby then it might not be quite as worthwhile. But, I wish something like this had existed a few years ago when I was just starting to get deeper into rails. It would have saved me a lot of time. They're also giving away a free Peepcode screencast when you finish now which it a little nicer. There's no shortage of decent Peepcode videos that are worth purchasing after all.

The thing I'm most excited about is what they're going to do with this platform in the future. It really is a great system and something that I intend to get anyone I come across wanting to learn something to sit down in front of. I'm particularly looking forward to some frontend devs I know sitting down in front of their upcoming Jquery course.

Server setup for Rails Camp NZ

This is a bit of a dump of the stuff we needed to set up the server and network for Rails Camp NZ. Hopefully it will be of use to others trying to run similar events.

Taking over the DNS for the network with Dnsmasq

The first and most important part of setting up the server for Rails Camp is making it serve custom DNS records that let you create seamless copies of websites that rubyists needs access to.

• Set your router(we used an airport extreme) to point to the server you're going to be using. The server should have a static IP outside the DHCP range being issued.  
• Setup DNSmasq on the server, this requires telling it IP's for various things. There's a copy of the setup we used which assumes the server has an IP of 10.0.1.201 at https://gist.github.com/901075. We created this by taking Ben Hosking's Babushka recipes and changing values until it worked.
• Setup up a web server(we used apache) with its default site serving whatever page you want everyone to see first.
• Serve Rails apps like twetter in the normal way with addresses pointing at the appropriate hosts.

Creating a Rubygems Mirror

Gem Mirror used to be  a built in gem command, but it was extracted out into it's own repo due to how rarely it was used. Unfortunately this means it's less well maintained that it once was and a bit more of a pain to set up.

The gem server will need a decent amount of RAM, more than 2 GB and at least 33 GB of free space to fit all the gems(this amount is growing all the time as more gems are created). We learned about the RAM requirement the hard way as the initial laptop I tried to use failed to index the gems when it ran out of memory while indexing them.

• Mirror all the gems using rubygems-mirror. I've updated the documentation for this and fixed a bug in the code but I'm waiting for that to be merged in, if it doesn't happen then there are better docs at my fork. 
• Once the mirror has finished downloading, run gem generate_index in the folder you sent the gems to(This is where everything will blow up if you don't have enough RAM).
• Finally, point rubygems.org in your server at the directory you generated the index in.
• (optionally) Update your server conf so that it will send not-modified messages when people request the gem index, otherwise it'll be sent every time someone does a bundle install.

Git

There are various levels of complexity for git setup depending on whether you want to give people write access and how much time you want to spend managing keys.

The simple stopgap is to put all your git repos you want shared in a directory and run:
git daemon --base-path=dir --export-all
Which will cause all the repos under dir to be served by the git daemon, unfortunately this is read only.

To get write access users will need to use ssh and have their keys added to authorised_keys for a user on the server. You can do this manually or with something like gitosis. We didn't get as far as gitosis for Rails Camp NZ, but I'll look at doing it next time.

Things to do Next Time

• Better git access
• Wiki
• Host Ruby versions for rvm
• Ubuntu package mirror

Rails Camp NZ Wrapup

Months of planning culminated last weekend in Rails Camp NZ. I first posted to the Rails Camp Google group with the idea in December 2009 so it's been a while to get every one on board and an event actually happening. The event was from my perspective a success with everyone going away happy as far as I can tell. There were a few hiccups in getting things going properly as we don't have as much in the way of experience running Rails Camps in NZ but after a somewhat hectic week leading up to the event and Friday night, most things ran smoothly.

The weekend saw the development of a number of cool things, particular things I noticed included: a distributed achievement system using bananajour, quite a few Refinery plugins, rornz, a javascript game engine and a game where you click on ruby programmers in questionable swimsuits. It was great to see people being pulled onto things and building into a proper NZ (and AU) rails community.

We had a good selection of talks including: coffeescript, javascript, engines in 3.1, balsamiq, people who go to SXSW are cooler than you, vim, web servers and  although I think I'd like to look at building a scheduling system for them on the server next time around  so that short talks are handled better than the current system of squares on the whiteboard. Coming prepared with all the stupid mac display adapters will probably also help.

I didn't really have time to do a lot of sponsor hunting this time around but the two we did have were awesome Ninefold sponsored what turned out to be awesome coffee and 3months helped out with getting wifi gear at the last minute. In the course of the 44 person camp around 400 coffees were made using these coffee machines. I think they can be called a roaring success.

Coffee thanks to Ninefold

 
The hardest part of running Rails Camp in terms of getting under way with planning was finding a venue as it's quite a time commitment in the weekend to drive out to various places and find somewhere suitable for us. Camp Kaitoke basically won us over by being the friendliest and promptest with emails and when we saw the place it looked really nice(as a number of people commented at rails camp). Really I think friendliness should be the key factor in picking anything like this, it makes the staff much more friendly, even when they see the first three people show up with three kegs(Henry Collingridge did a great last minute job of organising people who wanted to do a group beer thing).

We do have a lot of room to grow if we use the venue again as we used the lunch hall for coding and another room for presentations, but there was also another large room and a small room available in other spots if we had wanted to spread out more. The large room we didn't use was particularly notable for having a proper roof mounted project setup, unfortunately the projector was stolen. I'd also have liked to see more use of the gymnasium, the two person game of basketball I fit in was a good way to recover from some of the Sunday morning sleep deprivation, but it's not easy to have pick up games in it as people can't see in from outside the building.

I do advise others avoid setting their Camp dates for shortly after a national disaster. Having a few people people out or just not sign up because of earthquake pressures was a real pity. Losing the networking gear when I had already relaxed about that area of things was a pain and meant that the number of things sitting on my todo list really close to camp dates got uncomfortably large. It all mostly turned out ok but networking wasn't as tidy as I would have liked it to be.

Ticketing started off with a bang and then slowed down a lot. There were a couple of months where I was quite worried about us not making enough sales to cover minimums at the venue. They picked up a bit, but I did end up spending a lot of time hunting people down and giving them the hard sell to convince them to come. In general we had a lot less locals than I would have liked. But people went away positive with a lot of other Kiwi's interested in running or helping run the next Rails Camp NZ so I think we're going to grow a decent amount and the event will be able to run a lot more smoothly with more people to spread the organisation around. 

Given that there shouldn't be a problem with having to pay for extra bunks next time around and that we've proven that we'll get a decent crowd it should be possible to lower ticket prices a bit next time around and to drum up a bit more sponsorship. We only really started looking like we'd definitely have more than 30 people in the last week of sales and it was hard to claim that we were a serious thing with so few people signed up. I'd like to also make a more explicit effort to pull in people who may not be able to afford full priced tickets for whatever reason. A couple of people who were a bit cash-strapped at the time are paying me back when they get the chance, but that only covers people who I was prodding directly.



Werewolf continues to be a brilliant way to meet people at camp and remember learn people's names. I did a lot of "Who are you?", point, "Yeah, you're the werewolf". Unfortunately Phil Arndt and I played up our roles as lovers a bit too much in one werewolf game and ended up getting paired a lot throughout the weekend to the detriment of our survivability.

I'm going to do another blog post in the next few days covering all the networking and server stuff as it started off a bit chaotic, though it doesn't seem like many people noticed as Friday night is pretty much beer and meet people time. I'm hoping for the post to also serve as documentation for how to set up this kind of thing in the future without our approach of having a general idea and then changing settings until everything worked.
 
Ryan Bigg has already written a write-up that covers a lot of what happened at the camp from the perspective of an attendee who pitched in a decent amount as well.

Crafting Rails Applications Review

Jose Valim is well known in the Rails community for writing a lot of code and being on the Rails core team. He's also to blame for Inherited Resources a plugin that I've seen be more horribly misused than any other. He's one of the most qualified people you could get talking about some of the more advanced tricks that are present in Rails these days and Crafting Rails Applications really does cover a lot of ground in intimate detail.

Crafting Rails Applications is a tough book to review, there's a lot of really good information in it that can't be found anywhere else short of reading through the Rails source and trying to work out what's happening. But, anyone who really is going to get a lot out of the book is going to end up reading a lot of the source anyway. A good deal of the information in it will be of more use to people creating plugins and engines than the general run of the mill development people involve themselves in. This may be a reflection of Rails maturing as a framework in that it's starting to really support expert level content being published as books rather than disparate blog posts.

The book covers a wide array of the new features in Rails 3, but unfortunately it isn't particularly well organised making it difficult to use as a reference book. Much of the book is spent examining the status of various features of the rails rendering stack, this is interesting information and there's use for it when building something like a CMS, but outside of that I can't see it being used for that very much. Indeed, of the topics that are explicitly addressed I have only needed one of them in the past(Building a translation module for kete using mongomapper)

On the other hand, throughout the book there are lots of little tidbits and functions of Rails that I did appreciate learning and will use in the future. The poor organisation makes this a book to read with a notebook or sticky notes at hand to keep track of things that interest you. And the section of creating custom responders in particular was an interest addition that I'd quite like to try for cleaning up code.

The book suggested layering custom responders on top of custom renders as a powerful way of tidying things up. That might have been the aim in tying things together but I think for most development shops that would lead to entirely too much magic and the code becoming quite opaque to less experienced developers. Worthwhile if you're writing a plugin that needs the powerful generic solution, but not something I want to see everyone using.

One particularly useful bit of coverage is Rails engines, they aren't covered in any section in a particularly focused fashion but are used a lot and the demonstration 'Enginex' gem helps with creating them. If you've been wanting to work with engines this is probably the best overview of them that has been published so far, although that is perhaps more of an indictment of current resources than anything else, hopefully some of the upcoming rails books will deal with them more explicitly.

Is it worth reading? Yes, but there are a lot of other books that you should definitely have read first before this gets to the top of the reading pile. If you're doing a lot of work with plugins or gems, or one of the chapter headings jumps out at you as something you need to do soon, then pick it up with haste. But if it's just on your reading list out of interest then in the Ruby world Metaprogramming Ruby is a more important "advanced" book and I'd also suggest reading more broadly in related technologies before hitting this book.

Webstock 2011

Webstock is a weird kind of conference. I enjoy it a lot, but it isn't all that practical. I'm impressed by the number of people who convince their jobs to pay for them to go given that it mostly suggests quitting, starting a startup or becoming a musician. There are some more practical talks mixed in there though; they're the ones I enjoy least.

Frank Chimero opened the conference with a talk about the importance of story in content of any type. And the number of really good talks that were more story than collection of useful cool things really reinforced this message. Unfortunately he says his favourite book is Catcher in the Rye, so I can't approve of him as a person.

One of the major draws for me at the event this year was Jason Cohen as I've been reading his Smart Bear blog for a couple of years now. He didn't disappoint. Giving a humble tale of his experiences with learning how to do the non-geeky portions of a startup. From dealing with shark-like salesmen trying to join his company and take %50 for his troubles, to learning to sell himself and the misplaced feeling of being in a room where they say, "Hey did you see the big game last night", and know which game it was. Jason is one of the best examples of a successful solo founder who still comes across as completely geeky.

The best story of Webstock was probably Peter Sunde, the tales of the pirate bay would fit perfectly well in some kind of surrealist novel. Featuring lines such as, "There was a private investigator following Hans for 4 weeks. Saw him once. He doesn't go out much" and "We tried buying a country. It's a thing we do when we're bored". Sunde's story is completely insane and really shows how unique the pirate bay has been in it's place in internet history. Sunde's latest project, flattr is a very interesting answer to the problems that all the record labels raise regarding artists losing money.

Sunde being there to talk about flattr was particularly well timed as when I asked Amanda Palmer the day before about what she wanted on the internet as a musician, she responded by speaking about the need for some way to perform the equivalent of busking online. Even though her attempt at busking in Wellington only made her a dollar, perhaps not the best endorsement of the business model. She did manage to crowd surf in the middle of civic square though.

The other speakers were all very good and covered a wide array of information and good stories. With the final talk being Merlin Mann giving a very thoughtful talk about things people are scared of. A surprisingly downbeat talk to end on, but one that really rounded out webstock nicely and made it feel like the talks had been crafted to mesh together better than anyone had probably really intended. It was a good thing that it was to be follow with lots of free alcohol though.

Wrapping up Webstock with an Amanda Palmer and Jason Webley gig was very successful. They have a surprisingly large number of very geeky tunes that I don't really notice when I'm just listening to their albums at other times. And Amanda Palmer dedicating a performance of Pirate Jenny to Peter Sunde and the Pirate Bay is all kinds of badass.

Goals for 2011

Release Rabid Tech's first app.

Contribute to more open source.

Have Rails Camp NZ go well and also make it to the Aussie ones again.

Start building up some more passive income streams, small weekend apps that actually monetize etc. I have a new todo app idea that I'll have a look at building sometime soonish(The todo app market is clearly not saturated enough).

Edit my Nanowrimo novel from this year and look at trying to actually finish it. We've got a decent bunch of people carrying on from nano this year so might be able to get some more momentum behind it this year. My writing has improved each year as well.

Read more and widely, particularly:

• Some Proust
• One of Chinese four great classic novels, probably Dream of the Red Chamber given I already have some familiarity with Romance of the Three Kingdoms and Water Margin
• More History in the areas I'm unfamiliar with. Byzantine to start with.
• Finish Structure and Interpretation of Computer Programs including most of the excercises.
• More Steinbeck
• Godel, Escher, Bach: An Eternal Golden Braid - I've been meaning to read this for ages.
• A few more biographies - I really enjoyed Richard Branson's this year.
• My usual mixture of Sci Fi and Fantasy.

Blog more - at least twice monthly.

Watch more good movies, with a minor focus on getting up to a convincingly large portion of the imdb top 250 list. I'm up to having watched 112 of them so far and I'm finding the more obscure or older films that place on the list to be particularly enjoyable.

Do some more teaching Rails to people, either mentoring or more workshops.