Categories
About

Nodeta is a software development company that focuses on web software. We employ a highly agile and effective process. We have worked both on light independent projects and in the environment of large global enterprises.

Archives

TODOs are conversation

Mikael Roos March 8th, 2010

A good way to start the work week is to go through some TODOs. These days there’s about a zillion ways to manage them online. With Flowdock, the unique aspect is that you can handle them right in the middle of the conversation. There is no gap.

Here’s an example from our own flow. If you come up with something, that needs doing you can just throw in a line with the #todo tag included.

Chatting with tags

But because this is a conversation, if someone else says something worth TODOing, you can just add the tag yourself if the other person didn’t realize to do so.

Tagging chat messages

The todo list lives in Flowser as a search. You can use other tags to better categorize the todo items: milestones, project names etc. Whenever you complete a task, just tick the x on the todo tag to remove it.

Searching for TODOs

This is a lightweight process, which you can work with in the privacy of your own team’s conversation.

Only 2 days till Flowdock public beta!

Agile Development with Flowdock

Mikael Roos March 4th, 2010

As Flowdock enters public beta (opens on March 10th!) we’ve begun doing continuous deployment. As an agile software development shop, we also test extensively and practice continuous integration. At the same time we need to monitor that Flowdock is running smoothly and when problems occur, we can fix them right away. All this requires fast working channels of communication so in the center of it as the hub of our team, is naturally Flowdock. I’ll walk you through our development process from the developer’s point of view.

Committing changes

Git push show a pretty view of the pushed commits

We use git for version control. Each time someone pushes commits to a branch, an email is sent to Flowdock with tagged information on

  • commits that were pushed (committer, commit message…)
  • component and branch, into which was pushed

This lets us do real-time code reviews. We habitually discuss individual commits inside Flowdock. We use a git post-receive hook to pipe the changes into Flowdock via email. The hook is available here as a gist on GitHub.

Continuous integration

Continuous integration

Whenever someone pushes some changes into the master branch, our continuous integration server runs all the unit tests in the project and if they do not pass, an alerting email, such as the one above, is sent to our flow. The message comes with details on who to blame so others can target the correct amount of mocking towards the culprit.

Continuous Deployment

Continuous deployment

When the tests pass, the master branch is then deployed to our QA environment.
All deployments send properly tagged messages to our flow in Flowdock. I can always tell what was deployed:

  • component: front end, back end, specific service…
  • environment: production, qa…
  • changes: log of commits the deployment brings into the environment

The QA deployment runs acceptance tests, which make sure all the important use cases function properly in a production-like environment. For acceptance tests, we use a combination of Cucumber, Selenium and RSpec. Once everything passes in QA, the deployed version is tagged a suitable candidate for production deployment. Next we do some smoke testing in QA, and finally deploy to production.

Deployment log

Flowdock also gives me a deployment log. For example to see front end deployments in production, I just search #deploy #production #frontend in Flowser.

Exception notifications

Error message from production

Whenever something goes wrong in production, we get notifications to our flow. This way we can debug problems together, immediately when they occur.

6 Days to public beta!

Handle feedback with Flowdock

Mikael Roos March 3rd, 2010

We try to be as responsive and communicative as possible towards our users because they are our future customers (fingers crossed), and they provide incredibly valuable customer feedback.

We try to give our customers enough ways to give us feedback, so they don’t have to sweat it. They can use a feedback form inside Flowdock flows, use our Uservoice page or send us email directly to team@flowdock.com. Some users choose to use Twitter for feedback and they catch our attention by mentioning @flowdock. All this means we need to track different mediums. Luckily enough, Flowdock gives us everything we need, in real time.

Emails and Twitter

Handle feedback from different mediums

In this example from the Tour, you can see how we handle feedback from emails and tweets.

  • Responsiveness comes easily when the whole team can respond to the feedback
  • All feedback form emails have the tag #feedback in their subject, so they get correctly tagged
  • We have forwarded all the emails to team@flowdock.com to our development flow as well, so it’s easy to answer to them and track them in Influx
  • Live, face-to-face feedback we just type into the chat and tag it with the same #feedback tag

With these practices, all the feedback is easily accessible when we need it.

Uservoice

Uservoice changes in Influx

Uservoice is a great way of sourcing and managing ideas and suggestions from the user community. The team gets notified about all changes in Uservoice as well. It’s great to talk over new feature requests inside our flow right away when they’re suggested. Then we tag them further and they become part of our backlog. That is agile.

7 days to Flowdock public beta on March 10th!

Track your brands with Flowdock

Mikael Roos March 2nd, 2010

