My Clippings on NewsGator Online

That's Not a Memory Leak, It's Bloat

Thu, 03 Sep 2009 19:46:03 GMT

Catch up or get left behind

Ryan Sholin — Wed, 02 Sep 2009 21:28:43 GMT

I’ve been a nomad for a few days in the middle of a short-by-my-standards 300+ mile move from the suburbs of Rochester, NY to the suburbs of Washington D.C. and boy are my legs tired.

But I’m catching up on my reading, and found a few things to share with you on the theme of catching up…

VIDEO: Investing in Your Staff

CoPress on Vimeo | September 2, 2009
The latest excellent video presentation from CoPress, making a case for innovation in your news organization.

2010 Knight News Challenge is now open for business
“Got a great idea for transforming the future of news? The 2010 Knight News Challenge is now accepting applications, through October 15th!”

The future of news in 4 dimensions: Charting new kinds of news orgs
Nieman Journalism Lab | September 1, 2009
C.W. Anderson builds the sort of continuum/quadrant chart that makes the mass communications scholar in me go all smiley.

brianboyer: If you’re a Tribune reader, this’ll make it nicer. RT @ryanmark: Update to ChicagoTribune.com userstyle http://userstyles.org/styles/20347
Twitter | September 2, 2009
If you understand what these two Chicago Tribune developers are up to here (providing savvy online readers with an incrementally improved stylesheet for the recent redesign long before the changes get built into the live site’s code), then you’ll understand why I think it’s pretty cool of them.

Five concrete steps to improving the news
Newsless.org | September 1, 2009
Matt Thompson follows up his post about what goes missing from most news stories with a few suggestions for how to roll out a contextual approach to a news story. I like #4, which includes this idea: “Keep a public list of the most important things you don’t know about your topic.”

New report: How to build a user community online
Mark Briggs of Journalism 2.0 and his team at Serra Media put together this great report on community management.

Young Families are the Real Early Adopters
Mash this market research up with the right Pew report, and you’ll have a good idea of how to deliver the news to an audience that is the most likely to want it.

mattwaite: Today, we launched Home Team, a local high school sports site: http://hometeam.tampabay.com/ And I now I need to sleep for a month.
Twitter | September 2, 2009
Matt and company at the St. Petersburg Times demonstrating what a solid Web framework and some experience can help you get done in a short span of time. More details in the tweets that followed this one.

Lifestreaming: Newspaper Uses Posterous to Solicit and Publish Reader Photos
The Steve Rubel Lifestream | August 30, 2009
Did you spot the Austin American-Statesman using Posterous to collect reader photos last week?

So, are you caught up?

If Posterous, Django, market research, community management, contextual news, CSS, the Knight News Challenge, and CoPress are all alien objects to you, pick any one and get up to speed.

Catch up or get left behind.

Previously

Participatory Politics Foundation: Rails Programmer

Wed, 02 Sep 2009 02:26:19 GMT

Location: New York, NY
URL: http://www.participatorypolitics.org/

We’re a non-profit organization that builds open-source web tools for political engagement. We believe the web presents an unprecedented opportunity to amplify political actions and make politics more widely accessible.

Our flagship project is the government transparency site OpenCongress, a joint project with the Sunlight Foundation ::

http://www.opencongress.org/

… the site’s code is free, open-source, and non-commercial, written primarily in Ruby on Rails.

We’re seeking an experienced Rails programmer, one who shares our principles of facilitating broad-based political engagement, to join our development team on OpenCongress. As a new full-time programmer, you’d be involved in all aspects of site development, including building new features & integrating new data sets. Solid experience with Ruby on Rails is required — knowledge of postgres database is a bonus, but not necessary.

Ideally, you’d be based in the New York City area, but we’re flexible — feel free to apply wherever you’re based. Women and people of color are encouraged to apply. We’re a free-culture-friendly, collaborative crew, so feel free to get in touch, we’d like to hear from you.

To apply: Send a resume and a brief note of intro to drm@ppolitics.org

jQTouch, a jQuery plugin for mobile web development on WebKit devices

Mon, 31 Aug 2009 16:50:52 GMT

jQTouch, "a jQuery plugin for mobile web development on the iPhone, Android, Palm Pre, and other forward-thinking devices," is now available in public beta. This obviously blurs the line rather extensively between native app and web app and, as such, I'm still formulating an opinion. But the approach to cater to WebKit-enabled devices is a plus one.

No Surprises

michael.lopp@gmail.com — Mon, 31 Aug 2009 04:23:58 GMT

At the end of each fiscal year, companies take stock of their performance. How'd we do? Better or worse? This is a natural time to reflect upon individual performance -- this is when your boss writes your review.

In my ideal management world, a review is simply a documentation of well-known facts, your performance over the year. It also contains constructive advice and insight regarding how your boss believes you can improve on that performance. My dream is that you already know all of this information because you've been getting year-round feedback from your boss.

I wish.

Whether your manager is consistently delivering this information or not, the feedback, written down, is completely different from receiving it verbally. The path to your brain via the written word is dramatically different than for the spoken word. Reading the highs and lows of the past year makes them permanent and makes them real.

And then there's the surprise.

Show Me the Money

Bad news. The surprise has nothing to do with money. We're not talking about compensation here. Yes, you did a splendid job this year and I think they should be throwing raises, bonuses, and stock your way. But it's even better if it's clear why you think you did a splendid job. Can you articulate it? And you might know, but does your boss? Can he explain to you, in detail, how well you kicked ass?

I didn't think so.

See, your boss has you and a bunch of other yous who are all allegedly kicking ass, and all of that ass kickery is tricky to monitor, especially over an entire year. It gets even worse when one of your team members is not kicking ass. Legitimately or not, that's actually where a lot of your boss' attention is going. You read that right: someone else's failure is distracting from your phenomenal year.

Let's fix that.

There are three strategies I'd like you to employ when it comes to your yearly review. They are:

Ignore the measures, focus on the content.
Prepare for the fact a review is a discussion and, sometimes, a negotiation.
Deconstruct the surprise.

Measures versus Content

I've experienced a lot of different review formats at different companies, but let's boil it down to three buckets. A review describes:

What you did.
How you did it.
What you need to do next.

This is a massive simplification of your review. Your review has all sorts of other corporate and division focus areas, but these impressive sounding labels are still just lenses through which you understand how you did versus what was expected.

For each of the buckets, there are two classes of information: the content and the measure. I want to explain how you can save yourself a lot of sleepless nights ignoring the measures, but first, a definition.

