“Small batches” have been on my mind a lot lately. Eric Ries discusses the concept in his Lean Startup book. The basic idea is to do repetitive work in small end-to-end batches, creating one finished product at a time, rather than in large batches where you create many products at once in a phased manner. He credits the concept to Toyota, and applies it in turn to startups. Here’s a real-world example from his book of a race on stuffing envelopes between a father and his two daughters:

The daughters, age six and nine, knew how they should go about completing the project: “Daddy, first you should fold all of the newsletters. Then you should attach the seal. Then you should put on the stamps.” Their father wanted to do it the counterintuitive way: complete each envelope one at a time. They told him “that wouldn’t be efficient!” So he and his daughters each took half the envelopes and competed to see who would finish first. … The father won the race, and not just because he is an adult.

Ries cites many benefits to doing work in small batches, including less waste, less inventory, earlier discovery of defects, and a tighter feedback loop. I’ve found all these to hold true in doing software development. I happen to be focused on web services, but I see no reason these benefits wouldn’t also hold true for many other kinds of software and creative production work.

When not writing code I’m often planning what work we should do next, and I’m finding the small batch philosophy yields benefits on planning too. Here’s an example: we made a change on CampusPerks a week ago to our planning granularity. We used to estimate our work in half-day units, equating 1 Pivotal Tracker “point” to 4 estimated developer hours. Now we equate 1 point to 1 estimated developer hour. Sounds simple, right? You might think it would have little to no effect, but in fact after only a week I can already see a few significant benefits:

• We’re estimating our work with greater precision, and there’s a 1:1 mapping between estimated points of work and available developer hours. So questions like, “Can you get feature X done by Wednesday?” have become easier to answer (i.e. less time-consuming, with smaller error bars).
• We can now give credit for smaller pieces of work… the sort of stuff we might have assigned zero points to in the past because it took an hour or less to do, or lumped together with 4 or 5 similarly-sized items into a 1-point story. I find this especially true of design work, the fit-and-finish and attention to detail that is essential for making a product beautiful, but that often doesn’t get the full respect it’s due. Being able to give credit for all work regardless of its size feels more equitable to me and, I suspect, makes everyone on the team happier.
• It’s easier to decide how to fill small chunks of available work time. If I have an hour before lunch I can take 10 seconds to pick the next 1-point item off the backlog, knowing that I’m likely to complete it before my energy fizzles. In the past I might have wasted 5 or even 10 minutes hunting for a small-enough work item.
• My motivation to begin a new work item is higher, because none of the tasks look as daunting now (everything is scoped in hours, not half-days or days), I’m more certain of how long each task will take, I get to check off tasks more frequently, and I almost always get the satisfaction of carrying the baton across the finish line on tasks that I start.
• All this leads to more time when I can reach a state of flow.

The fact that chunking work in this way motivates me more and helps me reach flow was a delightful surprise, so much so that I’ve applied the same 1-point-equals-1-hour change to the other software projects I work on. It isn’t just accounting or semantics; there’s a real psychological difference. The bottom line is I find myself more willing and able to work if I invest the time up front in batching the work into smaller units. The work is easier to begin, faster to complete, and more satisfying to perform.

Pivotal Tracker. This is the single tool I use for managing software projects at the designer/developer work item level. It’s great… very easy to use, full history tracking, lives in the cloud (backed up), optimized for software projects, predicts dates for me, and lets me organize work into a few logical buckets. Some people don’t like the automatic date prediction, and if you need to work that way (“Precisely Scheduled Project Candy-Cane Land”) then it is not the tool for you. I think Pivotal would also work for many other kinds of creative project work — not just sofware — and I’ve suggested this to the good people at Pivotal Labs a few times, but they seem locked on the software space. All the better for us nerds.

Trello.  Trello is my single “big picture” list-making tool these days. At work I’ve just started using it for tracking high-level work project deliverables, e.g. key milestones and handoffs with clients. At home, I use it with Katrin to plan our expenses, prioritize home improvements, track movies, music and books we’d like to buy, and more. It’s simple, visually beautiful, and works on our computers, phones, and iPads. I’ve only been using it a few months now, but I think this one will stick because it addresses so many of the failures that stopped me from using other list-making tools.

