We like champagne. It’s really a no-brainer.

Here’s How You Do It!

It also goes great on a fridge! Everyone wants an agile fridge!

Meet Grand Cru, founded in 2011 by six Finnish game industry veterans, they are a Helsinki based team of game creators. They say they have one direction: to revolutionize mobile and social gaming.

In their quest they have found Flowdock to be an essential tool. Creative director Harri Granholm says that with Flowdock, “we can work tightly together, but at the same time everyone can concentrate on their tasks without any unnecessary interruptions”.

The Cru’s new upcoming game, the Supernauts lets you create your superhero alter ego online. As a social game, the game is naturally best when played together, so it supports real-time multiplayer on a massive scale.

The Cru team is made up of mobile gaming and virtual world veterans combined with fresh design and other talent. That makes Flowdock a great fit:

We have noticed that Flowdock works well for the Cru as it has similarities with IRC which is a familiar tool for many of us. Many features, such as embedding images in a conversation and the integration with Pivotal Tracker, are essential to our work. In addition, our graphic designers are constantly sharing the material they are working on through Flowdock.

The Cru is also hiring.

TL;DR: Check out our deployment resources and enjoy multiple Node.js version bliss.

Chef Recipe for Node

Chef is used at Flowdock to configure servers. Naturally we wanted to use it also for managing our Node versions.

We ended up with having a recipe for compiling Node packages and uploading them to Amazon S3 and another recipe to download the correct binaries. If you want to see all the gory details, we’ve published our Node.js recipes.

As an end result, we can have a machine with all necessary Node versions set up in practically no time and applications can choose Node versions with little $PATH mangling.

Capistrano scripts for Node

Capistrano has proven itself and, above all, there’s an awesome Flowdock integration for it. There probably are Node-based alternatives, but we didn’t feel bold enough to try them out.

To avoid any hubbub during deploy, each deploy should use the Node version defined in package.json. This allows us to try out new version of Node without any changes in system configuration. Also, if the deployment is bad, we can always roll back to a working version.

To achieve this, our Capistrano script reads the package.json definition, extracts Node version constraints and uses Gem::Requirement from rubygems to choose satisfying version candidate. During deployment node and npm binaries are symlinked to $PROJECT/bin.

Keeping Node up and running

Now that the basic environment is set up, we just need something to manage our Node services. Our boxes already have runit for this task, so why not use it for our Node apps, too? You can even use foreman to export the service definitions for you.

Here’s how a runit definition looks like for our Streaming API.

#!/bin/sh
cd /home/florence/florence/current
exec chpst -u florence -e /home/florence/env sh script/run

This uses envdir to configure environment variables. script/run is responsible for mangling the $PATH and other fine-tuning.

#!/bin/sh
exec &2>1
export PATH=`pwd`/bin:$PATH
./node_modules/.bin/coffee app.coffee

Capistrano tasks are almost trivial.

task :start, :roles => :app, :except => { :no_release => true } do
  run "sudo sv up florence"
end

task :stop, :roles => :app, :except => { :no_release => true } do
run "sudo sv down florence"
end

task :restart, :roles => :app, :except => { :no_release => true } do
  run "sudo sv term florence"
end

Of course, you can also use upstart or supervisord if that suits you better.

Added bonus – Continous Integration

I’m lazy and haven’t managed to set up a setup for multiple Node versions on my personal development machine. To ensure that my changes will work when deployed, CI needs to use the same version of Node as in deployment.

To solve this, our Capistrano script has a local mode, which does the same symlinking stuff, but to a local directory. The CI script adds ./bin to $PATH before starting the test suite.

Conclusion

Having flexible Node version management on deployment and CI has been a blast. We can even try out unstable versions without extra ops work.

Jenkins is a popular continuous integration system that runs on the Java platform. Up until now, you could only integrate Jenkins to your flow by setting up email notifications for builds. Thanks to the recently published Flowdock Push API, there’s no longer need to resort to just plain email notifications. We have embraced the world of Java and developed jenkins-flowdock-plugin to make integrating Jenkins to Flowdock easier and a more pleasant experience.

Installing the plugin

• Go to Manage Jenkins -> Manage Plugins -> Available
• Find “Flowdock plugin” and install it
• Restart Jenkins

Now you can configure Flowdock notifications for any build by setting Post-build Actions:

And here’s a happy notification in your flow:

Fork your own notifier!

We had some arguments about the notification message configuration and how to implement customizable notifications. Soon we figured out that there’s just no point in trying to do that. Why not publish the plugin sources and let the developers hack it?

Forking the plugin and implementing your own awesome notifications takes just a few minutes and is well worth the effort. The plugin classes already provide all the Push API features, so you can start customizing the notifications to your liking straight away.

