Tuesday, April 29, 2014

Raspberry Pi Information Radiator: Building The Dashboard

The fifth and final post in a series for building an information radiator using the raspberry pi, it describes how to take the working Dashing dashboard from last time and customize it for our own purposes. I briefly outline the basics of populating a dashboard with widgets and jobs and discuss issues specific to running dashing on the raspberry pi.

Widget Basics


The dashing website describes the basics of a widget in detail. Essentially, a widget is defined using three files: a small amount of html specifying data bindings for the delivered data, style information in a SASS scss file, and event handling code in coffeescript. Once a widget is defined, instances can be created by editing the dashboard's ERB file. You just create a div with a data-view attribute matching a widget's class name and a data-id that is used to route data to the widget. Data can be pushed to the widgets by submitting an HTTP POST to /widgets/<data-id> from an external job or application, or can be pulled using Dashing's job support. The web site describes how to get data into your widgets in more detail. 

Installing Widgets


Because widgets are usually just three files (or four with a job), Dashing comes with the ability to install the necessary files from a GitHub Gist. The installer uses the file extensions of the files of the gist to tell whether the file should be placed under widgets/ or jobs/, as you can see from the Dashing source code. You do this by using the 'install' command followed by the gist id of the widget. For example, the asana tasks gist is https://gist.github.com/willjohnson/6334811 or gist 6334811. To install the widget, we run:

 $ dashing install 6334811  
    create widgets/asana_tasks/asana_tasks.coffee  
    create widgets/asana_tasks/asana_tasks.html  
    create jobs/asana_tasks.rb  
    create widgets/asana_tasks/asana_tasks.scss  
 Don't forget to edit the Gemfile and run bundle install if needed. More information for this widget can be found at https://gist.github.com/6334811  

As you can see, the command installs the files in the proper places and instructs you to continue with other widget-specific installation steps manually. Note that this does not add the widget to a dashboard. It only installs the widget as an available type. You still have to edit your dashboard ERB file to include a widget of the appropriate data-view type and data-id for the job.

Widget Declaration and Layout


Once the widget is installed, we can include it in our dashboard. We simply edit the dashboard ERB file under dashboards/ to include something like the following:

   <li data-row="1" data-col="3" data-sizex="1" data-sizey="2">  
    <div data-id="asana_tasks" data-view="AsanaTasks" data-title="Today's Tasks"></div>  
    <i class="icon-check icon-background"></i>  
   </li>  

As previously mentioned, the important parts for the widget definition are the data-id and data-view. These relate the div to the data event name and widget type, respectively. You can see here that you can also provide data to the widget directly by specifying it with a data- prefix. Here, the title of the widget is set directly rather than using data from a data event.

The li element is to specify how to layout the widget, these inform the location and size of the widget in the dashboard. The data-row and data-col attributes specify the cell that the widget's upper-left corner will be start in. The data-sizex and data-sizey attributes specify the width and height of the widget in grid cells. You can read more about how to position widgets from the Dashing site.


Further Customizations


Armed with the basics, you can create a dashboard customized specifically for your needs. However, I ran into a few issues I feel warrant additional treatment. Some are specific to running on the raspberry pi.

Separating Configuration from Source Code


The first issue I wanted to address was removing the somewhat sensitive information like API tokens and authentication credentials from source control. I found that the widgets typically didn't bother doing this. However, I wanted to publish the complete development history of my dashboard, so I needed to address this up front. I ended up using the dotenv gem to put settings into the ENV array. I then just changed the widgets to use ENV[setting] rather than hard-coding the setting directly in code.

I did run into one snag with this approach. Initially, I loaded the environment directly in the rackup file, config.ru. However, I found this did not load the settings into ENV in time for all the necessary code. Specifically, jobs that referenced ENV outside of the scheduled routines could not see their settings. Looking at the source code, I found that Dashing loads files under lib/ before it loads the jobs. By putting the environment initialization in a file under lib, settings were loaded and accessible as I initially expected. 

