I think the biggest flaw is the assumption that each day must stand on its own. I'd say that its generally much cheaper to make one big meal than to try and make 3 individual meals, but there's no attempt to create large soups or chilis or something in which you CAN use fractional prices because the final product will last several days or can be frozen.
Ironically, the first two of the "four livelihood-threatening fundamentals" that the Lean Startup methods distracted them from are pretty much verbatim parts of the Lean Startup method.
That caught my eye too.. perhaps it's because laptops are designed with being carried around in mind? Or, to draw on the other conclusions from the paper, because laptops generally have lower-frequency chips (and for that matter, slower memory and disks too)?
Interesting stuff. You can improve reliability by running your system at a lower speed. Here's a blog post with a summary of some of the conclusions of the paper above: http://grano.la/blog/2012/06/improve-the-reliability-of-your... (Disclaimer: that's my company's blog)
One question I still have is whether the switching of CPU frequencies has any effect, or if it is only the average speed that correlates to the reliability. Anecdotal evidence suggests that this is the case, but it could be an area for further research.
The promise of the web (and I suppose, most web services) is/was to make our lives easier, smoother, and better, but it seems like each new app or service I use takes a little more of my time rather than a little less.
I personally feel like the slow web movement is at it's heart about using the web for its purported purpose: streamlining communication pathways instead of creating new ones.
Most of the interviews I've given are broken down into two sections: does the candidate have an effective baseline understanding of the technologies involved in the proposed job, and can they apply that understanding to complex problems?
If a candidate says "I don't know" during the first part, it's a sign that they will flounder during the second part. However, I usually guide the questions to try and actively FIND the "I don't know" point for the second part, as it helps me establish the boundary of their abilities.
I haven't looked at HMOs, and I'm really skittish about the idea of going without. I'm currently thinking catastrophic + HSA. Though I'm in my mid-20s and generally in great shape, I've had a couple friends who had really serious medical problems, so I've got some availability bias working against me.
Using the ternary operator is more "eloquent" than conditionals? That's true iff "eloquent" means terse in terms of number of characters, but I find if(...){} much more readable.
Then I will be porting my projects over to Requests very soon :)
It's pretty easy to implement, as it already works at the lower (socket) level with the ssl module, it just hasn't made it up the stack into urllib2 (or Requests..yet!).
I love Requests, but it would be really nice to have some Python libraries with cert-verified SSL support. I've hacked SSL support on top of urllib2 for my projects at work (https://github.com/josephturnerjr/urllib2.VerifiedHTTPS), but it'd be really nice if libraries started prioritizing secure communications as a first-order requirement.
Less so for b2b, but during product development a third way is to reduce the length of the runway itself by making sure developer resources get applied to their core problem: development.
For us, that meant things like paying a relatively small monthly amount for services that would otherwise have to be administered by our development team: things like repo/wiki hosting (github) and website administration (rackspace). If you consider that every hour of developer time costs the company $25-$50+, these services make a lot of purely economical sense as well.
Additionally, the author of the article is potentially weeding out the exact people his company is looking for. Some (myself, as an example) are passionate about what they do for their job, to the point where they do development on work projects in their spare time. Presumably that person is better than the aspiring OSS developer who grinds their job for 8 hours only to go home and work on their pet project.