a timocracy of one

as it would have made plenty of tooling around exploring (and even a job interview) easier. It’s much nicer than just sorting the whole mess after you decide it would take less time to find what you want then implement this very functionality.

# List instance methods without ancestor methods
String.instance_methods(false)

From 5 Ways to Sharpen Your Ruby-foo

What To Do when Mongrel Stops Responding to Your Requests and Ruby Doesn’t Want to Tell You About It – Philippe Hanrigou

Collar mikes are fucking loud if you hold them in your hand and talk right into them. The sound guy should tweak things a bit, but still, they are definitely designed for high gain and really easy to spike.

Lots of Star Ward humor, again, and again.

Keep mongrels running via your OS tools. If there is a problem, it’s never mongrel apparently – it can be rails, your code, your db, etc. just not mongrel. I guess props to Zed, eh?

Server Admin peeps here say they learned a ton from his book. This continues to prove I don’t want to do SA for personal stuff. Maybe I will apply for Dreamhost PS (basically affordable managed VPS), after all.

gdb and dtrace (and thus D)

Lightning Talks

• gem_installer – much look at for at work, since I keep adding gems. :D
• xmpp (jabber) ruby bot (twitter signs)
• couchdb stuff about async datastore
• Ruby golfed duck ascii art. Ruby can look like perl
• RubyCocoa
• IO
• All sorts of fixtures alternatives, such as ObjectMother, scenarios builders, etc

Ruby Internals – Patrick Farley

This talk is actually the hard-core internals as advertised. Dig up the slides and prepare for some C. Well presented, though. Nice object-graphs/diagrams. Might be worth listening to the video, not just the slides if you are interested, as he seems to explain well. Lots of Star Wars slides/humor. Seems to be a theme since Giles’ Darth Vader/sombrero slide (note to DHS: Sith Lords could be sneaking across our unsecured border)

BDD with Shoulda – Tammer Saleh

General BDD soft sell followed with same for Shoulda – one line of spec for one line of code. Argument for testing AR association as such, not testing what they do. Overmocking – still haven’t found a good answer myself. I do agree that nested contexts help.

Related: got into debate about mocking/whitebox/glassbox/inside-of-contract vs. non-mocked/blackbox/outside-of-contract testing. I am firming up my thoughts on having both and calling them “unit” and “functional” specs/tests. During refactor functionals must pass and you rewrite units as the BDD process for your refactor. Rando (in conf irc, no idea who) seemed to follow similar practice, which is the first non-PDI response I have gotten.

Enough Statistics so that Zed won’t yell at you – Devlin Daley

Reminds me how horrible our whole society is about the basics of stats and probabilities. I think our overly trained ability to pick out patterns really hurts us. At least it’s not just programmers who are clueless about stats – it’s just more surprising because they are technically proficient and assumed to be intelligent and educated in math. Good survey lecture for what programmers should know before thinking about doing any benchmarking.

Next Generation Data Storage with CouchDB – Jay Lehnardt

Why is everyone hating on RDBs. ;) Cool talk – already read a lot about CouchDB, though. Do like the focus on some of the whys for parallelization/map-reducing. Hmmm, couchdb as the git of data. I would follow it closer, if I had a use anywhere on the horizon. I figure by the time I get around to using it the nitty gritties might have changed (especially usage and client libraries)

Evan Phoenix opening keynote (how Rubinius is run)

Highlights low barrier of entry for developers as theme

• Anti-core/elite group – creates unhealthy environment (reminds me of how getting a patch applied for merb on github was)
• Spec suite makes good entryway

Talking about ruby community in general

• Niceness
• Excitability/early adopterism
• again, see slideshow for highlights

How to run community

• A little polyanna (I don’t think so, but it got mentioned)?
• very gitty bazaar style (gack, typo NOT cathedral)
• a lot of subtle “drawing contrasts” with rails

My sorta hippie.

My thoughts on question?: ease of contributing, github as singularity, loved it all, but self-selecting elitism by cutting edgeness, does it scale? How do you keep openeness as project grows – see mailinglist overwhelmed with help vampires after rails got popular. Also see back-channels

A: Roughly: organically. Create the excitement and environment and the pool of people to handle the growth will come online as it grows.

Ezra’s half

Don’t be overly clever. Really most of his talk is about that and being a responsible coder if you are making a library. And a reminder that avoiding premature optimization doesn’t mean avoiding all optimization

• Good explanation of event-driven (thin, even mongrel) versus threaded server (mongrel)
• Rack sidestepping of framework is sexy
• Provides is the best feature, still. Action-args is close. Picking a favorite child.

My thought: what about elegance/clever usages getting mainstreamed into the interpretor. Refactor then, I assume? To simple to bother asking. Mongrel + evented mongrel? A: yes, if needed Magic of action args countered by increasing client-code explicitness