Sprinkled across your review are measures. These are words like "Needs Improvement", "Satisfactory", or "Excellent". These words grab you because they're easy to understand. They are effectively your grades, and you've spent a lot of your formative years waiting for grades to show up.

If I told you that you got an A on a piece of work, you'd internally translate that letter into a pleasant, "I did about as well as I could. Go me." Grades - measures - are efficient, they do convey information, but they lack essential content. I'll explain via example.

When I arrived at University of California, Santa Cruz in the 90s, they had no grades. Hippies. At the end of the quarter, you received a written evaluation. For each student in the class, the professor or the teaching assistant would produce a written evaluation -- a plain English description of the type and quality of the work produced over the semester.

I don't know who came up with the idea of ditching grades, but my hope was that they wanted to ditch the measures. The intent of measures are not to derive useful information, they are designed to allow for comparison and, duh, measurement. Am I higher or lower than you? How many As? Are there more As than Bs? It's interesting data and I'm sure if you took a classroom full of data and plotted it on a graph, you'd learn something. Look! A bell curve!

A measure doesn't help you in your career. Your performance review isn't about comparisons to others. They're about what you did and what you could do. What you're looking for is the content.

Tell me which is more useful:

"You did well."

-or-

"You finished the work on schedule, the customer was happy with the results, but there were lingering quality issues with the code. Looking at the last two releases, you had 2x the numbers of bugs than in prior releases. Focus on..."

We get hung up on grades, on measures, because they are so gosh darned digestible. They give us the illusion that they show us where we fit, but they don't tell us what next?

At UCSC, the point of the gradeless report card was to create a vacuum where the professor would actually say something useful. You're not going to get rid of measures -- they serve a distinct purpose -- but when you're first reading your review, I want you to ignore those seductive one-word assessments of your entire year. Their simplicity, while comprehensible, is just going to obscure the complexity of your year.

Rather, look at the content behind the measures. Whatever your particular areas of focus are, does your boss do an effective job of explaining what you did, how you did, and what you could do better? It's a simple set of requirements, but your boss is going to mess it up, which is why you need to be clear that...

A Review is a Conversation

The written word is intimidating. An assessment of a year is a big deal, so what are you going to do when you sit down with your boss and he hands you three poorly crafted paragraphs littered with the word "significant"?

No, you don't ask about the raise. You freak out about the paragraphs. THREE PARAGRAPHS? I'VE WRITTEN MORE IN EMAIL THIS MORNING THAN YOU JUST WASTED ON MY YEAR.

Calm yourself.

Think of this pathetic piece of paper as an opening offer -- a poor offer. Your job is to transform this travesty into an accurate reflection of your year and you're not doing this just out of a sense of self-righteousness, you're doing to get the set the record straight.

This piece of paper is one of the only official documents of your career at this company. If you move, if your boss leaves, if there's a reorg, this is often the first document reviewed to understand the degree of your asskickery and that means you want your boss to comprehend it.

"But Rands, I was just... so pissed. Three paragraphs? I spent my entire winter on the project. I was FURIOUS."

Again, your review will contain surprises, and they will rattle you, which is why you prepare with a self review.

Whether your company asks for it or not, the moment the mail from HR alerts you to the review season, you start cobbling together your self review. Same buckets as above. My move is to keep a yearlong log of significant work as a task in whatever task tracking system I'm currently ignoring. Even if you haven't been paying consistent attention, you'll be surprised by what you can dig up in a weekend of considering your year.

Take a look at your year. How'd you do? No, really, I'm not actually reading it so you can have an honest opinion. Was it a great year or did you just think it was great? Yes, your boss' opinion about your year is key, he does sign the checks, but it's a key surprise reducing technique to walk into the review with an opinion. This moment of personal honesty you're having with yourself is a big deal because that's the foundation you're going to stand on when the three pathetic paragraphs show up. Having a justifiable opinion regarding your year is a powerful, defensible position.

While it's important to send the self review long before your boss writes his review, it's more important that you have this opinion, this well-defined opinion, when sitting down to read your boss' review. Does it document what you did? Everything? Does the description of what you did match your perception? No? Why? Don't tell me, tell your boss, and make sure he gets it because it's these types of historical perception mismatches that form an unhealthy basis for emerging misunderstanding and resentment.

The point of a review is he debate -- to align your perceptions with those of the person who signs the checks, but even with all this structured healthy debate, there's still going to be a...

Surprise!

I don't know what the surprise is. It's your review. Some of the doozies over the years from mine include:

The total absence of recognition for a multi-month multi-team project that kicked ass.
A reversal of opinion regarding a piece of work I'd done, usually towards the negative.
Completely contradictory areas of improvement.

Unfortunately, the surprise is the point. A review not only forces the alignment discussion, it serves as a warning for the coming year: What do I need to do differently to avoid being blindsided when the next review arrives?

Fact is, you're never fully going to get your boss on-board with your year. There are opinions he has which aren't going to change which means if you don't want another surprise next year, you have to change.

A review's value lies not only in the documentation of what was observed, but also what was not.

The Permanence of the Written

In many years of reviews, the only consistency I've noticed is that they're getting shorter. My unsubstantiated paranoia is that lawyers apply subtle corporate pressure to retain less descriptive documentation of what actually happened in the company. But perhaps it's just a growing professional laziness.

Whatever the reason, a brief review is just sad. If you're staring at three useless paragraphs, you have a couple of problems. You've got a company that allows crappy reviews and you've got a boss who is unable or unwilling to articulate either the quantity or quality of work you've done.

That's all sorts of screwed, but it's only complete breakdown only occurs when you don't react.

The first review I wrote was awful. It was three paragraphs derived from scanning status reports from the past six months. I sat in the room as she read the review and she didn't have to say a thing for me to understand that I'd be spending the weekend actually writing the review. I got an accusing, furious glare. You didn't even try.

So I did.

Little, shiny robots

Adam Milligan — Sun, 30 Aug 2009 03:01:00 GMT

One of my favorite computer games when I was growing up was Robot Odyssey; I imagine it will come as a surprise to no one that I was a nerdy kid. This article is a little bit of a tribute to that game, and the coolness of solving complex problems with a handful of simple concepts combined in clever ways.

Imagine you want to write a web-based game that involves robots. The robots in your game are a bit like the robots in Robot Odyssey: you program them with a list of simple instructions and when you turn them on they follow those instructions faithfully. Let's say, for the sake of argument, that your robots can Walk Forward, Turn Left, Turn Right, Jump, and Beep.

You model each of the moves your Robot can make as an Action, and a Program as a list of Actions. Since each Robot can execute any number of Actions as part of its Program, and any number of Robots can execute Actions, you join Programs and Actions through the Instructions table. Like so:

