Adam Wiggins

In 2006, I wrote Catapult: a Quicksilver-inspired command-line for the web. I deployed it to a VPS (Slicehost), then gave the URL out to a few friends. At some point I stopped using it, but some of my friends remained heavy users. Two years later, I got an email: the site was down. Logging into the server with ssh, I discovered many small bits of breakage: The app's Mongrel process had crashed and not restarted. Disk usage was at 100%, due to growth of logfiles and temporary session data. The kernel, ssh, OpenSSL, and Apache needed critical security updates. The…

Visibility and introspection capabilities are critical for managing and debugging real-world applications. But cloud platforms are often lacking when it comes to visibility. The magical black box is great when it "just works," but not so great when your app breaks and you can't look inside the box. Standard introspection tools used in server-based deployments — such as ssh, ps aux, top, tail -f logfile, iostat — aren't valid in a multi-tenant cloud environment. We need new tools, new approaches. Heroku's new runtime stack, Celadon Cedar, includes three powerful tools for visibility and introspection: heroku ps, heroku logs, and heroku…

Node.js has gotten its share of press in the past year, achieving a level of attention some might call hype. Among its touted benefits are performance, high concurrency via a single-threaded event loop, and a parity between client-side and sever-side programming languages which offers the Promethean opportunity of making server-side programming accessible to front-end developers. But what is Node.js, exactly? It's not a programming language – it's simply Javascript. It's not a VM: it uses the V8 Javascript engine, the same one used by the Chrome web browser. Nor is it simply a set of libraries for Javascript. Nor is…

In the beginning was the command line. The command line is a direct and immediate channel for communicating with and controlling a computer. GUIs and menus are like pointing and gesturing to communicate; whereas the command line is akin to having a written conversation, with all the nuance and expressiveness of language. This is not lost on developers, for whom the command prompt and blinking cursor represents the potential to run anything, to do anything. Developers use the command line for everything from starting a new project (rails new) to managing revisions (git commit) to launching secondary, more specialized command…

Ruby 1.9.2 on Bamboo is now the default for new apps created on Heroku. As we said back in April: Ruby 1.9.2 as the new gold standard for production Ruby apps. In 2011, we’ve seen more and more developers move to 1.9.2. It’s fast, stable, and sees excellent support throughout the community. You can always list available stacks with the heroku stack command; and if you want your new app on Ruby 1.8.7 you can run heroku create –stack bamboo-ree-1.8.7 to explicitly ask for the older stack.

In December, we rolled out the public beta of a sweet new logging system for Heroku. The new system combines log output from your app’s processes and Heroku’s system components (such as the HTTP router). With all of your logs collated into a single, time-ordered stream, you get an integrated view of everything happening in your app. Here’s a sample: $ heroku logs 2010-10-21T14:11:16-07:00 app[web.2]: Processing PostController#list (for 208.16.84.131 at 2010-10-21 14:11:16) [GET] 2010-10-21T14:11:16-07:00 app[web.2]: Rendering template within layouts/application 2010-10-21T14:11:16-07:00 app[web.2]: Rendering post/list 2010-10-21T14:11:16-07:00 app[web.2]: Rendered includes/_header (0.1ms) 2010-10-21T14:11:16-07:00 app[web.2]: Completed in 150ms (View: 27, DB: 121) | 200 OK…

The improved maintenance mode we described last month is now standard for all existing and new apps. This new maintenance mode is faster and much more scalable, particularly for apps with more than fifty dynos. It handles maintenance mode at the HTTP router, providing an instantaneous response for turning maintenance mode on or off regardless of the size of your app. It uses a standard page which serves with an HTTP 503 code. (If you preferred the old maintenance mode, you can manually add it to your app by installing this middleware and setting a MAINTENANCE config var.) Read the…

When your app is crashed, out of resources, or misbehaving in some other way, Heroku serves error pages to describe the problem. We also have a single page for platform errors, once known as the ouchie guy (pictured right). While the approach of showing error information directly via the web has worked well enough, there was room for improvement on both developer visibility and professionalism of presentation to end users. With that in mind, we’ve reworked our approach on error handling, making improvements that should make it much easier for you, the developer, to diagnose and correct errors in your…

Access to application logs on Heroku has historically been one of the least usable functions of the platform. The “heroku logs” command was nothing more than a broadcast fetch of the logfiles for every web and worker dyno in your app. This worked ok for small apps, but the user experience became very poor once you got past five or ten dynos. I’m incredibly excited to announce that today we’re rolling out the public beta of our new logging add-on. This is a whole new way of capturing and collating logs, based on a syslog routing layer we’ve dubbed Logplex.…

When a team of developers uses continuous deployment to deploy to their Heroku staging and production apps multiple times per day, having a record of what was deployed and when can be very valuable. This is especially true when bad code gets deployed: being able to recover quickly from failure is a key part of any agile process. Today, Heroku is announcing our release management add-on. When installed on an app, every code deploy is recorded in a ledger with information about who deployed, when, and what commit hash. And it’s not just code: anything that changes the app environment,…