Though different, the two of them covered similar ground and did similar exercises. And I saw the same opportunities being missed in both.
When hiring people, beyond the basic competency requirement of the role, I look for an alignment in future goals. This is why the question of “where do you see yourself in N years time?” is so ubiquitous.
As you may know Ruby 2.0.0 has been released.
Despite the major version it is mostly an incremental release. However, it does
include a few breaking changes so a major version is warranted.
However, whilst the usefulness of most of the new features was obvious to me, I
couldn’t say the same of
However, whilst listening to the
Ruby Rogues podcast on Ruby 2 one of
the Rogues (I think it was Josh Susser)
referred to memoization as a case
where it would make a difference. Because of that I thought I would implement
memoization in 1.9.3 and then in 2.0.0 using
Module#prepend and see what came
out of it. The process led to a personal “ah-ha” moment and so I thought I’d
share what I found.
If there was one thing that I learnt in 2012 that I would want to convey to all the developers I know, it would be this:
Logging is about so much more than failures
I don’t know if it was just my experience but little to no emphasis was put on logging aside from handling exceptions. In the .NET world this boiled down to adding ELMAH to your project and then forgetting about it, with Rails it meant having nothing but the logs that you got out of the box. I’ve found that if that’s all you have, you’re really missing out.
Usually – almost always – there’s a much simpler solution waiting to be
discovered, one that doesn’t involve all the architectural noise, convolutions
of the straightforward, and misguided emphasis on hooks and options for all
kinds of tangents which might be useful someday. Discovering that solution may
not be easy, but it is time well spent.
The Boy Scout (or Girl Guide) Rule is to leave the campsite tidier than you found it. This helps avoid making the problem any worse and the propagation of Broken Windows.
Among some of the more interesting feedback were some requests for some links and an overview of the things mentioned in my talk.
A few people mentioned they felt misled by the title and synopsis of the talk. I read it back and I think it’s accurate, but then I would. If you are one of those people can you email me at email@example.com with suggestions on how I should change it. It would be greatly appreciated.
Also, versioning APIs sucks. It’s not that it’s hard, it’s that once you publish
an API, you pretty much have to support it forever. This is especially true when
your API is being consumed through multiple layers. I can’t force game
developers to upgrade, because they can’t force their users to upgrade. The
lesson here is simple, if you don’t have to make something public, don’t!
An interesting article exploring the relationship between quantum physics and continuous delivery.
None of it is real until it is in the hands of actual users. I don’t mean
someone who will poke at it a bit or evaluate it. And I don’t mean a proxy who
will tell you if the users might like it. I mean someone who will use it for its
intended purpose as part of their normal routine. The experience those users
report is reality. Everything else is speculation.
Last Monday I gave my talk “Gain Trust and Create Change” for the first time at the London .NET user group. The guys at Skills Matter recorded the whole thing so you can watch it online if you missed it.
I am reasonably pleased with how the presentation went. Watching it back was an uncomfortable experience but is very useful to feed into the next time I give this talk. Speaking of which, if you run a user group and would like me to give this talk get in touch.
I’d like to thank everyone who turned up, Ian Cooper for giving me the opportunity and Skills Matter for hosting.