Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

Ezra Zygmuntowicz -- Farewell, Friend.

Posted by Mon, 01 Dec 2014 17:53:00 GMT

Yesterday, I found out that Ezra Zygmuntowicz had passed away.

Ezra and I first met in the #Caboose family. The first time we got to spend time together, in person, was at RailsConf 2006.

(photo credit: Jarkko Laine)

A few weeks later, he emailed me to ask about getting a job here at Planet Argon. We couldn’t afford him so he continued to pursue other paths… and a month later was helping found EngineYard.

(…one of those things that I still find myself asking, “what if we could have?”)

Back when Planet Argon had a hosting department, Ezra and I collaborated on various deployment best-practice projects. He was always helping our team figure out how to make deployment easier. Some of us might remember his famous nginx configuration (the closest version I could find). He was an active contributor in the Ruby on Rails Deployment group that I started. He was always around to help the community.

Ezra always seemed to find time for the community… whether on mailing lists, at conferences, commenting on our blogs, or chatting over IRC.

When Ezra and his family moved to Portland, we made several half-assed attempts to schedule time to catch up again in person. It never happened and our interactions were limited to keeping up on Facebook

His passing is a great loss to our community.

To his friends and family, I am sorry for your loss.

To his son, (should you ever discover this), your father helped pave the way for hundreds of thousands (if not millions?) of software developers around the globe—whether they know it or not. He was constantly looking for innovative ways to solve problems. His talks at conferences were always fascinating… and the rest of us would sit back and think, “where does he come up with these ideas?!”

He was a trailblazer.

He will be missed.

Thank you for everything, Ezra.

Update: If you would like to contribute to the memorial fund for Ezra’s son, Ryland, please visit this campaign on indigogo.

Ruby on Rails is like IKEA...whaa?

Posted by Wed, 02 Apr 2014 17:14:00 GMT

Recently, I found reading an article by Paul Venezia titled, Fatal abstraction: A bottom-up view of high-level languages, where—if you read between the lines—you can see that Paul just found himself waking up from a coma and it’s no longer 2004.

“I may have questioned Perl’s future now and then, and Perl certainly doesn’t have the presence it once enjoyed, but the strength of Perl has always been its flexibility. You can do pretty much anything with Perl, and you can do it in a wide variety of ways. Perl’s core revolves around the idea that there’s always more than one way to do it. In fact, there may be dozens of ways to do it. PHP shares a similar trait in that it gives you a large set of tools and leaves the construction up to you.

Ruby, and especially Rails, is the opposite, and Python definitely leans more in that direction. Essentially, it’s the difference between building a chair from raw lumber and assembling one from IKEA. This isn’t to say there’s anything wrong with assembling from parts, and clearly Ruby and Python are very capable and strong languages. However, they’re not my cup of tea.”

Admittedly, perhaps I’ve been in drinking the “kool-aid” for far too long, but I thought this tired argument has run it’s course.

I take huge offense to comparing Ruby on Rails to IKEA furniture. It’s far easier to build a web application with Ruby on Rails than it is to build an IKEA bookshelf

“When it comes right down to it, I need to know exactly what my code is doing. I’m going to keep an open mind and spend more time on the other side of the fence in the short term. Perhaps I’ll be won over, but it won’t be easy. Trust issues are complicated.”

Paul, I completely understand where you’re coming from. It sounds like you’re dealing with similar trust issues that I had nearly a decade ago. Trust me, it will be okay.

Ruby on Rails isn’t magic. Behind the curtain you’ll find a collection of object-oriented code written in one of the most readable languages in existence.

Jim Weirich -- Farewell, Friend.

Posted by Fri, 21 Feb 2014 05:30:00 GMT

It’s been an odd day. The sort of day where you really don’t know what to say. The only thing you can manage to get out is, “Sigh. I’m going to miss him.”

Jim Weirich was building interesting stuff with Ruby several years before I was introduced to it. Tools that most of us have taken for granted. Tools that were just there.

Before Jim came along… they didn’t exist.

Back in the early Ruby on Rails explosion era (circa 2004-2006), it was much easier to get to know the great Rubyists. I remember finally getting a chance to meet Jim (and _why) at FOSCON here in Portland, which still goes down as one of the best “conferences” I have ever attended.

(I think we all knew something special was happening.)

Jim spoke at a ton of conferences. At any conference that I seemed to get invited to speak at… Jim seemed to always be on the speaker list too. We’d end up meeting up on the conference circuit a several times over the coming years. It was always a delight to catchup.

Photo by Obie from Rails Underground 2009

