Raspberry Pi in text mode

After a little exploration from the command line, startx brought up the GUI.

Raspberry Pi running X

As well as the composite video output, the Raspberry Pi supports HDMI. My monitor (a Viewsonic VX2235WM-3) has VGA and DVI inputs, so I ordered the AmazonBasics HDMI to DVI Cable. Connecting up to my monitor, I was disappointed to see no video signal whatsover - the monitor wasn't seeing the Raspberry Pi at all.

Googling around, I discovered that you can set various configuration options that are read before the Raspberry Pi even boots. With a little experimentation, I found that setting

hdmi_force_hotplug=1

in config.txt solves the problem - I see video output from the moment I power up the Raspberry Pi! This makes sense - the description of hdmi_force_hotplug is "Use HDMI mode even if no HDMI monitor is detected" - I'm guessing the cable is not signalling the presence of a monitor to the Raspberry Pi, so it decides that it doesn't need to send HDMI output.

Watch this space for more Raspberry Pi fun!

Here's a completely unofficial, unsupported recipe for running your own Node.js version on Heroku. These instructions are based on those at the Heroku Node.js Buildpack repository, with some extra steps that I found were necessary to make the process work. Note that buildpack support at Heroku is still evolving and the process will likely change over time. Please leave a comment if you try the instructions here and they don't work - I'll do my best to keep them up to date.

Before you start, update the heroku gem, so it recognizes the --buildpack option:

gem update heroku

(Thanks to 'tester' for leaving a comment reminding me that using an out of date heroku gem can result in the error message ! Name must start with a letter and can only contain lowercase letters, numbers, and dashes.)

Note: If you just want to try out a completely unofficial, unsupported Node.js 0.6.1 on Heroku, just create your app with my buildpack repository:

$ heroku create --stack cedar --buildpack http://github.com/metadaddy-sfdc/heroku-buildpack-nodejs.git

Otherwise, read on to learn how to create your very own buildpack...

First, you'll need to fork https://github.com/heroku/heroku-buildpack-nodejs. Now, before you follow the instructions in the README to create a custom Node.js buildpack, you'll have to create a build server (running on Heroku, of course!) with vulcan and make it available to the buildpack scripts. You'll have to choose a name for your build server that's not already in use by another Heroku app. If vulcan create responds with 'Name is already taken', just pick another name.

$ gem install vulcan
$ vulcan create YOUR-BUILD-SERVER-NAME

Now you can create your buildpack. You'll need to set up environment variables for working with S3:

$ export AWS_ID=YOUR-AWS-ID AWS_SECRET=YOUR-AWS-SECRET S3_BUCKET=AN-S3-BUCKET-NAME

Create an S3 bucket to hold your buildpack. I used the S3 console, but, if you have the command line tools installed, you can use them instead.

Next you'll need to package Node.js and NPM for use on Heroku. I used the current latest, greatest version of Node.js, 0.6.1, and NPM, 1.0.105:

$ support/package_node 0.6.1
$ support/package_npm 1.0.105

Open bin/compile in your editor, and update the following lines:

NODE_VERSION="0.6.1"
NPM_VERSION="1.0.105"
S3_BUCKET=AN-S3-BUCKET-NAME

Now commit your changes and push the file back to GitHub:

$ git commit -am "Update Node.js to 0.6.1, NPM to 1.0.105"
$ git push

You can now create a Heroku app using your custom buildpack. You'll also need to specify the Cedar stack:

$ heroku create --stack cedar --buildpack http://github.com/YOUR-GITHUB-ID/heroku-buildpack-nodejs.git

When you push your app to Heroku, you should see the custom buildpack in action:

$ cd ../node-example/
$ git push heroku master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (11/11), 4.02 KiB, done.
Total 11 (delta 1), reused 0 (delta 0)

-----> Heroku receiving push
-----> Fetching custom build pack... done
-----> Node.js app detected
-----> Fetching Node.js binaries
-----> Vendoring node 0.6.1
-----> Installing dependencies with npm 1.0.105

Dependencies installed
-----> Discovering process types
Procfile declares types -> web
-----> Compiled slug size is 3.3MB
-----> Launching... done, v6
http://strong-galaxy-8791.herokuapp.com deployed to Heroku

To git@heroku.com:strong-galaxy-8791.git
cd3c0e2..33fdd7a  master -> master
$ curl http://strong-galaxy-8791.herokuapp.com
Hello from Node.js v0.6.1

w00t!

Note: Due to an incompatibility between the default BSD tar on my Mac and GNU tar on Heroku, I saw many warnings while pushing my Node.js app to Heroku, of the form

tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'

These are annoying, but benign - the push completes successfully. If you're on a Mac and you want to get rid of them, add the line

alias tar=gnutar

just after the opening #!/bin/sh in both package scripts.

