Last year, when Obtiva was purchased by Groupon, I wrote a “what I learned” post talking about things I thought I came to understand about software projects after working on a bunch of them. Now that I’ve moved on from Groupon, I started to think about what, if anything, I learned while I was there. I keep coming back to three different things – this is a more personal set of lessons than the last batch, so maybe they’ll be less generally useful.
Something like 25 years ago, Bill James wrote an essay asserting that one difference between smart and dumb baseball organizations was that dumb organizations behaved as thought Major League talent was normally distributed on a standard bell curve, and smart organizations knew that talent is not (it’s the far end of a bell curve). Hold that thought. So I just finished reading Laurent Bossavit’s self published book The Leprechauns of Software Engeneering, which I recommend quite highly.
Oh yeah, things happening… Got A New Job, Got A New Office First off, I’ve started a new job as a Senior Developer and Agile Coach at Table XI, putting me back in the realm of small, Chicago-based consulting companies. Very exited, Table XI seems like a great place so far. Hoping to do new things, challenge myself, and learn. Book Update Most importantly, you can still buy it. It’s going slowly but steadily, thanks for asking.
Charles Max Wood posted this on Twitter: Am I misunderstanding agile? or is it inappropriate to try to peg velocity? — Charles Max Wood (@cmaxw) October 26, 2012 @noelrap They’re telling us we behind on the sprint. My understanding of agile is velocity is set by team pace, not wishful thinking. — Charles Max Wood (@cmaxw) October 26, 2012 @noelrap You can push for deadlines, but you can’t tell us that we’re behind on the sprint just because we’re not going to achieve velocity.
I have a new book, Master Space and Time With JavaSript. You can buy it. Here’s the secret origin. This all started over a year ago. Rails Test Prescriptions had been complete for a few months, and I was getting a little antsy to take on a new project. But what? I wanted it to be a project where I would learn something, and I wanted it to be something where I had a particular perspective to offer.
For the first time in quite a while, I’ve been able to spend time working on a brand-new Rails application that’s actually a business thing and not a side project. It’s small. Okay, it’s really small. But at least for the moment it’s mine, mine, mine. (What was that about collective code ownership? I can’t hear you…) This seemed like a good time to reflect on the various Object-Oriented Rails discussions, including Avdi’s book, DCI in Rails, fast Rails tests, Objectify, DHH’s skepticism about the whole enterprise, and even my little contribution to the debate.
Updates, schedules, things, and stuff. Scottish Ruby The Scottish Ruby conference is having a charity workshop June 28, and I’m presenting my “Advanced Rails Design” workshop. This is the extended dance mix version of the workshop I did at Mountain West Ruby earlier this year. I thought it went really well (so did the attendees, I’m sure), and I’m very excited about this one. Details at http://scottishrubyconference.com/charity/ — you don’t need to be attending Scottish Ruby, but you do need to register in advance.
At it’s best, working in Mac OS X combines the power of the Unix shell with the convenience of an actual interface. Here’s a best case scenario: As I may have mentioned here a few times, I’m writing a book. As part of my current workflow, I need to convert my text from it’s old format to my new format, which is Markdown. The old format is a custom XML-based language the details of which don’t matter beyond the fact that it’s XML-based.
Now that the new book is public, I’m going to start doing more frequent status updates. It’s going to be weird for me, after keeping the project under wraps for so long, but I’m sure we will all get by. When the book, shall we say, reverted back to me, I had two immediate questions: what to write, and how to deliver it to a (hopefully) desiring public. Let’s talk about the content first, though in practice, I needed to make sure I had a tool chain I liked before proceeding.
The key to fast tests is simple: don’t do slow things. Warning: this post is a kind of long examination of a problem, namely, how to integrate fast non-Rails tests and slow Rails tests in the same test suite. This may be a problem nobody is having. But having seen a sample of how this might work, I was compelled to try and make it work in my toy app. You’ve been warned, hope you like it.
Everything I know about the world of fine dining I know from watching Top Chef and from eating at Five Guys. But I do know this: chefs have the concept of mise en place (which does not mean Mice In Place), which is the idea that everything the chef is going to need to prepare the food is done ahead of time and laid out for easy access. The advantages of having a good mise en place include time savings from getting common prep done together, ease of putting together meals once the prep is done, ease of cleanup.
If I don’t write about iOS editors every few months, then it’s harder for me to justify continuing to mess around with them… The thing that’s changed my editor use in the last couple of months is iaWriter Mac and iOS adding iCloud support, even more deeply integrated than Apple’s own applications. iaWriter is the first writing program I use to move to the iCloud future (though there are some games and other programs that also sync via iCloud already).