class Robot < ActiveRecord::Base
  has_one :program
end

class Program < ActiveRecord::Base
  belongs_to :robot
  has_many :instructions
  has_many :actions, :through => :instructions
end

You build a whiz-bang interface for programming each Robot using JavaScript, which will PUT a collection of Action IDs to programs#update (each Robot creates a blank program on initialization, so no need for programs#create).

This seems pretty straightforward, doesn't it? Unfortunately, it won't work; the update will fail to reliably record the uploaded Actions. Here are some examples:

@program.action_ids  # []
@program.action_ids = [1, 4] # Forward, Jump

@program.action_ids # [1, 4]
@program.action_ids = [3, 1, 2, 5] # Right, Forward, Left, Beep

@program.action_ids # [3, 1, 2, 5]
@program.action_ids = [5, 5, 5] # Beep, Beep, Beep

@program.action_ids # [5]   ?????

What happened here? The problem lies with the way ActiveRecord collection associations update themselves. Here is the interesting code (slightly paraphrased) from association_collection.rb:

# Replace this collection with +other_array+
# This will perform a diff and delete/add only records that have changed.
def replace(other_array)
  ...
  delete(@target.select { |v| !other_array.include?(v) })
  concat(other_array.select { |v| !@target.include?(v) })
end

As you can see (or you could just read the comment), this only adds an element to a collection if that element isn't already in the collection (and it acts similarly for deletion). Sadly, it doesn't take into account how many times an element appears. So, above, when I tried set the action_ids to [5, 5, 5] it saw that the action_ids collection already contained that ID and moved on. If I had set the action_ids collection to [5, 5, 5] when it already contained [1, 4], the result would have been the expected [5, 5, 5].

Now, I'm on the fence with regard to whether I consider this a bug or just a somewhat inconsistent, but expected, behavior. To begin with, the fix is annoyingly nontrivial, and would potentially have a noticeable performance impact. Far more importantly, I'm not sure how often this might reasonably cause a real problem. In the case of your Robots game, you'd probably care quite a lot about what order your Robot executes its Actions in, so you'd likely have a position column, or something similar, on the instructions table. Given that, you'd probably update the Program by sending in a list of nested attributes which would create Instructions, each with the correct position and associated to the correct Action.

Even so, this is behavior worth knowing about. In the infinitude of possible update scenarios someone will want to update their HMT associations this way. I know I initially wrote code to do this as a temporary experiment, and ended up spending the rest of the day trying to figure out why my updates did the wrong thing a small percentage of the time.

All About Placebo

Lloyd Morgan — Wed, 26 Aug 2009 08:16:31 GMT

Wired has published what must be one of the most comprehensive articles looking at the phenomenon of the placebo effect.

From its humble beginnings in WWII with anesthetist Henry Beecher to the placebo’s transition from being treated as a purely psychological trait to a physiological one; there’s some great material here.

Two comprehensive analyses of antidepressant trials have uncovered a dramatic increase in placebo response since the 1980s. One estimated that the so-called effect size (a measure of statistical significance) in placebo groups had nearly doubled over that time.

It’s not that the old meds are getting weaker, drug developers say. It’s as if the placebo effect is somehow getting stronger.

The fact that an increasing number of medications are unable to beat sugar pills has thrown the [pharmaceutical] industry into crisis. The stakes could hardly be higher. In today’s economy, the fate of a long-established company can hang on the outcome of a handful of tests.

Related: Placebo in History.

via @jonahlehrer

You may also be interested in:

Ruby On Rails Developer (Ongoing) (Ann Arbor, MI (Telecommuting Possible))

Fri, 21 Aug 2009 21:05:20 GMT

We’re looking for an Ruby / Ruby on Rails developer with an eye for detail and a drive to learn and improve his or her skill set while working in a fast-paced environment. At MetaSpring, you’ll be developing a diverse range of dynamic, Web 2.0 applications and working with our designers to tie in slick and usable front end interfaces. The ability to handle server administration tasks as they arise is a big plus.



Required Skills &amp; Knowledge

A solid understanding of the web from philosophical foundations to the nuts and bolts of its implementation
The ability to create good abstractions that actually get reused
Experience developing front end components utilizing XHTML, CSS, JavaScript, AJAX, XML, JSON and microformats
Experience delivering non-trivial production-ready Ruby on Rails code
Experience with MySQL and database architecture
Exceptional problem solving skills
Experience with cross-browser development and all of the fun challenges that this entails
A familiarity with Agile Development practices

What would be extra awesome:

Solid communication skills
Knowledge of Photoshop, Flash, etc
A flair for the written word
Any server administration experience
A passion for usability
Familiarity with the Mac development environment

Thu, 20 Aug 2009 04:39:08 GMT

The case for innovation

wemediaguru — Wed, 19 Aug 2009 18:55:14 GMT

Sometimes things are all about timing. The last two days I’ve come across four things that I needed to read and the very moment they came around.

They all have to do with innovation, taking risks and breaking down barriers. Engaging in those and taking a critical look at the tasks I’ve been doing, has given me some of the fire back that has been absent for awhile, so I felt a need to share. Here goes:

The first is a video from the folks at CoPress called A Case for Innovation. Simple, to the point and right on.

The second is a post by Dan Pacheco on how fear, brand addiction and paranoia block innovation. This struck with me because breaking down these and other barriers is going to lead to some really cool stuff.

Just to be clear, I’m not opposed to building and growing existing brands, but in today’s fragmented world I think that “one size fits all” brands have limited appeal. My advice to mature information companies is to think of their brands as “wrappers” for capabilities and expertise. They deliver solutions to customers. But every audience prefers different packaging, so if you use the same brand for everything you end up polluting their potential.

The third is a very clear set of tasks that can be done to create a ecosystem of local knowledge. It comes from Chuck Peters in a post called Focus on Essential New Tasks.

It is a collaborative blueprint for fundamentally changing the way media companies collect content, engage audiences and new voices, disseminate information and work more closely with communities they serve.

We need to create content in the first instance with a new mindset, both those content creators we employ full time, and contracted or freelance community content creators. All content creators need to have a primary emotional bond with their content and audience, not a product or company.

This content creation needs to take place in a new infrastructure which allows atomization and tagging at the simplest elemental level. Today we are stuck with locked-down story and advertising publishing systems, and a bewildering array of blogs, tweets and social space entries.

The fourth comes from Neil Perkin and his Only Dead Fish blog. If you’ve never come across him, take the time. It’s worth it.

He recently wrote a post about the power of incomplete ideas, which to me speaks directly to the way innovation often happens.

