Recently, as I was working on a Rails application, I found myself needing to generate a random 5 digit numeric code in order to verify a user entered phone number. Essentially I needed to generate a code that I could have them text to my app from their entered phone number in order to ensure it was theirs. Additionally, I needed to mark the number as “not verified” and generate a new code automatically in the event that they changed it. To handle this, I elected to use ActiveRecord hooks in my model file. It works perfectly, and handles everything automatically in just a few lines of code.

While I had long known about the presence of these hooks, I had not known about the magic of the _was modifier. I could try to explain it, but instead I’ll provide you with a code sample that uses it.

1
2
3
4
5
6
7
8
9
10
11
12
13

before_create :generate_phone_code
before_save :check_for_new_phone_number

def generate_phone_code
  self.phone_code = "%05d" % Random.new.rand(99999)
end

def check_for_new_phone_number
  unless self.phone == self.phone_was
    self.phone_verified = false
    generate_phone_code
  end
end

So now, when a new row in our model is created, we automatically create our 5 digit, zero padded verification code. When the row is edited, we check to see if the phone number has changed using the _was syntax and if so, we generate a new code and indicate that their phone is no longer verified. Simple right?

I haven’t had a ton of time to work on my node.js project lately so I figured I’d just put it out there in its current form as a learning tool for others. In this blog post I’ll walk you through everything I did to get it working and, by the end, you should be able to write your own basic webapps using socket.io.

First, let’s start with an overview of the functionality we’d like to have. We want a semi-real time news feed that can display messages passed in from one or more client applications. In order to tell which application passed in which message, we’d like to have some color coding as well. Since we’re using socket.io we also want to avoid AJAX callbacks in favor of server pushes. Finally - it would be cool to see a count of the number of other people also viewing the news feed.

For this project I’m going to use the Jade templating language, and the Express node.js framework, which provides Sinatra style routing for node applications. Links to each can be found in the project readme.

Lets start off by creating our app and setting it up to use Jade, socket.io, and Express.

1
2
3
4
5
6

var app = require('express').createServer();
var socket = require('socket.io').listen(app);

require('jade');
app.set('view engine', 'jade');
app.set('view options', {layout: false});

We need to import the Express library and call the createServer() method on it to get a server object. We’ll store it in app. Then we import the socket.io library and attatch it to listen on our newly created server. Finally we import the Jade library, set our app to use it as the view engine and configure some basic settings.

Now that we have the basic setup out of the way - lets set up our routes to serve both our main news feed page as well as any javascript or css we may need. If you’re familiar with Sinatra in Ruby and Javascript’s callback syntax - these will make perfect sense to you.

1
2
3
4
5
6
7

app.get('/*.(js|css)', function(req, res){
  res.sendfile("./public"+req.url);
});

app.get('/', function(req, res){
  res.render('index');
});

You’ll see that we match any GET requests for js and css files and pass them along to the “public” dir, which is where we will serve our static files from. Then we’ll take any root level requests and serve up our index view. As we have it written here, node will look for a file called index.jade in the “views” directory, run it through the Jade processor, and then render it out to the browser. At this point, we should probably take a quick look at the index view. There’s nothing complicated here, just a couple of lists and a couple of divs. I won’t go over the syntax of Jade, but it should be pretty self explanatory. We set up some script tags to include JQuery and socket.io from their respective CDNs and a local javascript file for our application specific code. Then we add a couple of lists for our news feed and a footer to display our connected client count.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