Here are my slides with some presenter notes included:

Again, thank you Katja Zorina, Heimo Laukkanen & others for organizing the event!

Predictions have been told over the years about the downfall of e-mail, all of them nonsense. E-mail is a great messaging technology. Most importantly, SMTP is a push protocol making e-mail relatively real-time. That’s also why it’s been used for automated notifications since its birth.

Automated e-mails can easily clutter your mailbox to the point where you filter them out and start ignoring them. Flowdock is a great solution for this as it frees your own mailbox. Automated mails are much easier to process if the work is shared by a team. A shared pain is a lesser pain.

Another great side of e-mail is its ubiquity. Any old tinderbox of a web application has the ability to send notifications via e-mail. That means Flowdock can be integrated to almost any service.

Get The Most Out Of Your E-Mail Integration

Using e-mail with Flowdock gives you full control over what notifications should contain and when they should be sent and who should be addressed in particular. Here’s how.

Create Logs With Tags

It’s a great idea to pre-tag automated e-mails to create sensible logs. For example, our deployment notifications come tagged both with #deploy and the name of the deployed project (frontend, backend) and the environment (qa, staging, production).

There are two ways to make this happen, you can either use a #hashtag in the subject, eg. “Deployed #frontend on #qa”, or you can add the tags prefixed with plus (+) signs into the e-mail address used for sending like this:

flowname+deploy+frontend+qa@organization.flowdock.com

Log By User And Get Attention

You can also tag by users. Lets say I wanted to easily see all deploys deployed by a certain someone, I could either use @username in the subject “Deployed #frontend on #qa by @mikael” or add the tag to the email address prefixed with a dot (.) like so

flowname+deploy+frontend+qa.mikael@organization.flowdock.com

So all strings prefixed with a plus sign after the flow name are stored as tags, and all prefixed with a dot are stored as user tags. You can also use the user tags to get someone’s attention. The @everyone tag can also be used and is also handy for important notifications that require everyone’s immediate attention.

Real-World E-Mail Workflows

Tags are a great way to filter important content that streams to your Flowdock flow. We recently showed how we handle feedback using a lightweight process.

In fact, we use e-mail integration with a bunch of services ourselves:

• Uservoice (feedback / feature requests)
• Feedback (simple form in the app)
• Google Calendar
• Nagios (monitoring)
• Bamboo (continuous integration)

Uploading a file

The REST API supports two ways of attaching files: encoding them with Base64 in a JSON request or sending them as form data. The details of both approaches are described in the new Files page of the API documentation.

Here’s a quick curl example of using multipart/form-data to upload a file:

curl -v -X POST -F "event=file" -F "content=@path/to/file.png" https://BASIC-AUTH@api.flowdock.com/flows/ORG/FLOW/messages

Finding files

Messages containing files can be fetched by filtering messages by the file event or the :file tag. The difference is that filtering by the :file tag will match any type of message that contains files, eg. team inbox messages with attachments.

For example, here’s how you would fetch the 10 latest files uploaded to your flow:

GET https://BASIC-AUTH@api.flowdock.com/flows/ORG/FLOW/messages?event=file&limit=10

Downloading a file

Once you’ve got some messages with files attached to them, you will probably want to download them for viewing as well. The REST API path of a file is stored in the path field of each attachment. For reference, see the file message section of Message Types documentation.

The path can be used to download the file by appending it to the API URL https://api.flowdock.com/:

GET https://BASIC-AUTH@api.flowdock.com/flows/ORG/FLOW/files/deadbeefdeadbeef/screenshot.png

That’s all for now, stay tuned for more API updates!

A new song is picked every about two weeks (depending on the annoyance factor) by each team member on his turn. The requirements for a song:

• 2-4 minutes long
• must be found on Youtube

We started the practice this fall and now we want to share them with you, so here is a Youtube playlist. Enjoy. :)

Booker T & The M.G.’s – Green Onions

Currently playing, is the smooth tunes of Booker T and his M.G.’s. It’s an uncommonly pleasant song, perhaps spurred by the incredible unpleasantness of the previous, short lived, song of the sprint: Witch Doctor by Cartoons.

Bob Marley – Get Up, Stand Up

This oh-so-aptly titled Bob Marley song has lyrics that were just made for a sprint song!

Dizzy Gillespie – Salt Peanuts

A brilliant 1945 bebop tune with lyrics consisting entirely of the phrase “Salt Peanuts”. Dizzy played this particular version with Charlie Parker.

M.A. Numminen – Yes Sir, Ich Kann Boogie

A Finnish, German-language absurdist cover of the 1977 smash hit single by Baccara.

Kari Tapio – Aaveratsastajat

A Finnish cover of the legendary cowboy song: Riders In the Sky.

Kojo – Nuku Pommiin

