Steve Conover's blog



Steve ConoverSteve Conover
Standup 4/4-4/8
edit Posted by Steve Conover on Monday April 11, 2011 at 08:51AM
  • "Floated selects in Chrome don't respond to mouseclicks ??" A: There was some speculation that the size of the clickable area of the element had collapsed to zero. The answer: "try display:inline-block".

  • Gotcha: "CSS ellipses can change the output in Capybara and cause tests to fail." There was a general reminder to everyone that ellipses don't work in any version of Firefox.

  • Help: "What's a good jquery placeholder plugin?" A: Placeheld

  • GoGaRuCo 2010 Videos are finally ready - yay! This was a quality conference, props to @joshsusser et al, each of these talks is worth your time.

Steve ConoverSteve Conover
Chef-solo is great. You might not need client/server.
edit Posted by Steve Conover on Wednesday June 16, 2010 at 10:00PM

You should be doing automated configuration, period. Chef is a great automated configuration tool.

It has to be said, however, that chef has lots of parts, arguably an excess. If you google around for chef intros you see chef-solo referenced as a simple first step into "full" or "real" chef - chef client/server.

On our project we've built a mature web application, we've been using chef for over a year, and have never once felt the need for the client/server model, and we have no reason to expect to.

Here's how we run chef manually:

cd ~/projectroot
git pull
chef/run.sh

