This release handled a few bugs and improves integration with the testing suite, particularly for people running it via Vagrant. The biggest benefit with testing is that the staging environment is now created and reset automatically when phpunit is run, rather than needing to be initialized separately. This release also adds better support for messages with special encoding.
As I was poking around the Packagist website this morning I found that Stash has reached 40k downloads through composer! What’s really exciting is that 2,135 of those downloads were just in the last 10 days.
This is an exciting milestone for me. Stash has been in active development since 2009, but was only moved to Github 2 years ago- around the time that it was made available through Packagist. Since then the community has rallied behind it- with 23 different contributors, a fork supporting PHP 5.2, bundles for popular frameworks like Symfony (thanks Josh!), and adoption of projects like EZPublish, the growth of this project has been phenomenal.
Thanks to all of the community for their help in developing Stash! I’m looking forward to my next update on Stash, where I’ll talk a bit more about what makes it such a great caching library.
In my previous post I introduced the testing suite I created for Fetch. Here I want to go through exactly what needed to be done to put that together. This post is a bit longer, and you really don’t need it to take advantage of this package, but it may provide some insight to anyone hoping to do something like this themselves.
For me testing has two major components- it should ease development on the local level by preventing regressions, and it should help me as the maintainer of an open source project by giving me trust in the pull requests that are coming in to me. Travis-CI, an application I’ve been using extensively for my projects now, makes that last problem much easier as it will run my test suites and tell me right in the pull request if any problems have come up. On the local level I decided to use Vagrant, as it makes adding virtual machines to source control (without adding a huge binary file) really simple.
Years ago I wrote a library, Fetch, which was designed to read email using the PHP IMAP Extension. At the time I did not expect it to get much reuse so I skipped out on much of the test suite- if I’m going to be perfectly honest here though I have to admit that a huge reason for not building out a test suite then was that I was unsure how to go about it. Building a test suite for an email library has some very interesting requirements, especially if you want to test it in as real world a setting as possible.
- You need a mail server.
- That mail server needs a variety of messages, folders, flags and attachments for all the for different types of tests that are needed.
- Those messages have to remain consistent between test runs.
- Resetting the mail server to it’s original state should be fast to encourage lots of testing during development.
- The test suite, and thus the mail server, need to be portable so other people can run tests on their changes.
- Continuous integration (integrated in with something like Github) is really really nice.
Unfortunately for me all of my great excuses have vanished, thanks in large part to Travis-CI and Vagrant. Both of these systems are fantastic for testing. Travis is a continuous integration environment that’s setup for a number of languages and has direct integration with a number of services such as Github. Vagrant makes sharing server environments as easy as passing along a configuration file. With the two of these tools I was able to put together a testing package for Fetch that met all of those requirements, and after a bit of additional work I’ve broken that up into a stand alone package for people to use in their own projects.
Using this is really simple- you just need to call SetupEnvironment.sh before each run of your test suite. Once that is finished running you have a fully functional Dovecot server with a consistent set of messages. It doesn’t matter if you’re running this from your home computer or if it’s run on Travis-CI, as the SetupEnvironment.sh script will recognize where it’s being run and work accordingly.
There are also some cool optimizations to make testing faster. The test environment will stay up and running for a half hour after the last test before shutting itself down, so you don’t have to wait for the virtual machine to boot between tests. Rather than start from a blank slate each time, the environment has a reset function that restores the original inboxes. With an already provisioned test environment there is almost no overhead by this package between tests, as resetting the inbox takes only a couple of seconds.
The project is up on Github at tedivm\DovecotTesting, so if you’re writing an email reading library there’s no more excuses. I’ve also put together a more detailed post describing how this was put together.
I was writing up a new blog post that had some Yaml config files in them. I’ve been using the Syntaxhighlighter Evolved plugin for this, which has worked remarkably well. Unfortunately it seems that Yaml is not one of the supported languages, and I couldn’t find much about it.
Luckily for me the author wrote a fantastic blog post about extending his plugin, which I used to create my very first WordPress plugin. If you’re looking to add Yaml highlighting to your blog you can grab my SyntaxHighlighter Evolved: Yaml Brush plugin right off of the WordPress Plugin Directory. The first version is pretty simple, but I’m considering collecting a few different languages together for a more comprehensive pack.
As part of maintaining Fetch I have to install the php imap extension quite a bit. Although this is pretty trivial on most variants of linux it’s kind of a pain for OSX- you have to find a few dependancies, compile the imap c library from source, create the extension against your currently installed version of php (which typically won’t include it’s source on the system), and then take that one resulting file and set it up.
After doing this for the millionth time I decided to script it, and like any good programmer I looked to see what was already out there. I found a script by Ivan Vucica for an older version of OSX and then polished it up. My version should work on more than just OSX, although in most cases you’ll want to use the system package manager in that case anyways.
Whether it’s from a planned upgrade or a blown RAID, your site is going to go down eventually. This was brought to light for a lot of people by a recent outage on Hacker News- an outage that was made worse by HN responding with 200 Status Codes. During the subsequent discussion I posted a few quick pieces of advice which got a bit of attention, so I thought it was worth writing up a real post about it. Since this all started with a website and a status code it’s only fair to focus the attention on HTTP and how it can be used to help.