briandoll

This might be awesome. Arizona's discrimination laws are offensive and annoying. Their own government are essentially trolls to society.

Governments don't operate by the third law of robotics (http://en.wikipedia.org/wiki/Three_Laws_of_Robotics) so perhaps it's possible for this law to take effect and for it to instantly outlaw themselves. Sweet!

I feel the need to point out that regardless of how you're "pre-warming" the cache, you're missing the primary benefit of page caching.

By default, Rails' page caching persists to disk. An immense advantage of this solution is that you can use your web server to serve these pages directly, without ever hitting the Rails stack.

You're saving the page generation time, but you're still hitting the Rails stack + Redis for every single page request, both of which are entirely unnecessary.

One nit: "considering the loss of the convenience of mouse input"

You can get full mouse support in tmux/vim.

I recently read the tmux book by the pragmatic programmers and highly recommend it: http://pragprog.com/book/bhtmux/tmux

It's short, well written and contains lots of essential configuration tips to get not only mouse support but also system copy/paste on a mac. Here's my tmux.conf if you're curious: https://github.com/briandoll/dotfiles/blob/master/tmux.conf

Besides being an awesome post on both the business reason for this implementation as well as details on their solution, this is a perfect model for how companies use and contribute to open source software.

Etsy wins, Etsy customers win, and now everyone who uses Solr and ttorrent wins too.

If you dig this, you'll want to check out Safecast.

