One of my favorite aspects of Mint Digital's work is starting new projects on a regular basis. This lets the team learn from past mistakes, and incorporate the latest design and tech ideas that we've been itching to try out. When we find something that works well, we're able to update other projects with the best new ideas.

We certainly don't kick off each Rails app from scratch. The starting point is BloomBox, our toolbox for building fast, scalable websites. As the project progresses, we learn hard lessons about zero-downtime deployments, front- and back-end optimization, and our development and testing practices.

A few critical pieces of BloomBox tech have made our recent websites noticeably faster and more reliable. These features would also improve our older projects nicely, so we extracted them to gems. These gems solve some common problems, so to contribute back to the developer community, we've released them as open source.

Last week saw the first London Redis meetup, which we were proud to host over at Mint Towers.

We don't want to get involved in Steve Jobs' war on Flash. But just in case he wins (and on current form, who'd bet against him?), we have re-engineered Hemlock, our open source framework for real-time web apps, to work in 100% Javascript environments.

When making a web page load faster, one of the most commonly cited front-end techniques is minimizing the number of HTTP requests. In fact, it's Yahoo!'s number one rule. Each HTTP request is slow; making many requests is very slow.

Until yesterday, one of our in-development applications was routinely taking over 4 minutes to run its full test suite (without running our Cucumber tests). Four minutes per run can pretty easily turn into an hour per day when testing every commit. I was beginning to think that "testing" is the new "compiling".

At Mint, we make some pretty cool websites. We also pride ourselves on the quality of our code. Sites like Landshare, Orange unsignedAct and Sexperience all use technologies like AJAX and JavaScript to make them look good and feel great. But, as with anything in life, adding complexity to something increases the risk of things going wrong.

Until now, we have relied on our eagle-eyed Quality Assurance Police to prod, poke, push and pull our sites ad nauseum in search of these failures.

This is time consuming and error prone, even for our über talented QAs. So, being the geeks we truly are, we thought we’d get a computer to do the leg-work. Consequently I have been working on a little hocus-pocus to bewitch web browsers into thinking a real person is using the site. The result is pretty entertaining: a browser dancing away, apparently all by itself! It also uncovers any errors in the code - but that is less fun.

I had to move the browser so you could see it, but other than that it's all magic!

It's been a long time coming. We've talked a lot about it, we've even teased a little bit, but we're finally there. Today marks the initial release of Hemlock, Mint's real-time web framework, to the public. The open source code is hosted over at GitHub and is available via hemlock-kills.com.

We are extremely happy to finally be able to share Hemlock with you and can't wait to see what you guys build with it.

(Photo by Gary Simmons)

We're at it again. We've stripped off our renowned Mint Digital robes, and we're showing off the goods.

Replace "robes" with "CSS", and "the goods" with "some good HTML". But enough jargon. What happened to Mint's website? Where did that beautiful design go? You're not really naked, are you?

On the 15th October, Mint was confronted with its 10,000th case in FogBugz, an imposing visual landmark of four consecutive zeros across our computer screens. An outsider’s reaction might be that Mint has made a lot of mistakes in the last couple of years. Surely 10,000 bugs in roughly two years for a company the size of Mint Digital must be a bad thing, no?

At Mint, the 10,000th bug is not only a positive milestone, but also a time for reflection on our development process, our accumulation of collective expertise, our desire to involve all team members in all projects. Instead of a liability, it represents on one hand the accomplishment of the volume and diversity of Mint’s work. Perhaps most importantly, bug 10,000 captures the dogged commitment to a process that has provided a practical foundation for Mint’s core values.

Last Saturday, I went to the Gotham Ruby Conference. It was partly sponsored by Google, at their New York offices. They're beautifully set up to handle these kinds of things, with a nice sound system, open wireless, and four big screens for presentations. Overall it was a great day, with interesting speakers, and ample opportunities to meet our fellow New York (and Boston, and Philly, etc) Rubyists. Here's my quick summary of what I saw: