ActiveRecord Conditions: named variables

Today I learnt something amazingly cool about ActiveRecord that I never knew:

You can pass in named variables to your finders!

No more question mark soup.

Instead you can replace all those question marks with named symbols. Then provide a hash with the values for each symbol.

You still get all the ActiveRecord goodness of sanitising your inputs, but in a more readable form.

I can’t believe I went all this time without knowing this existed. Named arguments is one of my favourite parts of Objective-C, whilst it can make method signatures long I find the increased readability to be a bonus.

Check it out on the docs: http://api.rubyonrails.org/classes/ActiveRecord/Base.html

Lean Startup Machine London

I’ve been interested in Lean Startup techniques for a while now and wanted to learn how best to apply them, so I’ve been really looking forward to the Lean Startup Machine. It seems like a really nice mix of workshop / tutorials and actually doing something! Whilst it’s always great to read up on anything, you’ll never really understand it until you attempt to practice it.

Pitches

I was actually surprised by the quality of the ideas in the pitches, they were generally quite different from the usual ideas you hear (Groupon for dogs!). I think this was due to a different crowd: more women and people from a wide age range.

The mentors were incredibly helpful and I definitely learnt the most from them. I thought I was pretty good at narrowing down our idea and testing our assumptions. But after conversations with mentors they would bring up assumptions that we had made and ask why. However, I didn’t even realise these were assumptions, they were just ingrained beliefs.

The lessons that I really took away:

  • The important of actually getting out of the building and speaking to people. Also how to ask your questions: How to get more than opinions
  • How essential it is to test all of your assumptions, spend some time really thinking about your existing assumptions that you may not even be thinking about.
  • You don’t have to build anything to test your idea, go out and do it manually at first and see what the feedback is. This is especially important to developers as we love to jump straight into writing code.

To Pivot or Not To Pivot

There was a big emphasis on pivoting. To the point where it almost seemed that most of the teams placed more importance on pivoting that on discovering and building a great product. Throughout the weekend teams were collecting feedback from potential customers, but once they received any response they were eager to take that onboard and pivot their idea.

Not I’m totally not against the idea of pivoting, but I do think you need a reasonable set of feedback before making any big decisions. If you’ve only spoken to 3 to 4 people, it’s just as likely that the next person may say something entirely different. However, this was most likely due to the time constraint of the weekend and there wasn’t really enough time to get feedback with any statical significance.


Overall, I had a great weekend and learnt a hell of a lot. It was great to interact with the mentors and see some of the great ideas that the teams had. Hopefully, I’ll return next year with some ideas of my own.

How NOT to do OO design

There’s been lots of talk about ‘good’ OO design here, here and here.

Writing OO code is difficult and usually evolves as you better understand what you’re working with. But it’s staggering the amount of times I’ve seen people write something like this:

Breaking down your code into encapsulated objects is great, but when you try and force it you get complete misunderstandings like the above. I’ve always found that as long as you’re refactoring your code you’ll start to see dependencies and other code smells and naturally split them out into objects, if and when necessary.

The rules for memory management

  • If you own an object, you are responsible for releasing it when you are finished with it. Claiming ownership of an object increases its reference count. Releasing that object decreases the count. An object is unused when its reference count is zero.
  • If you don’t own an object, you should never release it.

Those sound pretty straightforward, this memory management can’t be that hard!

10mins later…pulling hair out trying to find memory leak and praying for a garbage collector.