Menu Sidebar

Avdi Grimm

Hacker; code documentarian.

Where to find me in 2015

The first half of my conference-going year is starting to firm up, so I thought I’d briefly post about where you can find me this year, if you feel so inclined. So far it’s a light year for travel, but I’ll probably be adding a few more dates as the year advances.

March 4-8: Tropical Ruby 2015, Brazil

I feel like this speaks for itself:


If you want to join me here, check out the site. They are also seeking sponsors, in case you represent a company that is looking to invest in the community.

July 20: Brighton Ruby Conference, England

Apparently 2015 has a beach theme. I’m excited about this conference, because after years of passing through Heathrow on the way to somewhere else, I’m finally attending a conference in England itself!

Here’s the website. This conference is seeking sponsors as well!

Beyond July: ???

I’m not actively submitting talks this year. But if you want me to come speak at your conference, or for that matter if you just want me to come and wear silly hats and spend a day pair-programming with attendees, get in touch. Bonus points if your conference has a dance floor.

Tangent: a CoC policy

I was very pleased to see that both of the above-referenced conferences had prominent codes of conduct posted on their websites. This is something that I am now looking for when considering whether to attend a conference (whether I am speaking or not).

As far as why, I think John Scalzi sums it up best:

Because I want my friends and fans to be able to come to a convention and feel assured that the convention is making the effort to be a safe place for them. I want my friends and fans to know that if someone creeps on them, there’s a process to deal with it, quickly and fairly. And I want my friends and fans to know that I don’t support conventions that won’t go out of their way to do both of these things.

As far as details go: basically, Scalzi’s policy is my policy too. If you have any questions, check out his original post and the followup FAQ.

(And a big thank-you to John for, once again, saying sensible things so that I can be lazy and point people to them.)

Who is your failure helping?

True story: I once worked on a project where I was told from the outset that “we probably will not use your code”.

This was back when I worked at a big defense contractor. There were negotiations under way for an expanded contract that would obviate the work I was doing, if it were signed. But someone still had to do the work, to meet current contractual obligations and in case the negotiations fell through.

Back then I estimated that about 50% of the work I did was eventually shelved and never used. Contracts changed, or a feature went over-budget and was cut, or a management shuffle resulted in new priorities. I began to think about projects as being similar to teeth: ignore them long enough and they’ll go away. This environment lead to an interesting productivity optimization: I realized I could ignore projects for weeks on end, and focus on my self-teaching instead. Eventually half the projects would go away, and the rest I could cram out with a few over-nighters.

Read More

Why does Ruby have blocks?

Ruby’s blocks are easily the biggest hurdle most newbies to the language have to overcome. Even for people with years of experience in other languages, the the concept of blocks is often an elusive one at first.

In my opinion, some of the difficulty in grokking blocks can be chalked up to how they are usually explained. In this article, which started out as a post on Parley, I want to explain how I think of blocks: as just a pragmatic shortcut for a pattern you’ve probably already used in other languages.

Read More

In defense of fat tools

Rails has this thing called the “flash”. It’s like a special subset of the session hash. It’s a key/value store with an enforced short lifespan. Stuff you put in the hash lasts for exactly one render or redirect, and then goes away. It’s handy for stuff like notifications. You can set it in the controller:

# ...
flash[:notice] = "Your order has been submitted."
# ...

…and then you can reference it in a view:

<div class="notice"><%= flash[:notice] %></div>

You can then be confident that after the view is shown, the message will go away and not be seen again.

Recently on the Ruby Rogues we talked to Michel Martens about keeping libraries small and simple. It was a good show and he had a lot of good things to say. You should give it a listen.

Read More

Older Posts

Virtuous Code

"The three virtues of a programmer: laziness, impatience, and hubris" — Larry Wall

Books and Screencasts

RubyTapas Screencasts

RubyTapas Screencasts

Small plates of gourmet Ruby code.

Confident Ruby

Confident Ruby cover

32 Patterns for joyful coding.

The Making of

Confident Ruby cover

Watch me build an app in Sinatra and Rails

Objects on Rails

Objects on Rails

A developer notebook on applying classic Object-Oriented principles to Ruby on Rails projects.

Exceptional Ruby

Exceptional Ruby

The definitive guide to exceptions and failure handling in Ruby.