Uncategorized

The Great Dill-Off

Being of Scandinavian descent, we have a great affinity for dill in my family. There are very few dishes that can’t be improved by a little dill, and as a result it’s been a garden staple for several years. Phoenix being Phoenix, however, dill can be a problematic herb: it tends to prefer steady, cooler temperatures. We often get erratic weather which dill does not enjoy.

So was born last year’s garden lab experiment: Battle of the Dills. The old standby of Bouquet was seeded along with newcomer Tetra (or Dukat). The results were interesting (and again proved this kind of experimentation is well worth the effort and meager garden space it requires).

Bouquet Dill

  • Better overall flavor throughout the season
  • Maximum height of approximately 5 feet
  • Suffered partial losses during varied weather
  • Bolting common as spring began; could be retarded by cutting
  • Dead by mid-spring
  • Large, recognizable seeds; good for pickling

Tetra Dill (Dukat Dill)

  • Good flavor at peak season, bland but recognizable at end of season
  • Maximum height of approximately 4 feet
  • Unaffected by varied weather
  • Did not bolt
  • Survived through summer, though with reduced flavor
  • Smaller seeds; less flavor per seed, but can use more seeds
  • Can address plant as Gul Dukat and shout angry DS9 dialog at it

With the new dill season upon us, the battle royale continues with additional contenders. Joining the fray this year are Mammoth and Fernleaf varieties.

Ruby

Behold the Glory of Ruby 2.1

With some of the changes in the forthcoming Ruby 2.1 (specifically garbage collection), I thought it would be interesting  to throw some (synthetic) benchmarks at it. In a couple internal benchmarks, it offered noticeable performance increases.

For a more well-known point of comparison, I turned to Mike Perham’s Sidekiq benchmark. The results were… unexpected.

MRI 2.1.0-preview1: 30 seconds
JRuby 1.7.4: 39 seconds
MRI 2.0.0-p247: 82 seconds

No, your eyes do not deceive you: Ruby 2.1.0 bested even the venerable JRuby. This outcome was so surprising that I ran the benchmark again several more times than I’d intended. The results didn’t change; 2.1.0 reproducibly came out ahead of JRuby by around 10 seconds.

While there are certainly other good reasons to go with a JVM-based interpreter, Ruby 2.1 may well turn out to be the response to many users’ performance needs—all while maintaining native extension compatibility and using the gems you know and love.

Uncategorized

Desk.com CSS Overrides

Contrary to what you’ll probably experience if you try it, Desk.com (formerly Assistly) CSS overrides do, in fact, work. You’ll end up with hideously ugly and redundant markup strewn across your support portal, and some browsers may be confused by all the ridiculousness, but it is possible to style your portal.

The trick? The default templates use !important damn near everywhere in the default CSS.

This will not work because the stock CSS is a horrible mutant:

#company-header {
background: #123;
}

This horrible abomination will:

#company-header {
background: #123 !important;
}

It’s bad form, and you’ll want to smash your head repeatedly into your desk after littering your own CSS with !important for the bazillionth time, but there you have it. If a CSS override isn’t applying and you’re sure you have the right element, add !important and cross your fingers. Maybe it’ll work. Maybe your code being the fifteenth instance of !important-flagged attributes for that element will cause your browser’s CSS engine to do weird and unpredictable things. It’s CSS roulette!

Try it, find out, and hope your users’ browsers behave the same way yours do.

Or you can always pay $19 a month to add custom templates that don’t have completely broken CSS! Wink wink nudge nudge.

Uncategorized

Dynamically Configuring RSpec for JUnit

Aside

Using continuous integration? Using RSpec? Selectively configuring RSpec to output JUnit with RspecJunitFormatter but finding your output file to be empty?

You need to configure your output file before you set your formatter(s).

Allons-y:

RSpec.configure do |config|

  # ...

  # Use JUnit output for CI
  if ENV["BAMBOO_INSTALL"]
    config.output_stream = 'rspec.xml'
    config.formatter = RspecJunitFormatter
  end
