« January 2011 | Main | July 2011 »

May 19, 2011

Developer Happiness at Etsy

Listening to Chad Dickerson (CTO at Etsy) speaking about optimizing for developer happiness at RailsConf 2011.

Etsy releases software 25 times a day with 75 engineers. They emphasize constant progress with a radical decentralization. It shouldn't work, but they are built on trust. There is one button that folks can press (after some fanfare) that pushes code up to production

They've had developers push code on their first day, they've had board members deploy code.

Chad contrasts industrial revolution assembly line times with how Etsy works. Etsy highly prioritizes letting the developers be human, having lunches together, having offices that are full of creative, fun stuff. Dogs have deployed code by guiding a paw to pressing the button.

Releases are done with a self-managed push queue, developers put their names in a queue kept track of in an IRC topic. When the first person in line pushes and is clear he/she notifies the next in line.

Remember, your team is your community. Help people finish things and see their progress.

Optimize your teams for the happiness of people.

Posted by mike at 3:03 PM

Glenn Vanderburg on Building Software

Fantastic closing keynote by Glenn Vanderburg at RailsConf 2011 about software engineering.

Great ideas about software engineering and how it compares to classical engineering disciplines (civil, structural, industrial, mechanical, electrical, traffic, etc). Compares the definition and process of structural engineering to software engineering.

Is software engineering or craftsmanship? In software, the documentation that is required by other disciplines is actually the artifact that gets built in software engineering. Classical engineers diagram, plan, document, model and then take those and build the artifact. Software engineers diagram, plan, document, and model as a part of building the actual artifact. Also interesting, software is changing the way classical engineering works, a lot of software being used in the planning process to understand how the actual artifact

We are designers and builders. Software has to be the solution and describe the solution.

Programs must be written for people to read and only incindentally for machines to execute. Harold Abelson and Gerald Jay Sussman

We are engineers and craftsmen.

Posted by mike at 2:43 PM

Software Version Numbers

In the RailsConf 2011 RubyGems presentation this afternoon, Nick Quaranto spent some time talking about versioning software, showing the versioning of TeX as kind of crazy where they use PI, adding a new digit of PI on the end of the software version number for each release.

Nick suggests that Semantic Versioning is the best methodology. Read more at http://semver.org/

The idea is:

1.2.3 (major.minor.patch)

major versions - for major releases where there may be some backward incompatible changes
minor versions - for minor changes, no API or other changes that make it incompatible with previous versions
patch version - for fixes, improving stability

Posted by mike at 1:40 PM

Long Evening At Camden Yards

If the value of a baseball ticket is measured in hours spent in the park, I definitely got my money's worth last night. Baltimore Orioles vs New York Yankees, 15 innings, Orioles lose it in the 15th after having many chances to put it away earlier in the game.

