I don't normally make this kind of post here, because I try to keep this site technical in nature, but over the course of some recent conversations, both at RailsConf and elsewhere, I found it surprising just how many people seemed genuinely interested in this aspect of my life. So I am going to break form, just this once, to share a bit of personal information and ask for your help, should you feel so inclined.
I love Mustache for rendering. Its simplicity pretty much forces you to do The Right Thing™ in code that uses it, and it's got an implementation in just about any language you might find yourself using. That being said, I did find myself wishing for one feature: multipass rendering. So, loving both Mustache and Ruby, I decided to add support for multipass rendering to the Ruby implementation of Mustache.
Recently, I saw Ashe Dryden's excellent dedicated page for her (also excellent) talk at Ruby Midwest. I thought it was a great idea, so this is my shameless copy of that idea. Thanks, Ashe!
I'm on my way to Portland today for RailsConf 2013! Be sure to say hi if you happen to see me. I'll look mostly like my Twitter avatar, only without an ocean behind me. One guaranteed spot to see me is my talk on Tuesday in 252 & 253: An Intervention for ActiveRecord.
Hope to see you there!
While I was on my way to Ruby Midwest on Thursday, I was pleased to discover that Confreaks posted the videos from Big Ruby!
If you weren't able to make it to Big Ruby, you can check out my talk here: The Most Important Optimization: Happiness.
While you're there, I also recommend checking out the lightning talks (especially the ones by Chris Morris), Joe Kutner's "Building a Bigger Brain: How Healthy Living Makes You Smarter", and Wynn Netherland's "Hypermedia - less hype, more media please".
I returned from Big Ruby yesterday, and have had a day to recover and reflect on things, so I thought I'd do a quick write-up.
I just got word this weekend that my talk, "An Intervention for ActiveRecord", was accepted to RailsConf! It'll be a discussion of various ActiveRecord oddities, how they could bite you, what you can do to protect yourself, and how you can help. If you have a specific issue you'd like me to consider including in the talk, let me know in the comments.
I'll see you in Portland!
In what has to be my most successful New Year's resolution ever, I'm happy to announce I'll be speaking at Big Ruby on February 28th - March 1st. The topic is "The Most Important Optimization: Happiness", and as you might expect, it'll expand upon some of the ideas presented in my previous essay about optimizing my own life for happiness. I'm still fleshing out the talk, so if there's anything specific you'd like to see included, please let me know on Twitter or here in the comments.
Not able to make it to Big Ruby? I'll be giving the talk at another conference, to be announced as soon as the organizers make it public.
[Update: It's Ruby Midwest, on April 5th and 6th!]
Happy new year, everyone! Since I've found that without an accountability partner, I fail at keeping resolutions, you're my new accountability partner. My New Year's resolution is to speak at at least one conference this year.
There are a number of topics I think I could easily fill an hour with, so now it's just a matter of picking one (or more) out, and actually running with it. If you have any suggestions for me, please leave them in the comments.
Thanks!
Quick Ruby quiz for you. Consider the following code:
proc {|arg1, arg2|}.arity # => 2
proc {|arg1|}.arity # => 1
proc {|*args|}.arity # => -1
proc {||}.arity # => 0
proc {}.arity # => ???
What's the output of the last line?
It's about freaking time. Merry Christmas to me! (And to you)
[Update: You can now view my talk on this subject.]
For a while now, I've had the tagline you see on this site's header as of this writing:
No, I don't work in NYC, DC, or the valley, and I'm cool with that.
Like many (if not most) of you, I'm regularly contacted by recruiters. Unsurprisingly, they generally haven't learned anything specific about me, aside from what they find on my LinkedIn or GitHub profile. If they have visited this site, they certainly haven't read the tagline. I'm getting tired of sending out what amounts to the same e-mail (though still probably more customized than the typical recruiter e-mail) over and over again, so I hope those of you who primarily read this blog for useful bits of Ruby info will forgive me this brief and selfish digression.
I am a software developer in Louisville, Kentucky, and I am really freaking happy here.
Ruby class variables don't see a lot of use, largely due to one of their more interesting properties -- inheriting classes see (and modify) the same object as their parent. Still, you will at some point find yourself using them, so it's good to understand as much as possible about their behavior. Since modules can have "class variables", I ran a quick experiment last night to see how they behaved. I found the result a little surprising, so I thought I would share.
Recently, a really great article was published over on the Code Climate Blog. Titled "7 Patterns to Refactor Fat ActiveRecord Models", it's a must read for everyone who works with Rails. If you haven't read it, go do so.
Seriously. I'll wait.
Anyway, at the very top of this list is a recommendation to extract value objects, and it got me thinking about a pattern I really like, which I wanted to share with you today.
Something I've always loved about Ruby is that no matter how long I've been using it, it continues to surprise and delight me with neat little tricks. Here's one I was really surprised I never knew until now:
Let's say you want to enforce some kind of parameter formatting on an inherited method. You probably already know that you can write something like:
def my_nifty_method(value)
super(nifty_parameter_formatter(value))
end
But, did you know that you can also do this?
def my_nifty_method(value)
value = nifty_parameter_formatter(value)
super
end
I didn't, until I just gave it a try this evening, for giggles. I figured it might work for methods that mutate an object, like Array#unshift, but since variable assignment is creating a new reference, I just assumed I'd need to explicitly pass in my modified value. Chalk me up as pleasantly surprised! Since I don't ever remember seeing this information before, and a few quick Google searches turned up empty, I thought I'd share.
[Update: I've been informed this specific behavior was one of the topics covered in James Edward Gray II's (aptly named) talk, "10 Things You Didn't Know Ruby Could Do". Worth a look for some other nifty tricks!]
Looking for a previous post? Check the archives.