Installing Native Gems Through APT


Another snag I ran into was that certain ruby gems needed native extensions. Since these are architecture dependent they need to be compiled for the raspberry pi's ARM processor. While it eventually worked, the time it took to install was extremely long. I found that I didn't have to do this. Raspbian includes packages for certain common ruby packages. Before installing gems that a widget requires through gem install or bundler try installing it through APT first. For example, I installed nokogiri directly like so:

 $ sudo apt-cache search nokogiri  
 libnokogiri-ruby - Transitional package for ruby-nokogiri  
 libnokogiri-ruby1.8 - Transitional package for ruby-nokogiri  
 libnokogiri-ruby1.9 - Transitional package for ruby-nokogiri  
 libnokogiri-ruby1.9.1 - Transitional package for ruby-nokogiri  
 ruby-nokogiri - HTML, XML, SAX, and Reader parser for Ruby
$ sudo apt-get install libnokogiri-ruby
... 

Slow CSS Transitions


Finally, I found that many of the widgets used CSS3 transitions to make the widgets look more visually appealing. However, these transitions did not render well on the raspbery pi. Instead of looking smooth and visually appealing, they often just delayed the widget from showing up quickly. I ended up modifying the offending widgets to not using transitions.

Summary


That about covers the basics and a few snags you might encounter while developing a dashboard for the raspberry pi. I have made the complete source code for my own dashboard available on my github account. Have fun developing your own!

Tuesday, April 22, 2014

Raspberry Pi Information Radiator: From Zero to Dashing


The fourth post in a series for building an information radiator using the raspberry pi, it outlines how I built a Dashing-based dashboard using a raspberry pi and a blank SD card from my Windows 7 x64 machine, using Cygwin.

Installing Raspbian


Before I could do anything, I needed to install an operating system on the SD card for the pi. I chose to use raspbian, but decided to use a raw image instead of NOOBS. For my needs, the extra splash screen and slightly longer boot delay weren't worth it.

Downloading The Image


The first step was downloading the disk image. I got the latest raspbian image using the following:

 $ wget http://downloads.raspberrypi.org/raspbian/images/raspbian-2014-01-09/2014-01-07-wheezy-raspbian.zip  

I used windows explorer to extract the .img file (you can use your tool of choice, of course).

Identifying the Flash Drive Under Cygwin


If you are using Linux, OS X or plain Windows, you can just follow the image installation instructions on the raspberry pi site. However, since I preferred using the Linux-style disk dump (dd) tool under Windows, I needed to determine what Cygwin device corresponded to my physical flash drive. 

First, I inserted the disk into the flash reader of my machine. Windows informed me that it couldn't read the device format (my disk was not formatted) and asked whether I wanted to scan and fix it. I declined, since it wouldn't have found a Windows file system and I'm trying to overwrite the disk with a Linux file system anyway. To see which disk I needed to find, I right-clicked 'My Computer', and selected 'Manage...'. I opened the disk manager by selecting 'Disk Management' under 'Storage' on the tree view to the left. I noted that Windows labelled this as 'Disk 1', and I noted the partitions (the Flash drive had 2, my primary drive had 3).

Next, I read how Cygwin names the drives and it appeared that the Windows 'Disk 1' was going to be Cygwin's /dev/sdb. To reduce the risk of accidentally destroying my laptop's operating system by writing to my primary drive, I looked at /proc/partitions to see that /dev/sdb only had one Windows partition (/dev/sda had three, so it was obviously my primary drive).

 $ cat /proc/partitions   
 major minor #blocks name  
   8   0   488386584 sda <=== Disk 0
   8   1     1228800 sda1  
   8   2   474867708 sda2  
   8   3    12288000 sda3  
   8   16   31166976 sdb <=== Disk 1 (Flash Drive)
   8   17      57344 sdb1  
   

Writing The Image To The Flash Drive