Flowdock has been designed to be the best group messenger in the world, but it can be so much more. We’ve previously covered using tags to abolish the barrier of reporting bugs, and now I’ll show how you can make your team act as a single unit in tracking, creating, molding, protecting and generally managing your brand.

Flowdock allows your team to react to everything with zero delay. You can pipe anything into Flowdock’s Influx as RSS feeds, tweets or emails. Here’s a couple of things we’ve found immensely useful in tracking our brands. You should try them out.

Add Twitter tracking for your brand

This is basic functionality of Influx in Flowdock.

1. Go to Influx and select sources from the top right

2. Choose the Twitter tab and add your brands as Twitter searches

Add Twitter search in sources dialog in Influx

3. React with zero delay

React with zero delay

Add Google Alerts for your brand

1. Go to Google Alerts and add alerts (RSS) with your brand names as search terms

Create a Google Alert

Choose “Feed” in the “Deliver to” selection.

2. Copy the alert’s feed address from Google Alerts

Copy the alert feed URL

3. Add the feed to Influx through the sources dialog

Add the Alert feed to Influx

4. See what the internet says about your brand, and discuss it in Flowdock

Google Alerts are fuel for discussion

Flowdock is completely real-time, and so will your team be once you start using it.

8 days left till public beta on March 10th!

Flowdock Public Beta to launch

Mikael Roos March 1st, 2010

Flowdock was built to be the best group messenger in the world. It must be true, because it says so right on the About page of our new web page! That’s right, we’ve launched our website at www.flowdock.com and in ten days on March 10th, we’ll launch Flowdock to open public beta.

The new version of Flowdock has just been deployed and the 500 companies participating in private beta are already using it.

Here are some highlights of new stuff.

All those flows

Up till now, we’ve wanted to fine tune and get all the customer feedback on the user interface of the flow user experience, so we didn’t even provide anything else in private beta. However, Flowdock is not about only the one flow. You need to use different workspaces for different projects. Here is the new view for that, which we’ve endearingly named “My Flows”

Flowdock - My Flows

Tour

We’ve added a tour to the web page. There’s already a few use cases on it, and we’ll be adding more as we get closer to the public beta launch. Here’s one such case demonstrating how a law firm uses Flowdock to collect various kinds of information about their competitors and clientele.

Flowdock - Tour case

Flowdock screencast (+700 new invites!)

Mikael Roos January 20th, 2010

It’s been a crazy busy winter as we’ve been developing our shiny new group collaboration web app, Flowdock. Up till now, we’ve had about 100 teams trying out Flowdock and today marks the moment when we ship out over 700 more invites to people who want to see how Flowdock could make their teams’ lives easier. Haven’t requested an invite yet? Add your email address at flowdock.com.

Here’s something brand new right off the presses: a Flowdock screencast, showing the most important and interesting parts of the app, briefly illustrates how Flowdock can make your teamwork immensely more efficient and simply flowing.

In the following days we’ll be posting about some new things we have in store for our users. So, stay tuned! Also, check out @flowdock on Twitter and our Facebook fan page.

Flowdock went Silicon Valley

Mikael Roos November 5th, 2009

Me, Otto and Karri spent last week in California around the Bay Area promoting Flowdock and making connections. With us we had veritable crème de la crème of young Finnish entrepreneurs, including the founders of Powerkiss, award winning independent iPhone app developer Elias Pietilä (now from Qvik), and the CEOs from GrowVC and Mysites amongst others.

We had a great time, met awesome people and owe big thanks to the organizers of the trip, Aalto Entrepreneurship Society plus ArcticStartup. We especially want to thank Kristo Ovaska, Krista Kauppinen, Riku Seppälä and everyone who made the trip possible and awesome.

Flowdock went to Silicon Valley with AaltoES and ArcticStartup

Flowdock Press

We did a lot of press contacting to prepare for the public launch of Flowdock later this year and even gave an early video interview to ArcticStartup. Amongst tons of meetings we met with an insightful lady, Tanja Aitomurto, who blogs regularly to Helsingin Sanomat here (in Finnish) about what’s buzzing in the Silicon Valley and got to demo Flowdock to her and get her feedback.

We were also interviewed by Skype Journal in a bit of a controversial situation, where we ended up criticizing Skype as a collaboration tool for its lack of ability to make anything useful out of the information gathered with it.

From Silicon Valley we dove straight back into the slush of Finland’s beginning winter and Slush Helsinki 09, the aptly named startup event where we demoed Flowdock live to the public hordes for the first time ever. Here’s a video interview with Karri pitching Flowdock in Slush by FreejamTV.