Text files. When I’m keeping scratch notes on a project, or drafting a blog post, or trying to organize something that doesn’t fit into a list, it goes into a text file. I write in either straight .txt format or MarkDown to get a teensy bit of formatting. Every file is named yyyy-mm-dd-the-topic-title.md, e.g. “2012-01-27-writing-about-startups.md”, and this gives me a clean way to organize files and rediscover stuff I wrote months or years ago. Within software projects, a few text files in the doc directory suffice for readme’s and specs, and they get stored in our git repository for backup. For personal stuff, gitdocs automatically backs up my docs directory to the cloud. If I need a fancier looking document I generally switch to Google Docs, as I hate trying to reconcile and merge copies of office docs. But I always miss the speed and simplicity of editing a local text file, and I find myself back in text files before long, ast least for the initial drafting step.

Here are some tools I’ve tried that didn’t work well:

• Rich text “office” docs stored on a file server, e.g. Word, Excel, StarOffice, etc. plus file servers, Sharepoint, DropBox, etc. The richness of these document formats is fantastic for loosely structured content, but I find I always get caught up in formatting content and rearranging it on the page instead of getting down to the real work of writing. (Now that I write code for a living, I grit my teeth when someone sends me an amazingly formatted rich text document. “How long did that take to do?”, I wonder, and “how much better could the actual content have been if you hadn’t spend so much time formatting?” Sorry, all you devs I spammed with beautiful specs at Microsoft.) I’ve also never found a filing system that worked for teams… they all turn into junkyards, and then into graveyards. So I try only to go here when I have to work with big, bulky documents, e.g. video, PhotoShop PSDs, and such.
• Calendars, e.g. Google Calendar, iCal, Outlook/Exchange. Some people are huge fans of putting everything on a calendar, arguing that it forces time-based tradeoffs, thereby avoiding overcommitment. I find this too constraining. It forces me to think of everything in half-hour or 1 hour chunks of time, which isn’t a natural fit to the kind of work I do right now.[1] It limits my flexibility in deciding what to work on at any given moment. I don’t want silly reminder popups interrupting me every 30 minutes. My calendar drifts towards being 100% blocked out, and then I start chopping time into 15 minute segments… madness. And I find myself spending way too much time trying to optimize which day and time each thing needs to happen on. Time trap.
• Defect trackers, e.g. JIRA, FogBugz. If you have a defect-tracking list that’s separate from your feature-tracking list, it’s easy to ignore, because it’s one more thing to pay attention to. Plus you have to continually make arbitrary decisions about whether something is a defect, a feature, or in between (“by design”, “spec bug”, etc.). This is a waste of everyone’s time… who cares what you call it, the question is “are you going to do it, and if so, when?” What’s more, the same people who build features are usually responsible for fixing bugs. So I try now to avoid the disconnect by using Pivotal, which combines “bugs”, “features” and “chores” into a single work list.
• Project schedulers, e.g. Microsoft Project, or Excel for critical paths. Gantt charts and the like are pretty, and the promise of accurate schedule prediction is enticing. But they’re a lot of work to build and maintain, and they rely on people being good at estimating work, managing risk, predicting uncertain future events, and sticking to commitments. In my experience, most people (myself included) are not very good at any of those things. So project schedulers lead you down the path of building a beatiful house of cards, only to have to reconstruct it every week or two when schedule predictions are inevitably proven wrong. They are good only for point-in-time “aspirational” planning, IMO. Some projects do need this (building a new airplane, say), but I’ve found that many do not.
• Task lists and To-Do’s, e.g. in gmail, Microsoft Outlook, Things, Basecamp, etc. These tools encourage you to break goals down into fine-grained tasks, which you then prioritize and check off when they’re done. I find I tend to put way too many things on task lists, at which point I promptly get overwhelmed with analysis paralysis. Not for me.[2]

As a rule, when I find myself spending more time organizing the work rather than immersed in doing the work, I have a broken process. At that point I stop, hit the reset button, and start over. The tools I’m using these days are great assistants: they help me arrange my plan, and then they step quietly out of the way.

Thanks Ilia for the nudge to write this.

