Tuesday, August 20, 2013

Minimalism, KISS, elegance

This essay is just some exploratory thought sparked by http://www.zedshaw.com/essays/master_and_expert.html. It's worthwhile reading for anyone. You should read it.

I'm guessing you probably didn't read it anyway, so here's the summary: Masters of any subject know how to use the minimum amount of resources to accomplish goals. Experts like to build complexity where it doesn't exist to show off their prowess at handling their created complexity. For every time someone makes some computer function ridiculously simple, there are 10 companies putting buttons and knobs and whistles and levers onto something as basic as email.

What do I have to add? Well, the first things that come to mind are how this idea can be used in practice: When looking for places of employment, do the coworkers add complexity or remove it in their day-to-day activities? Do you find people engaged in discussions about arcane lingo that was internally invented to discuss invented complexity or are the discussing the underlying problems?

People who are good examples of this that spring to mind are John Maeda and Donald Knuth.

One of the reasons I love squash is that it is such a ridiculously demanding physical sport that to play at an advanced level you must remove any wasted movement; Ceteris Paribus, anything but the minimal path around the court means you lose.

In short, I'll end this rambling with a simple reminder: For those of us in technology, always ask yourself: "Am I making my users' life easier by removing complexity or more difficult by adding complexity?"

Friday, August 16, 2013

Rails Callbacks: Being a Good Neighbor

Using callbacks like before_save, after_destroy, etc. in your rails models is a very important way to ensure that the things you assume about your data are actually enforced.

If you return false, and halt the callback chain, be sure to include error messages via errors.add("..."), so the caller knows why it failed.

Class User < ActiveRecord::Base

  before_save :update_other_subsystem

  def update_other_subsystem
    success = some_other_subsystem.send("new user!")
    unless success
     errors.add("couldn't update the subsystem")
     return false

This is a pretty contrived example, but you get the idea.

Friday, July 12, 2013

Making Rubymine Play Well With Others

I use RubyMine, but my colleagues don't. This can cause lots of problems when RubyMine needs specific gems for debugger integration:

    gem 'ruby-debug-base19x'
    gem 'ruby-debug-ide'

Crucially, it's incompatible with the debugger gem, which everybody else needsHere's how I got it working:

1) Don't require the 'debugger' gem if rubymine is present:

In your gemfile:
# rubymine needs some specific gemfiles that conflict with debugger. Rubymine puts an .idea folder
# in the git root, so that's how we detect its presence
is_rubymine_present = Pathname.new("#{File.absolute_path(File.dirname(__FILE__))}/.idea").exist?
# include the debugger gem, but don't require it if rubymine is present. This will load the gem,
# so we don't get Gemfile.lock changes, but it won't be require'd and rubymine will function.
gem 'debugger', (is_rubymine_present ? { :require => false } : {})

2) Let RubyMine install debug gems it needs outside bundler
If you try to debug your server (Run -> Debug...), RubyMine will prompt you to install some gems. Click Ok.  This installs the gems via gem install, which doesn't modify your Gemfile and screw up your teammates bundles.

3) Don't put ruby-debug-ide, ruby-debug-base19x, or any other gem that rubymine needs into your Gemfile.
If you do, you'll break debugging for everyone who doesn't use rubymine.

This reminds me why I often get frustrated with Configuration Driven Development: You're not building stuff, you're just googling around and twisting arcane nobs on someone else's work until your rube-goldberg machine finally works.

Friday, March 22, 2013

Some good recruiting guidelines

   1. Tell me about the 3 biggest things you must accomplish.
   2. Tell me why you must accomplish them.
   3. Tell me when you must accomplish them by.
   4. Tell me how you intend to accomplish them.
   5. Tell me what you're already doing to accomplish them.
   6. Tell me the role you envision me playing in accomplishing them.
   7. Tell me what you expect from me.
   8. Put me with some of the key people already working on them.
   9. Tell me what you'll do when things change or go wrong.
  10. Take me to coffee.

Courtesy edw519

These apply better to larger companies, of course, as early-stage startups tend to have quite a bit more unknowns.