• "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.

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:

• Cooking with Chef 101 - a chef-solo-centric chef introduction
• Chef wiki

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:

• from Startup Product Development: Simple Now vs. Complex Later

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.

• from Are you punching your users in the face?

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.

• from Agile Anti-Patterns: Democratic Design

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.

• "If you split test every idea, you'll end up with either porn or gambling."

• "Every time you convince a client to leave their Excel spreadsheets behind and use @PivotalTracker an angel gets his wings."

More popular shared items:

• 7 LESSONS LEARNED WHILE BUILDING REDDIT TO 270 MILLION PAGE VIEWS A MONTH

• The Case for Git Rebase

• "The best way to handover work is to leave a broken test for your colleague to fix."

• Nonblocking ActiveRecord & Rails

• HTML5 vs Flash performance

• How many lines of code does it take to create the Android OS?

• The unimportance of product names (which got smacked down in the Google Reader comments)

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.

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."

• 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:

  • "I've gained a new appreciation for the importance of carefully thinking through security and escaping in RoR there's more than just h()'ing all your user entered data."

  • XSS vulnerabilities - http://ha.ckers.org/xss.html.
    Very useful catalog of different XSS vectors. Includes some utilities to base64-, URL- and hex- encode attacks so you can test out your apps.

  • General OWASP wiki - http://www.owasp.org/index.php/Main_Page. Lots of useful data information here. OWASP is a nonprofit group charted to improve the security of webapps in general.

  • Security Guide for RoR - http://www.lulu.com/product/download/owasp-ruby-on-rails-security-guide/4489819 general guidelines/things to think about for securing RoR apps.

  • Loofah - http://github.com/flavorjones/loofah is supported by a fellow Pivot and provides fast and good sanitization built on Nokogiri, albeit slightly slower on short strings than brittle regular expressions. It's in production at several companies.

    "Loofah excels at HTML sanitization (XSS prevention). It includes some nice HTML sanitizers, which are based on HTML5lib’s whitelist, so it most likely won’t make your codes less secure."

• Happy New Year

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.

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:

• ycombinator Hacker News
• Tabbloid
• Any blog

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?

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.

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.