The link above helped to make sense out of statsd and graphite reports. The values are not alway what you expect if you have small counter numbers (e.g. counters with less than one event per second)
This post is about running Akka on the Raspberry Pi, but because this is so simple to do I will also talk about a simpler development and deployment process.
Clearly from the posts before you can see that the Java JVM on Raspbian is not very fast, so I looked at a process of developing a Scala / Akka application on my Linux desktop and just copy it to the Raspberry Pi as a Jar file and execute there, to remove the tedious wait during the compilation of my source code.
So here we go:
according to the documentation on the Typesafe website you should use the “Universal install”, i.e. download a tarball and copy it to a place of your choice.
tar xovzf typesafe-stack-2.0.2.tgz
sudo mv typesafe-stack /opt
chown -R bin.bin /opt/typesafe-stack
Step 1: Java
I have connected my Raspberry only with power and network (no keyboard/mouse/display) for now and log in via ssh from my Linux desktop. Not only to save cables on the desk, but also to allow copy and paste between desktop and RaspberryPi. I am running Raspbian wheezy 2012-08-16 downloaded from the Raspberry website.
We just brought live the new site of http://www.frontiersin.org, which was my biggest SCRUM project up to now. Here are my first learnings from this project:
SCRUM helped us (we were client on this project) to see much earlier were the development team was going, and had regular feedback points at the SCRUM demos.
However, there was a conflict between the SCRUM tenet of minimal documentation and our customer requirement to fully document the project – which was needed for support and knowledge retention purposes, but also to have an agreed baseline for customer acceptance.
The size of the project (1 year, a peak of 60+ people in 8 teams) was quite amazing, and being a “remote” customer in a different timezone did make communication difficult at times.
Splitting out some special teams was also not strictly in line with SCRUM, but it has worked for us – we have split out a functional analysis and screen design team, which worked always 1-2 sprints ahead of the development, and in the end we also split out a separate test team. Especially the separation of the test team was a violation of the SCRUM tenet of cross-functional teams, but again: it has worked for us in this specific environment.
Each of these points would be probably worth a separate article in the future – let’s see whether I find the time for it.
I would be interested to learn of any experience of other people on larger SCRUM projects.
Another quick tip I found useful – how to set the timezone on a CentOS linux system: http://whomwah.com/2008/10/01/setting-the-timezone-on-centos/