The Finnish entry to the 1982 Eurovision Contest.

Eero Raittinen – Rakkaudelta Näyttää Hitto Vie

An ultra-naivist love ballad and Finnish cover of the Swedish entry to the 1968 Eurovision Contest

Kikka – Apinamies

No Comments.

Hikawa Kiyoshi – Kiyoshi No Soran Bushi

A charming Japanese fishing song by the prince of enka singing.

Andy Suonsilmä – Karrelle Palanut Enkeli

Oh dear.

That’s right, you can now GET messages. It is an obvious extension to the Flowdock API, the ability to fetch messages of a flow given certain filters. You can fetch up to or starting from a specific ID, filter by event or tags and so on.

Read the docs ➝

A basic example of filter use:

GET /messages?until_id=3456&limit=20&event=message

This request will get you 20 plain chat messages leading up to the message with ID 3456 (which will not be included).

Searching With Tags

The new API lets you also search messages by tags. Getting all the messages tagged with the tags #feedback and #todo is as simple as

GET /messages?&limit=20&tags=feedback,todo

Tags are used to a lot of things internally in Flowdock. Filtering by tags gives you access to several features, such as fetching all the comments of a team inbox item with ID 12345

GET /messages?&limit=20&tags=:influx:12345

or listing messages that contain links or files:

GET /messages?&limit=20&tags=:url
GET /messages?&limit=20&tags=:file

Check out the tags documentation for specifics.

Message Types

We started documenting the different Message Types. There’s still a lot to be done on that front. We haven’t covered much of the team inbox events in the docs and we are going to be changing some of the events’ structure.

Parsing URLs from text is certainly no trivial task. We’ve had our problems in that front before. If it wasn’t unmatched parentheses being captured (like this https://www.example.com), it might just have been a case of catastrophic backtracking on certain browsers. In any case, failing to properly turn URLs to links is something that is immediately obvious to the end user, and we wanted to get rid of that once and for all.

Enter twitter-text

Twitter-text knows how to turn URLs, hashtags, mentions and lists into HTML links from any string you give it. Also provided are methods to simply extract them into an array like so:

> twttr.txt.extractUrls("(like in this http://www.example.com)");
[ 'http://www.example.com' ]
> Wow it works great!
SyntaxError: Unexpected identifier

The functionality was exactly what we needed. After all, we sort of do the same thing as Twitter in that regard: users enter plain text, we have to present it in a nice way.

Obviously the twitter-text library is built for the needs of Twitter, and some of its functionality wasn’t a very good fit for Flowdock. Some parts we didn’t need at all (for example list parsing) and some of it just didn’t quite work the way we wanted (parsing usernames), so we made some changes to meet our needs.

Unlike twitter-text-js, Flowdock-text allows dashes as a part of a hashtag. Also due to the use case with Github issues and Bamboo builds Flowdock-text allows all-numeric hashtags.

Flowdock needs to match usernames from messages as well. Twitter-text-js provides methods for extracting and linkifying @-prefixed usernames, but due to the nature of Twitter usernames (which can include only alphanumeric characters and underscores) are inadequate for our needs. This lead to us using the same regexp in both hashtag extraction and username extraction.

We also added an option to extract usernames based on an optional whitelist. This is used internally in Flowdock to exclude non-existent @users from turning in to links. On top of that Flowdock-text provides a few new methods to help message processing.

Usage examples

Using Flowdock-text in your own client is very straightforward. The Flows resource returns a list of users belonging to each flow, which can be passed as-is to Flowdock-text methods. In this simplified example, we’ll extract all tags from a new chat message before it is sent to Flowdock. Provided is also a reference to me-user, to make sure that a special :unread: tag is not applied to that user.

> var users = [
  {nick: "Marty", id: 1, disabled: false},
  {nick: "Emmett", id: 2, disabled: false}
];
> var me = users[0];
> FlowdockText.parseTags("@anyone seen this: http://www.bigwaste.com/bttf/twin_pines_mall.shtml #cool", users, me);
[ 'cool', ':url', ':user:everyone', ':unread:2' ]

Some special tags get returned from parseTags(). Since the provided message contains a URL, the method returns a special :url tag. This allows more fine-grained message filtering in Flowdock search. Also since the message contained one of our special @everyone tags (which are @everyone, @everybody, @all, @anyone and @anybody), :user:everyone is also returned. Appropriate :unread: tags with user ids get returned too.

We also provide some helper methods:

> FlowdockText.mentionsUser("hey @Marty, when this baby reaches 88mph yada yada yada", me);
true
> FlowdockText.mentionsAll("can @anyone help me?");
true

More examples can be found in the Flowdock-text README.

So there’s your short introduction to Flowdock-text. The source resides in Github, feel free to poke around!