As Matthew May says in the introduction to his lovely manifesto on the subject (HT to Johnnie Moore for the link): “Conventional wisdom says that to be successful, an idea must be concrete, complete, and certain. But what if that’s wrong? What if the most elegant, most imaginative, most engaging ideas are none of those things?”. Matthew goes on to make a brilliant point about this, that it is the “unusually simple yet thoughtful construction of what is there” that gives the missing piece its surprising power. Rather like Itay Talgam’s ‘Doing By Not Doing’ (if you haven’t seen that talk yet, watch it. It’s worth it).

I am a media junkie and love the idea of forging ahead and breaking down barriers to lead to new success stories in this industry. I take these four items as a call to action.

10 Vital Lessons for Web Start-Ups

Drew McLellan — Wed, 19 Aug 2009 16:26:24 GMT

This summer we launched Perch as a side project from our web development agency, edgeofmyseat.com. Perch is a really little content management system aimed at web designers who want to enable their clients to update their own site content. As this is our first product (we normally work on website projects for design agencies), there were quite a lot of new things for us to learn.

In this post I’ll cover some of the things we’ve learned along the way. Whilst the same lessons won’t apply completely to every situation, they’ll be interesting to anyone thinking about launching a web app.

#1 Choose Your Payment Provider Carefully

Rather than operating as a hosted service, Perch is a PHP app that you download and install as part of your own website. As such, we’d be selling it from our site via electronic delivery. We decided pretty early on that we were going to sell Perch using PayPal. As our target customers are web designers, we figured that most designers would be familiar with PayPal and probably already have an account. What’s more, it would be easy to integrate into our checkout, still allows customers to pay with a credit card, and there are no up-front fees involved.

That last point was important, as one of our business decisions with Perch was that we wanted the project to fund itself. Although being born out of a profitable existing business, we wanted to bootstrap Perch as much as possible, so paying a fee for each transaction but nothing up-front suited us just fine. The downside of this is that the fee per transaction is higher than it would be with traditional credit card processing, so there comes a point whereby you’re doing enough credit card business through PayPal that it’s more profitable to pay for the merchant account and payment gateway.

For Perch, about one third of our payments are with a credit card via PayPal, so we certainly need keep an eye on the figures to make sure we’re getting the most cost effective deal on the processing fees.

#2 Know How You’re Going to Deal with Invoicing

As a web development agency, we work alongside design agencies building content managed websites and online stores, and typically only deal with a handful of larger invoices each month. However, with Perch we quickly found that we would be facing hundreds of invoices that would all need to be created in our accounts system by hand.

We use the online accounting software Xero for all our accounts, and found that this had a couple of features that would save the day and enable us to handle the volume of invoices more easily. Firstly, we discovered that Xero can import transactions from PayPal just like any other bank account. Once an hour the software updates showing all the new payments that have come in, ready to be matched up with invoices.

Those invoices are the second half of the problem. Fortunately, Xero has a RESTful API that would enable us to programatically create each customer and invoice in our accounts directly from our web server. This is great, because it means that within about a minute of each sale we’ve got the customer and their invoice set up in Xero, and then within the hour the PayPal transaction appears, ready to be matched up. The only manual part is the matching up, which is very quick to do.

Using an API to manipulate your business accounts can sound a bit daunting at first, but Xero have a good testing platform to develop against, and our integration was manually checked over before we could go live to make sure that we weren’t doing anything stupid.

#3 Be Super-Organised with Customer Support

Another new area for us was dealing with end-user support. We were fairly sure we wanted to do this out in public on some sort of forum rather than in email. We felt it was important that customers could search past discussions before posting in case their question had already been answered.

After looking around at a few different solutions, we discovered Tender, which seemed to do what we wanted. Crucially, they had an option to point a subdomain at their server so that we could use support.grabaperch.com for our site. This also meant that we could share cookies between our customer account system and the support system on Tender, meaning that, with a quick bit of integration, customers can access both systems with one account.

One thing we didn’t quite appreciate up front was the distinction between discussion and support. Anything posted to Tender is flagged and requires a response from our team, which is great when customers have issues they need our help resolving. This means that nothing gets missed and on average all support requests are dealt with in under one hour.

This isn’t so great for general discussion between users, as the environment appears to discourage discussion, as every post is implicitly requesting a formal response. As a reaction to this we’ve just set up a separate community discussion forum where customers can chat and share ideas. We’ll see how that goes – our one concern is that customers will be unsure where they should be posting for help.

#4 Provide a Demo

One thing we’d seen with other CMS products is the pitifully sad online demo where the login details are published and anyone can go in and have a play. We always felt that the customer experience was pretty bad with these, as each customer ends up looking at a CMS full for everyone else’s test junk. Also, with Perch being designed for small sites, the likelihood of two customers being logged in and attempting to edit the same page at once was fairly high. As soon as that happens the appearance would be that the CMS is behaving erratically. Not good!

Because of this, we decided we didn’t want an online demo and launched the product without one. Customer feedback quickly told us that that wasn’t going to be good enough, so we had to go back to the drawing board. We were still convinced that a shared online demo would suck, so we decided to provide each customer with their own unique install of Perch to play with.

We built a system that enables customers to sign up for a demo. This then automatically installs a new copy of Perch for them and emails the customer their access details. This way, each customer can try the system out without all the usual disadvantages of a shared system.

#5 Make it Easy for Customers to Send Feedback

At the end of the demo process (each demo site runs for 24 hours) we send the customer an email to thank them for trying out Perch. We thought that this was a great opportunity to find out what they thought of the software. We added the following to the email and hoped for the best.

Loved it? Hated it? One crucial thing missing? Hit reply and let us know – we’ll use your feedback to make Perch better.

Turns out that this was one of the smartest things we did. Asking a customer to just hit reply and talk to us made it so easy for people to respond that more than 25% of customers did just that. We could quickly answer any questions, and most importantly, that we are able to catch those who decided not to buy because they thought Perch was missing a feature that they’d just not spotted. For those who ultimately did walk away, we were able to get an idea of why they chose not to use Perch and we can use that to inform future product decisions.

#6 Just because a Market’s busy, Doesn’t Mean it’s Saturated

At some points, we’ve stopped to think twice about launching yet another content management system product into the market. There are so many different systems out there, commercial and open source, small and large. The reason that there are so many options is that content management is an extremely broad area, with lots of different customer requirements. What’s more, almost everyone with a website is a potential customer for some sort of CMS of some description, and there’s certainly no shortage of people with websites.