[1] Outlook/Exchange calendaring was an essential tool for me in my last few years at Microsoft, because most of my workday consisted of meetings. But even so, I used the calendar way too much. Better to leave some ad hoc unscheduled time in the day. Give serendipity a chance.

[2] I’m not sure why I find Trello so much more pleasurable than any of the task list and to-do list alternatives. After all, Trello is at its heart a list-making tool. Perhaps something subtle in its design helps me “chunk” list items at a more appropriate granularity. I’ll have to think more on that.

“How will I pay the bills?”, you might ask. “What if it all goes wrong?”  ”How will this look on my resume?” “What will my friends think?” “Will my family understand what I’m doing?”

Well, to the last of those, I will answer “probably not”. Unless you come from a family of entrepreneurs, your fam will probably have no clue what you’re doing. This will make for lots of awkward holiday dinner conversations. Oh well.

Will you have to take a pay cut? Probably. In exchange for your Stable Corporate Salary you will get to work on an idea you are passionate about, in a work style you own, with a chance at more long-run financial upside. If that tradeoff of short-term money for immediate happiness, immediate control, and long-term financial potential sounds bad to you, stop now.

As for the optics, I guarantee you will become a more interesting person, both on paper (your resume) and in the eyes of your friends. You will be learning new things, meeting new people, stretching yourself. Simply by taking this risk you will be markedly different from everyone in Corporate World. If you go back, you will be noticed. And that’s a good thing.

Lastly, what if it all does go sideways in Startup World? Consider this: when you exit a stable job in which you’ve done well, it’s highly likely you can turn right back around and knock on the door you just stepped out of. All those people you just said goodbye to like you. They miss you. They might even envy you. And they will be happy to see you again.

Pretty good worst case, no?

Don’t be afraid of the start.

For a brief while, somewhere around beer number three, I had a flashback to 2005 when I moved to Toronto. Things were very quiet in the tech startup scene. Ruby on Rails was just starting to take off. DemoCamp had yet to begin. Lots of smart people were building things with software here, but most of them worked out of IT departments in office towers on Bay Street. The only “tech startup” people could commonly name was RIM, and it was already 10 years old and publicly traded by then.

Things have changed. A lot. There were over 100 attendees at Unspace HQ last night, with at least 20 employers pitching their companies, all vying to hire Ruby developers. I saw a lot of familiar faces, but also many new people I’d never met before. And pretty much every employer in the room was representing a startup. Joey de Villa was there from Shopify. Paul and Geoff from CommunityLend. Katherine Hague and Phil from ShopLocket. William and Bart from Engagio, freshly funded by Fred Wilson of Union Square Ventures. Paul from GaggleUp. Krista and Aidan from Winston. Mike with his University Health Network project. Startups everywhere.

That says a lot about Ruby on Rails; it’s clearly got great traction in the web startup space here. It also says a lot about Toronto and the community that has grown here around Ruby, Rails, and web startups. The barriers to creating startups are coming down. Starting a company is now much more socially acceptable here, desirable even. Designers and developers who want to be true craftspeople increasingly “drop out” of mainstream IT work to join startups. Technologies like Ruby, Rails, git and Heroku continue to reduce the cost of building and deploying great web software. And, at least from my little corner of the web, the local demand for web developers and designers seems to be at an all time high. All subjective, I have no hard numbers to offer, but I believe it’s real.

The startup scene in Toronto is really taking off.

I love that fact.

Much of this has come about organically, due to these enabling factors kicking in at the same time. But it really struck me last night that the community piece is different. This community didn’t just spontaneously assemble itself and become awesome overnight. Instead, a small handful of very diligent community builders, most notably Pete Forde, Meghann Millard and their amazing crew of coworkers at Unspace, worked hard and gave freely of their time and energy to help seed and build this. Free advice. Encouraging pats on the back. Rails Pub Nites. Technologic. Ruby Fringe. FutureRuby. Ruby Job Fairs. Friendship, even. They have done a ton to foster and ignite the web startup community here in Toronto. And they continue to do so.

So I will say it here, and hope others repeat it: Thank you, Unspace. You are doing great things for Toronto. We are proud of you.

#ThanksUnspace

