Tearing code out of a project is immensely satisfying. Yesterday, I tossed out Denby’s ugly URL shortening mess in order to create a (much nicer!) library version: node-shorturl.
The screenshot below illustrates how Denby uses it in the most simple case — passing a link without choosing a particular service — and a more complex case, using bit.ly with login/key authentication.
As Denby is adopted beyond our cadre of keenly interested alpha testers, users are less likely to be forgiving of faults or crucial feature absence, so I’d like to see how much of the low-hanging fruit I can pick off before our next big leap in usage. (Which, by the way, is likely to be this weekend, soon after the new site streams based server goes live!)
To do that, I need your help.
A deceptively simple question for current and aspiring alpha testers: What do you need to use Denby full-time? Which absent feature has you regularly resorting to the Twitter website? What’s missing?
I’ll start!
The two main things for which I regularly visit the website are:
I’ll be working on both of these today… and I’m sure I’ll be pleasantly distracted by your great suggestions too. 
And for amusement value, here’s an early twitbox prototype:
Yes, Denby has a command line. No, you don’t have to use it. But it’s incredibly quick and convenient for development… which is still ultimately a win for users who don’t (want or need to) care about it!
The client side of Denby is split into two pieces: the core communications module, which provides a programming interface to the Denby server; and the user interface module, which howitzers the awesome straight at your face.
As you can tell from previous posts, my focus right now is a multi-column, “death star console” user interface, but I do plan for more (single-column, mobile, etc). So in a way, the command line in your browser console is just another user interface profile.
Now for some technical details.
A set of functions on the server side is exposed to the client via JSON-RPC over the same Socket.IO pipe from which all your streaming tweets arrive. In the optimal case, this is a websocket or flashsocket, so it’s designed for bidirectional chatter.
When you Denby.send(), a JSON-RPC packet with a unique ID is sent to the server, which does whatever you’ve requested and sends back a response with the same ID attached. That way, the client can keep track of requests and responses.
I have tried to make this as seamless as possible, though I’m still cheating a bit. Surely it would be nicer to call, say, Denby.updateStatus() versus Denby.send('updateStatus')? I will eventually get there, but am also striving to get the balance right between getting out of alpha mode, surfacing features and gold-plating the infrastructure. 
The example below shows one of the simplest functions, updateStatus(text, [params]), called on the server by Denby.send(method, [arg1], [arg2], [argN], callback). I made it accept an arbitrary number of arguments before the callback just to make things a bit easier. The callback is of course a local function, remembered by the JSON-RPC client and called when the server responds.
For the curious, here’s what it looks like in JSON-RPC. First, the client:
{
"jsonrpc": "2.0",
"method": "updateStatus",
"id": 1294764619011,
"params": [
"Showing off the @hellodenby \"command line\" for a screenshot. #denby"
]
}
Then hopefully pretty soon after, the server:
{
"jsonrpc": "2.0"
"id": 1294764619011,
"result": {
"created_at": "Tue Jan 11 17:08:34 +0000 2011",
"id": 24875324479115264,
"id_str": "24875324479115264",
"source": "<a href=\"http://www.hellodenby.com/\" rel=\"nofollow\">Denby DEVEL</a>"
"text": "Showing off the @hellodenby \"command line\" for a screenshot. #denby",
"user": { ... }
}
}
Icky, sticky, yucky Flash because I having trouble getting WebM to work here. Download the WebM version of the screencast if you’d prefer not to use Flash.
(Crap, looks like both the Flash and WebM versions cut out after about 7 minutes, right in the middle of things… sorry about that. I will have to improve my screencast workflow again!)
http://www.hellodenby.com/wp-content/uploads/2011/01/hiatus.flvWhile I’m doing a bunch of plumbing deep down in Denby’s infrastructural guts — much of it involving contributions to the Node libraries we rely on — you should check out the live, bleeding-edge, read-only demo:
https://app.hellodenby.com/ ← early prototype user interface action here!
Some notes for intrepid testers:
<audio> for the win! Your thoughts and suggestions are always welcome — please add a comment to this post. Enjoy!
Update: What’s with Vault Boy? He’s our chipper, unflappable development mascot. At some point, we’ll need a real logo.
Korean and Japanese popping up in the search column, beautifully rendered.
The surrounding border is actually a <fieldset>, so the whole widget looks ripe for text entry (and accepts clicks to focus the <textarea>)… the only remaining hint that this is not true? The resize grabby at the bottom right of the <textarea>. Which will go away.