Do feel free to leave any suggestions for PId in the comments here, and have a good weekend, identity folk!

Heroku's announcement of the public beta of their new 'Celadon Cedar' stack, including Node.js support, inspired me to try out Ryan Dahl's Node Chat demo server on Heroku. Getting it up and running was very straightforward - I went to GitHub, forked Ryan's node_chat project to my own account and grabbed the source:

ppatterson-ltm:tmp ppatterson$ git clone git://github.com/metadaddy-sfdc/node_chat.git
Cloning into node_chat...
remote: Counting objects: 183, done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 183 (delta 117), reused 168 (delta 110)
Receiving objects: 100% (183/183), 50.07 KiB, done.
Resolving deltas: 100% (117/117), done.

Now I could create my Heroku app...

ppatterson-ltm:tmp ppatterson$ cd node_chat/
ppatterson-ltm:node_chat ppatterson$ heroku create --stack cedar node-chat
Creating node-chat2... done, stack is cedar
http://node-chat2.herokuapp.com/ | git@heroku.com:node-chat.git
Git remote heroku added

...and add the couple of files that Heroku needs to run a Node.js app (see the excellent Heroku docs for more info):

ppatterson-ltm:node_chat ppatterson$ echo "web: node server.js" > Procfile
ppatterson-ltm:node_chat ppatterson$ echo "{ \"name\": \"node-chat\", \"version\": \"0.0.1\" }" > package.json
ppatterson-ltm:node_chat ppatterson$ git add .
ppatterson-ltm:node_chat ppatterson$ git commit -m "Heroku-required files" Procfile package.json
[master a7617af] Heroku-required files
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 Procfile
create mode 100644 package.json

Now everything is ready to deploy:

ppatterson-ltm:node_chat ppatterson$ git push heroku master
Counting objects: 187, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (67/67), done.
Writing objects: 100% (187/187), 50.40 KiB, done.
Total 187 (delta 118), reused 182 (delta 117)

-----> Heroku receiving push
-----> Node.js app detected
-----> Vendoring node 0.4.7
-----> Installing dependencies with npm 1.0.8

Dependencies installed
-----> Discovering process types
Procfile declares types -> web
-----> Compiled slug size is 2.9MB
-----> Launching... done, v4
http://node-chat.herokuapp.com deployed to Heroku

To git@heroku.com:node-chat2.git
* [new branch]      master -> master
ppatterson-ltm:node_chat ppatterson$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         starting for 3s     node server.js
ppatterson-ltm:node_chat ppatterson$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         up for 6s           node server.js
ppatterson-ltm:node_chat ppatterson$ heroku open
Opening http://node-chat.herokuapp.com/

And, just like that, my chat server is up and running and I see it in my browser. It all works nicely - I can hit the URL from a couple of browsers and see all the chat messages going back and forth. Only one problem, though - I'm seeing errors when the chat server is idle:

A look at the logs reveals that connections are timing out.

2011-06-14T19:10:44+00:00 app[web.1]: <Pat2> Hi there
2011-06-14T19:10:44+00:00 heroku[router]: GET node-chat2.herokuapp.com/send dyno=web.1 queue=0 wait=0ms service=6ms bytes=16
2011-06-14T19:10:44+00:00 heroku[router]: GET node-chat2.herokuapp.com/recv dyno=web.1 queue=0 wait=0ms service=3520ms bytes=102
2011-06-14T19:10:53+00:00 app[web.1]: <Pat> Now I can talk to myself - woo hoo!
2011-06-14T19:10:53+00:00 heroku[router]: GET node-chat2.herokuapp.com/send dyno=web.1 queue=0 wait=0ms service=2ms bytes=16
2011-06-14T19:10:53+00:00 heroku[router]: GET node-chat2.herokuapp.com/recv dyno=web.1 queue=0 wait=0ms service=9185ms bytes=128
2011-06-14T19:10:53+00:00 heroku[router]: GET node-chat2.herokuapp.com/recv dyno=web.1 queue=0 wait=0ms service=9203ms bytes=128
2011-06-14T19:11:24+00:00 heroku[router]: Error H12 (Request timeout) -> GET node-chat2.herokuapp.com/recv dyno=web.1 queue= wait= service=30000ms bytes=
2011-06-14T19:11:24+00:00 heroku[router]: Error H12 (Request timeout) -> GET node-chat2.herokuapp.com/recv dyno=web.1 queue= wait= service=30000ms bytes=

So what's up? The answer is in the Heroku docs for the new HTTP 1.1 stack:

The herokuapp.com routing stack will terminate connections after 60 seconds on inactivity. If your app sends any data during this window, you will have a new 60 second window. This allows long-polling and other streaming data response.