end
Consort

Introducing Consort 0.1.0.pre

For newer Rails projects, I’ve often found myself combining SQL with noSQL technologies, taking advantage of each solution where its strengths lie.

Sometimes you can even get away with your “NoSQL” needs using only an SQL product; Postgres offers hstore, which hits a good swath of use cases and is easily integrated into an ActiveRecord environment via Juan Maiz’s activerecord-postgres-hstore.

But when you need to combine, say, Postgresql with MongoDB, things get less pretty. For obvious reasons, most ORMs and ODMs only support associations within themselves. (DataMapper neatly works around this by supporting multiple data stores, so if you’re a DataMapper user, stop reading this and go read the much-overlooked “multiple data-store connections” documentation instead.) You start to miss the convenience of easily accessing associations that you get with a single-database stack. And so you end up writing glue code.

Maybe you write really simple glue code. Maybe you find yourself writing so much simple glue code that you adapt it into metaprogramming. Maybe you’ve even finally gone off the deep end and done some hideously clever monkey-patching to turn method_missing into the grand prize winner of the Bad Idea competition.

That’s why I wrote Consort. Tired of writing nearly-identical glue over and over, I went meta. And at the point I’d gone to that much work, I figured why not bundle it up into a gem and save the world’s supply of horses from the glue-hungry fists of the world’s Ruby developers? (Sorry, horses, but you’ll still have to contend with Python and Java users.)

Today marks the release of version 0.1.0.pre. All the association-y goodness of versions 0.0.1 through 0.0.3, now with the added goodness of MongoMapper. It’s on rubygems now; grab it, give it a spin, and hit me on github with any issues or feature requests!

Customer Service

Satisfaction is a binary state

The biggest lie perpetrated by modern industry is that customer satisfaction is quantifiable on a scale.

How many surveys have you taken where the options range from “Completely Dissatisfied” to “Completely Satisfied”?

Let us consult the Oxford:

satisfaction |ˌsatisˈfakSHən|
noun
fulfillment of one’s wishes, expectations, or needs

Fulfillment. Not half-bakery, not partial implementation, not attempted fulfillment. Fulfillment, full stop.

Options on a satisfaction scale are expressing nothing useful. The customer’s either satisfied or she’s not. Calling it “partial satisfaction” is just a way for a company with terrible customer service to justify it while patting themselves on the back. Ah yes, the board can say, our customer satisfaction metrics are up! 70% of surveyed customers were at least partially satisfied! Which, back in the real world, means probably 60+% of your customers think your customer service is shit. If they were satisfied, they would have responded with “fully satisfied.”

Think back to the last time you answered a survey yourself with “Mostly Satisfied” or “Somewhat Satisfied.”

Did you actually mean “my issue is resolved and I am a happy customer”? Or did you mean “well, that didn’t really solve anything, but I guess it’s the best I’m getting. Screw you, Dell/Comcast/Verizon!”?

If you really want to know how you’re doing, cut the charade and quit wasting your customers’ time: Make satisfaction a binary option.

Find out if they’re really happy.
Find out if their problem is really solved.
Find out if they’d really recommend you to a friend.

Don’t give yourself an out. Don’t coddle yourself. Ask. Yes, or no?

Uncategorized

Welcome.

Hi. I’m Colin. I write software, do technology consulting, and make photographs, but I’ve found myself boxed in to those topics when blogging in those professional capacities. And so I now have this blog. Here, I’m free to talk about whatever I like—being a photographer, being a developer, delivering awesome customer service, being an avid outdoorsman, or where to find the best chorizo in Phoenix.

If you know me through either of those professional capacities, bully for you; just know that this blog is relatively unfiltered. FCC Safe Harbor rules are not in effect, so there may well be swearing, but I’m also not George Carlin.

Got something to say about something I post? Discourse is always welcome in the comments, just keep it civil.