Update 2012-02-13: Fred Wilson personally funded Egagio. The funding is not from Union Square Ventures. Thanks William for the correction.

I spend a lot of my waking hours trying to create nice things with software. I care about my efficiency, both in the short run and the long run. It’s my time I’m burning, after all… it’s finite. And so the topic of creative efficiency has been on my mind lately.  I think it’s a vital topic in the creation of many different sorts of things — design, software, food, movies, and books, for starters — but I’ll stick to my knitting here and write just about software.

There seem to be two different schools of thought in software development: let’s call them “Pay as you go” and “Buy now, with no money down!”. (Yes, with an exclamation mark.)

Tech industry rags like TechCrunch like to publish stories in the “Buy now, with no money down!” category. They tend to run something like this:

I was sitting around the other day inventing awesome ideas like I do. As usual I came up with some exceptional stuff, and this time I chose one of my particularly outstanding ideas and decided to go for it. Since I am already doing an 80-hour a week job at Amazing-Company.com I figured it was no big deal to do a little more on the side. I asked three of my favorite genius buddies to go in on it with me. We got all stoked up on <favorite energy drink>, busted out <latest shiny hipster technology> and started working all-nighters and weekends. A couple of weeks later, bingo! Out popped our killer app. We knew it would be awesome, but damn if it isn’t even more more awesome than we planned! We’ve already sold 3 million copies on <App Store | Android Market> and the traffic from TechCrunch and Hacker News brought our site to its knees. And that’s just the MVP, yo. We took a 2-hour break yesterday and now we’re working on version 2.

Horseshit.

Stories like this probably drive a lot of ad revenue, but they are misleading, at best, and damaging, at worst, for people who actually want to create something good. Here’s why:

Unicorns are rare: First off, we would all love to work with geniuses who consistently churn out large amounts of production-quality code in short amounts of time. I’ve had the pleasure of working with a few people like this. They do exist. Alas, they are only slightly less rare than unicorns. And they tend to be quite selective about what they want to work on. So while you should certainly seek smart people to work with, don’t peg your business plan on hooking up with a bunch of geniuses, ‘cuz it probably ain’t gonna happen. (Dear reader, if you are a genius-unicorn-type-person, please stop reading now and email me as I’d love to work with you on my next awesome idea. Seriously.)

Hero-working sucks: Secondly, the “hero” work method is painful and usually long-term-bad, for reasons I outline below. For every company that succeeds working this way there must be hundreds who fail. Popular media tends to skip over those failures and glorify / whitewash the successes.

Here’s the classic “Buy now, with no money down!” storyline, as commonly found in popular press: Round up some unicorns geniuses. Incent them to work as many hours as humanly possible. Fuel them with food, drinks, money, candy, bacon, apples, hay… whatever motivates them. Set hardcore release dates and explain repeatedly and heatedly how vital it is that the dates are met. Ship. Repeat. Massive success!

So exciting!

Unicorns! Hardcore release dates! Bacon!

And here’s how it normally plays out in reality: due to a curious shortage of unicorns geniuses, management reluctantly hires merely-smart people, wishing out loud they were smarter. Managers amp up the reality distortion field and succeed in convincing everyone to work a lot. Perhaps they are lucky and the initial product release gets out the door quickly. And if they’re really lucky the product will work for a while. But they eventually discover that under the intense pressure and grueling work conditions they’ve created, employees have…

1. Made more mistakes.
2. Cut corners on quality. Most commonly, by testing only manually, instead of writing automated tests. Or by pushing half-finished code under the carpet, hoping it won’t be found until much later.
3. Hacked and flailed at the code until it works, instead of building it to last.
4. Lost motivation.
5. Gone emotionally flat. (Burn-out = numbness.)
6. Disengaged with the job/team/workplace.

This is why I call it, “Buy now, with no money down!”. It’s equivalent to taking out a high interest loan, in that there’s never a convenient time to pay it back, you must eventually pay, and the payback really hurts.

So what does payback look like? More time to fix bugs, fill in the gaps, and rewrite shitty code when you want to upgrade and extend the system. More time to rehabilitate, re-recruit, or replace burnt-out and demoralized employees. And more cost scrambling to retain pissed-off customers and acquire new ones.

