The Ship's Log

Nathaniel at FutureRuby

Wed, 15 Jul 2009 15:50:07 +0000

I had the opportunity to open up the FutureRuby conference in Toronto, Canada this past weekend. For more details, including the full text of the talk, head over here: Owning the Means of Production.

The Lean Startup Primer

Mon, 08 Jun 2009 14:35:33 +0000

I’ve been focused on the care and feeding of young businesses for over three years now. It’s my passion. It’s what compels me to run Terralien. It’s what got me interested in the ideas behind Spreedly. It’s one of the skills I’m most excited about passing onto each of my children. It’s something that I’m on a never-ending quest to get better at.

So when an idea comes along that has the potential to make more young businesses successful, I get really excited about it. Sometimes so excited that I have to do something to promulgate it right away. When I ran across the growing Lean Startup meme last week, it intersected with my passion so powerfully that I spent most of the weekend building the Lean Startup Primer.

Now, my interest in Lean Startup concepts didn’t begin last week: I’ve been applying some lean principles for years, mostly under the auspices of Getting Real, and have further been studying lean manufacturing concepts for months seeking ways to help Terralien deliver better value for our clients. As a matter of fact, just this past Tuesday I had a discussion before the Agile RTP meeting about wanting to put on a course about lean principles and how they apply to young software businesses. But I was missing Customer Development, Steve Blank’s excellent methodology for finding out what the market really wants before spending time building the wrong thing.

With a (more) complete picture of how to apply lean principles to formational businesses, I knew it was time to get real and actually teach the material, and thus the Lean Startup Primer was born. The goal is not to teach you everything there is to know about Lean Startups (the mind boggles), but rather to give you an overview of the powerful principles involved and a jumping off point from which to learn more. With a very small class size (12 people max) and hosted at the wonderful Carrboro Creative Coworking, it should be a fantastic experience. If it goes at all well there will be additional events, though the price will go up after this inaugural session.

I’m really, really excited about the Lean Startup Primer, and I hope to see you in Carrboro on June 17th: sign up now!

Five Skills Every Freelancer Must Have

Fri, 27 Feb 2009 19:51:00 +0000

If there’s one thing I do a lot at Terralien, it’s work with freelancers. And if there’s one thing I’ve learned while working with them, it’s that some freelancers are way better than other freelancers, and the difference usually isn’t technical. Thus I’ve been chewing on the idea of giving a talk about some of the important differences between those who excel and those who struggle, and I got my first chance to do so at RubyRX this past weekend.

I’d appreciate any feedback you have, either in the comments below or at SpeakerRate, as I’m hoping to take this material (and more) and flesh it out in to a course and/or a book.

A little about how this was recorded: I set up my Flip Video Recorder on a little tripod with the expectation that it would run out of space at 60 minutes and I’d have a recording to review for technique and to improve the next talk, but that I wouldn’t capture the whole thing. Well, I was wrong: I got everything except the last 5-10 minutes of questions! I think because the view was stationary that the video compressed well. All in all I captured just over 83 minutes on my 60 minute Flip.

A Coffee Shop Chat

Tue, 03 Feb 2009 15:23:00 +0000

As part of the lead-up to RubyRX I got the opportunity to sit down with Jared Richardson and chat about Ruby, what makes a well-rounded programmer, Spreedly, the importance of going to at least one or two conferences a year, and more:

The funny thing (in retrospect at least!) is that we did the interview twice, but the first time, unbeknownst to us, the tape ran out halfway through! I’m just glad it turned out natural the second time, probably because we talked about a somewhat different set of topics.

Thanks to Jared for doing the interview – it was a blast. Hope you enjoy it!

Why You Should Be At RubyRX

Mon, 26 Jan 2009 17:27:00 +0000

In his excellent book The War of Art, Steven Pressfield talks about “Turning Pro” as the key to overcoming resistance and consistently spending time on what we truly value:

Aspiring artists defeated by Resistance share one trait. They all think like amateurs. They have not yet turned pro.

…

The traditional interpretation is that the amateur pursues his calling out of love, while the pro does it for money. Not the way I see it. In my view, the amateur does not love the game enough. If he did, he would not pursue it as a sideline, distinct from his “real” vocation.

The professional loves it so much he dedicates his life to it. He commits full-time.

That’s what I mean when I say turning pro.

Resistance hates it when we turn pro.

Steven Pressfield, The War of Art, “Professionals and Amateurs”

For myself, a big part of turning pro in software development was committing that I would go to at least one excellent conference every year. It’s a costly commitment at times, but it’s been so incredibly worth the investment. I’ve formed lasting relationships, gotten the jump on important techniques and technology, and found out about tools that I still use on a regular basis. I’ve also seen that a conference serves to get me pumped up to tackle things that I’ve been putting off, and gives me new perspective on problems I’ve been scratching my head over.

I’m a big fan of hobbyist conferences. RubyConf has been my mainstay for years, and I’ll be at the most excellent acts_as_conference in a few weeks. But I also think there’s an important part to be played by professional conferences that have an invite-only speaker list, and are paid for by attendees rather than by sponsors. If you look at the list of speakers and the set of sessions scheduled for RubyRX, you’ll find an A-list of smart folks and a wide set of topics guaranteed to teach you something outside your comfort zone. And if you’re a professional software developer, as I know many of you are, then I believe you’ll find yourself more than paid back in learning and growth by attending. There’ll be talks on Merb and Rails 3, Erlang, Rewriting Rails in 90 Minutes, Clojure, Sinatra and more – how many of these topics have you wanted to explore but just haven’t had time to yet? Well here’s your chance!

If you’re not a professional yet, still sitting on the sidelines, then this could be a great opportunity to make the jump. A conference like RubyRX is a great kick in the pants, and can give you the confidence to go to the next level. You’ll get lots of hallway time to chat and get inspiration from those who’ve already turned pro, and the sessions will generate all kinds of ideas on how to go from being an amateur to being a professional. I’ll personally be giving two talks that I think every professional should hear – one on the Fear of Programming (with more from the War of Art) and one on the Five Skills Every Freelancer Should Have.

RubyRX is February 19th-21st, 2009 in Raleigh, NC. You have until the end of the week to (January 30th) to get the early bird price, so don’t delay. I can’t guarantee that RubyRX will be one of the excellent conferences this year, but I can guarantee that Jared, myself, the other speakers and all the attendees are going to do our best to make it so. And it’s even more likely to be excellent if you decide to come, so sign up, come out, and let us help you “turn pro”!

