Emperor Gets Kanban

Lately I’ve been using Emperor to manage many of dayjob work tasks. This level of dogfooding has exposed some limitations in Emperor’s ability to present work in a useful way. Giant lists of ticket’s aren’t helpful when you need status at a glance.

One of my favorite development processes is Kanban. I’ve used physical kanban boards with post-it notes in past jobs to keep things straight. This has been a feature of other ticketing systems for a while, it was just lacking in Emperor.

As such I’m happy to tag Emperor 0.2.1 today that includes a kanban board for every project.

In addition to the expected visualization of states via columns, Emperor’s kanban implementation also provides easy filtering to view just the tickets you are interested in. This feature is often implemented as swimlanes in other kanban implementations.

Emperor’s kanban is also implemented using JavaScript and the new search api endpoint. This means that it’s really fast!

There are many features that I look forward to adding to Emperor’s kanban but this is a great start.

Emperor Continues

After a four month period of silence Emperor is still alive and kicking. Some major changes have been made under the hood during this time and I’m excited to talk about them.

Rabbit Hole: Easier Deployment

Using Emperor previously required a few setup tasks:

• Install MySQL and create user accounts
• Configuring Emperor to connect to the database and mail server
• Compilation and deployment to a server with the above

This wasn’t particularly complex but I felt that thinks might be easier if Emperor could be deployed to services like Heroku.

This idea created two problems:

• Heroku uses PostgreSQL
• Running an in-JVM ElasticSearch was difficult due it’s expectation of using port 9200.

These complications led me decide on two things. The first is that Emperor’s schema could use some small changes after lessons learned from the first version and that a simple, REST-based ElasticSearch dependency might serve better in the long run.

PostgreSQL

The change to PostgreSQL gave an opportunity to revamp Emperor’s schema. The first change was to use sequences for the numbering of tickets and the latter was to separate mutable and immutable ticket data into separate tables.

There was of course a lot of SQL rewriting to eliminate some MySQL-isms and take on new PostgreSQL-isms. Since Emperor uses a very minimal model layer it is both refreshingly free of abstraction and frustratingly prone to failure across database vendors.

In the end I feel this was a positive change that benefited Emperor and made for a better codebase for future changes.

ElasticSearch REST

ElasticSearch has an extensive Java client library that Emperor previously used via Benny Sadeh’s scalastic.

This heavy depdendency on ElasticSearch’s pile of JAR files and the fact that ElasticSearch has such a rich REST API irked me and when I ran into hosting troubles with an in-JVM instance of ElasticSearch it was the final straw. So I created wabisabi, a pure REST client for interacting with ElasticSearch.

Picking Up The Pieces

After the two above changes there was lots of fixing to be done. The significant fundamental changes to Emperor’s model made for a lot of broken functionality that requires extensive testing. This is of course not the fun part of software development, so it took longer.

Recently I resumed working on these fixes after moving from Nashville to San Francisco and today I am happy to tag a new version and to resume using Emperor for some small day to day projects.

The Future

The landscape of ticketing systems hasn’t changed much since I created Emperor just over a year ago. JIRA continues to dominate my professional career and GitHub Issues provides reasonably powerful issue tracking for OSS projects and small teams. I still think there’s room for middle ground. Maybe it should be hosted?

Working on Emperor cemented my understanding of Scala and reintroduced me to modern JavaScript frameworks. It has reinforced my love of ElasticSearch and given me many a late night of hacking. I expect I will continue developing it in the hopes of finding like minded folks who want a similar system. If not, then it will continue to serve as an excellent platform for learning new things.

Deploying Play Applications with Capistrano

I'm building an open-source issue tracking and project management application called Emperor in Scala using the Play Framework. Recently there was discussion on the Play mailing list about deploying Play applications so I thought it might be useful to demonstrate how I deploy Emperor using Capistrano.

Isn't Capistrano For Rails?

Capistrano — or just cap as it is often called — is widely used for deploying Ruby on Rails applications. But it's possible to use cap for deploying any type of app you like. At Twitter it's used to deploy pretty much anything you can imagine.

So I set out to use it for Emperor because it's deploy and rollback process is quite nice. Here's how you do it.

Going Off The Rails

I'm assuming you've already got cap installed. If not then do read the docs.

The first step is to install the railsless-deploy gem. You can find instructions for installation and use in the linked documentation. If you check the docs it will advise you toward a simple Capfile.

Actual Deployment

Here's a complete Capfile with comments explaining the bits.

Conclusion

Capistrano is a great tool but I've find it to be poorly documented. The above Capfile took me a few hours to piece together. That being said I'm very happy with how it works! Hopefully this helps other Capistrano users that are deploying non-Rails systems.

Getting Started With Emperor Development

My OSS, Scala-based issue tracking and project management application, Emperor is progressing nicely. That it’s written in Scala may be a burden for some people, as Scala has yet to become as widely adopted as I would like. As such I’ve put together the first post in a series on getting started with Emperor development. This will serve as a starter for some Scala newbies as well as those interested in Emperor or the Play framework.

Mid August Emperor Updates

Working on pacific time means that I have a lot more hacking time on weekday evenings, as I stay up much later. Emperor has directly benefited from this, with a big sprint being completed on Friday. Version 0.0.6 has been tagged and the following features are there:

• There is now an edit button on the ticket view page. (EMP-2)
• A ticket’s resolution status is now clearly shown on the ticket view page (EMP-3)
• Reporter now defaults to the logged in user when creating a ticket (EMP-4)
• Resolution status (via strikethrough) and summary are now shown in links (EMP-6)
• Ticket creation now shows up in the timeline without a reindex (EMP-7)
• Project is now listed as the first item in ticket creation and editing (EMP-8)
• Revamp search results page to show more information (EMP-9)
• Ticket links are now styled
• Ticket links can now be removed (and have an API call)
• Add more API docs (but they are still bad)
• Change color of search filter buttons

I’m planning my next sprint now and it is likely to involve further link improvements and project-level settings for ticket attributes.