It’s very tempting to be put off from lunching something just because there are already other products that do a similar job. It’s important to remember that it’s not only the job you do, but how you do it that counts. If your product can offer something different, be that in user experience, a way of working, unusual features, or specialisation for a role or industry, then they’ll be some kind of market for it. There are millions of customers out there. All you need to do is figure out if the potential market is big enough to support your plans.

#7 Don’t Worry About the Dinosaurs

Right from the start we were sure that Perch had to be built in PHP, as customers would need to be able to get the CMS running easily on their own hosting. PHP is rock solid and super-easy to host. One concern we had was that although PHP5 has been around for ages, there are still a lot of servers out there running PHP4 even though it’s no longer supported. Projects like WordPress have a goal of being able to run anywhere, and as such stick to the parts of the language only available in PHP4.

As a company, we develop primarily in object-oriented PHP5, and knowing all the advantages that well structured OO code brings, I was reluctant to develop a new app in crufty old PHP4 code. We played with the idea of having two versions, but that meant twice the work on new features and twice the bugs to fix. So we just took the plunge and made the app PHP5 only, thinking that we’d wait and see if there was any demand for a PHP4 version.

As it turns out, it’s been a complete non-issue. On the occasion when a customer has found their hosting is PHP4, they’ve been able to contact their hosting company and get the site switched to PHP5. It’s all surprisingly low-hassle. Turns out we were worrying about a problem that didn’t even exist.

#8 Release Early and Often, but Plan Ahead

We often hear the phrase “release early, release often”, but what does that really mean? For us, it meant getting our initial release of Perch to a point where it had just enough functionality to be useful and stopping there and shipping. From a development point of view, releases force you to get bugs tied down, loose ends tied up and get everything properly tested. So a shipping release is a known stable point in where everything is 100% solid and functional. Incrementally adding new features on top of a release then becomes a more reliable process and it’s much easier to keep your application stable.

When we were building the initial version of Perch I had a whole list of ideas of what features we’d build into 1.1, 1.2 and so on. It’s great that we released early, as it turns out that none of the features I thought were essential have been asked for by customers. I thought we’d need RSS – no one cares about RSS for a small site.

So whilst you don’t want to spend loads of time building in features before you ship, it is still important to plan ahead and leave doors open for the features you may wish to add further down the line. With Perch, I figured it might be good to have the option of translating the admin interface into different languages. I didn’t have a specific plan for how it would work, and certainly didn’t spend time building it, but what I did do was make sure that every piece of text in the interface was passed through a translation function.

At the time we launched, my PerchLang::get() function calls just returned whatever string was passed to them – the function basically did nothing. But it did mean that when I came to implementing translations in version 1.1.5, all I had to do was think of the best way to take a string in English and find the translated version. At the time of writing, Perch is available in 12 customer-contributed languages from Russian to Portuguese, with minimal programming needed.

#9 Make Full use of Existing Tools

What no one tells you when you launch a product is that about 50% of your effort goes into developing the product, and the other 50% is putting infrastructure in place to market, sell and support it. There’s a lot of work that goes into all the peripheral systems needed, and I think we’d have given up if we tried to implement all that ourselves.

Instead we made use of PayPal to take funds, Tender to handle the support, we asked people to follow us on Twitter to keep in touch rather than setting up some kind of mailing system. We’ve set up our discussion forums using bbPress. Anywhere where we can make use of an existing solution instead of writing our own, we’ve tried to do so. Not only does it work out more cost effective, it enables us to focus on our main task – building a useful product.

#10 Hire in the Experts

First and foremost, we’re web developers. That means there are parts of a project that we’ll be good at, but there are going to be parts that are outside our expertise. One thing we’ve learned is that it’s really important to call in the experts to help cover your weak spots.

The first experts we called in were our solicitors to draft up a professional software license agreement. We could have probably come up with something ourselves, but the chances are that when it came to the crunch it wouldn’t stand up in a court of law and therefore would be worthless. We hope that we never have to test our license in court, but there’s no point in having a cobbled together legal document of any kind – it’s as good as having none.

The next job that called for experts was with the interface design. We like to think we know one end of a usable interface from the other, but when it comes to the crunch it’s not our core skill. We wanted the UI for Perch to be really well considered, easy to use and something that designers would be happy to hand over to their clients to use. So we called on the help of our friends at Nine Four who were able to take our jumbled prototype UI and turn it into something that really worked.

When we launched our marketing site, still trying to not spend money we didn’t need to spend, we bought some stock illustration from iStockPhoto and just ran with it. This was nice and cheap, but long term is was fairly charmless and we didn’t think it wise to build up a brand around illustration that wasn’t technically ours. So shortly after launching, we hired illustrator Kev Adamson to develop some original illustrations that we could use going forward. The great thing is that now not only is the illustration a thousand times better than what we had from stock, we have someone to go back to for any further work we need doing.

As an agency we’d be horrified if our customers thought they’d do their web development themselves instead of calling us in to do it properly. We’ve tried to apply the same principal to our own project and call in experts where they can help.

In Conclusion

Of course these are not universal rules, but they are fairly broad lessons that we’ve learned on our journey so far. Some we knew in theory and have put into practice, and others we’ve picked up along the way. I’m sure as we carry on down the road there’ll be plenty more to learn. Perhaps you’ve had similar – or contrary – experiences, if so leave a comment and tell us about it. And if you ever build small sites for clients, family or organisations you care about, perhaps you’ll come and check us out.

ABingo: An A/B Testing Plugin for Rails

Peter Cooper — Wed, 19 Aug 2009 18:21:08 GMT

ABingo is an "A/B testing" plugin to use on your Rails applications in order to test differences between two ways of showing the same information. It was developed by Patrick McKenzie, known mainly in the developer community as the creator of Bingo Card Creator.

A/B testing (also known as split testing) is a system of having two versions (or sometimes more) of a Web page and then showing them randomly to visitors, then comparing what visitors to different versions of the page do. This allows you to see if something as simple as a headline change or as complex as a total redesign has an effect on what user's do - such as purchase your product or signup for your service. Once the "best" version has been determined, you can then continue to do further A/B tests until you run out of things to try, thus resulting in a better page.

ABingo adds helpers to Rails to make it easy to implement A/B testing in your views and controllers:

# Simple syntax to start a test
<% ab_test("login_button_test", ["/images/button1.jpg", "/images/button2.jpg"]) do |button_file| %>
<%= img_tag(button_file, :alt => "Login!") %>
<% end %>

# Track any arbitrary event as a conversion
def login
  # Business logic goes here
  bingo!("login_button_test")
end

Jumpstart Lab is running a JavaScript Master Class for Javascript & UI programmers with Thomas Fuchs (Scriptaculous, Prototype Core) and Amy Hoy (UI Expert) on 9/12 in Washington, DC. Save 10% with code "rubyinside"!