Sprint or Marathon?

Mon, 12 Jan 2009 19:13:00 +0000

Both sprints and marathons have starting lines, and the people lined up behind them are equally pumped up to start running the race. Adrenaline courses through the veins of a marathon runner on the starting line as surely as it does through the runner of a sprint waiting for the gun. And each kind of runner looks towards the finish line for their race, the end goal in sight.

And yet – what happens between the start and finish of a marathon and a sprint couldn’t be more different. In a sprint, the effort is focused in to mere seconds or perhaps minutes, and the runners push hard, giving everything they’ve got with each foot traveled. It doesn’t matter if they collapse after only running a few hundred yards – so long as they got over the finish line first, they’ve won. The start is critical, as it makes up a huge percentage of the race, and as the race is run, a tiny stumble spells doom. It’s a very unforgiving race – everything must be done just right, or there’ll be no trophy.

A marathon is something altogether different. Everyone knows as they leave the starting line that they’re going to be running a long time, and that if they don’t pace themselves they’ll never make it to the end much less have the best time. The start is important, but pales in comparison to sustained progress. Even a large stumble disappears in to the noise of the race so long as it doesn’t result in any physical damage. And the race is as much against the clock as it is against the other runners, with everyone striving towards their personal best.

Now, I’m more of a sitter than a runner, so I know these things not from experiencing them but rather from watching Chariots of Fire and talking to people who have run marathons. But what I do have lots of first hand experience with is building businesses, and I can tell you that there are important, enduring lessons to be had in this comparison for anyone thinking of starting a business. The external view of entrepreneurship, and the view of many just starting out in it, is that it’s a sprint: all the energy focused in to a small period of time for a huge pay-off at the end. Yet once you have a few months of a new business under your belt you’ll discover that it’s really a marathon, with the focus being on endurance and constant progress. Going really fast turns out to be overrated, and envisioning and constantly moving towards a finish line that is well out of sight is what separates the winners from the losers.

Those who approach business as a sprint quickly burn out. They run the first few months, maybe even the first year or two, with a gusto that seems enviable. And yet, as time wears on, they tire and start to get discouraged, and often collapse well before the half way point. Those who realize they’re embarking on a marathon, however, get off to a good start, and yet quickly fall far behind the sprinters. But soon enough they catch up, and then gradually leave those less prepared behind.

As you think about the business you want to start (I know you have one!), are you prepared for it to be a marathon? Are you ready to stick it out for years to make it a success? Big, sudden success stories are usually the product of years of quiet persistence, or as Sam Walton said of Wal-Mart, “Like most other overnight successes, it was about 20 years in the making.”

So which are you planning to run? A sprint, or a marathon?

Nathaniel at acts_as_conference

Wed, 17 Dec 2008 19:37:00 +0000

I’ll be keynoting at acts_as_conference in Orlando, Florida in February, and I can’t wait! More details over at my personal blog.

Codename MC

Mon, 08 Dec 2008 20:55:00 +0000

Terralien’s building a product! Come follow along at Codename MC to get a peek at what we’re building and the process we’re building it with.

Now or Never

Thu, 04 Dec 2008 21:53:00 +0000

There’s a lot of uncertainty right now about the economy, about jobs, and more immediately for some folks, about paying for Christmas. Economic times are tough, or so they tell us, and all the talking heads (who were, it should be noted, saying how great things were six months ago) are telling us the sky is falling. Regardless of how sound your personal financial position is, it’s hard to not accept at least a part of that vibe in to your own thinking, and start panicking inside over what might (or might not) happen.

And yet, the amazing thing is that today is pretty much like yesterday, and this month is pretty much like last month. The only real difference is in our perception and understanding (right or wrong) of reality.

So the question is, why aren’t you starting that business you’ve been contemplating for months? Or maybe it’s been years? Is it because of the current economic news? I doubt it. If it was, you would’ve started it before we realized things were bad, and it would already be in process now.

The story we tell ourselves is key, and while we might be getting bombarded with a particularly sour story right now externally, it’s the internal story that prevents (or enables!) us to build something successful. And that’s why a whole bunch of smart people with way more experience than me are saying that right now is a great time to start a business, Seth Godin and Paul Graham being just two of them.

Regardless of what you decide to do, I know what I’m going to do: lean in to the wind of popular opinion and use this time to build something great. I hope you’ll join me!

Of course, I have an ulterior motive in encouraging you to get started, since it’s startups and entrepreneurs and small agile businesses that we focus on here at Terralien. If you need help on the software design+development side of things, I hope you’ll drop me a line so we can figure out how Terralien can help you succeed regardless of what the pundits say.

Smart Asset Management for Rails Plugins

Fri, 14 Nov 2008 20:23:00 +0000

Many Rails plugins require that certain files like images, CSS, and JavaScript get copied to the public folder during installation. The typical way to do this is add code to install.rb, which then gets executed when you first install the plugin in your Rails project. What happens when the assets in a plugin you’re using change, though? You end up having to manually copy files around anytime the plugin gets updated, which is an extremely error-prone process (if you remember to do it in the first place!).

I got tired of mucking around with install.rb and having to sling files around whenever a plugin changed, and so I wrote asset_copier. It’s a generator that runs against your plugin and installs an asset management system that gets checked in with the rest of your plugin code. Once installed, any Rails app your plugin is installed in gets a plugin_name:install task that intelligently copies over any files located in the /files subdirectory in the plugin. Files will also be copied over every time the plugin is reloaded or Rails is restarted in development mode. When running in production mode, warnings will be printed to the log for files that are missing or have changed.

You can check out the README for installation instructions and additional documentation, and I’d love to get any and all feedback you have as you start using it in your own plugins.

Oh, and if you’re looking for a plugin using asset_copier, look no further than the textile_toolbar that Terralien announced recently.

Announcing the textile_toolbar Plugin

Wed, 29 Oct 2008 21:51:00 +0000

I’m tired of settling for a WYSIWYG editor in my Rails apps. Plugins like FCKeditor and TinyMCE work moderately well for the end user, but they can generate ugly HTML on the backend. I hate dealing with that. Textile is so much better, but our clients often dislike dealing with the markup. Isn’t there a way to bridge the niceness of Textile with the end user experience of a WYSIWYG editor?