(that's it)

run.sh contains:

sudo sh -c "RAILS_ENV=$RAILS_ENV chef-solo -c chef/config/solo.rb -j chef/config/$RAILS_ENV/`hostname -s`.json"

We have capistrano (multi-server ssh tool) do the equivalent on deploy:

sudo [
  "cd #{app_root}",
  "export RAILS_ENV=#{self.variables[:rails_env]}",
  "chef/run.sh"
].join(" && ")

We deploy our code and update system config at the same time.

And that's all we need or want.

Links:

Steve ConoverSteve Conover
"Pivotal News Network" Highlights from May
edit Posted by Steve Conover on Wednesday June 02, 2010 at 07:10AM

The Pivotal News Network has been going strong for six months (Pivots: talk to me if you'd like to share into the feed). Here are some highlights from May:

When starting any software project, there’s an age old argument: should we build something simple that solves our current problem or should we use an existing product that’s more complex, but more feature rich, since we know that’s where we’re going to end up in the future?

...

an oft neglected repercussion of building too much too quickly is that the extra functionality can calcify your product and make it very rigid. Releases become more complex, new features take longer to implement and bugs take longer to fix. You can find yourself a prisoner of your product, maintaining functionality and features that no one ( or very few ) people use. It can demoralize a engineering team, making them more and more susceptible to the nuclear option: the big rewrite.

I think the tendency to lean towards a more exhaustive solution upfront comes from a time when the effort require to change software was much higher than it is today. When systems were written in C, C++, Perl or even Java, making changes was a large undertaking. The thought of possibly throwing away chunks of code was nerve racking. It represented a huge investment in time and money. However, with todays rapid development languages and frameworks like Ruby/Rails & Python/Django, the investment required to create something, both in time and money, is rapidly shrinking.

Jeff [Patton]’s reply shocked me:

“The Ruby community cares about building high-quality apps, but doesn’t necessarily care about shipping high-value apps.”

Jeff went on to say that the Ruby community is obsessive about craftsmanship. This is a good thing, of course. We test. We write clean code. We take the time and care to build applications that are beautiful and do what our customers ask for.

Therein lies the rub: what customers ask for is rarely what they want, and almost never what they need. As Henry Ford put it, “If I had asked what people wanted, they would have said faster horses.” Or as I put it, your customer may pay you $1000 to deliver him a knuckle sandwich, but no amount of precision or strength training is going to leave you with a happy customer.

It turns out that constructing a high-quality application is not enough – you have to conceptualize and design an application that users will actually find useful. Doing this is every bit as difficult as constructing the software, if not harder. It requires a combination of research – generating new ideas from asking questions & identifying problems – and feedback – testing out ideas you’ve created. The Ruby & Agile worlds have been primarily focused on getting user feedback, without doing the all-important research.

Weeks ago, some people in the Ubuntu community got a bit disappointed with the distribution’s core team:

We are supposed to be a community, we all use Ubuntu and contribute to it, and we deserve some respect regarding these kind of decisions. We all make Ubuntu together, or is it a big lie?

We all make Ubuntu, but we do not all make all of it. In other words, we delegate well. We have a kernel team, and they make kernel decisions. You don’t get to make kernel decisions unless you’re in that kernel team. You can file bugs and comment, and engage, but you don’t get to second-guess their decisions. We have a security team. They get to make decisions about security. You don’t get to see a lot of what they see unless you’re on that team. We have processes to help make sure we’re doing a good job of delegation, but being an open community is not the same as saying everybody has a say in everything.

  • from Velocity as a Goal

    From my experience having velocity as a goal doesn't make any difference to the motivation of the team which is often cited as the reason for referring to it as a target. In all the teams I've worked on people are giving their best effort anyway so they can only really have an impact on the velocity by doing one of the following:

    • Working longer hours
    • Cutting corners on quality (by less testing perhaps)
    • Finding a smarter way of working

    ... In reality I haven't noticed that people on the teams I've worked on pay that much attention to whether velocity is considered a target or not. People just do their job and we pretty much always have the same velocity each week regardless.

More popular shared items:

Steve ConoverSteve Conover
Standup 1/7-8: Bundler, MySql vs Sqlite on disk vs Sqlite in-memory
edit Posted by Steve Conover on Friday January 08, 2010 at 09:21AM

Bundler 0.8.1 is out. There have been some significant changes around how the vendor directory is organized, so you'll want to rm -rf vendor/gems and re-run bundle.

A team tried swapping in Sqlite to see if it made any difference in test suite runtime. It was actually slightly slower than MySql. In-memory Sqlite didn't help either.

Steve ConoverSteve Conover
Standup 1/5: capistrano and bundler
edit Posted by Steve Conover on Wednesday January 06, 2010 at 07:47AM

A gotcha when using cap and bundler:

"If deploy.rb does a require 'auto_tagger' and the auto_tagger gem is in the app's bundle but not the system, running the system cap won't find the auto_tagger gem. Using bin/cap runs the bundled cap and thus has access to all the gems in the bundle."

Steve ConoverSteve Conover
Standup 1/4: XSS Galore
edit Posted by Steve Conover on Tuesday January 05, 2010 at 07:30AM
  • XSS #1: There's a huge cross-site scripting hole if you use the meta refresh tag...it has a "data" attribute into which you can insert arbitrary javascript.

  • XSS #2: Cross-site scripting resources, from an internal mailing list:

  • Happy New Year

Steve ConoverSteve Conover
Announcing the "Pivotal News Network" RSS Feed
edit Posted by Steve Conover on Saturday November 14, 2009 at 04:00PM

We've pooled some Pivot shared tech news feeds and made this feedburner feed:

http://feeds.feedburner.com/pivotal-news-network

The content is in the spirit of Blabs, so we hope readers here might find it to be useful. See what you think.

Steve ConoverSteve Conover
Dear Lazyweb (RSS-based news page)
edit Posted by Steve Conover on Friday November 13, 2009 at 08:00PM

I have an RSS feed, and I'd like to make a little news page out of it with the ability to post comments. Having done a quick survey of what's available, I'm thinking of doing nothing. But I'd like to find out what others have to say about tools available.

General requirements:

  • I'd like to take an RSS feed and make a nice news page out of it.

  • No mangling or truncating of articles in the feed.

  • It'd be great if I could tie comments in. That might mean, for instance, dropping in disqus.

  • I'd rather not have to write, deploy, or maintain any code. But if there's some set of tools/apis I could easily tie together with code, I'd consider it (some Heroku-type setup, for instance).

Examples of sites I consider to be at least partially what I'm driving at:

If I had to write code, I could imagine using something like feedzirra, sticking it on a many-times-per-hour cron job, and writing out a page and dropping in disqus.

Thoughts?

Steve ConoverSteve Conover
Naked Planning
edit Posted by Steve Conover on Friday October 23, 2009 at 06:00PM

I just got the chance to listen to this interview with Arlo Belshee about Naked Planning ("Kanban Simplified"):

http://cdn2.libsyn.com/agiletoolkit/Agile2008_Arlo_Belshee.mp3

Highly recommended. My summary of Naked Planning:

  • Teams work toward delivering Minimum Marketable Features - usually chunkier than User Stories but more relevant to customers. Think "administrator can set user permissions" vs what you might break that down to in terms of finer-grained stories.
  • The dev team breaks MMFs into tasks as appropriate.
  • Teams work on MMFs in a ratio of about one MMF to every two pairs.
  • There is no estimation (it's usually wrong, there's no particular reason why the time before you start a story - when you know very little - ought to be when you assess cost). Instead a pure yesterday's weather approach is taken: you write down the date you start the MMF, and the date you finish it, and keep a rolling average days to complete an MMF - that becomes your "velocity" (no need for that word though).
  • "Done" means everyone - customers, developers - determine that the MMF is done. That means development is finished, any follow-on discovery or bug fixing is done, support staff are trained up, and the feature is really ready to go out into the world and be used by users and create value.
  • The MMF backlog is somewhere between 5 and 9, because beyond that prioritization (remember, we're talking about something chunkier than a User Story) is mostly useless. If it takes, say, 15 days to finish an MMF, on a two pair team with a 7 MMF backlog, you're out about 6 weeks - this is when any backlog typically starts to degrade a bit. At the outside you're planning for an entire quarter.
  • One slot, that you try to keep empty, is reserved for fires. The customer can put in a fire card that the team immediately works on. You can only work on one fire at a time - others go into the backlog with the MMFs.

This is a sort of Lean/XP/Kanban fusion that Arlo created and refined on a project he heads up. It drops some of the weirder parts of XP-style planning and distills down to its more interesting ideas, and addresses many of the beefs I have with point estimates, velocity, and iterations in practice. At the very least it's food for thought.

And here's a video in which Arlo explains the planning board.

Steve ConoverSteve Conover
Planning, WebOps
edit Posted by Steve Conover on Saturday October 17, 2009 at 03:00PM

This thread on the Agile Systems Administration group is particularly good:

http://groups.google.com/group/agile-system-administration/browse_thread/thread/7c32b729aaa1079b

There's some great stuff in here about planning in a highly interrupt-driven environment, and I particularly like Allspaw's breakdown of ops work at Flickr (the "MumbleMumble" process). Anyone who's wondering what's generally involved in making webops go ought to have a look.

Other articles: