Just a couple weeks ago I was wondering how Google made its sparklines for Google Analytics. I was creating a Health Page of sorts for my application (a rudimentary listing of recent performance statistics, like how long it took to get a DB connection). I had designed my stats collection piece to keep track of data over the last 15 minutes or so, hoping to show a chart of recent activity when I hit my health page. I had plugged in the Colt statistics library to perform some calculations on the set of measurements in each minute. I had a lot of data points ready to display.
But I didn’t like how the Java Sparklines library worked, and I couldn’t see an easy way to mimic Google. Then just a short time later, they released their Chart API. So this morning I put my data into their API and the charts came out pretty decent (ignoring the fonts, decimal formatting, and alignment of my other stuff):
I can’t figure out how to get rid of the x and y axes entirely. I mimicked the Analytics chart size of 75×18 (or thereabouts), and it’s close. The Analytics charts also seem to have a minimum 2px buffer of fill along the bottom, so even 0 has some fill below it. They also seem to auto-size so the max measurement it at the top. There are several ways to refine what I’ve started with, but for an admin page that’s full of 80-150 charts, and only viewed by a few people, it’s a decent start.
Please leave a comment if you’ve got any tips on how you use Google’s Chart API to create sparklines.
I’ve registered several domains using Google Apps. Lately I’ve been fiddling with using Jabber with those domains, and I wanted to have a program be able to interact on IM using an account like tim@example.com. Furthermore, I wanted to have everything Just Work.
The place to start was with DNS. Google has a help page about how to setup your DNS so that your Google Apps accounts can be federated with other non-Google Jabber communities. The problem is that neither xmpp4r-simple nor iChat simply work if I use tim@example.com as my JID. Then I stumbled across this post that connected the dots for me.
Here’s a screenshot of how I setup my SRV records over at eNom:
After that, my simple chat listener worked:
require ‘rubygems‘
require ‘xmpp4r-simple‘
im = Jabber::Simple.new(“tim@example.com“, “secret-password“)
puts im.connected?
im.accept_subscriptions = true
while true
sleep(5) unless im.received_messages?
im.received_messages { |msg| puts msg.body if msg.type == :chat }
end
My little “bot” silently accepted new buddy requests, and printed out recent messages every 5 seconds.
UPDATE: Something’s amiss here, I think. I’ll update when I have more details. Guess not. I tried this out on another domain, and thought that things didn’t work right. But I was mistaken. Everything looks good.
I’ve managed to patch together several 10-minute sessions of playtime with Rails over the past few weeks, and the subject I’ve been pursuing is how to make Rails use Google for authentication.
I first played with this idea back in February, after reading Phil Windley’s article on GTalk using XMPP. I grabbed the source of XMPP4R, and hacked it to use the X-GOOGLE-TOKEN in its SASL protocol. It worked, and I was able to issue the XMPP message to Google’s servers to grab my mail — just like GTalk does on Windows. There were a few drawbacks to this, though. First, I had to convince people to type their Google username and password into *my form*. I wouldn’t want to do that. Bad idea. Number 2, there was no way to kill a token once it was requested. If a user left my site and never came back, I’d be able to read his mail forever. Bad idea #2. You can read more on this here and here.
So I waited. I still hoped to use Google’s authentication. With all the security breaches these days, who wants to store passwords, much less credit card info.
Then Google came out with AuthSub. I now had a way to have users type their username and password into a Google web page, and then have Google simply give me a token. It wasn’t too hard to get working. You can see the beginnings of it on gotdone.com. Right now, there’s nothing there but the login, the welcome, and the logout. Eventually I want to offer login either via Google or via Yahoo! BBAuth.
This is cool, since I no longer have to write a silly register form with every app that will ask for your name, email, username, and password. I simply glean it from Google when you give me access. Once you logout, I can tell Google that the token is revoked, and then it can’t be used by anyone else again — including me. Nice.
One of the next steps available via Google is to register my domain with them, and then you won’t see the warning message “Don’t even think of doing this unless you trust gotdone.com” (or whatever it is they actually say).
Yahoo! takes a different approach. You must register your endpoint with them *before* you can use their authentication method. As far as I can tell, this makes it difficult to have your app redirect to localhost during development and your true domain during production. Perhaps they have a developer sandbox I haven’t seen in my 30 second perusal.
Either way, there’s a handicap that you hit with taking either of these roads: you can’t develop on an airplane. Well, more accurately, you can’t login during development unless you have Internet access. If you wireless goes down, if you’re commuting to work in your carpool (not driving I hope), or if you’re stuck at a conference without the $15 it takes to get access, you can’t use your app. Now, that doesn’t mean there aren’t workarounds. You could write your own trivial Rails app that acts as a bogus auth mechanism, you could swap out code so you use one piece of code for prod and one for dev (yikes!), or you could simply sit back and enjoy your plane ride… Yeah. Like that’s gonna happen. In any case, let me know if you’ve got grand ideas about how to adapt your app to offline development with this new authentication paradigm.
So, in conclusion, I think that Google and Yahoo! are on the right track by offering their auth services. Are they perfect? Nope. Are they foolproof? Nah. Are there still security concerns? Absolutely. But I like it better than having your password. And I certainly like it better than having to write “Forgot My Password” code for the zillionth time.
You decide.