It turns out that there is: it’s the new textile_toolbar plugin. Extracted from a recent Terralien project, the plugin adds a handy toolbar to Textile-enabled form fields. The buttons on the toolbar generate the appropriate Textile markup for your users. For example, clicking the “Bold” button will surround the highlighted word with the correct Textile markup to make it bold.

textile_toolbar lets you retain the benefits of Textile while at the same time offering your users a friendly interface for generating markup. The plugin is a great way to learn Textile, but even if your users don’t want to bother with memorizing the markup, the toolbar will still be there to assist them with their editing.

It’s easy to get started with textile_toolbar. To install the plugin in your Rails 2.1 (or greater) project, run:


script/plugin install git://github.com/pelargir/textile_toolbar.git

To add the toolbar to an existing text area, change the text_area or text_field helper call to textile_area. It’s that simple! Be sure to check out the README for further integration guidelines and options.

Update: A live example of a Textile-enabled text area can now be found here.

%B %Y Archives

Fri, 27 Jun 2008 15:59:00 +0000

Posted by on | 1 Comment

Radiant CMS Extensions

Wed, 18 Jun 2008 09:32:00 +0000

Up until recently I had admired the Radiant Content Management System from afar but hadn’t had a chance to really dig in to it. While the Terralien website runs on Radiant, a lot of the power of Radiant doesn’t come to the fore until you want to extend it, and our website’s needs are very vanilla. So when an opportunity came along for us to do the back-end for a content heavy site for Ignite Social Media, I jumped at the chance to put Radiant through its paces. In particular I got to do a bunch of Radiant extension development, both writing an extension from scratch as well as doing heavy hacking on some existing extensions, and I’d like to talk some about that process as well as highlighting the (all open source) extensions that came out of it.

First, a little about the site we built: it’s a marketing site for a newly launched product, and we were tasked with taking comps from Ignite, implementing them in Radiant, and hooking up the various dynamic pieces of the site. Those dynamic bits included a quiz visitors can take, blog comments, various mailer forms, site search, a site map, etc. All fairly standard stuff, but the goal was to build out exactly the back-end that was need for the project rather than using a CMS that provides everything and the kitchen sink and ending up with a cluttered, confusing admin interface. Of course Radiant being Rails-based was also a big draw: almost every project needs to “draw outside the lines” at least once, and we think it’s ever so much nicer to do custom development in Ruby than it is in PHP, the lingua franca of most popular CMS’s.

After getting Radiant up and running on our staging server – a completely painless process – work commenced with the quiz extension which I wrote from scratch. The experience was mostly painless, but there were two aspects I think can be improved on. First of all, the available documentation is a bit spotty, and while this didn’t bother me too much (I’m an avid code reader) I could see it causing issues for some folks. The other thing I found somewhat disconcerting when getting started was the lack of direction on how best to implement the mechanics of an extension. Some extensions post back to a custom page type, some extensions provide their own controllers, and error handling is all over the map. I think some of the issue is just that generic component-based development is hard, but that doesn’t mean that a “best practice” extension style couldn’t be adopted and encouraged. I ended up settling on a particular style that I think works well, but it still has some significant drawbacks, and I’ll definitely be continuing to noodle on the issue as I work on future extensions.

After the quiz extension, I moved on to some areas that already had existing extensions available, in particular mailers and comments. Github was the star that stole the show here, since I ended up forking both of these extensions and hacking on them extensively to get them working like I wanted. Since the comments extension was already on Github I was then able to submit the changes to it right back to the original author, and he incorporated them in to his repo. Currently you can only get my mailer changes from my Github hosted fork, but a little birdy has told me that Radiant will be moving wholesale to git in the near future, and when it does I’ll be contributing my changes back.

Of course, we also used a bunch of extensions completely as-is, in particular the Copy Move extension, the Reorder extension, and the Search extension. Thanks so much to the authors of these extensions as well as the ones we forked: you saved us so much time!

And we’re not done yet: in the works we have a “ratings extension”, and we’ll also be doing some serious hacking around WYSIWYG editing and asset management. You can keep up with the latest by watching my Github page, or I’ll try to post an update when we push out our next batch of extension-y goodness.

In the meantime, have you tried out Radiant? What did you think of it? Any cool extensions you’ve found whilst poking around the internet that we should be sure to take a look at? Have you written an extension yourself? I’d love to hear your thoughts!

Ruby Hoedown!

Wed, 11 Jun 2008 09:38:00 +0000

If there’s one thing that we believe in (and have benefited from in a big way) at Terralien, it’s the power of the Ruby community. Since I attended the first RubyConf in Tampa in 2001, I’ve been constantly amazed by the vibrancy, passion, and all-around niceness of Rubyists when they gather in groups, whether virtually or physically. And so it is with great pleasure I point you to the second annual Ruby Hoedown, the southeast region’s premier Ruby conference, taking place this year in Huntsville, AL. The organizers already have the schedule up and registration open, so head on over there, check out the top-notch offerings, and make your plans to be in Huntsville in August this year. While I’m not helping to organize the conference this year, I’m definitely going to be attending it, so I’ll see you there!

Prices: To Publish, or Not to Publish?

Wed, 04 Jun 2008 11:22:00 +0000

It’s an age-old question for services companies: should we publish our prices, at least some of them, or should we wait until we’ve had a conversation with a potential client before discussing price? Recently at Terralien we’ve changed our answer to that question and decided to start publishing some of our prices, and I thought I’d write a bit about the thought process that went in to the decision.

Actually this process started at least a year ago when I added a little drop-down box to our contact form that had general budget information in it. The options started at $10k and went up from there, and the reasoning was simple: I was getting at least one request a week from people looking to get their huge projects done for $2k (more or less). Talking to people with such unrealistic expectations was a complete waste of time: no, we’re not going to do your 400+ hour design/development project for $5/hour. Really. And just putting that little $10,000 budget as the lowest option immediately cut these requests out almost completely.

Now we’ve taken it a step further: on our Product Outlining and Launch Cycle pages you’ll find a published price for each of those services. These prices, and a price for our Background Work, also show up on our updated contact page as well. Of course, all prices are negotiable – we’d love to customize a project for you that fits your budget and your timeline. That said, we think that providing at least a starting point for negotiations helps potential clients to envision and plan what it would take to get their idea live, and that’s important for an entrepreneur.