Giles talk

I read enough of it on blogs, and aside from that it’s a little crazy. Giles is quite interesting in person. I think his shown code may be a little unneccessaily “meta.” He’s keeping mum if that is an ironic by intent thing

Wycats:

DM Rocks, that is all. Also awesome transitions in slides.

Didn’t take notes for rest.

I think Evan’s talk was the best part. The technical talks you can pick up from the slides, but the more overviewy touchy-feely part is hard to get except in person. Everyone rocks, but I really liked Evan’s talk.

Yesterday I wrote a post on capturing the output of rake from a ruby call using backticks, because I wanted to do so in a test. Well, I had Date.today stubbed out, but got lazy and used yesterday’s date, so of course when I come in today the test fails. In the light of a new day my problem was obvious. If you call rake from a sub-shell, say via ``, of course your mocking will not exist in that process. So today, I had Another Wonderful Opportunity for Learning (there are acronyms for this that use a different word than wonderful): a chance to do it right.

It took a little digging to figure out how to get this to work right with the built-in rails tasks, so here you go:

require 'rake'
require 'rake/rdoctask'
require 'rake/testtask'
require 'tasks/rails'

def capture_stdout
  s = StringIO.new
  oldstdout = $stdout
  $stdout = s
  yield
  s.string
ensure
  $stdout = oldstdout
end

Rake.application.rake_require '../../lib/tasks/metric_fetcher'
results = capture_stdout {Rake.application['metric_fetcher'].invoke}

I liberated capture_stdout from the rake tests themselves. In retrospect, I should have just looked there first. As TDD and especially BDD get even more widespread the tests are often the easiest place to look for good examples of usage.

As you may know system() and `` both make system calls in ruby, but the second one captures the STDOUT for you, essentially, which is handy sometimes, like when testing. They don’t necessarily both do this by just a straight call to the commandline, but various internal utilities that make such thing possible in Windows too, for instance.

Well the problem with this is it can mess with your setting of an ENV as a precursor to your command. For instance, this is valid on my platform:

RAILS_ENV=test rake metric_fetcher

and works via system():

system("RAILS_ENV=test rake metric_fetcher")

but chokes in backticks, probably due to the aforementioned jiggering around for Windows compat:

`RAILS_ENV=test rake metric_fetcher`

Now you generally can just move the command back to the beginning of the line:

`rake RAILS_ENV=test metric_fetcher`

but if for some bizarre reason that doesn’t work for you (it’s probably something else going, wrong, though, to be honest) you can do this:

ENV['RAILS_ENV']='test'; `rake metric_fetcher`

So ultimately, I can do this hacky wonder:

assert `rake RAILS_ENV=test metric_fetcher`.empty?

if my rake task succeeds silently and fails noisily (which is a useful characteristic for cron’ed tasks).

Thanks to Defiler and ocotpod for proving to me I really did have my head up my ass and that all but the leading env var in backticks form should work as expected.(fixture set-up issues as usual).

Addendum And if you are calling rake like this in a test and getting odd problems – consider turning transaction fixtures off.

Apparently my earlier posting about our job openings be scaring people off people who don’t want to do PHP. There is at least one Rails dedicated opening. While we are also looking for someone to work on the PHP app we are not looking for people only to work on both: I only work on the Rails app (and associated ruby libs I’ve written for said app). So if you want to only work in Ruby or only in PHP or don’t care and would do either go ahead and apply, not only the last case.

Planet Caboose was down for a bit, and a lot of my reach comes from that, since way more people probably read that then my blog. Unfortunately, that downtime came right when I was posting that the company I work for is looking for 2 bad-ass developers in San Francisco, ASAP. So I’m posting this, for those that certainly missed the original announcement.

Edited for typo: downtime != downtown

The company I work for is looking for 2 more software engineers, to work on our two main apps: http://www.yieldbuild.com/ and http://hubpages.com/. They are written in RoR and PHP, respectively, but my boss says he is not looking for anyone with a specific set of preexisting language skills as much as just someone who is wicked smart and a solid developer. In fact, skill with unmanaged languages wouldn’t hurt (but certainly is not required).

It’s a really cool, laid-back place to work, especially for a start-up. Our money situation is solid. Some of us occasionally fly RC helicopters in one of the meeting rooms. A number of us (but not all, so it’s not like you have to) go out for beers on Tues/Fri. You know the general SOMA start-up thing, but with a good business plan, revenue, and without the hype or extravagance you might have seen the last time on the roller-coaster.

Drop me a line at timocratic@gmail.com if you are interested or want details, and then I’ll hand you along to my boss.

Update: You won’t get stuck doing PHP if you applied to do Rails. I don’t touch the PHP, myself, and at least one position will be filled solely for working on the Rails app. First come first serve, and/or depending on skillsets and all that, you know? If you want a job working on Rails, just say so.