I’m not making this stuff up. For real-world examples, read the Steve Jobs bio. Steve worked exactly this way.

The two exceptions I can think of where you don’t have to pay off the loan are toy apps, i.e. software that is trivially simple, and throwaway code, i.e. code you will use for only a very short amount of time and then archive or sell to a naive buyer.

So what’s an alternative, you ask?

• Hire good people. They don’t have to be geniuses, but they do have to be smart. You should be able to find people who are instinctively driven to get the right thing done, have great potential, and have passion for the work itself.
• Invest continually in good, simple design. One should always strive for this, but it takes time, money, and skill (hard to find). This makes it tempting to underinvest in design and just skip straight to writing code, especially if you yourself know how to code. That’s usually a mistake. Story for another day.
• Build atop existing successes. In software, this means things like (a) making smart choices in platforms and tools; (b) avoiding Not Invented Here syndrome; (c) copying/cloning, existing successful patterns, which can be very effective, but doesn’t obviate you from the need to differentiate your product.
• Bake in quality up front, when you build it, instead of deferring problems to be fixed later. A big part of this is testing the product, both manually and with an automated test suite. Features aren’t “done” until you’ve built repeatable automated tests.
• Take the time and care needed to keep things simple as the project grows. This means reusing and refactoring code you’ve already built, cleaning up messes you make along the way, fixing performance bottlenecks as they come up, and so on. It’s like weeding a garden.
• Work at a sustainable pace. When you must, burn the midnight oil, but only as a band-aid for emergencies, i.e. urgent unplanned work. Don’t do this as part of your normal plan.
• Use historical data to predict what your future velocity will be

I call this approach “Pay as you go”. I’ve found it to be a more humane and efficient way to work, both in the short term and long term. I aspire to work this way. I am getting to be OK at it.

Some people will scoff at this and call it too idealistic or unrealistic. “By the time you get your v1 out, your competitor will already have locked up all the customers”. Investors and execs may ask, “why aren’t we moving as fast as Competitor X? Are you guys just being lazy?”. It does require more trust: you have to place faith in the product team, trust their estimates, and trust that they are working as hard as they can to build a great product, even when you don’t see them sweating bullets. Or building a pile of empty Red Bull cans on their desk. Or punching in 12-hour days, 7 days a week.

But it can yield great benefits. You’ll probably build a better quality product, for starters…  a product customers will be more likely to love. You accrue less technical debt in the codebase.* You can ramp up new employees quickly because your system is clean and simple. Your employees aren’t burnt out, and they like the work. You can predict with honesty and higher precision when you’ll actually ship something new that you’re committing to, because nobody is lying about dates, or lying about quality, or about to quit. And your test suite enables you to add new features with fairly high confidence that you aren’t breaking existing stuff. Long term, you come out ahead.

There’s more; these are just the highlights.

Pay as you go may not be as glamorous as “Buy now, with no money down!”, and it may not get you written up in TechCrunch. But it’s achievable, and affordable too.

*  I’m not necessarily saying to shoot for zero technical debt… zero technical debt is often a silly and suboptimal goal. But carrying only a low amount of debt is good, because it enables you to move forward at consistent speed instead of being forced to stop for a month or two to fix bugs.

When someone asks what I do, I explain this. Inevitably the response is a long, blank stare, followed by one of:
- Are you out of your f’ing mind?
- Why are you doing this to yourself?
- How do you handle working on three entirely different startups?

Assume for the moment that I have good reasons for doing this, and that I may or may not be insane. Let’s talk about “how you do it”.

First of all, I try to choose very carefully what to work on. I want to work only on things I am passionate about. I like to build things I can honestly be proud of. And I aim to surround myself with people I really like and respect. After all, life is short… all else held equal, why would you work on a project you don’t really like, or produce something that customers/consumers don’t really like, or work with bozos? You’d have to pay me an immense amount of money to do that.

I’ve been fortunate to find coworkers who are willing to work with me in this way. More on that later.

I’ve been fortunate also to find projects with synergy. These are all software-based projects. My role is similar on each one: I own definition and delivery of the product, meaning the product plan and everything it takes to get it designed, built, and operating. I’m using many of the same technologies on each project, so that switching from one project to the next costs me very little time. I use many of the same processes and tools (git, Pivotal Tracker, et. al.) And most of the things I learn on one project apply well to the others.