Startup panel review

Tue, 18 Aug 2009 23:54:54 GMT

Panelists

Last night’s startup panel included representatives from self-funded (thoughtbot), angel funded (oneforty), and Series A and Series B funded companies (Panjiva and Zendesk). All four companies are using Ruby in some form.

While many topics were addressed, such as why each company uses Rails, how they developed their products, how they hire, and how they secured funding, there was a common theme to every topic.

People are the most important part of a startup

The following quotes are paraphrased from memory and Josh Nichols’ notes.

“Investors aren’t interested in Ruby; They’re interested in startups.” - Jim Psota, Panjiva

“The most important effect of publishing open source code for us has been attracting great employees.” - Matt Jankowski, thoughtbot

“The best people want to be part of something big so as a founder, you need to articulate the vision and communicate why it makes sense to job candidates.” - Jim

“The great secret of startups is every day you’re doing something for the first time so the most important quality we look for is ability to learn quickly.” - Jim

“We secured our angel round through networking. They then introduced us to the right people for later rounds.” - Jim

“We were initially self-funded, then raised enough from friends and family, offering 1% portions of the company for cheap, to allow us to work on the product full time.” - Morten Primdahl, Zendesk

“When you pitch an investor, be very honest. Say, ‘These are the things I know, and these are the things we don’t know. Here are our current hypotheses on the things we don’t know which we need to experiment on.’” - Jim

“We secured angel funding due to the strength of our founder’s network. She knew or found the right investors for our type of business.” - Mike Champion, oneforty

“It’s a positive to structure your team like Lincoln’s ‘team of rivals.’ Contrarian views questioning the status quo are necessary from inside the organization.” - Jim

Comprehensive notes

If you’re interested in reading more about the tools, techniques, and technologies each companies use, read Josh Nichols’ comprehensive notes, which are available here.

TuneUp your iTunes collection

Erin Doland — Tue, 18 Aug 2009 11:30:00 GMT

I use iTunes to organize my digital music collection and, for the most part, it suits my needs. I say “for the most part” because similar to the problem I’ve been having with the photographs that I had scanned, not all of my music has correct information associated with it. Fortunately for my music, though, I don’t have to go through my entire iTunes collection song-by-song to straighten out the missing and incorrect data. I have found a program that simply corrects my data — TuneUp.

Based on algorithms and other technical things I don’t fully understand (kind of like the iPhone app Shazam), TuneUp picks up where iTunes leaves off at properly identifying the music in my collection. I no longer have seven Track 03s on my playlists. All I have to do is drag the misidentified song into the “cleaner” and TuneUp pulls up possible matches. (The cleaner function is displayed at right.)

In addition to identifying songs, it also fixes formatting, finds rarer cover art, matches artist names, and even gives information about the songs in your collection sort of like VH1’s old Pop-Up Videos.

There are other programs out there similar to TuneUp, I just happened to find this program first and since it worked for me I didn’t try the others. If you have tried other programs and had success, please tell us about your experiences in the comments. TuneUp is free for a “limited-access” download, and is around $20 for an “unlimited” version.

If only I could find a program to clean up my digital photographs as easily …

(Image from TuneUp’s website … I fear if I show my music collection you all will make strange — but probably correct — assumptions about me! And, it should go without saying, but I wasn’t paid to write this review.)

JavaScript MVC

contact.us@alistapart.com (Jonathan Snook) — Tue, 18 Aug 2009 09:00:38 GMT

As JavaScript takes center stage in our web applications, we need to produce ever more modular code. MVC (Model-View-Controller) may hold the key. MVC is a design pattern that breaks an application into three parts: the data (Model), the presentation of that data to the user (View), and the actions taken on any user interaction (Controller). Discover how MVC can make the JavaScript that powers your web applications more reusable and easier to maintain.

Parallel processing in ruby made simple

Sun, 16 Aug 2009 17:04:43 GMT

Parallel processing for ruby allows to easily run any code in parallel Processes or Threads , no more piping/forking/serialisation knowledge required, just results = Parallel.in_processes(2){|i| expensive_computation(data[i]) }

Rails requests missing the HTTP body

Adam Milligan — Sat, 15 Aug 2009 20:56:00 GMT

This is a bug in Rails that quite likely affects you, but which you've even more likely never experienced. I've posted it here for the benefit of the small number of people who will run into this problem and turn to Google for help.

