Identicons provide a nice visual indicator that's unique to each user on a website. It's unique since it's based on the user's IP, but it's not possible to recover the IP by looking at an Identicon so each user's privacy is protected.
Identicons look cool. Phil implemented it in the comments on his blog:
Any comments I post on Phil's site will have that little pink symbol, while Matt (an anonymous user) will always get that purple design. That's a nice visual cue, but it also prevents me from pretending to be Matt and writing stupid comments. Yes, unfortunately, stuff like that happens.
Things move fast in thissy here bloggersphere.
Don Parks came up with the identicon idea on 1/18, and Jeff Atwood wrote me about it on the evening of 1/20. My obsessive coding compulsion kicked in, and I ported it form a Java servlet to an ASP.NET HTTP Handler and got it to compile. I called it quits at 2 AM and passed it to Jeff, who spent his Sunday debugging a tricky GDI conversion issue (plus cleaning up the code and adding cache optimizations). I was calling Graphics.RotateTransform(turn * 90, MatrixOrder.Append), but that MatrixOrder.Append was causing each of the nine tiles on the identicon to overwrite the previous, so all you saw was the last written.
Monday morning, Phil repackaged Jeff's implementation as a compiled DLL + handler file so it will work in ASP.NET Web Application Projects.
Porting a Java servlet to an HTTP Handler with the JCLA
I used the JLCA - the free Java Language Conversion Assistant. If you've got Visual Studio 2005 installed, there's a good chance you've got the JLCA on your computer, living a lonely life in in C:\Program Files\Microsoft Visual Studio 8\JavaLanguageConversionAssistant. It's a command line utility, but it's not too hard to use. The command I used was:
jconvert "c:\users\jon\documents\identicon_-_2_java_src" /out "c:\projects\identicon"
That works out to jconvert (source folder) /out (destination folder). Not too tricky.
The JLCA creates an HTML conversion report (IE only) in the root of the target folder with all the warnings and errors. I'm glad I didn't spend much time with it, because all the information was copied into the source as comments.
At that point, it was time to apply the age old programming technique known as BOIUIW (bang on it until it works). Some highlights:
- First, convert the servlet to an HTTP handler. The best plan there is to just create a new handler and copy the code from the servlet's doGet() method to the handler's ProcessRequest() method.
- Comment out or convert calls to the servlet's log and cfg methods to .NET equivalents.
- Replace calls to the SupportClass methods (created by the JCLA) anywhere they caused a problem. They help to get things close to compiling, but in some cases it was simpler to just replace them with the .NET equivalents. As an example, JCLA created SupportClass.MessageDigestSupport, which I replaced with System.Security.Cryptography.SHA1CryptoServiceProvider.
- Slightly interesting - the Java code used sbyte, but the .NET SHA1 message dictionary hash provider creates a byte. You can convert from a byte to an sbyte by first casting to an Array object: sbyte hashedIp = (sbyte)(Array)hashedIpBytes;