Writing (sometimes)

Early last year the Beanstalk team started an internal conversation on the best ways for a private team to control code quality and minimize the chance of breaking production code with a “bad" commit. As a small team of developers we are not used to formal processes, so the most natural thing was to see what bigger teams do. I started researching code review processes and tools in various companies and was astonished by how different they can be. In retrospect it makes sense — software built for NASA has a much smaller right for an error than an open source experiment built on the side. Here are a few cases I found the most interesting:

It’s a beautiful summer here in Philadelphia and our team started to get tired of all the dark brown backgrounds in Beanstalk. So what can be a better time to give it a slight facelift? Those of you with a sharp eye might have noticed that some things changed this morning.

We’re really excited to announce a new navigation in Beanstalk. It solves a few problems, provides a bunch of improvements and introduces several new features. We’ve been working on it for a while and think it creates a great foundation for our upcoming features.

It’s not unusual to have a flashback to the Netscape Navigator 4 and Internet Explorer 5 days when working on an HTML email. The quality of rendering engines is totally inconsistent, most modern development techniques are unavailable, and even images – an essential element of many emails – are turned off by default in many clients. This can feel like 1998, but the web development community has learned a lot since then. Strategies like progressive enhancement and modern tools like Litmus can help us build HTML emails suited for today’s Babylon of inconsistent desktop clients, various web clients, tablets, smartphones, and high resolution displays.

At Postmark, our goal is to be an extension of your infrastructure – you set it up once and then forget about it. This can cause problems though – while we’re sending your emails with no issues, you aren’t really keeping an eye on problems (like bounces, spam, etc). Yesterday we launched a new major feature which will help you keep track of your servers’ activity without needing to login – weekly digests.

Beanstalk is a mature product and during its’ 5 years of existence the design and UI have been changed a lot. Our CSS grows accordingly and lately it consisted of 5 files, 14,211 lines and 290 KB of code. We handcrafted our CSS from the start but more recently it had become quite hard to manage. With the growth of new tools like Sass and LESS I decided to rebuild our stylesheets into something cleaner and easier to maintain, and after working with the new system for a month I’m really happy with the results.

Since the early days of Beanstalk we have been using our Twitter account for status updates and maintenance notices, but it became obvious that a separate status page was needed for better communication. Twitter is a great way to learn about problems or maintenance, but only for people who check it all the time. People who are not on Twitter or don’t follow us have to check our Twitter stream which can be cluttered with replies or retweets and not clearly display the current status of our services.

A month ago, Wildbit released a mobile-optimized view of Beanstalk which is very handy for code-collaboration on the go. While researching for this project, I was surprised to find that mobile usage is slowly passing usage of IE 6-8 at Beanstalk. It’s like a dream come true!