We had some interesting internal discussions about publishing prices, and I’m not 100% sure it’s something we’ll do long-term – for now it’s very much on probation. There are concerns that it makes us appear as a commodity instead of the custom software shop we are. On the other hand, there was a lot of internal excitement about being so transparent. As entrepreneurs ourselves, we know how useful it can be to get an initial peek at what it might take to launch our ideas before diving in to details negotiations.

So what are your thoughts? Should services companies publish at least some of their prices? Should Terralien? Does it help or hurt?

Refining and Refreshing

Mon, 05 May 2008 14:03:00 +0000

We just launched a refresh of the content on our main site – do check it out! While the changes aren’t very drastic, they do reflect a significant refinement to how we do business and I wanted to take the opportunity to talk a bit about why we made them…

As any business owner will tell you, two years of running a business will net you a lot of learning, and that’s certainly been true with Terralien. As I’ve worked with clients and crew members over the past two years, I’ve been able to start recognizing some patterns in the requests that we get, and in the expectations that our clients have. In particular I’ve found that our clients highly value three things: insight, predictability, and transparency. Every successful Terralien project has had a high level of these three things, and every failure of any size has been lacking in one or more of them. I’ve come to realize that if Terralien can consistently deliver all three, we stand a good chance of making each and every project a raging success, which is of course our ever-present goal. So how are we addressing each of them?

In the area of insight one of the primary ways we’ve failed in the past is at the start. We’re not big fans of lots of up-front planning, but me whipping out an estimate in a couple of hours was not cutting it. Part of the difficulty is the snow-ball effect – if the project gets started off on the wrong foot, it’s a lot more likely that things will get worse than that they will get better. Thus we’ve started going through an explicit product outlining process with most clients where we spend some quality time understanding what needs building before we try to build it. As an added benefit, product outlining generates portable insight: clients can take what we learn and use it to get estimates from shops other than Terralien. Definitely check out the details.

Predictability is a real conundrum since we haven’t yet figured out how to predict the future, and reading “Prognostication for Dummies” didn’t seem to help much. Regardless of the difficulties, though, this is one of the most immediate concerns clients have, and every project starts out with the same questions: “How much will it cost and how long will it take?” While we can’t predict the future, past experience has taught us that we can almost always launch a useful product in about two months. We call these two month time boxes launch cycles and we’re finding they really help clients to both know what their budget will be for initial launch and to stay focused within that window.

Finally, there’s the all-important quality of transparency. Transparency isn’t so much about one big thing; rather, it’s about a lot of little things that add up to a big thing. If a client is paying us they deserve to know how the work is going and to feel comfortable with our progress, and there are lots of small ways we’ve learned and are learning to keep them in the loop. Most important is just making sure they’re comfortable telling us when they’re not satisfied so we can fix it, and I personally am learning a lot about making myself open and available to hear the concerns. It’s not always easy to do, but it’s always worth it.

We’ve really tried to capture the essence of these things in the site refresh, so please have a look and let us know if we’ve succeeded. Feedback is always welcome!

"Camping in 10" at BarCampRDU

Sat, 04 Aug 2007 11:40:00 +0000

I’m currently hanging out at BarCampRDU 2007 and having a blast. BarCamps are “unconferences”, which means the talks are proposed and given by the attendees on the day of the conference. Rather than just soak it all in, I decided to throw my hat in to the presenting ring and do a redux of the Camping in 10 talk I put together for Raleigh.rb a little while ago. After getting through a few projector struggles, it went really well, and I was able to expose about 30 people to Camping.

A few folks asked for my slides, so I threw them up on the interwebs, and you can get them here: Camping in 10 slides. Enjoy, and if you attended the talk and end up writing a Camping app of your own, drop me an email or a comment and tell me about it – I’d love to see what folks come up with.

Ya’ll make delicious pork pies!

Sales Jeopardy! at RailsConf!

Wed, 16 May 2007 14:20:00 +0000

So the tricky part about proposing a talk so many months in advance is that you never know what you’ll have learned (or not learned) by the time the conference actually rolls around. Back in November when I proposed my RailsConf talk, I was thinking that by now I would’ve reduced my sales and marketing efforts down to at least a general outline I could share with those at the conference. Boy was I wrong! The more I work to land projects, the more I realize that at least in this business, each sales process is unique as a snowflake. Yup, that’s right, the “MVC” pattern I put in the abstract is really clever, but turns out to not be very useful, at least for me.

So where’s that leave my presentation on Saturday? Never fear! Because while snowflakes are each unique, they do share common properties. So what I’m going to do is switch from focusing on a process, and instead do my best to pass along the tips, tricks and rules of thumb I’ve picked up over the last year and a half of selling Terralien. I might not have a useful system for selling custom software, but I sure have a lot of great “lessons learned” that I think everyone at the talk will find hugely valuable.

Upon figuring all this out, I was left with one problem: how do I structure the presentation? I mean, c’mon, every presentation needs a gimmick, right? After much mulling, I struck upon the perfect approach a few days ago, and instead of doing a plain old boring presentation, we’re going to do a super-agile game show! That’s right, we’ll be playing Sales Jeopardy!, with actual cash prizes to boot. Of course, not being a rich TV show, the prizes will lose a few zeroes off the usual Jeopardy pay-out, but hey, somebody might be able to at least buy themselves dinner ;-)

Hope to see you on Saturday in Portland!

Ruby Hoedown!

Tue, 27 Mar 2007 21:01:00 +0000

I don’t want to dup the whole post, but in case you don’t follow my personal blog, I just posted over there about the upcoming Ruby Hoedown 2007. Have a look and make sure to sign up for the announcement list if you’re at all interested in coming. See you in August!

Ruby Tidbit: Enumerable#collect_one

Thu, 01 Mar 2007 14:02:00 +0000

  module Enumerable
    def collect_one(default=nil)
      inject(default) do |d,e|
        if v = yield(e)
          break v
        else
          d
        end
      end
    end
  end

So this:

  element = %w(a bb ccc).detect{|e| /b/ =~ e}
  size = (element ? element.size : 0)

Becomes this:

  size = %w(a bb ccc).collect_one(0){|e| e.size if /b/ =~ e}

Discussion starter: does the name communicate?

TextMate tip - Run Last

Thu, 08 Feb 2007 10:40:00 +0000

When coding Ruby, I love being able to run a test suite right in TextMate (Command-R), but recently I was wanting something a bit more. Back in my bad old Eclipse days, I used a nice little feature that let you hit Ctrl-F11 to re-launch the last command you’d run in the IDE, regardless of where you currently were. After an intensive cycle of test-code-test-code in TextMate, I was getting tired of having to switch back to my test to re-run it, so I decided to take a page from Eclipse’s book and “Run Last” was born. Lets walk through it.