From the logs, it looks like the connection is being dropped after only 30 seconds, but, no matter, the principle is the same - I need to periodically send some data to keep the connections open. The solution I settled on was having each client set a 20 second timer after it starts its long poll; on the timer firing the client sends a 'ping' message (effectively an empty message) to the server, which, in turn, forwards the ping to all attached clients, causing them to cancel their ping timers and iterate around the long polling loop. Normal chat traffic also causes the timer to be cancelled, so the pings are only sent during periods of inactivity. You can see the diffs here. Now my chat server stays up for hours without an error:

If you grab my fork from GitHub, you'll see I also added message persistence, using Brian Carlson's node-postgres module - mostly because I just wanted to see how easy it was to access PostgreSQL from Node.js on Heroku. The answer? Trivially easy As Jeffrey mentions in the comments, apart from those code changes, I also needed to add the 'pg' module in package.json and the shared-database addon. The new package.json looks like this:

{
  "name": "node-chat",
  "version": "0.0.1",
  "dependencies": {
    "pg": "0.5.0"
  }
}

The command to install the shared-database addon is:

heroku addons:add shared-database

Disclosure - I am a salesforce.com employee, so I'm definitely a little biased in favor of my Heroku cousins, but, I have to say, I remain hugely impressed by Heroku. It. Just. Works.

• Single Sign-On with Force.com and Microsoft Active Directory Federation Services
• Persistent OAuth Tokens in Mobile Apps
• Just-in-Time User Provisioning in Summer '11
• Digging Deeper into OAuth 2.0 at Salesforce.com
• WS-Trust and SAML and OAuth, oh my!

Some topics just don't fit into the main 'flow' over at Force.com, though, so I'll start blogging them here and flag them from Force.com from time to time. Tune in later today for some Node.js goodness...

Packt Publishing were kind enough to send me a review copy of OpenAM, and a very professional job it is. While I've not had a chance to read it in detail, what I have read so far has been excellent - Indira writes clearly, covering every aspect of OpenAM, from the basics of single sign-on to advanced topics such as integrating OpenAM with Google Apps and salesforce.com (yay!) and interacting with OpenAM via its RESTful identity web service interface.

I'll post a more thorough review once I'm done reading, suffice to say for now, if you're working with or evaluating OpenSSO/OpenAM, this should definitely be on your bookshelf! Click here to go to Packt's page for OpenAM.

In itself, it's not that big a deal; I usually notice the bogus post pretty quickly and just delete it, but, by then, it's been tweeted by Twitterfeed, pushed to Facebook, and folks have it in their RSS stream, so they hit the 'links for the day' link and get the default '404 page not found' message. In fact, if you ever delete a post for any reason, you're in the same situation - the link is out there, you can't call it back (even if you go delete it from Twitter and Facebook, it's still out there somewhere!), and people are going to land on that ugly page.

So, I got thinking... That default 404 page isn't really good for much... What if I could just send people to the main page of my blog? Well, with a couple of minutes googling I found a useful blog post on the subject and the WordPress docs for get_bloginfo(), and came up with the following replacement for the default 404 page:

<?php
   header("Status: 301 Moved Permanently");
   header("Location: ".get_bloginfo('url'));
?>

You could do fancier things with a JavaScript redirect that shows a 'page not found' message then redirects after a few seconds, but I prefer the more direct approach

I'm currently reading 'Behind the Cloud'

It's the end of my second week at Salesforce.com, and I seem to have hit the ground running... A day of orientation, a couple of days working through the Force.com and Chatter developer tutorials, then head down on a guide to Getting Started with the Force.com REST API, published alongside the REST API Developer Preview Webinar last Tuesday (the webinar replay is online now).

The getting started guide featured a sample Java web app that acted as an OAuth 2.0 client, redirecting the user to login at Salesforce.com and obtaining an access token with which to interact with the Force.com REST API. Cool stuff, but there were a couple of questions on the webinar asking how to do the same thing from other languages. It took just a few hours to rework the sample web app, first in Ruby, then in PHP. I've also noticed a .NET implementation, by Dan Boris - cool stuff!

I'm commuting up the peninsula about three days a week on Caltrain, which is working out pretty well - there's a station less than three miles from my house, and I can change to the Baby Bullet in San Jose, with the ride to San Francisco taking about an hour. I actually enjoy the time on the train - I just get my laptop and 3G card out and tap away - in fact, I'm on the train right now, somewhere near Palo Alto.

So - two weeks in, I've published three pieces on *force.com, seen some very cool ISV demos at the second AppQuest judging round, and I'm off to Internet Identity Workshop XI tomorrow. If this sounds like your idea of fun, take a look at the Salesforce.com careers page. Lots of opportunities there, and, if you see something you like, don't forget to tell them that sent you!

• Interact with the Force.com REST API from PHP - Force.com Cookbook - PHP sample code that uses the cURL and JSON PHP modules to implement a minimal web application able to obtain an OAuth 2.0 access token and interact with the Force.com REST API.