Meet Scalandra: Scala wrapper for Cassandra

Ville Lautanala August 28th, 2009

Developing Flowdock, a real-time environment allowing teams to work together seamlessly, we needed a database able to scale horizontally for huge amount of write operations. Cassandra’s data model and performance characteristics made it a perfect fit for our needs. It is a distributed database with a data model slightly like Google’s BigTable. Cassandra was originally developed by Facebook to run their in-site messaging system, Inbox. If you want to learn more about Cassandra, Evan Weaver’s up and running with Cassandra is a good place to start.

In the beginning of July when we started to use Cassandra, there wasn’t any usable bindings for  Scala, which we use for Flowdock back-end, and hence we decided to develop our own. Two months later, the Thrift API is barely recognizable, but still bag of hurt in Scala. Others have also noticed this and developed their own bindings for Scala, but they all have slightly different approaches.

In Flowdock we use Scalandra to handle three tasks: wrap the Thrift API in a more painless interface, manage connections efficiently using a pool and to serialize and deserialize byte arrays, which are used in Cassandra to store data. In Scalandra you can use three levels of serialization to support all possible combinations of different data types in Cassandra data model.

Scalandra has two levels of interaction. At the lower level, it provides a similar API to the Thrift interface with commands for get, slice, insert, remove and count operations. Client API is meant to be used together with connection pooling to make sure that only a reasonable amount of sockets is opened. Unfortunately for our purposes, Scala doesn’t have RAII and because of that connections have to be managed more explicitly.

Assuming that we had a Cassandra instance running at localhost and it is configured to contain a standard column family “Users” in keyspace “Keyspace1″, we could use the Scalandra API to insert and read data like the following example.

import com.nodeta.scalandra._
import com.nodeta.scalandra.serializer.StringSerializer
import com.nodeta.scalandra.pool.StackPool

val pool = StackPool(ConnectionProvider("localhost", 9160))

pool { connection =>
  // Let's create a client which assumes everything is a String
  val client = Client(connection, "Keyspace1", StringSerializer)

  // Let's insert some data to Cassandra
  client.insertNormal(
    ColumnParent[String]("Users", "jsmith"),
    Map("first" -> "John", "last" -> "Smith")
  )

  // Slice all results from Column Parent
  // None parameters are lower and upper bounds for slice
  client.slice(
    ColumnParent[String]("Users", "jsmith"),
    None,
    None,
    Ascending
  )
  // Returns data from previous insert

  client.get(ColumnPath("Users", "jsmith", "first"))
  // Returns Some("John")

  client.get(ColumnPath("Users", "jsmith", "nonexistent"))
  // Returns None
}

As the Casssandra data model is basically a multi-dimensional map, we’ve built a Map-like interface to Cassandra. It is not very polished in its current state. Mutations work, but are not always intuitive to work with because they might require a Scalandra Map object as parameter. Using the previously inserted data, the map model could be used like this:

import com.nodeta.scalandra.map.StandardRecord
import com.nodeta.scalandra.ColumnParent

class User(protected val connection : Connection, key : String
 ) extends StandardRecord[String, String] {
  protected val path = ColumnParent[Any]("Standard1", key)
  protected val keyspace = "Keyspace1"
  protected val columnSerializer = StringSerializer
  protected val valueSerializer = StringSerializer
}

pool { connection =>
  val user = new User(connection, "jsmith")

  // User is basically the same map as inserted before
  user("first") // returns "John"

  // But also, slice actions exist
  user.slice("bar", "foo")
  // Returns Map("first" -> "John")

  // Insert value
  user("age") = "53"

  // John doesn't need to have a last name so let's remove it
  user -= "last"
}

Scalandra Git repository is located at Github. We’ve also generated Scaladocs to help with usage information.

If you have any comments or use this, please drop us a line. Also, patches are welcome :)

Flowdock update: Time-lapsed daily scrums

Karri Saarinen July 21st, 2009

A quick update. Along with elegant git branching, we’ve been busy taking Flowdock forward.

To show you a bit about our processes, we have been recording our daily scrum stand-ups and now compiled it all to a single time-lapsed video.

As you can see in the video, in start of each sprint we have our stories, represented as white A5s and tasks as Post-its on the left side of the whiteboard. Stories are prioritized from top to down, top being the most important.

When a task—for example, “make a time-lapse video”—is put on the board, it’s moved from left to right according to the approximate amount of work done, measured in Zörgöns. On the most right is the “done” column, where tasks regarded as complete are moved.

Video holds about 4,5 sprints (10 weeks) of daily Scrums in 30 seconds. Check it out below.

Read the rest of this entry »