Create the new command (by ripping off the standard one)

Hop in to TextMate (it’s already running, isn’t it?)
Select “Bundles>Bundle Editor>Edit Commands” from the menu
Expand the Ruby bundle, and select the “Run” command
Click the little ‘double-plus’ at the bottom, which duplicates the current command
Name the new command ‘Run Last’

Make it use our special file

With “Run Last” still selected, paste this in to the text area:


  export RUBYLIB="$TM_BUNDLE_SUPPORT/RubyMate${RUBYLIB:+:$RUBYLIB}"
  export TM_RUBY=$(which "${TM_RUBY:-ruby}")
export TM_FILEPATH=`cat “$TM_PROJECT_DIRECTORY/.tm_last_run_ruby”`
cat “$TM_FILEPATH” | “${TM_RUBY}” — “$TM_BUNDLE_SUPPORT/RubyMate/run_script.rb”

What we’re doing is reading a hidden ‘.tm_last_run_ruby’ file to figure out what file to run.

Get the special file written out

Now go back to the “Run” command, and change it to this:


  export RUBYLIB="$TM_BUNDLE_SUPPORT/RubyMate${RUBYLIB:+:$RUBYLIB}"
  export TM_RUBY=$(which "${TM_RUBY:-ruby}")
echo “$TM_FILEPATH” > “$TM_PROJECT_DIRECTORY/.tm_last_run_ruby”
“${TM_RUBY}” — “$TM_BUNDLE_SUPPORT/RubyMate/run_script.rb”

This writes out the file about to be run to the special ‘.tm_last_run_ruby’ file.

Enjoy!

Assign a key combo to “Run Last”. I use Command-Ctrl-R.
Delete the scope in “Run Last” – we want to be able to run it anywhere and everywhere.
Ignore ‘.tm_last_run_ruby’ in your source control, lest it bug you.
Run a Ruby file like normal, then go anywhere and re-run it with impunity.

Make it better

This is totally my little hack – if you have ideas for a better way to do it, I’d love to hear them. Also, if there’s a good way to distribute things like this that doesn’t involve all the manual steps, I’d love tips on that, too. And of course, if this helps you, I’d love to hear about it.

Rails Sharing++

Tue, 19 Dec 2006 11:08:00 +0000

Our own John Long has a very thought-provoking article over on his weblog about Rails needing something better than Engines for sharing large chunks of functionality between applications. While John and I have had a lively discussion about where the infrastructure for such sharing should live, we both agree 100% that (a) we need something better than what we have, and (b) Rails itself should at least make it easier to do things like add additional template_roots and externally define new routes. So go have a read, have a look at some of the various attempts in existence (such as Radiant’s extension system, Mephisto’s plugin infrastructure, PluginAWeek’s collection of plugins (no longer available) or the venerable Rails Engines) and lets all start brainstorming and hacking to find the best solution going forward.

Using Protected Attributes in your Rails Models

Tue, 28 Nov 2006 09:40:44 +0000

Terralien crew member Matthew Bass has a great article over on his weblog outlining how to use protected attributes to protect your Rails models from malicious use. Definitely worth a read, both to understand one of the vulnerabilities that a Rails application can have, and how to combat it.

Ruby Certification NOW!

Wed, 15 Nov 2006 10:55:00 +0000

Terralien is a people-centric business. I just had a conversation with a customer wherein he praised the developer working on his project (Matthew Bass) up one side and down the other, asked me how in the world I found such a great developer, and then wondered somewhat incredulously if I had any more. Why yes, as a matter of fact I do, and if you’d like one working on your project, drop me a line :-)

But that is a good question – how do I find great developers (and designers) for the Terralien network? Just like with any other selection process, I stereotype, judge and discriminate. Oops, I guess the more politically correct term these days is, I “filter”. So what are my filter criteria? Well, some of the folks in Terralien are people I’ve worked with in the past. That one’s pretty easy – I know from first-hand experience they can cut it. In the absence of that, the first thing I’m looking for is code, often via the open source projects someone is involved with. Oh, and seeing the code goes for designers just as much as it does for developers – pretty is great and necessary, but what I really want to know is does the designer get the web, and their code is the best way to tell that.

I have two other filters that really matter to me. First, I want to see how someone communicates. One of the Terralien distinctives is that we’re not just code monkeys – everyone communicates well with the “business people” and can do their own day-to-day project management. Thus I’m looking for blogging, conference presentations, project documentation, etc., that will tell me if the person involved is a good communicator. Second, entrepreneurial pursuits are really important to me, since they say something about initiative and a passion for software that goes beyond the technology and in to the business. Since we like working with people starting things, it makes a big difference if my designers and developers have tried to start something themselves.

So what does all this have to do with certification? Well, there’s been a big rumbling in the Ruby community lately about certification, brought on by Pat Eyler’s revelation that he’s working with a university on a certification program. Now I know Pat, and I know he’s very interested in community feedback, as his Ruby Certification: Is It Worth It? post makes clear. My impression is that Pat might be on the fence, especially now that guys like Jamis Buck are saying NOT to do it, and I want to make sure he makes the right decision.

So here’s what I think, Pat – we need Ruby certification (and Rails certification) as soon as you can make it happen. It would simplify my filtering job a lot, since I would be able to immediately discount a whole swath of potential network members. I’d be able to quickly tell if someone just can’t cut it in the real world, has trouble communicating, is more interested in having things given to them than in making things happen, has no passion for software, and likes to buy their way rather than earning it. This would be of great value to me, and to a lot of others like me, so lets do it sooner rather than later.

Now, I know a lot of people are going to say that someone having a certification doesn’t tell you any of those things, but they’re wrong. You see, the problem most people have when filtering by certification is that they disqualify people who don’t have them. I’ll be instantly disqualifying everyone who does have a certification, or at least everyone who’s lame enough to tell me they do, and I can’t think of a better first-pass filter.

So what are we waiting for? Lets make this Ruby certification thing happen, and start separating the wheat from the chaff. It’ll just make my job that much easier.

Repeating Query Parameter (Quick Tip)

Fri, 10 Nov 2006 11:16:00 +0000