I structure my time carefully. My weekdays generally look like this: up by 7:00; breakfast; chase 3-year old around until she is dressed; commute; daycare dropoff, some days; daytime work hours; read news during lunch; daycare pickup, some days; dinner / family time / playtime; bathtime; bedtime stories; and usually some 9pm to midnight work. Notably missing from this routine: exercise; sufficient family time; sufficient free time to think; margin for error. (Hint: you should not do what I am doing.)

Mondays through Thursdays are CampusPerks days. Fridays through Sundays I reserve for my other two projects. Urgent stuff like service outages interrupt my routine, but this is rare… all of these web sites rarely go down because I write bug-free code. (Little programmer joke there.) Firewalling projects from each other in this way is vital; without this approach I would be too mentally fragmented, and unable to reach a state of flow on any one project.

I also try to be draconian with my time, by which I mean things like being frugal with commitments, saying “no” to most new opportunities and requests (thus avoiding death by a thousand cuts), and avoiding distractions that fritter away time (cable TV, I do not miss you, not even one little bit). That said, I wish I had more time. I miss saying, “yes”. When you have a child, especially, you desperately crave more time to say “yes”.

I try to chunk work into small batches: my tasks take a few hours or at most one day, instead of days or weeks. There are so many reasons to do this, but three biggies are that you get more flexibility in choosing what to do next, you learn quickly whether you’re doing something well, and you get frequent satisfaction from finishing something. “Small batches” is something I’ve only recently learnt about, and now I’m trying hard to double down on it. I’d like to write more about it a different day.

I separate my workspaces too. Two different office spaces, three different web browsers, three different gmail accounts (one for each project), and so on. One computer, though. Many backups.

There’s lots to improve in all this, of course, but… it’s working. I’m making forward progress, a little each day. And managing to have fun while doing it.

What’s hard:
- Saying no
- Remembering passwords
- Remembering which services/accounts to use for each project
- Staying focused on doing the right thing next
- Keeping energy levels up and consistent
- Being entirely present on the task at hand (see: energy)
- Having the patience to be a good parent, coworker, etc. (see: energy)
- Exercising
- Carving out time for play (I try to remember: having the time and means to play is one of the reasons I do all these other things!)

Busy. Fun. Busy. Fun. Busyfun.

I’ve been a terribly inconsistent writer on MyOwnPirateRadio over the years. I’ve written sporadically. I’ve written snotty rants, mind-numbing trivia, and esoteric technology crib notes. I’ve written about completely random and unrelated topics. In short, I’ve written so poorly that only my most patient, masochistic, and excitement-starved readers are still around. (Hi, mom! Oh, wait, she doesn’t have an internet connection.) So, dear reader(s), I’m sorry. I apologize. I’ve been a shit.

But I do want to write — it makes me happy — and so I’m going to start again.

I will write about one topic:

Life trying to get startups off the ground.

This will not be “How I succeeded at getting my startup off the ground”, or “My genius recipe for gobsmacking success in startup life”, or, ”How I built and sold my company for $10M in just 3 months with only 8 toothpicks, a pair of tweezers, and a tenth of my staggeringly massive brainpower, bitch”. This is not one of those blogs. Gloating will be kept to an absolute minimum. I intend to write more in the vein of “How I’ve worked like crazy on too many projects at once for 5+ years with little to show for it except a much smaller bank account, a bunch of hard-earned lessons, and a smug sense of satisfaction. Please send help.”.

I will write as openly and honestly as I can.

I will try really hard to write regularly, at least once a week.

I will spend no more than 30 minutes writing a post.

I will avoid the temptation to portray this lifestyle as glamorous. ‘Cuz it ain’t. Read me?

And I want to feel good about doing this. I have a lot of “priority guilt”… why write blog posts when I should be writing code, helping out at home, doing some exercise, or becoming a better husband and dad? I also fear the embarassment of screwing up in public. But I’ve come to grips with a few realities: I need to write; my privacy is largely an illusion anyway; and I’m much less interesting to everyone else than I like to think.

