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!
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!
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.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 or the venerable Rails Engines) and lets all start brainstorming and hacking to find the best solution going forward.
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.
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.
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!