Say you’re using ActiveRecord, and you want to write a query that uses the same parameter value several times. For instance:


  Lead.find(:all, :conditions => 
    ['created_at > ? AND updated_at > ? AND published_at > ?', 
      10.days.ago, 10.days.ago, 10.days.ago])

Hmmm… that’s not very DRY, is it? How about we spiff it up some with a bit of Ruby hackery:


  Lead.find(:all, :conditions => 
    ['created_at > ? AND updated_at > ? AND published_at > ?', 
      *([10.days.ago] * 3)])

That works, and it’s probably the shortest solution you’ll find, but it has a few problems. Most glaringly, we’re still not really DRY, because the idea that there are three query parameters is repeated in both the query itself and in the substitution values. Named parameters to the rescue:


  Lead.find(:all, :conditions => 
    ['created_at > :time_limit AND updated_at > :time_limit AND published_at > :time_limit', 
      {:time_limit => 10.days.ago}])

While this is actually the longest solution character-wise, it’s the shortest conceptually, and that’s the way we like it. The one other thing I’d want to do in a case like this is look at the underlying data model and make sure there’s a good reason to repeat the parameter like that… but that’s a topic for another day.

Named parameters are an oft-neglected option in ActiveRecord, even though folks like Robby were riffing on them over a year ago. They’re a major DRY’ing agent, so add them to your toolbox today!

Site Downtime

Fri, 27 Oct 2006 16:04:00 +0000

It figures that right after putting up my RubyConf talk the server I host terralien.com on would bounce, and I would find out that the cron job I set up to re-spawn the site didn’t quite work. Oh, and that all this would occur whilst I was out all day at meetings. And on top of this, I would attempt to show a client our portfolio page in the midst of a sales meeting and get a 500 error. Oh Murphy, how I love thee, let me count the ways…

Moral of the story? Test your cron jobs, especially the ones that only happen at system boot. Only an idiot wouldn’t (d’oh!).

Open Classes, Open Companies - RubyConf 2006

Thu, 26 Oct 2006 17:34:00 +0000

This was my talk at RubyConf 2006, and I can’t tell you what an honor it was for me to address RubyConf for the sixth consecutive year. With each passing year I’ve been a little more surprised, since I just know that someday, one of two things is going to happen: either a baby is going to come in October, or the organizers are going to realize they could fill the time better! Until then, though, I’ll just keep enjoying the opportunity to get up in front of some of the smartest, friendliest people I know, throw some ideas out, and learn something from the conversation that ensues. And boy, have I learned a few things in the past six years!

So here’s the basic premise for today’s talk – the language you’ve chosen to spend time with, Ruby, has certain characteristics that in turn reflect back on you, for better or for worse. I want to take what I consider to be some of the most positive characteristics of Ruby and use them to shine a light on what I further consider to be some of the best ways of doing business – at least if you’re a Rubyist.

A disclaimer – we’re going to be talking about my experiences, both personal as well as what I’ve been able to vicariously glean from the writings and presentations of others. I don’t suppose to know very much about business, and in fact, that’s one of the reasons I’m excited to be giving this talk. I’m really, really hoping that you take these ideas about business and turn them over, poke at them, try them out, and report your experiences. That’s what I’ve had the opportunity to do over the last year or so, and what I plan to continue doing in to the foreseeable future, and let me tell you, it’s a lot of fun.

From whence do these experiences grow? Well, at the end of 2005, after trying my hand at being a regular employee (that didn’t really work out), I decided to get serious about doing consulting. Even while making the transition back in to freelance work, it became readily apparent that being completely independent was going to be tough. Either you’re heads down, trying to get client work done, or you’re scrambling to try to find work when you get finished with a client. Sure, you can hold down multiple contracts, but that’s a recipe for not seeing your family much and not having time to work on other ventures.

The other thing I quickly realized when I got back in to consulting was that my 5+ years in the Ruby community was finally starting to pay off, as the Rails boom was driving demand, and I already had an established name. So, I found some of the best developers and designers I knew that were available and interested in breaking in to Ruby and Rails, and I started finding work, sub-contracting it out, and supporting work in progress. Thus Terralien was born – it’s a very different feel from any contracting/consulting company I’ve ever seen (in a good way), and it’s been a blast.

Now that you know a little bit more about where this is coming from, lets jump right in to our analogy. Again, the premise is that the language we’ve decided to spend time with, Ruby, has certain characteristics that we value, and that we can gain some insight in to business by looking at how those characteristics manifest in business. So for our first characteristic, lets look at dynamic. This is one of the first things a lot of people hear about Ruby – “It’s a dynamic language”. It’s good that it’s a positive word, unfortunately it’s also a very vague one. For me, when I say Ruby’s “dynamic”, I’m contrasting that against “static”, and I’m talking about Ruby’s typing. In practical terms, Ruby’s dynamism means that I get to spend my time building my program, not feeding a type checker. The boogy-man of ending up with a type I don’t expect pretty much stays in the closet, and I get a lot more done. Static typing sounds great in theory, but in practice turns out to not be worth the cost.

Where do we find this in business? How about job titles? “Everyone needs to know where they fit and what they’re responsible for.” Sounds good in theory, but does it work out so well in practice? Think about your current title. Does it help you do your job? My experience has been that when you stick a person in a box, they happily stay in it. This is nice for Human Resources, since it makes it easier to figure out what to pay that person. It’s not so nice for the long-term success of your business, however, since that person becomes, even if just sub-consciously, limited in what they will and won’t do by the title they’ve been given.

In Ruby we have duck-typing, right? If it walks like a duck and quacks like a duck, it must be a duck. When I came to RubyConf in 2001, I was a programmer. I bet you can list off a litany of things a programmer is – but have you ever thought of what a programmer isn’t? A programmer isn’t an accountant, isn’t a “business person”, isn’t a salesman, isn’t ultimately responsible for the success of the business. And so when I came to the 2002 RubyConf in Seattle, I wasn’t a salesman, even though I’ve now found out that I can quack a lot like a salesman. What if I hadn’t been boxed in by my own myopic views of titles? Maybe I wouldn’t have been laid off in 2003, because maybe I would’ve grown beyond the code and taken ahold of the business.

Of course, hindsight is 20/20, and I’m sure there was a lot I needed to learn between where I was then and where I am now – things that help me to sell now. Things like Ruby, which has since taught me the power of dynamism and not being too quick to label things.