In short, if you use Mongrel app servers (this may affect Passenger as well, I don't know), the first HTTP request to your Rails app after you restart your servers, or otherwise reload your environment, will have an empty HTTP body.

I say you've likely never experienced this because the majority of HTTP requests to your Rails app are likely GET requests, which always have empty HTTP bodies. After that first request everything will work just fine. Even if you're unlucky enough to receive a POST or a PUT request containing a body immediately after restart it will only fail once, which you could easily write off an an anomaly. You also won't see this behavior in your development environment, or any environment in which you use Mongrel as a web server rather than just an app server.

If you're interested in a patch for the bug, I've submitted one to Rails here.

The source of the problem lies in how ActionController initializes itself. In the actionpack gem you'll find the lib/action_controller/cgi_ext.rb file, which does little more than load the three files in the cgi_ext directory:

require 'action_controller/cgi_ext/stdinput'
require 'action_controller/cgi_ext/query_extension'
require 'action_controller/cgi_ext/cookie'
...

The cgi_ext/query_extension.rb file is the interesting one:

require 'cgi'

class CGI #:nodoc:
  module QueryExtension
    # Remove the old initialize_query method before redefining it.
    remove_method :initialize_query

    # Neuter CGI parameter parsing.
    def initialize_query
      # Fix some strange request environments.
      env_table['REQUEST_METHOD'] ||= 'GET'

      # POST assumes missing Content-Type is application/x-www-form-urlencoded.
      if env_table['CONTENT_TYPE'].blank? && env_table['REQUEST_METHOD'] == 'POST'
        env_table['CONTENT_TYPE'] = 'application/x-www-form-urlencoded'
      end

      @cookies = CGI::Cookie::parse(env_table['HTTP_COOKIE'] || env_table['COOKIE'])
      @params = {}
    end
  end
end

This replaces the default #initialize_query method provided by Ruby's CGI library:

    def initialize_query()
      if ("POST" == env_table['REQUEST_METHOD']) and
         r|\Amultipart/form-data.*boundary=\"?([^\";,]+)\"?|n.match(env_table['CONTENT_TYPE'])
        boundary = $1.dup
        @multipart = true
        @params = read_multipart(boundary, Integer(env_table['CONTENT_LENGTH']))
      else
        @multipart = false
        @params = CGI::parse(
                    case env_table['REQUEST_METHOD']
                    when "GET", "HEAD"
                      if defined?(MOD_RUBY)
                        Apache::request.args or ""
                      else
                        env_table['QUERY_STRING'] or ""
                      end
                    when "POST"
                      stdinput.binmode if defined? stdinput.binmode
# =====>              stdinput.read(Integer(env_table['CONTENT_LENGTH'])) or ''
                    else
                      read_from_cmdline
                    end
                  )
      end

      @cookies = CGI::Cookie::parse((env_table['HTTP_COOKIE'] or env_table['COOKIE']))
    end

The interesting line is the one I've marked with a comment rocket. Notice how it reads from stdinput; this leaves the read pointer at the end of the input stream. Now look back at the Rails override for this method, and notice how it does not read from stdinput, thus leaving the read pointer at the start of the input stream.

This is all fine and dandy as long as all of the ActionController code loads up and patches the CGI library properly. However, ActionController doesn't load the cgi_ext.rb file (or its dependencies) until it references either the CgiRequest or CGIHandler classes (which require cgi_process.rb, which require cgi_ext.rb), as part of the first request, which is after the default Ruby CGI library has read the input stream containing the request body. ActionController then tries to read the request body assuming the read pointer is at the start of the stream. Oops. Subsequent requests work fine, because everything has now been loaded.

Finding the source of this bug took some doing (Chris Heisterkamp, aka "The Hammer" and I tracked it down together), but the fix is easy. If you look at the patch you'll see it's simply a single require in action_controller.rb. You can achieve the same result by requiring 'action_controller/cgi_ext' in an initializer file in your app.

Like many problems, this one should go away in Rails 3. Rails has deprecated use of the CGI library, and the CGI extensions have already been removed from the Rails master branch. However, it's a real problem now, and will remain so for at least some amount of time.

Hostname middleware

Sat, 15 Aug 2009 22:58:11 GMT

How to know which server has sent back the response during development with multiple servers behind a load balancer.

A grand piano for your violin

Sat, 15 Aug 2009 18:00:54 GMT

Database indexes

What are database indexes? If you’re building web apps powered by a relational database, you should know.

A database index is a data structure in the database which improves the speed of operations (typically row lookups) on a database table, or across tables. Think of it like the index of a book. If you’re reading a book about the Wu Tang Clan and you want to find all the Method Man references, it’d be a lot easier to flip to the index and find “Method Man”, then open up directly to all those pages numbers (as opposed to scanning every page of the book for the words “Method Man”), wouldn’t it?

Well that’s basically how database indexes work. Assuming you have an indexed users.id column on your users table, when you query a database with…

SELECT name FROM users WHERE id = 1

…the database can find that row very quickly, rather than having to scan through every row in the table and check whether it’s “id” value is equal to 1.

So, in a typical rails application, what things should you index?

Primary keys

Most SQL databases with the concept of a primary key will automatically create an index on the primary key column when it exists. In Rails, this is typically the “id” column in a table, and because Rails tells the DB that it’s a primary key, you’ll get the index “for free”, created by the database. This is very important for a “show view” like /users/1, for example. The request comes in, and the query to “find user with id equal to 1” occurs very quickly because the users.id column is indexed.

Best practice: index every primary key

Foreign keys

Now what if that user has_many comments? In Rails, you most likely have a user_id column in your comments table, which the Comment model will use to determine the user that it belongs to. You should have an index on every foreign key column. When you make a page like /users/1/comments, two things need to happen. First, we lookup the user with id equal to 1. Assuming we’ve indexed primary keys, this will be fast. Second, we want to find all comments that belong to this user. If we’ve indexed comments.user_id, this will be fast too.

We’ve actually taken this to a “policy” point where we try to avoid ever naming a column with an “_id” suffix, unless it is an integer foreign key column that needs to be indexed.

Best practice: index every foreign key column

Columns used by to_param

Let’s say you’ve got indexes in place on users.id and comments.user_id, but then a request comes in to make “pretty urls” on these pages. Ok, no problem. We add a users.keyword column to users, and allow users to specify a username with their account. Now we can make requests to urls like /users/matt/comments, and see all comments by that user. Well, same situation as before, we need to do a find, but this time we’re matching against the ‘keyword’ column and not the ‘id’ column, so this needs to be indexed.

Best practice: index every column used in a WHERE clause

Composite keys on join models

What if multiple users could write one comment together, and we needed to store a timestamp to know when each of them last edited the comment? We could introduce a Commentary join model, which would connect users to comments. This model would have a user_id and comment_id column, along with a last_edited_at timestamp, or something.

In this case, there should be a composite index (an index across multiple columns, basically) on the (user_id, comment_id) combination on this join model. That way, when we run a query to find all comments that a certain user has been an editor on, we can quickly those comments through the join table.

Best practice: index composite keys on join models

State columns

What if comments can be in “Draft” (not done yet), “Submitted” (done, awaiting approval), “Published” (approved) or “Unpublished” (approved then taken down) states? We’re most likely going to have an interface for users which shows “all of your draft comments” so that they can resume working on them, and “all your submitted comments” so they can review their past wisdom.

In this case, we’ll add a comments.publication_state column to comments (I have an unfounded fear of using ‘state’ as a column name; sounds like a reserved word to me, but it’s not!), which will be a varchar column and hold one of those states as a string. We should index that column so that the queries to find comments in a certain state are fast.

Best practice: index every varchar/string column that’s used for storing state

Boolean columns

Well, with the introduction of the “submit for approval” concept we also need to add an “admin” concept for users, with the option to either be an admin or not be an admin. We need a “all users who are admins” view so that we can see at a glance who is doing comment approval and click through to see what they’ve approved.

In this case, we’ll add a boolean column called ‘admin’ to the users table (in mysql, this is implemented with a TINYINT column, may be different elsewhere). This column should be indexed, so that the query to find all admin users is fast.

Best practice: index every boolean column

Datetime columns

As this commenting application enjoys continued success, we’ve decided that viewing comments in the order in which they were posted would really improve our users’ ability to find what they were looking for. To do this, we’ll add an order by clause to the query that gets the comments for them to view.

To keep this performant, we should add an index to the ‘created_at’ column on comments. If we had a view sorting by published_at or updated_at, we’d want to index that as well.

Best practice: index every datetime column

Columns used in polymorphic conditional joins

In Rails when you establish a polymorphic relationship you end up with a condition on a join in the resulting query. For example, let’s say you can apply a Tag to a Comment via a Tagging association. There will be queries like:

SELECT * FROM comments INNER JOIN taggings ON taggings.taggable_type = 'Comment' and taggings.taggable_id = '3' INNER JOIN tags on taggings.tag_id = tags.id

In this case, you should add a composite index to taggings(taggable_type, taggable_id) pair, so that the initial lookup goes well. You should also have already indexed taggings(tag_id) because this is a foreign key association.

Best practice: index all _type/_id pairs on polymorphic join tables

Columns used in validations

Nine times out of ten you probably already have this covered by following the best practices already enumerated in this post, but another thing to watch out for are Rails data validations on models. If you have a column which has a uniqueness constraint, for example, every time you save a record of that class (regardless of whether that particular column has changed or not), ActiveRecord is going to run a query to try to find other rows which have the same data in that column. It will be much faster to do this comparison on indexed columns than non-indexed columns.

An example of this would be something like a users.email column, where the email had to be unique across all user rows in the table.

Best practice: index all columns that will generate queries from model validations

Columns used for STI

With the Single Table Inheritance pattern in Active Record, there is a ‘type’ column created to store the parent class of a subclass. For example, if FancyGroup inherits from Group with STI, there will be groups table with a ‘type’ column, which all FancyGroup records will populate with the “FancyGroup” string, to indicate that those records are of that subclass.

This means that every query which looks up FancyGroup records is going to have at least a WHERE groups.type = 'FancyGroup' clause in it, and that means that the ‘type’ column on that table should be indexed.

Best practice: index all ‘type’ columns on tables used for STI

How to add an index

In Rails, adding an index is really straightforward. Here’s an example from a recent application where I was converting what was previously a numeric lookup to be a “pretty url” lookup, and wanted something like /products/thirty-six-chambers instead of /products/123…

class AddIndexToProductsKeyword < ActiveRecord::Migration def self.up add_index :products, :keyword end def self.down remove_index :products, :keyword end end

The products.keyword column already existed in this case, it was just a matter of adding an index to that column. The Rails guides site has more about Rails Migrations.

To add a composite index (an index across multiple columns), Rails uses an Array syntax. Here’s an example for the earlier Tagging scenario:

class AddIndicesToAllPolymorphicTables < ActiveRecord::Migration def self.up add_index :taggings, [:taggable_type, :taggable_id] end def self.down remove_index :taggings, :column => [:taggable_type, :taggable_id] end end

Side note - the pattern by which Rails generates names for indexes has changed over time. In earlier versions of rails, for example, the table name was prefixed onto the index name, creating names like “posts_published_index”. In more recent versions, the same migration would generate an index named “index_posts_on_published”. If you are starting a new application, you can probably afford to not care about this at all. If you are updating a legacy application which added indexes to your production database using the old naming, be careful about how you add/remove/rename indexes, so that local developer environments don’t wind up out of sync with the production environment.

But I don’t have that much data…

Contrary to developer myth, database indexes are not “just for speed” (they are technically for speed, but they are for achieving it in the first place, not fixing problems), or only meant to be used once your data reaches a certain size, or a case of premature optimization. Sure, maybe you’ll get away with decent performance on your local database running in development mode with you as the only user, but that’s not the real use case for the application, is it? Database indexes are not tools to troubleshoot speed problems or data growing pains - they’re a fundamental tool that relational databases use to function correctly in the first place.

What about search?

This post doesn’t cover doing full text search against string and text fields, perhaps a future post will. That being said, basically everything in this post will likely assist in speeding up any query that is doing search, by virtue of speeding up the joins and ordering and state restrictions that may be included in a search query.

Ok, so this gets me like a 5% speed increase, right? Who cares.

Totally wrong. It’s hard to put an average on the speed increase, because it depends on the schema and the query. But that’s not the point. If you’re not properly indexing the columns in the database and making sure your queries are using them, you’re not using the tool correctly.

For the sake of example - it’s not too out of the ordinary to see a non-indexed query that takes 1 minute or more to complete drop down to the tenths or hundredths of a second in length once it’s been made to use proper indexes. It’s a BIG DEAL. Run your own tests if you don’t believe me. Have someone else run tests for you if you don’t know how to run tests. Just take my word for it if you don’t know anyone competent enough to run tests for you.

What’s the downside

Well, there’s no “catch”, other than needing to remember to do this regularly. There are two “downsides” to indexing.

First, if you haven’t introduced indexes from day one, or you are adding an index to a new column in a table with many rows, the migration can take quite a bit of time. For example, when we passed about 12 million rows in the “messages” table in Thunder Thimble, we started experiencing some sluggishness on a certain query, and found that indexing a previously unindexed column was necessary to get things snappy again. Running that migration on the 12 million row table took about 7 hours, and the bulk of that time was spent adding the index.

Second, you can’t just go about willy nilly and add database indexes to EVERY column in every table in your database. There is a cost to the database to maintain those indexes, and every time an INSERT or UPDATE occurs, there is work to be done that would not need to be done without the index in place. In most scenarios, this is more of a theoretical fear than a practical fear, but definitely do your homework on it before you go index crazy.

How about some brunch?

Adding database indexes to migrations when you should, and doing regular database schema reviews to look for missing indexes is part of any applications healthy breakfast.

There is a “rake db:indexes:missing” task (which identifies missing foreign key indexes) in our limerick rake plugin, for those inclined to make it part of their breakfast too.

FatSecret Looks To Become A Central Hub For Nutrition Data With New API

(author unknown) — Fri, 14 Aug 2009 11:36:54 GMT

Shared by Ryan Sholin
This is actually something I think we need: An API for nutritional data.

FatSecret, an Australian social network focused on nutrition and weight loss that we covered back in 2007, is launching a new API tonight that allows third party sites and services to tap into its database of nutritional data, excercise information, and other health stats. You can access the new FatSecret Platform here.

CEO Rodney Moses says that FatSecret is allowing developers to access the API for free, in the hopes of turning FatSecret into the reliable and accurate resource for nutritional information. He points out the fact that while there are plenty of diet sites on the web that contain nutrition info for various foods, much of the data is disjointed — there’s no established comprehensive source that people turn to first. FatSecret hopes to become the authoritative hub for this kind of information. The site has gathered its data from a number of publicly available resources like the USDA, and also has many user-submitted entries from users on its social network. Moses says that all of the data has been curated to ensure accuracy.

The other component to the new API is a brand utility, which invites food and beverage brand owners to submit their nutrition facts into the system so that they can be retrieved using the FatSecret API.

Moses says that the site itself is still growing steadily, with half a million monthly visitors and around double that number when including users who access the site through other means, like its mobile applications.

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.