With confidence that I was writing to the correct disk by using /dev/sdb, I ran the following command to write the raspbian disk image directly to the drive:

 $ dd bs=1M oflag=direct if=2014-01-07-wheezy-raspbian.img of=dev/sdb   

I then "safely removed" the flash disk using the normal Windows procedure to ensure everything was flushed to disk. I then removed the Flash media from my laptop's reader, inserted the it back into my raspberry pi and powered it up to boot into raspi-config.

Configuring the Raspberry Pi


Once the device had booted into raspi-config, I configured the device. 

Expand the Root File System


The first thing I did was to expand the root file system. NOOBS does this automatically, but when not using it, running this is necessary to have raspbian's root filesystem use the entire Flash drive's storage capacity.

Change the Pi User's Password


So that I can manage the pi remotely, I changed the pi user's default password. I simply selected 'Change User Password', entered and confirmed an alternative password.

Set Locale, Time Zone and Keyboard


I selected 'Internationalisation Options' then 'Change Locale' and added 'en.US UTF-8'. Then I used this setting to replace the default 'en.GB'. I then selected 'Change Timezone' and set the time zone to US/Eastern.

Advanced Options: SSH and Hostname


Finally, under 'Advanced Options' I selected 'Hostname' and set the name of the device to something better than the default. I then enabled remote ssh access by selecting 'SSH' and selecting 'Enable'.

Fixing the Video Output


On my television, a Vizio E320VL, the video output didn't use the entire screen. At first, I thought this was a resolution issue and I used the tvservice commands to set the resolution manually. However, after running the following I determined that it wasn't related to the resolution:

  # Dump the television's device identification data  
 $ tvservice -d edid.dat   
 Written 256 bytes to edid.dat   
 # Parse and display the television's data  
 $ edidparser edid.dat    
 Enabling fuzzy format match...   
 Parsing edid.dat...   
 HDMI:EDID monitor name is E320VL   
 HDMI:EDID found preferred CEA detail timing format: 1920x1080p @ 60 Hz (16)   
 ...   
 HDMI:EDID preferred mode remained as CEA (16) 1920x1080p @ 60 Hz with pixel clock 148 MHz   
 HDMI:EDID has HDMI support and audio support   
 edid_parser exited with code 0   
 # Output the current display settings  
 $ tvservice -s   
 state 0x12001a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60Hz, progressive   

Here I determined that the preferred and actual settings were correct at 1080p. I then tried disabling overscan by editing /boot/config.txt to have the following:

 ##  
 # To use the entire screen on the Vizio  
 ##  
 disable_overscan=1  

After restarting, I was happy to see the output use the entire screen.

Updating Packages


So that I didn't have to worry about outdated packages, I decided to update them before continuing.

Removing Wolfram Engine


I had problems updating with the gigantic wolfram-engine package. Since I won't be using it, I removed it by running the following:

 # Wolfram failed to upgrade due to space before, so I removed it  
 $ sudo apt-get remove wolfram-engine  
 $ sudo apt-get autoremove  

Upgrading The Packages


Once I was sure that the upgrade would succeed, I upgraded the packages:

 # Upgrade packages using apt  
 $ sudo apt-get update  
 $ sudo apt-get dist-upgrade  

After this was done, I was ready to install Dashing.

Installing Dashing


Following the 'Getting Started' instructions from the Dashing site, I ran the following:

 # Install shopify's Dashing (with verbose to see progress)
 $ sudo gem install dashing -V  
   
 ERROR: Error installing dashing:  
     ERROR: Failed to build gem native extension.  
...
 /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mkmf (LoadError)  
     from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'  

Doing a quick google search, I found that this is caused by tools missing for ruby development. Raspbian doesn't come with the ruby-dev package installed, so I installed it:

 # Need to install ruby-dev  
 $ sudo apt-get install ruby-dev  

I then re-ran the gem install command and it completed successfully. It did take a noticeably long time, which I presume was spent using the dev tools to compile for the raspberry pi's ARM processor.

