Here’s what to expect from the brand spanking new version of Interstate.
With roadmaps being our pride and joy it was about time they were made even greater. The new roadmap UI brings brand new ways to manage your roads and we’ve also added a few new features to help you organize your items even easier, such as item labels. We’ve also improved our support for attachments, roadmap sorting and pretty much everything else roadmap related!
Discuss is a feature that has been around since our last major release but it’s never really lived up to its potential. Up until now, Discuss was just a simple tab on your roadmap which would allow you to discuss that roadmap with your colleagues. We noticed this wasn’t getting much use or at least wasn’t being utilized in the way that we initially planned.
In the new Interstate, we’ve changed Discuss to be a stand-alone feature, which will be accessed via your Interstate’s navigation. You will now have the option to discuss roadmaps, groups or roads, speak directly to a team mate or just setup a general chat for whatever you want. Within discussions about roads you can update their status and progress without even leaving the room. You can also attach files directly to the chat room for colleagues to see or even embed external services such as YouTube videos or Dribbble shots.
You can now quickly navigate around your Interstate using our all-in-one search. Search for projects and people or if you’re viewing a roadmap use it to filter the roadmap’s contents. You can even input someone’s name to view items assigned to them. Search will only get more powerful as Interstate grows.
It’s certainly something which sets Interstate apart from its fellow project management applications. Embedding up until now has been simply allowing you to embed and share your entire roadmap, anywhere you want. That’s all well and good but we feel embedding has a greater potential than just providing a general overview of progress.
So instead of just being able to embed a full roadmap, you can now also embed groups or roads on their own - perfect for sharing progress of a single item with your colleagues or users outside of Interstate.
We’ve been wanting this feature for a while now ourselves to let us to explain feature development on our blog in more detail. Here’s a quick example of item embedding using only two lines of code!
We’ve also improved the look of the original two themes and added a brand new one which matches the new interface of Interstate. Hopefully they’ll all please your lovely eyes. Not forgetting of course, you can still design your own theme to fit in with your brand.
Overview has had a bit of an upgrade with our new real-time functionality. You will now see all the things happening on your Interstate, as they happen. On top of that, the new sidebar will now tell you exactly where your team are on Interstate (if they’re online), even telling you what they’re doing it as they’re doing it.
When managing your projects, you’ll now also see your colleagues changes right as they happen, providing an even better management experience.
Another cool addition is toast/growl notifications. These helpful little guys will tell you when a change you’ve made has been successful, when someone has updated a project and/or its contents and even alert you when you’re mentioned in a Discuss chat.
Up until now our only GitHub integration has been to pull in your commits and display them on your Overview. Somewhat handy but not at all want we’d like from GitHub integration. In the new Interstate you can attribute commits directly to roads with relative ease.
When posting a commit simply provide the road’s name or ID in two square brackets before your commit message and the commit message will be posted to the road as an update. Easy, peasy, lemon squeezy!
[Archived Items] Just finished up some interface work.
There’s a whole lot more we won’t go into detail about on the blog, you should really try it out by visiting the new Interstate!
One year ago, we wrote a blog post explaining Interstate's stack and architecture after we were just two months in to development. Since then a lot has changed on both the product and business sides of Interstate (we've released 3 new major versions since then and we recently took part in the Summer 2011 cycle of Y Combinator) and so I thought this would be a good time to explain what’s changed in the past year in terms of our stack.
At the time of our last post, we were running Interstate on a single server from the guys at MediaTemple. Whilst MediaTemple were a great host, they didn’t really support our expansion plans as well as other hosts could. Because of this, we moved our web app over to Amazon Web Services in June/July 2011. At the current moment in time, we’re running just one large (7.5GBs memory, 4 EC2 Compute Units) 64bit EC2 instance (with CentOS) in the US East (Virginia) availability zone. Over the next few weeks/months we’ll be looking to spread Interstate across more EC2 instances and availability zones.
At Interstate, we use MongoDB as our primary data store and before our switch to EC2, we managed our own MongoDB instance. Due to Interstate’s growth though, it was becoming a large effort to keep monitoring our MongoDB setup whilst still building our product. The main issue being that for the better part of a year, we hosted our MongoDB instance on the same server as our web app. This quickly became an issue as our Mongo instance was using too much of our server’s resources and so our web app quickly began to suffer.
Because of this, we made the decision to move our database to a group of guys who know a lot more about hosting MongoDB than we did, those guys being MongoHQ. We moved to MongoHQ around March 2011 and since then the experience has been pretty great.
Just as we were a year ago - we’re still using NGiNX to handle all of our requests and to serve our content. Here’s what we said in our original post regarding our choice of NGiNX..
We have decided to use nginx to serve all HTTP requests over the other popular alternatives such as Apache. We chose to use nginx after benchmarking other sites of ours that run on the same PHP framework but use Apache as the HTTP server. Both the speed difference and usage of system resources (e.g. memory) between powering these sites on nginx rather than Apache made it an easy decision for us to use nginx.
The language which Interstate is written in is pretty much always a surprise and shock for people. When we were originally meeting the other founders in our Y Combinator class, we often showed them what we were working on and 99% of the time, their first reaction was: “So what did you write this in? Rails, right?”. As we told them what language we actually used, letter by letter their face turned from interested to surprised, shocked and then somewhat horrified.
As you may have guessed (or previously read), we primarily use PHP to build Interstate. The reason behind this is not really all that strange, we’ve simply built a lot of PHP powered apps in the past and know how to build clean and efficient apps in the language. We believe you can write ugly and bad code in any language and so just because PHP has a history of badly written code doesn’t make it an inherently bad language. Yes, there are a lot of silly problems with the language itself (such as the infamous namespace separator) but most of the problems don’t really affect you (or at least they don’t affect me) day-to-day.
All that aside, the main Interstate app runs on PHP 5.3.6 using a custom (MVC) framework, which we hope to open-source in full at some point. To handle our PHP processes with NGiNX we’re still using PHP-FPM (which is now bundled with PHP as of v5.3.3).
As of recently, we’ve also began to start experimenting with Node.js for some new and exciting real-time features. Most notably, our new Streaming API (which will be opened up to developers soon) which powers pretty much all real-time updates within Interstate (such as our new Growl/Toast-esque notifications) and soon our Mac App. Our second biggest use of Node.js is our upcoming real-time team chat system, called Discuss - which Node.js has been particularly great for.
When developing apps using Node.js, we often use a mix of open-source modules made by other great developers. These modules generally include: Socket.io, node-mongodb-native, node-memcached and node-redis to name just a few.
To manage our Node apps we also use forever.
We still use APC for PHP bytecode caching and Memcached for all in-memory caching. Our use of Redis for caching has somewhat reduced and we’re now using Memcached a lot more aggressively than we were a year ago.
As said above, our usage of Redis as a cache has reduced and our main use case has shifted from caching to instead using it as a pub/sub backend for our Streaming API. So far Redis has been working really well for this use case. Once the Streaming API is made public, we’ll try and take some time to write about how the stream works in more detail.
To help us build Interstate we also use several third party web services..
At Interstate, we use git for version control. For our git hosting we tried out several popular services but we eventually settled for the most popular choice, GitHub. We chose GitHub simply because all of our open source and public projects are already hosted there and so to host our private repositories there as well just made things easier.
For the small bits of email marketing (newsletters) which we do, we have started using Mailchimp. We’ve only sent out one campaign so far but the service has been great.
For transactional email delivery (e.g. forgotten password emails, notifications, etc) we still use Postmark. Postmark makes transactional email delivery super easy (just as it should be), they provide great and simple analytics and an easy (and pretty cheap!) pay-per-email pricing model. We’re more than happy to keep giving these guys our money.
Finally, to build Interstate we use a bunch of great apps, including..
Coda to write all code for the web app.
Photoshop CS5 for all the UI.
Xcode to build the Mac App.
MongoHub for quick querying of our database.
Spotify for the great tunes.
Gaug.es for web analytics.
Interstate for project management ;)
If you have any questions about our particular use of any software in our stack or anything else, please just write a comment and we’d be happy to answer.
TL;DR: We’re hosted on Amazon EC2, running CentOS, NGiNX, PHP (+ PHP-FPM) and Node.js. We use Mongodb as our data store, Memcached for memory caching and Redis as a pub/sub backend.
Interstate CLI began on a whim, starting with my (Alec’s) recent conversion to Git from SVN. As you do, I started using Terminal so often that I couldn’t help but consider other tasks and ask whether they could be reasonably accomplished from the command line. This is not a new story, so I’ve gathered: this is why libraries like Thor, purpose-built for crafting shell scripts, exist in the first place.
We have happily discovered that, in fact, Interstate lends itself quite well to the command line. The Roadmap > Route > Road pathway is easily traversed with simple commands, and providing method options feels as natural here as it does in Git.
Some aspects, however, needed reconsidering. For example, we made the choice to remove Interstates as the point of departure. In terms of navigating to a road, this works perfectly well with a mouse, but is slightly fatiguing on a keyboard. Instead, we’ve made roadmaps top-level, whereby typing “interstate maps” presents you with a list of roadmaps.
The second big thing was that we didn’t want to type either a 22 character identifier or the full title of whatever we were navigating to. The API doesn’t provide shortcodes, so we generate them locally. We’ve kept them short and easy to read: just one letter and two numbers. Finding what you want in a list is easy and the shortcode seems to stick in your mind quite easily.
Without further ado, here is what interstate-cli 0.0.4 can do so far:
Show a list of tasks
Show a list of roadmaps associated with your API key
interstate map x##
Switch to a roadmap
interstate roads -r
Show a list of roads for the current roadmap. Because we have to cache the roads locally, occasionally run it with -r to see if you’ve got latest.
interstate road x##
Show a detail view of a road
interstate update x## -m -s
Update a road with optional —message (-m) and —status (-s) parameters. Note: the status parameter can take either a status code (1-14), the human readable status (e.g. “10%”, or “Started”), or if left blank, you’ll see a table of options and are prompted at that point.
interstate add -t -d
Add a road to the current roadmap with required —title (-t) and —description (-d) parameters.
interstate delete x##
Delete a road
Display a log of recent activity for the current roadmap
Resets all interstate-cli local config
Interstate-cli requires at least Ruby 1.87 and a reasonably current version of Rubygems.
Install it with
sudo gem install interstate
You may need to install Apple’s developer tools on certain machines, although this issue is not currently reproducable and I haven’t had time to look into it in any depth. Also, some machines experience write permissions with certain interstate-cli config files. We are also looking into that.
For now, if you have problems setting it up, please email email@example.com
Interstate-cli is by no means a finished product. If you like the concept and want to see it mature into a more useful, fully-rounded tool, please send us feedback! We see this as an experiment for now, but if it evolves into something bigger, that’s cool too!
Page 1 of 2Older