Where to next? How about this one – Ruby is interpreted. By this I’m not so much referring to Ruby’s current implementation that happens to run the program straight out of source code, but rather to the fact that in Ruby, the program that gets run is order-dependent. I know coming from Java to Ruby, this one tripped me up – the difference here goes way beyond not having a “main” method. Once you embrace the simple fact that Ruby strictly, without fail, interprets statements as it encounters them, you’ll start to understand something fundamentally different about Ruby, something that adds great power. For instance, all that nifty meta-programming in Rails that gives us validates_presence_of and it’s ilk – that flows from the interpreted nature of Ruby as much as it does from the ease of meta-programming.

So what insight for business can we draw from Ruby’s interpreted nature? How about this – it’s much more powerful to be able to react to changes as they happen than it is to plan what’s going to happen in advance. Interpretive code is inherently more flexible, because so many things can be decided at run-time, and in the same way, a business that can put as many decisions off until the last possible moment is a business that will weather external change much more smoothly. Of course, Ruby’s built for this, and a business that’s going to do it will have to be, too.

Have you read the original Jurassic Park? One of my favorite parts of that book is the meta-narrative that surrounds the chapters, which weave a lecture by the book’s mathematician character around the whole “modern day dinosaurs” theme. In that meta-narrative, he explains how systems must walk the line between order and chaos. If they get too ordered, they will become too rigid, and get overrun by something more flexible. If on the other hand they become to chaotic, they will lose cohesion and fly apart at the seams. When I talk about putting decisions off, I don’t mean to imply that decisions should be avoided altogether – rather that we want to remain adaptive until the last possible moment, make a decision when we need to and then keep moving. This line between chaos and order is fine, and I think Ruby walks it well – hopefully my business can do the same.

Paul Graham is entirely too quotable – that guy just needs to slow down and let the rest of us catch up. Anyhow, he has this great quote, actually the title of one of his essays, “Succinctness is Power”. To me that sums up a lot of the reasons I think we’ve seen Ruby catapulted from obscure language out of Japan in to “blow the doors off of RubyConf” popularity. Ruby is succinct, and I believe from what I’ve heard matz say both just last week on ruby-core and at RubyConfs in years past that succinctness is one of his goals for Ruby.

What’s so great about succinctness? Well, it allows us to do more. The hypothesis Paul Graham puts forward in his article, and that I’ve found holds true in my own experience, is that the amount of code we can produce is somewhat constant, on average, regardless of what language we’re using. If that’s true, then the more functionality a language allows you to implement in the same amount of code, the more powerful that language is. Of course, someone who uses PERL could stand up now and assert that PERL must therefore be more powerful than Ruby, because I think we can all agree that PERL is often more “succinct” than Ruby. The problem is that succinctness is a read/write thing – code is read more than it’s written, and for succinctness to be powerful, it can’t be in a funky shorthand even the author has trouble reading afterwards.

So Ruby is power, I’m preaching to the choir, ra, ra, etc. What about business? Well, let me tell you one of the things that I think has been a secret of my success with Terralien. It’s a closely guarded trade secret, you know… well not really. Actually it’s just that I’ve never asked a client to sign any agreement of any kind longer than two pages in length. And the second page is usually just signatures. What’s the secret here? Well, if succinctness is power in programming because it makes better use of the limited amount of code we can generate in a given week, then a succinct legal agreement is power because it makes wise use of the limited attention a client can give to figuring out what in the world he’s signing his name to.

Big disclaimer – I am not a lawyer, and you should talk to one before you take my advice here. However, I would also encourage you to find a lawyer you can have a good fight with, because too much legal advice is just taken at face value. Have you ever had the feeling that you’re just sort of making things up as you go along, and you wonder when somebody’s going to figure it out and call you on it? Well, your lawyer does that to. Sure, he’s had some expensive schooling, has some experience, and I’m sure he knows more about the law than you do, but he’s in a box (remember those?). From that box, everything is a threat except the fact that you might never actually do any work if you spend all your time worrying about threats.

Here’s the key point – legal agreements have one purpose, and that purpose is to properly set expectations on paper, so that nobody gets surprised. When succinctness is neglected, we end up with a situation where that purpose is lost, and the legal document can actually obfuscate the expectations of each side, with each side defending their position rather than trying to come to a common understanding so they can work together.

Lets say you’re an employee – how does this apply to you? Do you understand your employment agreement? Does it succinctly state both your and your employers expectations? Or does it obfuscate the fact that they expect you to be a corporate slave (maybe they call that the “no moonlighting” clause)? Or perhaps it says they want you having no part in that “open source” thing? I would highly recommend having a look at what you’ve agreed to, and making sure your expectations are in line with your employer’s.

The next Ruby quality I’d like to consider is reflection. Now, a lot of languages have reflection, but what I find great about Ruby’s reflection is its extreme transparency and the way it’s built in to the language from the ground up. Rather than an occasional trick used to work around language limitations, reflection in Ruby is a constant companion. One reason I think reflection is so key to Ruby is Ruby’s dynamic nature we talked about earlier – we have to have reflection in order to deal with everything not having a label.

In business, I think the same is true. If we don’t box ourselves in with titles and roles, then we need constant reflection on what we’re doing, how it’s working, and what we could change. Ask yourself – does the business you’re involved with now make asking questions about the way things are done easy? Or is it uncomfortable and potentially perilous?

The last characteristic of Ruby I’d like to discuss is the first one I analogized when I was trying to write a proposal for this talk. It’s also potentially the most controversial out of the bunch. I’m talking about Ruby’s open classes – allowing any code, anywhere in the program, to open up an existing class and add functionality to it, remove functionality from it, or generally mess around with its internals. Of course, this goes so far as having “evil” methods like #instance_variable_get and #instance_variable_set that allow us to intentionally break encapsulation. Could I break things horribly? Sure, but Ruby treats me like an adult and for that I love it.

Here’s the trade-off I think Ruby makes in intentionally allowing open classes – it values open communication and implementor power over security through obscurity and implementor safety. That’s something I want to do in my business – trade the security and safety of hiding information for the possibility of my sub-contractors and clients suggesting and doing useful things I never would have thought of because they can see what’s going on inside my business.

This can get scary, because when people close to you know so much about you, they can really hurt you. However, I’ve found that open communication, especially in the face of personal risk, is very good at building trust, which is the essential ingredient of any successful business transaction. If you don’t trust the other person, I don’t care how great your lawyers are, the deal is not going to be a good one in the long-term.