Creating and Running a Dashboard


After dashing was installed, I continued the 'Getting Starting' instructions by creating my own dashboard:

 # Create a 'Dashing' dashboard  
 $ dashing new dashboard  

That completed successfully under the subdirectory 'dashboard', so I continued to try and bundle it:

 # Bundle the dashboard application  
 $ cd dashboard  
 $ bundle  

However, the bundle command was not installed. So, I installed it:

 # Install bundler (raspbian has package through apt)  
 $ sudo apt-get install bundler  

After installing bundler, I was able to successfully re-run the bundle command. I then tried running the dashboard using the final 'Getting Started' command, but got the following error:

 # Try to start my dashboard  
 $ dashing start  
 /var/lib/gems/1.9.1/gems/execjs-2.0.2/lib/execjs/runtimes.rb:51:in `autodetect': Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)  
     from /var/lib/gems/1.9.1/gems/execjs-2.0.2/lib/execjs.rb:5:in `<module:ExecJS>'  
     from /var/lib/gems/1.9.1/gems/execjs-2.0.2/lib/execjs.rb:4:in `<top (required)>'  
 ...

The problem was a missing JavaScript runtime, necessary for running the server-side coffeescript code. So that I didn't have to compile V8 for the raspberry pi's ARM architecture, which takes a long time, I decided to just install the raspbian node.js package:

 # Installing therubyracer takes forever on the pi, using nodejs instead... 
 $ sudo apt-get install nodejs  

I then re-ran dashing start again and it successfully started up on port 3030. To verify that everything was working I accessed it remotely using a web browser by accessing: http://<raspberrypi-host>:3030/.

This lays the foundation for developing the dashboard, now all one has to do is to customize the widgets and configure the raspberry pi to boot into the dashboard.

Saturday, April 5, 2014

Raspberry Pi Information Radiator: Booting into a Browser

The third post in a series for building an information radiator using the raspberry pi, today we'll look at an approach for making a raspberry pi (running raspbian) boot up directly into a web browser. This was necessary for the information radiator since it was based on Dashing, a Ruby-based web application. While there were a number of articles describing how to boot into a browser, none of them worked in a way that was both simple and worked reliably.

The Application Script


So that I didn't have to debug the application startup and the boot process together, I developed a simple, but effective startup script for the application. It assumes there is a graphical environment running before it starts. The simple script starts dashing, waits for it to be available via HTTP and then starts the midori web browser in application mode, using our dashboard URL. I created the script in the pi user's home directory as $HOME/start-dashboard.bash.
First, let's setup the script to exit immediately on failure of a command:
 
 set -o errexit  

Now, let's start Dashing:

 URL=http://localhost:3030/sampletv  
  
 ##  
 # Start the dashboard, if URL is not already available  
 ##  
 if [ "$(curl --output /dev/null --silent -w '%{http_code}' --fail $URL)" != "200" ]; then  
  cd $HOME/dashing_sample  
  dashing start >& /dev/null &  
 fi    

Starting the application took much longer than starting the web browser. This meant that the browser loaded and showed "page not found" response. At least one other browser boot approach I found used midori's -i flag to periodically reload the browser. This would have worked except that the Dashing page loads take long enough on the pi that reloading periodically would have looked awful. It also would have shown the 404 page until Dashing started up. Rather than immediately starting the browser, I decided to simply wait until the dashboard URL was available to start the browser:


 ##  
 # Wait until the dashboard is up and running  
 ##  
 until [ "$(curl --output /dev/null --silent -w '%{http_code}' --fail $URL)" == "200" ]; do  
  echo -n "Waiting for ${URL}..."  
  sleep 2  
 done  
   
 echo "Starting web browser..."  
 midori -e Fullscreen --app "$URL"  
   

With that, our application startup script is complete. It starts Dashing, waits for our dashboard to be available over HTTP and then starts the web browser in app mode using our dashboard URL. All we need to do now is to use it during the raspberry pi boot process. The complete script:

 #!/bin/bash  
   
 set -o errexit  
   
 URL=http://localhost:3030/sampletv  
   
 ##  
 # Start the dashboard, if URL is not already available  
 ##  
 if [ "$(curl --output /dev/null --silent -w '%{http_code}' --fail $URL)" != "200" ]; then  
  cd $HOME/dashing_sample  
  dashing start >& /dev/null &  
 fi  
   
 ##  
 # Wait until the dashboard is up and running  
 ##  
 until [ "$(curl --output /dev/null --silent -w '%{http_code}' --fail $URL)" == "200" ]; do  
  echo -n "Waiting for ${URL}..."  
  sleep 2  
 done  
   
 echo "Starting web browser..."  
 midori -e Fullscreen --app "$URL"  
   

Hide the Cursor with Unclutter


By installing the unclutter package, the cursor will hide itself if left inactive for a short period. To clean up the interface by automatically hiding the cursor, install unclutter:

 sudo apt-get install unclutter  

Starting the App using LXDE's Autostart


At the time of this post, raspbian ships with the lightweight X11 desktop environment, or LXDE. We can configure the pi user's LXDE autostart setup to run our application startup script automatically. This leaves the default LXDE autostart configuration intact. First we have to create a user autostart file:

 # create an LXDE config directory for the pi user  
 mkdir -p $HOME/.config/lxsession/LXDE  
   
 # Create a new autostart file using your text editor
 vi $HOME/.config/lxsession/LXDE/autostart  

Then using our text editor, we add the following to our autostart configuration:

 # Turn off the screensaver  
 xset s off  
   
 # Disable blanking the screen  
 xset s noblank  
   
 # Disable display power management features  
 xset -dpms  
   
 # Run dashboard application  
 @/home/pi/start-dashboard.bash  

The xset command is a program that allows us to change the graphical environment's screen saver and power management features. We use them here to make the screen stay on 100% of the time. If we did not do this, after a period of inactivity a screensaver would start, the screen would blank or would be powered down. The xset command is not installed by default. It is part of the x11-server-utils package. To install it:


 # Install x11-server-utils to for xset command  
 sudo apt-get install x11-xserver-utils  

With this, starting the graphical environment as the pi user will automatically start our application. At this point, you can choose to configure booting into the graphical environment any way you like. I opted for manually configure it using /etc/rc.local and disabled the normal desktop tools.

Disabling LXDE Desktop Tools


While I didn't have to, I chose to disable the usual desktop tools that start with LXDE. I didn't want to spend the extra resources since the tools weren't going to be used in kiosk mode. To do this I edited the system-wide LXDE autostart file, /etc/xdg/lxsession/LXDE/autostartand commented out the usual tools:

 ##  
 # The original autostart setup  
 ##  
 #@lxpanel --profile LXDE  
 #@pcmanfm --desktop --profile LXDE  
 #@xscreensaver -no-splash# Install x11-server-utils to for xset command  

If you find yourself needing the full desktop environment later, you need only uncomment these lines and restart the desktop environment.

Starting X11 Using Rc.local


Rather than use raspi-config or /etc/inittab to automatically boot into the graphical environment, I opted for simply starting X11 as the pi user in /etc/rc.local:

 #!/bin/sh -e  
 #  
 # rc.local  
 #  
 # This script is executed at the end of each multiuser runlevel.  
 # Make sure that the script will "exit 0" on success or any other  
 # value on error.  
 #  
 # In order to enable or disable this script just change the execution  
 # bits.  
 #  
 # By default this script does nothing.  
   
 # Start X11 as the pi user  
 su -l pi -c startx  
   
 exit 0  

At this point, you should be able to reboot your raspberry pi and the application should start, the browser should start in application mode, and the screen should not go blank or disable automatically.

Friday, April 4, 2014

Raspberry Pi Information Radiator: Streaming Music

In my last post, I outlined a project I have been working on for building an information radiator using the raspberry pi. For the last few days, I have been using this for my own needs and I have noted that having the information on constant display has worked as a constant reminder and motivator. I quickly noticed the lack of the right metrics, like my overall GitHub and blogging activity, and I am currently working on adding and improving them. Nice!

I also recognized an opportunity to utilize the always-on nature of the radiator more completely. I  like to work to music and this device is always on and has audio hardware powered and ready-to-use (or so I guessed). While I could use it to signal updates to the display or something else purely functional, I figured, why do something functional when it is more fun to play internet radio?

Oh yeah. I'm not getting to those tasks on my task list... right. (it works!)

Since this was surprisingly quick, easy and appeals to the command-line lovers out there (my peeps), I figured I would share it.

Installing CMus

First, we need a tool for playing audio. There are surprisingly many music players for linux. I did not spend much time considering the alternatives. I just used CMus. It heralded command line usage and supported a vi-like command-line interface (I love you emacs, but you are absurdly fat for a command-line editor). Interestingly enough, I found what may be a more direct approach to what I will describe here using mpd (and it can be controlled from vim with vimmpc!). The message here is that this is not the only approach, or even the best. With that said, to install CMus was simple from raspbian:

 # Install CMus using apt  
 sudo apt-get install cmus  

Forcing audio through HDMI

For some reason the audio wasn't working. Fortunately, I noticed settings in the rapsi-config tool for audio and there was an option to force audio through HDMI. After enabling this setting, everything started working.

 # force audio through HDMI  
 sudo raspi-config  

The setting is under 'Advanced Settings' => 'Audio' => 'Force HDMI'. Once I enabled this, I did not have to reboot the device, though your mileage may vary.

Playing an Internet Radio Station

To test out the audio, I quickly searched the icecast stream directory for a reggae station. Once I found a station I could live with, I copied the M3U link location using my web browser. I then started CMus and added the file:
 # Start the player  
 cmus  
 # While you are in the program, type  
 :add url http://dir.xiph.org/listen/4032882/listen.m3u  

The station was added as <Stream>. To start playing it, I simply used arrow keys to select it and hit Enter. Once it was buffered, I heard Bob Marley singing to me from my television. However, when I quit the program the audio stopped immediately. Screen to the rescue!

Using Screen to run CMus in the Background

If you haven't used screen to detach from long-running processes before, try it. It's an awesome tool. It effectively allows you to detach and reattach to a terminal from different sessions. Did I say it was awesome already? It saved my sanity a few times doing OS installs over unreliable connections working in Kenya. After about the third time being disconnected and having to start over, I found this tool. Anyway, I quickly recognized it would work for running CMus in the background as well.

To install it:

 # Install screen using apt  
 sudo apt-get screen  

To start and detach from CMus:

 # Start screen  
 screen  
 # Start CMus  
 cmus  
 # To detach once you started your audio, hit ctrl-a then ctrl-d  

Once you do this, you will be back to a command prompt and you should notice the audio continues playing! You can quit your terminal session, and it will continue running. When you are ready to access the program again, simply login and do the following:

 # Reattach to the previously detached session  
 screen -r  

There is a lot more flexibility and power screen can give you, but this will be enough to run CMus in the background.

Using CMus Remote

With what we already setup, you could operate CMus simply by attaching and reattaching to the running processing using screen. However, CMus provides a program called cmus-remote that allows you to communicate to the running program through a named pipe. If you don't know what that means, that's ok, it enables you to run commands and control CMus without having to attach to the running terminal in screen. Just login and you can do things like the following:

 # Stop the player  
 cmus-remote --stop  
 # Start the player  
 cmus-remote --play  
 # Query the status of the player  
 cmus-remote --query  
 # Sample output from querying  
 status playing  
 file http://dir.xiph.org/listen/4032882/listen.m3u  
 duration -1  
 position 21  
 tag title BobMarley  
 tag genre reggae  
 tag comment http://bobmarley.blogdeouf.com  
 set aaa_mode all  
 set continue true  
 set play_library true  
 set play_sorted false  
 set replaygain disabled  
 set replaygain_limit true  
 set replaygain_preamp 6.000000  
 set repeat false  
 set repeat_current false  
 set shuffle false  
 set softvol false  
 set vol_left 100  
 set vol_right 100  
 # Set the volume  
 cmus-remote -v 80%  
 cmus-remote -v 100%  

One thing I did note was that for some reason, setting the volume to anything below 80% with my setup seemed to mute the audio entirely.

Improving On It

This enables you to play audio, but it does force you to login to the raspberry pi to do it. This worked for me, but I could definitely see wanting to improve on this. Some specific ideas I had were controlling CMus via an IRC bot and stopping and starting based on a work schedule using cron. You might also use something like mpd to eliminate the need for using screen entirely. In any case, it is a simple approach that may spark some of your own ideas. Enjoy!

Wednesday, April 2, 2014

An Information Radiator using Dashing and the Raspberry Pi

For those unfamiliar with the term information radiator, it is similar to what some call information dashboards. The term information radiator apparently comes from the Agile software development methodologies, as our friends over at Atlassian explain:
An information radiator is a large, highly visible display used by software development teams to track progress. The term was first coined by Alistair Cockburn, one of the judges for the Ultimate Wallboard contest, in his book as follows:
“An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions."
There are good things that come out of putting key pieces of information on public display. Such as a greater awareness and inevitable challenging of the metrics, conversations about, understanding of and stake in the quality and relevance of tracked metrics, and some creative solutions for better measuring and improving your work, especially if you find yourself on the right team.

I found the above description, and the site, when scouring the internet for a useful electronic wallboard setup for teams using Jira Agile. I was searching for an information radiator without knowing the name for it and was happy to have found myself in good company. For my purposes, I was interested in broadcasting the following:

  • The number of days left in the Sprint
  • The Sprint burn-down chart, showing the completion rate and remaining work in the sprint
  • The task board, showing what state the various tasks and stories are in
  • Projected release dates (as a calendar), for better overall awareness of projected release timings

Others metrics like code review, quality or test metrics would have been nice, too. However, since they were not directly relevant to what we were struggling with the most I felt it would have worked against my goal of increasing focus and clarity. More information would have worked against gaining an intuition for the key metrics and what they meant.

I pulled together a quick prototype based on the Atlassian article, which was easy with the Jira dashboards and the open social gadgets. Essentially, all of these pieces were already there and the Atlassian plugin framework enabled extending the platform with more gadgets if I needed more. The Jira dashboards were optimized for HD television resolutions, so I just needed a device to display the dashboard when I was finished. After doing some research, I decided I would use a simple mounted HD television driven by a raspberry pi.

However, I didn't have time to build the device before needing to part with the team. Nevertheless, I soon found a need for a similar device again. This time however, I didn't have all the information in Jira. Fortunately, the heroic developers from Shopify built an information dashboard tool called Dashing. By mashing up apis from different sources, and a little elbow grease patching up and rewriting widgets, I was able to design a dashboard that I felt was good enough and could be refined further.

Dashing on the Raspberry Pi
Much like the Jira dashboards, I could easily build dashboards for an HD resolution (1080p), so again it was then just a matter of getting a device to display it. With some configuration, I was able to get a fairly minimal install on a rasperry pi. The big benefits here are size, expense and power consumption. I'll post more details on how I configured Dashing and the raspberry pi shortly. Until then, here is the result of my initial pass. The information is being pulled together from GitHub, Asana, Yahoo! weather, Google Calendar, BBC News, and Twitter.

Continue reading for more detail on how to configure a raspberry pi with Dashing, booting into a browser, building a dashboard and even how you can stream music from your dashboard. I have also published the full source code on GitHub