I’ve put off starting this for a very long time now, so I’d better post this before I manage to stop myself again.

So here goes: Startup Fever. Wish me luck.

P.S. How Canadian of me, to start off with an apology. Represent!

Unlike Bamboo, Cedar does not offer Varnish as a reverse proxy cache, nor does it automatically gzip content. You need to do it yourself. Heroku recommends:

1. Use memcached, with Dalli as the memcached client. Make sure to follow the Rails 3 section.
2. Use Rack::Cache as a substitute for Varnish. Heroku links to this article which explains how to integrate Heroku with Rack::Cache. I couldn’t get it to work, so I hunted around and pieced together the folllowing riff.

require 'rack-cache'
My::Application.configure do
...
  # Enable Rack::Cache
  config.middleware.use Rack::Cache,
   :metastore => "memcached://#{ENV['MEMCACHE_SERVERS']}/meta",
   :entitystore => "memcached://#{ENV['MEMCACHE_SERVERS']}/body"

You can also set HTTP headers in production.rb as follows. (3600 is an example value, make this whatever you want.)

# Add HTTP headers to cache static assets for an hour
config.static_cache_control = "public, max-age=3600"

And you may want to add this to your config.ru to get gzip working:

use Rack::Deflater

References:

I just finished watching the videos of you launching Pressly at TechCrunch Disrupt. Well done. You and your team should be really proud of what you’ve achieved.

I wish you’d been given more opportunity to elaborate on your strategy to win. Instead you had to spend most of the Q&A time defending Pressly’s raison d’etre to Dustin Moskovitz et. al. That was unfortunate; deck stacked against you. But you did a nice job staying the high road and giving solid answers to the skeptical questions.

Jeff, I loved your comment about publishers being great at telling stories, and not so great at building technology innovations to deliver those stories (in compelling new ways, with compelling profitability). It’s true. And it’s good, I think, that Pressly is joining a cadre of other players in this same space. Existence of multiple players is proof that the market is ready. And publishers need lots of options right now, especially ones that let them do fast, cheap experiments. Pressly can help them do that.

I suppose controversy-seekers could frame this as “walled garden versus open web, round 2″. That was my very first thought after watching the video. But that isn’t really the case, is it? Neither the iPad/App Store ecosystem nor HTML is going away anytime soon. There will be multiple winners in this market, with multiple technology bets. Consumers will buy many different kinds of devices, and consume content in many different places and ways. It’s probably more accurate to compare Pressly’s space to the blogging services market back when it was just getting going: Blogger, WordPress, Movable Type, and so on. Lots of experimentation and diversity, with consolidation down the road.

My biggest takeaway on all this is that Pressly makes a lot of sense from a publisher’s point of view. Publishers are losing sleep over how to follow their audiences to digital devices without abandoning all the assets they hold dear: their brand, destination websites, exclusive content, and UX. And with limited capital and time/runway remaining for technology investment (or investment of any kind) they have to be brutally frugal and thoughtful about what bets they make. Pressly has good answers on the economics (very little cash up front), the technology (more open), the user experience (niiice), and control issues. Clearly The Economist and Toronto Star think so, and I bet many others will reach the same conclusion.

I hope Pressly does really well.

Let me know when I can buy some shares.

osh

I couldn’t find a way to do it with Facebook’s Graph API, but there’s good support for it in the FQL API. You can craft up queries by hand, as shown below, and issue them right from your web browser. The response is an XML document with the statistics for the URLs you want to know about. There are also FQL wrapper libraries in several languages… for Ruby I had some success with the fb_graph gem.

Multiple URLs example:

https://api.facebook.com/method/fql.query?query=select  url,like_count, total_count, share_count, click_count from link_stat where url in(“http://bing.com”, “http://google.com”, “http://facebook.com”, “http://twitter.com”)

Single URL example:

https://api.facebook.com/method/fql.query?query=select  url,like_count, total_count, share_count, click_count from link_stat where url = “http://bing.com”

Within the XML results, the “total_count” attribute is the number shown within the Facebook Like widget.

Docs:
http://developers.facebook.com/docs/reference/fql/link_stat/
http://developers.facebook.com/docs/reference/fql/