Safecast (http://blog.safecast.org/) is "a global sensor network for collecting and sharing radiation measurements to empower people with data about their environments." They are working on some really awesome tech and helping people in Japan.

Evan Weaver (systems engineer at Twitter) put together a great list of distributed system papers as well. His list is categorized and every paper in it is awesome.

distributed systems primer: http://blog.evanweaver.com/2009/05/04/distributed-systems-pr...

distributed systems primer (update): http://blog.evanweaver.com/2010/08/12/distributed-systems-pr...

IMHO, a key reason this works well for them is that their compensation package is really nice and well rounded: http://www.joelonsoftware.com/articles/fog0000000038.html

In short: they pay market rates based on a transparent internal system of scale, they have a generous profit sharing plan (thus motivating everyone to increase profits regardless of role) and excellent benefits (health and non-health related).

It's hard to argue against a system like that.

:set autoread

By the review, this sounds like it could be a great book. I've read, err skimmed, plenty of R books including the official documentation. Everything I've read so far about R was quite obviously written for a different audience. This seems to be aimed at telling visual stories with data, which is the only part of R I've ever wanted to learn.

Oh dear science, somebody just reinvented FormMail.pl from Matt's Script Archive.

Agreed. I just converted my blog (a trivial example) to Foundation with an intention of spending time supporting tablets and mobile browsers. I spent maybe 10 minutes adding in the media queries and css tweaks and everything else fell into place.

I'm looking forward to using Foundation on bigger projects.

I love that Amazon continues to explode our previous model of computing. The entire ecosystem of PaaS providers that are built on top of AWS benefit from these advances and Amazon wins by continuing to be the platform to build a PaaS on top of.

While I'm sure it's not their aim, the AWS console and associated web interfaces are functional but have pretty terrible user experience. It's as if AWS has found this perfect customer fit... build awesome tech, build an interface just-barely-good-enough to administer it... foster the ecosystem of providers that make your tech easier to use... rake in the cash because at the end of the day everyone is running on AWS regardless of who charges their card.

Absolutely. I wrote about this last year (Engineers- build businesses not apps: http://emphaticsolutions.com/2010/12/10/build-businesses-not...) and yet I don't think we can say this enough.

This is one of the primary values found in the essence of the lean startup movement. Customer development can not be overlooked. Business models can not be overlooked. Building apps is easy, building sustainable businesses is hard.

Reading on, "Open sourcing it would mean thousands of people worldwide could use it to build interesting Git tools, creating an even more vibrant Git ecosystem."

Awesome Git bindings to Ruby are critical to the functionality of Github, but a vibrant Git ecosystem is essential to its success. Business value trumps technical implementation.

In fact, Tom also mentions the libgit2 library that Github is working on, and may even replace some of what they use Grit for today.

Another point: Zurb recently open-sourced their CSS/JS framework that they use to build all their client sites/apps with. They have spent years making it awesome. It's a major part of the material goods that they hand over at the delivery of a project. After it being opened up on Gitub, they've seen lots of great feedback, bug fixes and enhancements. I'd also bet they've seen an increase in new clients. What they wrote is awesome and now they are known to many more potential customers as being the people who know what they are doing.

Business value trumps technical implementation.

I just posted the latest State of the Stack for Ruby.

http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-rub...

It has: - A breakdown of ruby versions - A chart showing the changes to ruby versions deployed since Rails 3 came out - A breakdown of rails versions - A breakdown of ruby dispatchers - The top 50 gems and top 50 plugins

At New Relic, we've published a report like this about once a quarter for the last few years for the thousands of Rails apps that monitor with us.

We included information on Ruby version, Rails version as well as popular gems and plugins.

You can see previous stats here: http://railslab.newrelic.com/

I'm working on publishing the next report, which should be out this week.

I personally rarely ever log into Facebook, so perhaps if you're closeness to the platform is from arms length too, I can see where you might be missing the news.

Let's use photos as an example to demonstrate the power and size of Facebook. This infographic shows the scale of photos stored in the Library of Congress, Flickr, and Facebook: http://s3.amazonaws.com/fromus/blog_posts/largest_photo_libr...

I work at New Relic, so I see a lot of companies (startups and otherwise) that have apps deployed on Facebook. The traffic they get is _insane_ and I don't see any indication that it's slowing down.

Games are an obvious category where Facebook dominates, but they are quickly becoming an obvious destination for new apps to launch, given the access to their social graph and the viral nature of the apps in general.

This isn't about hosting. This is about creating a living Facebook app in 5 seconds.

This is pure win. The screencast on this post shows that with one click you get a deployed app (in the language you choose) that ships with an app template that uses the Facebook APIs to get you started.

We're witnessing a Facebook app that creates real living Facebook apps. Heroku continues to impress with insanely easy onboarding of folks new to deploying web apps, and building features the way things should work.

It must be amazing to start programming in the age of Heroku.

I love Steve Blank's definition of a startup: A startup is an organization formed to search for a repeatable and scalable business model.

With that definition, we can assert that a startup is no longer a startup once they've found that repeatable and scalable business model.

We (New Relic) added a high-level "How It Works" video to our site during a recent redesign. Anecdotally, I know that many of our newer customers did watch the video and found it helpful in understanding our product.

We also use Olark chat on our site, which besides giving us the ability to chat with our customers easily online, we can see what pages the customers are visiting in real-time, during our chat. I've chatted with scores of customers this way, and it's typical for most every user to jump all around the site to get a good feel for 'how it works', 'what it does' and 'how much does it cost'. It's helpful if you have an obvious "sign up" link incorporated on every single page of your website, so no matter where on your site a customer decides they want in, they can do so easily.

I can say that adding that video did not hurt conversion, but it also didn't substantially increase conversions either. I do still think it's an important aspect of any new online service, regardless of your implementation (video, graphical, text).

(Disclosure: I work at New Relic)

New Relic is made for monitoring web apps, so I can't imagine anything better suited for your needs. We also have partnerships with most of the hosting providers, so you're likely to be able to use New Relic Standard service for free.

The basics: http://newrelic.com/ Top partners: http://newrelic.com/about/partners

Good luck on your launch!

I like the options to control the size of the 'IDs' and the charset used.

I wrote something like this a few years ago called 'acts_as_hashed' that as you might guess, uses a hash function to come up with a unique non-sequential identifier. https://github.com/briandoll/acts_as_hashed

Congrats to Chad and to Etsy. He's created what appears to be one hell of a great engineering culture that has helped to nurture a great community culture.

He gave a keynote at RailsConf this year about engineering for happiness, which is worth the watch if you haven't seen it: http://blog.chaddickerson.com/2011/05/20/railsconf/

I'm very excited to see Zed working on this. This exercise-driven tutorial format seems efficient and practical, but what makes this really stand out is Zed's approach to the overall goal.

I greatly appreciate an 'opinionated' programming book. I've probably heard more debates on formatting and style for C than any other language.

Every application and environment is different. The great thing about cloud providers is that they are so easy to get up and running. Test it out! Benchmark your app in both environments and compare how it performs. Weight the costs/benefits of both solutions (not just in terms of performance, but also in maintenance, friction to change, etc.) and go from there.

I was at devopsdays in Mountain View CA a week ago and one of the panel discussions was on package management. I was a bit surprised to see it as a topic, as there are numerous known ways to solve the problem.

It turns out, that's exactly the problem. The topic was hotly debated and yes, there are endless possible ways to distribute packages across a large environment.

I think choosing a pattern involves deciding for yourself how secure/auditable you need your environment to be and how tightly you want to couple your deployment process to your current architecture (ie. some package managers only work on some systems, etc.). That will narrow your choices down to a handful, and then you get to dig into the implementation details and decide from there.

Great analogy and well written. We often see attempts at this style of explanation, but we usually fail at one or both of those qualities.

While I wish I saw more of this style of teaching in technical publications, it's admittedly rarely done well enough to convey the point.

Also of note, according to the article they spend $2.5 B on developers (ops likely included in that stat).

Another data point to illustrate that to effect total cost of ownership on a given system, focusing on developer productivity can have a greater impact than operational efficiencies.

Great post. Thanks for the praise of New Relic as well.

I'd love to get your feedback on what use cases you had where we were not sufficient. Given that we've been around for 3 years and this is the first release of your profiler, it's not fair to compare features, but I'd still love to know what metrics tipped the scale toward building this.

Three huge features we offer that it seems like you're currently missing out on are automatic profiling of slow requests (vs. manual profiling), automatic real user monitoring to provide insight into the end-user experience, and automatic instrumentation (vs. stitching profiling code into your app).

We totally agree that it would be nice to see web frameworks embrace the concept of performance metrics and provide hooks that tools can use. Rails is way ahead of the curve here. Starting with version 3, Rails ships with plenty of hooks across various aspects of the models, views and controllers.

I can't help but think that anytime you think you might need a lawyer, you probably do. Personally, I'd get a lawyer to review the contract just so I understood exactly what I'm getting myself into, even if the incubator had been around for ages.

I'll also toss out a personal recommendation for Gabe Levine, who has a blog online about lawyering for makers: http://mylawyergabe.com/