!!! 5
html(lang="en")
  head
      title nodeFeed
    link(rel="stylesheet", type="text/css", href="/main.css")
    script(type="text/javascript", src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js")
    script(type="text/javascript", src="http://cdn.socket.io/stable/socket.io.js")
    script(type="text/javascript", src="/feed.js")
  body
    #heading
      h1 News Feed
    #content
      #categories
        ul#category_list
      #feed
        ul#feed_list
    #footer
      p
        span#client_count 0
        |  connected clients

If we were to run the node server now, it would work, but it wouldn’t do anything - it would just render out our basically empty view. Not particularly useful. Now that we have the basic structure in place however, the fun can begin. Let’s get socket.io hooked up and talking to the clients. We’ll start by implementing a real-time count of connected clients. On the server side it will look something like this:

1
2
3
4
5
6
7
8
9
10
11
12

var activeClients = 0;

socket.on('connection', function(client){
  activeClients +=1;
  socket.broadcast({clients:activeClients})
  client.on('disconnect', function(){clientDisconnect(client)});
});

function clientDisconnect(client){
  activeClients -=1;
  client.broadcast({clients:activeClients})
}

We will bind an anonymous function to the socket ‘connection’ event that will execute every time a new client connects. When this happens we will increment the current count of connected clients, and then send out a broadcast containing the count. The socket.broadcast method sends a message to all connected clients. In this case we’re passing some JSON that contains our count. We then use the same syntax to bind a function to execute when the client disconnects. This function simply decrements the count and broadcasts the count back to the remaining clients.

We’re all set on the server side but we need to set up some javascript on the client side to listen for the messages and update the view accordingly.

1
2
3
4
5
6
7
8
9
10
11

function msgReceived(msg){
  $clientCounter.html(msg.clients);
}

$(document).ready(function () {
  $clientCounter = $("#client_count")

  var socket = new io.Socket(null, {port: 3000});
  socket.connect();
  socket.on('message', function(msg){msgReceived(msg)});
});

This code will need to go in the feed.js file we linked from the main view. We’re using JQuery’s document ready function to set up our client side socket and cache the selector for the client count on our page. Node.js runs on port 3000 by default so that’s what we’ll enter here. We’ll then bind a function to execute on the socket’s ‘message’ event. This seems like overkill now as the function is only one line, we could just as easily declare it inline anonymously, but we’ll be building on it in the next step. For now we’ll just update the client count.

At this point we have a working app - you can start up node.js, navigate to localhost:3000 and see: 1 connected client. If you open the page in another tab, you’ll see the counter update to 2 on both pages. Likewise, it will decrement as you close tabs. So far we’ve seen how to set up a very simple node.js app, import the Jade, Express, and socket.io libraries, and pass messages from the server to the clients using “comet” style message pushes. Now that we have the basics down, we’ll work on our news feed in the next post.

Hope you found this helpful - if you want to skip ahead and see the ‘finished’ product you can take a look at the github repo, otherwise we’ll cover the rest in the next post.

While doing the excellent Rails for Zombies screencasts I noticed how nice the color scheme they were using for the embedded code editor was. A little digging through their page source informed me that they were using Mozilla’s Bespin. From there I googled for an existing vim colorscheme that mimicked Bespin. While I wasn’t able to find one - I did find this post where the author had created an emacs theme from a Textmate version of the theme. I ran the Textmate theme file through the excellent coloration gem and ended up with a pretty decent vim theme. I thought I’d share it with anyone else that may want it.

Theme Here - Screenshot

As of last night my blog is completely powered by Jekyll. I made the switch for two reasons: performance and ease of use.

Going with Jekyll has allowed me to shut down MySQL as well as all of the PHP-FPM processes that were previously required to run Wordpress. This saves a substantial amount of RAM and allows more overhead for spikes in traffic. This would have been especially useful last week when one of my posts hit position 3 on hackernews and the frontpage of /r/programming on reddit. Fortunately, I was able to avoid any real downtime - but with barely any RAM to spare. With this setup I should be able to sustain that amount of traffic again easily - all on a small linode instance. All that is required to run the blog now is nginx, which simply serves up static files. Add in some intelligent compression and caching settings and you have a recipie for lightning fast performance with minimal overhead.

For my purposes, Jekyll is also much easier to use. I set up a Rakefile with tasks to publish and create new posts. I can create a post, write and edit it in vim, and then publish all from the command line. This allows me to be super efficient in my workflow and use tools that I’m familiar with. Versions are tracked in git, posts are edited in vim, and publishes happen over scp.

So far the transition has worked quite well, the permalink structure changed slightly which, unfortunately, means I lost the disqus threads for my old posts - but that’s been the only negative so far.

My node.js project is coming along well and I am in the process of writing up a couple of detailed blog posts about it, but in the meantime I’ll leave you with this rant about SOAP.

While at work today I was writing some code to interface with Microsoft’s AdCenter API which, if you didn’t know, utilizes SOAP. My end goal was to POST some data to AdCenter, I had approximately 100 entries, each consisting of three primitive data fields (two 64 bit ints and a string). With any modern, usable, API this would be a trivial task completable in 15 minutes or less - but oh no. Not with SOAP.

For starters you have to point Visual Studio (sigh) to the service reference, at which point nine thousand (yes, that’s nine-zero-zero-zero) lines of code are generated. Next you have to write code to construct your objects and initialize your SOAP client. Only then are you able to actually use the API.

Anyways, all of this went more or less according to plan until I actually tried to run the code. I got an error. Not a descriptive error, or an HTTP status code, or anything that could be used to track down the problem but a “SOAP Error.” That was it. The whole text of the error from the Microsoft API was “SOAP Error.” Well, “no problem” I thought - surely I could step into the method I was calling using my debugger and see what was happening. Unfortunately I was wrong. All I really wanted was the ability to see the XML envelopes that were being generated so I could find out what was happening but alas, Visual Studio abstracts this away from you entirely. I asked a co worker and he helpfully pointed me to some web resources on how to inspect SOAP messages. The absurdity of the solution blew my mind. Keep in mind all I wanted to do is SEE what messages are being passed to the API - a simple enough request.

Long story short, in order to inspect SOAP messages you have to write a class that implements the ICLientMessageInspector interface. This class must implement the AfterReceiveReply and BeforeSendRequest methods. As you’ll see in my example code, I simply output the message to the console and write it to a file so I can look at it later.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class ConsoleOutputMessageInspector
: IClientMessageInspector
{
  public void AfterReceiveReply
      (ref Message reply, object correlationState)
  {
      var fileWriter = new StreamWriter("C:/reply.txt");
      fileWriter.WriteLine(reply);
      fileWriter.Flush();
      fileWriter.Close();
      Console.WriteLine("Received:\n{0}", reply);
  }

  public object BeforeSendRequest
     (ref Message request, IClientChannel channel)
  {
      var fileWriter = new StreamWriter("C:/request.txt");
      fileWriter.WriteLine(request);
      fileWriter.Flush();
      fileWriter.Close();
      Console.WriteLine("Received:\n{0}", request);
      return null;
  }
}

Okay, simple enough, but how do we hook it up? Well, for that we need to create another class. This one must implement the IEndpointBehavior interface. There are four methods we must implement in order to use this interface - but we only care about one of them: ApplyClientBehavior. We need to add our newly created message inspector to the list of client message inspectors.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class ConsoleHeaderOutputBehavior
: IEndpointBehavior
{

  public void Validate(ServiceEndpoint endpoint)
  {
  }

  public void AddBindingParameters
  (ServiceEndpoint endpoint, BindingParameterCollection param)
  {
  }

  public void ApplyDispatchBehavior
  (ServiceEndpoint endpoint, EndpointDispatcher dispatcher)
  {
  }

  public void ApplyClientBehavior
    (ServiceEndpoint endpoint, ClientRuntime clientRuntime)
  {
      var inspector = new ConsoleOutputMessageInspector();
      clientRuntime.MessageInspectors.Add(inspector);
  }
}

Alright, now we’ve done that - but our code still doesn’t actually do anything. What we need to do next is enable our newly created behavior. You can do this one of two ways - in your application configuration or programmatically. I chose the latter. To do this you add your new behavior to your instance of the SOAP client like so:

1
2

var behavior = new ConsoleHeaderOutputBehavior();
_client.Endpoint.Behaviors.Add(behavior);

Now, finally, the SOAP XML envelopes that our client sends and receives will be written to a file and to the output window for inspection. As you can see, the code is dead simple, but its incredibly frustrating to be forced to jump through hoops in order to do something as basic as seeing what messages your application is sending and receiving. As a proponent of RESTful interfaces its even more frustrating because I’m used to simply typing curl "resourcename" > file to accomplish the exact same functionality.

In my mind SOAP’s biggest failure is what some people consider to be its biggest success - it abstracts away all notion of the underlying HTTP model and replaces it with crutches like code generation.

As an aside - I later ditched the code I’ve shown here and just went with Wireshark. I was able to capture and reassemble the XML messages with it, and it provided a much nicer interface for searching and sorting them.