I believe the last one was in 2009 at Rails Underground in London. I remember walking in one of the rooms and spotting Jim. There he was… waiting patiently for his time slot… sitting by the wall in another horribly uncomfortable conference chair… hacking away on his laptop as if he was on a mission to save the human race. In reality, he was probably toying around with some new idea.

As I walked towards him… my red hair must have caught the corner of his eyes… because he looked up and with the warmest of smiles and kindest of voices said, “Robby!”

It’s people like Jim that helped me feel like I had something valuable to contribute to the community. The mere fact that he knew who I was, that he commented on my silly blog posts, referred potential customers to me, showed up for and complimented me on my talks, asked ME for advice on IRC, wished me a happy birthday on Facebook, responded to my lazy tweets… made me feel like I was welcome to (and part of) the party.

A party that started a number of years before I showed up.

Let us raise our glasses high and thank our host for the pleasure of being amidst his most generous company.

Thank you, Jim, for helping me learn more about myself. I only wish I had gotten to know you more.

Adieu l’ami.

Email twice. Four months later

Posted by Wed, 21 Oct 2009 22:41:00 GMT

It’s been just over four months since I posted about my experiment, Email. Twice daily. No more, no less. where I shared my plans to restrict myself to checking email only twice a day at designated times. In the post, I had hinted at sharing my lessons months later. So, it’s time to throw my dirty laundry in the street and expose myself.

First off.. the brutal truth. It’s really fucking hard to maintain this. Habits are nearly as hard to make as they are to break. I suspect that I honor my rule 2-3 days each week and it’s completely inconsistent the remainder. Usually, I find myself looking at email at 8:30am and have to slap myself and yell, “what are you doing?!!?”

Guilt sinks in and I hit ⌘-q. Problem solved… for a little while.

So, what has lead to this. Well, one of the biggest hurdles has been that one of our largest clients is now focused more in the United Kingdom. Luckily, I’m an early-morning person, but this means that my 10am PDT rule wouldn’t have me checking for their precious emails until 6pm GMT their time. Not exactly acceptable. So, I’ve been more flexible in the mornings and responding to emails as early as 5-6am PDT. However, I realize that I’m cheating myself of previous focus time and need to recalibrate my email windows.

Given these new constraints, I’m now trying 8:30am and 2:30pm as my primary email times.

I’m curious how this has been working out for you…

Remember to Flush Your Toilet

Posted by Sat, 20 Jun 2009 00:58:00 GMT

Saw this tweet the other day…

Twitter / Teresa Brazen: Design Principle: Flush t ...
Uploaded with plasq’s Skitch!

So, I have to ask. How many toilets (buckets) do you maintain? How many of them still have projects/tasks in them? Why haven’t you flushed your toilets yet?

Lessons through failure. Episode 1

Posted by Sat, 17 Jan 2009 23:34:00 GMT

I fucked up this last week.

On Monday, our primary contact for a large client sent over some last minute requirements and deadlines that were needed by end-of-day Wednesday. I didn’t have a lot of time to collect requirements and execute it without having to rearrange my priorities. But, I accepted the challenge.

The big change involved was that we were going to be supplied with a ton of data to be imported in to the database and approximately 20% of the data provided was new records, while the rest were duplicates. However, the other 80% wasn’t to be discarded as there were a few attributes that needed to be updated from the data file (which was supplied from the client’s parent company). In my haste to get the task done on time (didn’t get proper export file to be imported in our system until Wednesday morning)... I ended up running a few tests locally and pushed it out to production.

I managed to get the import file to run in production before leaving on Wednesday afternoon. The following morning, I came into the office to find out that my import process didn’t match up records properly and resulted in nearly all of the 80% side of that to be duplicated in the system. This resulted in lost productivity for our client, their vendors, and our team over a 12 hour period as people were confused about why reports were running weird, online transactions didn’t account for the duplicated, etc.

It took me most of Thursday and Friday to clean up the data that got skewed due to that oversight. Hi ho.

So, the take away from this? Sure, I could have blamed it on a lack of sufficient time to properly test things, but that’s bullshit. I should have had at least one other developer from our team review the problem and evaluate my proposed solution prior to me attempting to push into production.

Luckily, the client was happy that we were able to finish the last minute tasks, despite the unexpected headaches that cropped up.

If anything, I was just disappointed in myself, but Alex reminded me how important it was to fail early, fail often. It didn’t kill me (or anybody else for that matter), cost us the project, nor was it irreparable.

In the real world, deadlines and requirements change on a moments notice and it’s experiences like this that will make ourselves more confident that we can quickly respond to and execute.

What was your latest failure?

Older posts: 1 2 3 ... 9