I walked into the park at 6:30pm, left just under 6 hours later at 12:10am. Although I went by myself, I made a bunch of friends with the Orioles fans in the Picnic Perch (food isn't fancy, but a nice thing to have all-you-can-eat at your fingertips).

It was supposed to rain, and we saw a little lightning in the distance. It misted up a little, but not a drop of rain.

Posted by mike at 9:46 AM

LivingSocial's Aaron Batalion says "Be Nervous"

Great keynote this morning at RailsConf 2011 from LivingSocial's Aaron Batalion.

Favorite thought: be nervouse or your aren't trying hard enough.

Aaron says the right way to go at a new idea is to make decisions that make you nervous, all the time. This means you are pushing forward.

Advice that makes me feel better about some of the crazy stuff I've faced as the leader at a growing company. And excited to try some new stuff.

Posted by mike at 8:29 AM

May 18, 2011

Rails 3 Gemfile: Installing PostgreSQL on OS X

After two months of building my Rails app working on remote servers, I'm sick of always having to SSH in and use a server-side text editor to work. Not to mention that any time I move the laptop I've got to break and then re-establish all the terminal windows I had open.

So I embarked on setting things up to run my Rails app right on my MacBook Pro. Yea, the thing that 99% of the rest of the Rails community has been doing for years.

I figured everything except PostgreSQL is either already on the laptop or is nicely grouped together in the my Rails application in git. So I installed Postgres from their OS X Postgres install page.

Checked my git repo out on OS X, ran the "bundle install" and got:
Installing pg (0.11.0) with native extensions /Library/Ruby/Site/1.8/rubygems/installer.rb:533:in `build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb
checking for pg_config... yes
Using config values from /Library/PostgreSQL/8.3/bin/pg_config
checking for libpq-fe.h... yes
checking for libpq/libpq-fs.h... yes
checking for PQconnectdb() in -lpq... no
checking for PQconnectdb() in -llibpq... no
checking for PQconnectdb() in -lms/libpq... no
Can't find the PostgreSQL client library (libpq)
*** extconf.rb failed ***

Obviously a failure. The Gemfile includes "gem 'pg'", which works fine up on the Linux servers but apparently doesn't do so well on OS X.

A lot of digging and reading, followed by a lot more digging and reading.

The first solution...when compiling pg, the gem needs to have an environment variable set:
env ARCHFLAGS="-arch i386" bundle install --path /Users/mike/inventory/vendor

No problem running the bundler, but when you actually try to use the database:
bash$ rake
rake aborted!
dlopen(/Users/mike/inventory/vendor/ruby/1.8/gems/pg-0.11.0/lib/pg_ext.bundle, 9): no suitable image found. Did find:
/Users/mike/inventory/vendor/ruby/1.8/gems/pg-0.11.0/lib/pg_ext.bundle: mach-o, but wrong architecture - /Users/mike/inventory/vendor/ruby/1.8/gems/pg-0.11.0/lib/pg_ext.bundle

Tons more reading and digging, trying lots of suggestions.

Finally I stumbled into something that made a lot of sense. A post on the rails forum suggests that Ruby and PostgreSQL are compiled for different architectures and the gem pg connector isn't going to work unless Ruby and Postgres are on the same page.

I got an updated Ruby using MacPorts, same error. I got an updated PostgreSQL from MacPorts and attempted to run "bundle install" as standard.


Then I went back to including the architecture-specific command:
env ARCHFLAGS="-arch x86_64" bundle install --path /Users/mike/inventory/vendor

Works, and I'm able to run "rake db" commands.

Everything else looks like it's in place, am running the Rails app in my browser at localhost:3000 and have TextMate loaded up with my project files.

Much, much, much better.

Posted by mike at 3:45 PM

RailsConf 2011: Deploying with Bundler

Listening to Andre Arko at RailsConf 2011 talking about Bundler.

Bundler exists to make running your app consistent, repeatable, and guaranteed. Bundler doesn't let you use a gem unless it's in the Gemfile. Gemfile.lock keeps track of which version of the gem is running.

To publish the app. A very simple way is to tell Heroku or EngineYard to do it, they build right from your Gemfile and deploy.

To do it yourself. Make sure gems are installed within the app, not as the root user: bundle install --path app/vendor

Bundler provides a --frozen mode that makes sure that all of the Gemfile entries match up with the Gemfile.lock. This is a good thing to have in place on production.

For production: bundle install --deployment (turns on --path and --frozen)

For bundling to send to a server that has no outbound internet access: bundle path (not advised unless the only option, because requires downloading a ton of binary data from version control)

Posted by mike at 1:59 PM

RailsConf 2011: The Future of Stylesheets with Sass

Listening to Chris Eppstein at RailsConf 2011 this morning talk about Sass., a technology for making CSS stylesheets more robust with preprocessing.

Rational, problems it solves, syntax, best practices.

What is Sass? Syntactically Awesome StyleSheets, a stylesheet generator. CSS is 14 years old, selectors, properties, and values. Web developers need to support many browsers, many output types. CSS 3 will have 33 new selectors, 120 new properties, new @rules, but no new syntax. CSS was created for designers who wouldn't have to do any abstraction.

The reality is that most stylesheets are written by programmers.

Sass comes from real world experience, brings software development methodologies to stylesheets. Brings variables, mixins, inheritance, transformations, loops, and more to CSS.

CSS has many problems. Sass has some cool stuff to address them:

- Variables: define at the top of the file and then include the variable in the stylesheet
- Color transformations is awesome: define one color and then a bunch of variations of that color to get a
- @import directive lets you pull in files, build smaller CSS sheets and then only include what you need
- nested selectors let you simplify definition of selectors

As the session winds down I added "gem 'haml'" to my Rails 3 Gemfile and did a "bundle install" to start using this now.

Posted by mike at 9:49 AM

May 17, 2011

RailsConf 2011: Fat Models Aren't Enough

Listening to Jeff Casimir from JumpstartLabs at RailsConf 2011 talking about practices in Rails, skinny controllers and fat models.

Jamis Buck started the idea of fat models. Originally when rails was getting going tons of stuff was going into the views, then folks started stuffing everything into the controller. 80-100 line methods. The call to action was to move logic down into the model with well described method names.

Beautiful views are HTML. Views should be data access, a little bit of looping.

Controller actions should be 8 lines.

Most of the logic should go into the model. But fat models aren't enough. A model should be like a bento box, little pieces of art, structured division. The model layer is where we get to do real programming. But models don't have to get totally stuffed full of junk.

Let's look at the presenter and presenter pattern. The formal definition of a presenter is a decorator, takes in an object and adds some new options. Jeff likes to think of a presenter as more than just adding a new option or two but to add significant simplification to the app.

Helpers are stupid, a big mess.

[I'm going to have to grab the slides from this, a lot of good food for thought and practical advice.]

Posted by mike at 9:54 AM

RailsConf 2011: Tuesday Morning Keynote

At RailsConf 2011 this morning, after conference welcome, logistics updates, and a video about donorschoose.org, the keynote speaker is David Heinemeier Hansson.

After the DHH presentation. Yes, folks are excited for Rails 3.1.

Posted by mike at 8:04 AM

May 16, 2011

RailsConf 2011: Rails Best Practices

This afternoon I'm at RailsConf 2011 listening to a bunch of the Envy Labs guys talk about best practices in rails. Excited for this tutorial because I've used rails long enough now that there's a bunch more to know than just the syntax. There are many ways to do things, want to get some direction on how rails does it.

The better title is Rails Best Opinions. This is a lab, so we listen to a presentation and see some slides and then get on our computers and implement the ideas in code.

A few things that caught my eye, as time permitted to jot down.

For me, having worked heavily in Rails for the past month, the labs were a prefect stretch. Understandable, but challenging to work through the exercises.

Posted by mike at 12:37 PM

RailsConf 2011: Rails for Zombies

I'm at RailsConf 2011 this morning, listening to a bunch of guys from envy labs doing an introductory course to Ruby on Rails. I've dug in deep on Ruby on Rails for a month now, this might be a bit too introductory for where I'm at but want to make sure I've got the basics.

Things I learned that I didn't know about Rails:

Posted by mike at 8:02 AM

May 11, 2011

Ruby on Rails: DateTime Records with Microseconds

I'm working on a new web app for internal use at my company, from the ground up with Ruby on Rails.

One thing that has emerged as a critical component; having database records timestamped with more granularity than seconds. The solution was more involved than I would have guessed. Figured I'd log the steps since it took many hours of research and engineering effort.

1) Search for how to store microseconds in MySQL. Not possible in a traditional datetime or timestamp field. Explore all of the workarounds, none of which are ideal for the application. Realize there's no good current solution and a lot of folks have been begging since 2005 for someone at MySQL to fix so little hope it will come. See MySQL bug repot here.

2) Swallow hard and enter less familiar territory of installing and getting PostgreSQL running with the app. Lots of reading about PostgreSQL setup, configuration, and administration. Get roles set up, connected with the command-line tool, and get Rails talking to PostgreSQL.

3) Repopulate data from data sources (easier for me than the various MySQL -> Postgres transfer instructions I'd looked at)

4) Put code into Rails app to insert datetime with microseconds (this may get finessed):
datetime = DateTime.now
microseconds = Time.now.usec
params[:event][:datetime] = "#{datetime.to_s(:db)}.#{microseconds}"
@event = Event.new(params[:event])

5) Back to building functionality I was originally attempting without microseconds but was failing.

That was about two days of work, compressed into one day and a long night.

Although I've used Postgres a little bit before, I know MySQL extremely well and am comfortable in any situation that one comes across with that database (replication, disk failure, query performance, I've done it all). Postgres is a new frontier. I'm quickly becoming comfortable using it and the \ commands but know there's a lot more to be learned before I'm confortable running a production app on it.

I guess the title of this post could also be "Switching from MySQL to PostgreSQL to get DateTime records with Microseconds."

Posted by mike at 12:06 PM