Archive for the 'Fun' Category

What is DevjaVu even about?

December 27, 2007

As an introductory topic for our users forum, I’d like to pose the question: What is DevjaVu and Trac about?

It’s not exactly “project management” even if it does involve it. You might say “developer tools” but tell that to a developer and they’ll think compilers and editors. Sure it’s “issue tracking and version control” but that’s not all it is. Plenty of people have those things but don’t have what DevjaVu is.

So join us in a discussion about how to describe DevjaVu. As our users, you guys should know best!


Free projects and winter makeover!

December 4, 2007

The other night we deployed a new site. Actually, it’s the same site, it just looks different. It also has a slightly better signup process, something we’re still working on. Ideally it would be as simple and convenient as possible, since it’s the same process you’d go through to set up a free project…

Which reminds me, we’re going to open up free projects for a while. We’re going to do this by providing a master invite code for a limited time. You can use it to start free projects right now!

Just use johnny5 as the invite code when you select the Free plan. You’ll get an email confirmation and link to your new project almost immediately. You better get started now, this is a limited time offer available until the end of the year!


Service testing and alerts with Twitter

October 27, 2007

Have you ever messed with those site alert services that ping your site and email you if the site is down? For free services, they can be pretty handy. We used Montastic, made by the same guys that built Mojo Helpdesk, which we still use. The problem is that they don’t tell you much else, like if your registration page is broken or an SVN operation fails. Plus it would be nice to get IM or SMS alerts instead of emails.

So with a little work we took Mechanize (also available in Python and Perl) and a test framework and made high-level tests of our service’s functionality. For Rails users, it’s a bit like making integration tests, only it runs on the actual site, so it doubles as a more thorough site pinger. The downside is that you don’t really have fixtures, it’s all real data and real interactions. That can make it a bit tricky, but if you can get around that, you’ll have a nice service testing script you can run locally or on another server.

You might want to just put it in the other server’s crontab, but unless you get emailed the cron output, just running the tests is pointless without some kind of alerting. Even if you get cron output, you probably don’t want to see the test results every time it runs. If we have to do our own alerting, we might as well get fancy…

It turns out getting fancy is not all that hard thanks to Twitter. With almost no work at all you can write a wrapper for your tests that grabs the test status line (the one with the dots) and the name of the test that fails and then send them as a direct message to you with Twitter’s super simple web API. Then you get messages like these sent to your IM or even to your phone if you have direct messages enabled for it:

...F...... registration (Registration is broken)

......FF.. svn checkout (SVN checkout is broken)

FFFFFFFFFF homepage (The whole site is down)

Once you have your test script done, you can use a simplified version of our Ruby wrapper script to have your own super awesome free IM and SMS alert system:

require 'net/http'
require 'uri'

username = (your twitter user)
password = (your twitter pass)

alert = (array of twitter users to alert)

ruby_bin = (full path to your ruby, since run by cron)
test_path = (full path to your tests)

url = "http://#{username}:#{password}"

output = `#{ruby_bin} #{test_path} 2>&1`
test_stats = output.split("\n")[2]
failure = output.match(/\d\) ((Failure|Error):\n([^\(]+))\(/)
if failure
 failure = failure[3].split('_')
 failure = failure.join(' ')
 alert.each do |u|
   {'user'=>u, 'text'=>"#{test_stats} #{failure}"})

See? Simple! Now you can get woken up in the middle of the night as soon as something breaks…


WSGI makes us faster, simpler, nicer!

September 20, 2007

We’ve been working for a long time on getting certain infrastructural things fixed. For example, did you know up until now we’ve been running on CGI? As we posted before, the original plan was to get Trac running on a cluster of tracd’s, much like the cluster of Mongrel’s we use for the Rails part of DevjaVu.

Just think about that. At our simplest setup, we’d have 2 Mongrel processes and 2 tracd processes. Plus we have to run Apache for Subversion given our setup. But wait, then we have this load balanced across several machines! With every machine we add, we’d get another set of these processes to worry about.

I was okay with Mongrels, but really, I was a bit upset coming from PHP about how much more I had to worry about to make sure the application was running. With mod_php you can just assume that if Apache is up, the app is up. With Rails and any FCGI or Mongrel-like setup, there were now two layers, one of which is usually a cluster of processes that could die or leak memory.

So recently we started writing a new application to replace our Rails part of DevjaVu. We’re writing it in Pylons, which is really nice and Rails-like, while still very Pythonic. This led us to mod_wsgi, which boasted faster performance than mod_python, and was even easier to configure. We tried our new app on our dev server with mod_wsgi and it was very nice. Then I realized Trac had WSGI support, so I tried Trac on mod_wsgi. Perfect!

After a few changes, DevjaVu production is now running Trac on mod_wsgi. Pages are loading almost twice as fast! Our setup is simpler, too. Once we replace our Rails app with the Pylons app, we can run everything with Apache. We’re stuck with Apache for a while anyway, so why not roll everything in? Faster. Simpler.

And we can finally have nice URLs for real! Let me explain:

Before, we had to have URLs like this:

That was redundant, long and ugly. We were able to rewrite our ideal shorter URLs to the longer version, so you could use URLs like this:

However, that was just a cosmetic rewrite and Trac would always generate the long URLs.

Now, Trac generates the short URLs all the time and the short URLs are the proper, non-rewritten way Apache serves the request. We have the long versions that you probably have posted around the web do a permanent redirect to the short ones. This way you can still use them, but you should update your links at some point since they are now deprecated.

Anyway, that was fun. Hope you enjoy the changes. We have a lot more coming up. Let us know if you run into problems.


Be sure to log useful commit messages

June 5, 2007
18:56 Changeset [416] by
not sure why this is needed all of a sudden
19:09 Changeset [417] by

Your commit messages are supposed to be well-crafted, meaningful and useful, but sometimes bad messages can be greatly enjoyable. One of the things we want to build is a cross between and for commit messages. Wouldn’t that be awesomely great?

Sure, it would be one more thing to distract you from coding, but besides being entertaining, it would give you a feel for what other people use as commit messages. This way you can get an idea of how good your commit messages are, and in some cases see how to do them better.

Yeah, we just had to slip a productivity encouraging motive in there…


Nobody expects DevjaVu!

June 4, 2007

Our chief weapon is Trac… Trac and SVN… SVN and Trac… Our two weapons are SVN and Trac… and ruthless efficiency… Our *three* weapons are SVN, Trac, and ruthless efficiency… and an almost fanatical devotion to Project Management… Our *four*… no… *Amongst* our weapons… Amongst our weaponry… are such elements as SVN, Trac… I’ll come in again.

-Jeff (speaking on behalf of Mike, inspired by Monty Python)