How does open communication work in practice? Well, do you know what your peers are paid? Do you know what deals are in the pipeline? Can you see the books any time you want? Have you been offered stock options where the big guessing game is, “how many outstanding shares are there?”

The real kick-off for Terralien was engendered by Campfire’s lacking access controls – I wanted to invite a bunch of the best developers I knew in to my Campfire, but I also wanted to be able to discuss confidential client information without worrying about who was listening in. So I created a one-page agreement that basically said, “You’ll keep client information private”, and sent it around. What it didn’t do was place any restriction on sharing Terralien internals. Could someone use something they learn to hurt me? Probably. Will they? I don’t think so because I trust them.

One more example – I send out Statements of Work to my sub-contractors via Basecamp as private messages. The first time I had two subs on a project, I realized that they would be able to see one another’s hourly rate, and in this case, it happened to be different. I did it anyhow, though – if I can’t explain the rate disparity to them, why does it exist?

So, am I naive? Probably. But I think Ruby’s open classes are wonderfully naive as well.

So, five questions to ask yourself about your current situation:

Are you boxed in by a title?
How much is planned ahead, and how much remains flexible and gets dealt with as it arises?
Do you understand the agreements you sign and/or give others to sign?
Is introspection rewarded or penalized?
What’s the default for information? Allow or deny?

I’m assuming that to some extent, if you value Ruby, you value things that are dynamic, interpreted, succinct, reflective and open. If so, and you’re not in a business that also values those things, why not?

Terralien In Lights!

Mon, 02 Oct 2006 22:22:00 +0000

I just couldn’t resist:

Via RedHanded.

Open Response To (Clueful) Recruiters

Wed, 27 Sep 2006 20:43:00 +0000

There are three types of recruiters out there – those who can count, and those who can’t. OK, it’s an old joke, but I’m a programmer, and my jokes are usually either old or lame (and often both). My point is, I get contacted by recruiters who fall in to two groups: clueful and in-need-of-a-cluestick. The latter are easy to spot – they ask for my resume in Word format. Lets not go there – I’d like to converse, not rant.

So instead we’ll talk about the clueful recruiters. I got an email from one tonight, and thought I’d share, since I might be off base in my reply, and folks seemed to like my post on entrepreneurial pitches. Responses to clueful recruiters is something I really do chew on, as I think anyone would who gets regular offers of good money from reasonable folks.

Here’s what I received:

Subject: Java J2EE Agile dev positions, any interest?

Hi,
I am looking for Java J2EE Agile mentors who are hands on developers who want to work with teams to get a smooth oiled Scrum team in place, what I call Agile Advocates. Usually these folks are all the same ‘archetype’—very strong with XP (TDD, Pairing), usually working on open source projects and have been on a Scrum team for 6+ months. Usually someone who prefers not to have a title. Our clients are starting to request direct-hire candidates because they have stronger willingness for knowledge transfer, the ones who understand what they are getting themselves into understand that these transitions take years. I am constantly looking for this type of person. Right now we have openings for Agile Java developers in [3 locations].

Please feel free to send your resume and to share your thoughts with me and thank you!

Of course, this poor lady’s first mistake was to ask me for my thoughts… so I gave them to her:

<name withheld>,

Everyone I know who fits your description is fed up with big company politics and is fed up with the mess that is J2EE. I’m very glad that I’m flush with Ruby and Rails consulting work and don’t ever foresee doing Java again. I’m also glad to be working on small, entrepreneurial pursuits, and I don’t foresee being an employee ever again. I wish you the best of luck in finding the people you need, but while I easily know a dozen qualified candidates, I don’t know of one that would be interested. If you want to, you can tell your clients for me that if they want to succeed, they’re going to have to start changing faster.

Sorry to be so negative, but I’ve decided to be blunt with recruiters that contact me – you need to know what you’re really up against.

I really respect recruiters like this – this was obviously not a mass-mail, keyword based spamming – she has definitely looked at my credentials a bit. She also gets my respect for trying to find people against these odds – J2EE (blech), multi-year agile adoption process (ick), and full-time employment to a company with the same (gag). I’ll tell you one reason small, innovative companies are in right now – because by and large, the kind of people you want working for you aren’t going to work for anything else!

Now, maybe I’m way off base – if this sounds like your cup of tea, drop me an email and I’ll put you in touch with her. Of course, I know that some of what we’re seeing right now is cyclical – I can buy that there’ll be a few less one-man Rails consulting shops and a few less “web 2.0” startups when the tech economy retreats a bit. But still, I think we’re seeing something fundamentally different – a whole generation of the best designers and developers is realizing that they don’t have to work places they don’t like, that the security of a big company is no security, and that it is possible to build something small and successful.

So, best of luck my clueful recruiting friends, but you’ve got a tough row to hoe. Maybe it’s time for you, too, to think about how to serve the Fortune 5,000,000 and stop beating your head against the wall of the Fortune 5000. If you want my thoughts on that, I’d love to talk with you about it.

Colophon

Thu, 21 Sep 2006 11:16:00 +0000

I saw a “Colophon” section on a site the other day, where it was used to describe the technologies used in the site. Curious, I just looked up the term, and it has a fascinating history. It started out as “meta-data,” if you will, on clay tablets, and today is a publishing term for a book section delineating typefaces, ink, paper, and other production details. Colophons apparently show up most often in limited edition and private press printings – I suppose hard-core bibliophiles eat that sort of stuff up.

So here’s our colophon: we’re running terralien.com on Radiant CMS, which is of course by our own John Long. The Ship’s Log, which you’re reading now, is running on SimpleLog, which just so happens to use Matt McCray excellent theme_support plugin. Both apps are served as Lighttpd fastcgis running on TextDrive, and use MySQL databases.

So, how do I like the setup? I’m really loving SimpleLog – it lives up to its name, and seems to be developing very nicely. I’ve noticed that comment support is being added to trunk, so you can look forward to doing some heckling in the future (feel free to email me in the meantime – I’m always open for some heckling). Radiant is also a joy to work with, and of course it helps that I can IM John whenever I run in to something sticky (which is not very often). Lighty is great, and I can’t wait until 1.5 sees the light of day and I can use it in front of a pack of Mongrels.

I hope that satiates the technophiles – I’m one myself, and I’d love it if all sites had a colophon. Of course, the literal meaning of colophon is “finishing stroke,” so putting it in one of the first posts to the blog seems a bit backwards. However, if you consider the fact that a blog is usually viewed in reverse chronological order, this post will be at the end soon enough!