Erik Osterman

On Hacker News today there was a mention of how LinkedIn is using the Dust.js templating system. Dust.js is doing what XSLT always promised to do but never delivered on.

In the post, they make a pretty compelling argument for why to use client-side templating. Their problems are all similar to the ones I’ve seen countless times — anywhere a services based architecture is employed like at TV.com.

At LinkedIn they have a services based architecture with applications written in a slew of frameworks across multiple languages. Because of this, it’s hard to re-use visual components. Requiring that all components be written in the same language reduces productivity of developers and hinders their ability to rapidly prototype new features, but having the templates reimplemented in each language makes maintenance a chore. What LinkedIn settled on doing was to only require applications to produce JSON responses (light weight and efficient to render) and rely on client-side (browser) rendering to transform the layout templates with JavaScript. This puts the expensive cost of rendering on the browser (totally scalable), and allows for LinkedIn to cache the layout on CDNs to accelerate their delivery (in addition to the CSS, Images, JS, etc.)

Some might argue that well written HTML+CSS is essentially the same thing. It’s not. First, HTML is verbose; the amount of data needed to even express a simple document far exceeds that of JSON because it includes layout information. Then generating the HTML is an expensive operation on the server involving parsing some source templates in (ERB, JSP, Jinja, Smarty, etc) and assembling them in a string object with lots of concatenation. Lastly, no matter how “light” you make the HTML, you’re still mixing layout with data so you can’t statically cache the layout on a CDN without using ESI (fancy XSLT).

Compare this to simply requiring apps to produce JSON responses. JSON is lightweight and efficient to generate. Most scripted languages have native bindings to libjson so that rendering is done in C.

Lastly, if the thought of templating done entirely in the browser is not appealing (perhaps for SEO reasons), there’s always Node.js which can sit in between; however, this negates the CDN-effect for template caching and puts the computational onus back into your datacenter / cloud.

I’m not a “frontend” guy, so maybe that’s why this immediately appeals to me. I’m curious what frontend developers think about this approach?

For many months now, MobileMe has stopped syncing. This is a big problem when you depend on your phone to be in sync with your laptop so that you don’t miss scheduled appointments, or when you do, to have the contact number of the person you need to contact!

I am embarrased to say the number of hours I’ve spent on resolving this issue. I’ve tried every trick in the book to get it working from resetting sync settings, creating a new user account, to reinstalling OSX! I’ve spent 4 hours just on MobileMe support and even gone in meet with a tech at the Genius Bar. It turns out that my problem has alluded just about everyone.

I’m very happy to announce that I have a fix! It turns out that it’s possible for your keychain to get corrupt on MobileMe. When this happens, it will synchronize your corrupt keychain locally, thereby breaking Sync Services.

Possible solutions:

1. One solution is to reset Sync Data on problematic computer, then re-synchronize the keychain on MobileMe with the local computers active Key Chain. This will very likely not work because you cannot even check the box to synchronize data or when you try to register your computer the wheel spins forever. However, if it works for you, then when it prompts to merge choose to use “this computers” data and not the data from MobileMe. The downside is of course that you will lose any passwords stored in your keychain on MobileMe.

2. The most likely fix to your problem will be to reset your keychain. You will loose all of your stored passwords. (http://support.apple.com/kb/ts1544)

To easily recover from this situation in the future, backup your ~Library/Keychains/*.keychain files. The next time corruption happens (and it will!), just restore your keychain files from a backup so that you won’t lose all of your stored passwords. I am sure with a little bit more investigation, one can delete individual properties of your keychain to determine which key in particular is breaking the sync.

/var/log/system.log:

May 25 15:14:26 Quark mobilemesyncclient[1647]: POST / (FAILED), httpStatusCode:-1, errorType:100 (domain=Error domain 3, code=-9813), transactionState:5, txnId:869FFDB9-A01D-429F-808E-1DAD905BBEF7, auto-retries=0, manual-retries=0
May 25 15:14:26 Quark com.apple.syncservices.SyncServer[1325]: 2010-05-25 15:14:26.719 mobilemesyncclient[1647:903] POST / (FAILED), httpStatusCode:-1, errorType:100 (domain=Error domain 3, code=-9813), transactionState:5, txnId:869FFDB9-A01D-429F-808E-1DAD905BBEF7, auto-retries=0, manual-retries=0
May 25 15:14:26 Quark mobilemesyncclient[1647]: DMMKPATH /Library/Application Support/SyncServices/Clients (FAILED), httpStatusCode:-1, errorType:100 (domain=Error domain 3, code=-9813), transactionState:5, txnId:834B96C7-499F-42AD-AD31-FC23D0FED14D, auto-retries=0, manual-retries=0
May 25 15:14:26 Quark com.apple.syncservices.SyncServer[1325]: 2010-05-25 15:14:26.856 mobilemesyncclient[1647:903] DMMKPATH /Library/Application Support/SyncServices/Clients (FAILED), httpStatusCode:-1, errorType:100 (domain=Error domain 3, code=-9813), transactionState:5, txnId:834B96C7-499F-42AD-AD31-FC23D0FED14D, auto-retries=0, manual-retries=0
May 25 15:14:26 Quark mobilemesyncclient[1647]: PROPFIND /Library/Application Support/SyncServices/Clients/9B259C74-23C2-4D3C-AD7C-7C2AED9BB334.client (FAILED), httpStatusCode:-1, errorType:100 (domain=Error domain 3, code=-9813), transactionState:5, txnId:FBDED450-B0CE-47C0-BD3E-CFBC122F5FC0, auto-retries=0, manual-retries=0
May 25 15:14:26 Quark com.apple.syncservices.SyncServer[1325]: 2010-05-25 15:14:26.990 mobilemesyncclient[1647:368f] PROPFIND /Library/Application Support/SyncServices/Clients/9B259C74-23C2-4D3C-AD7C-7C2AED9BB334.client (FAILED), httpStatusCode:-1, errorType:100 (domain=Error domain 3, code=-9813), transactionState:5, txnId:FBDED450-B0CE-47C0-BD3E-CFBC122F5FC0, auto-retries=0, manual-retries=0

Recently, I learned how broken the dispute resolution process is with Bank of America. I asked them to send me the receipts for 5 recent charges from the same Mexican Food place across the street from me. I love Mexican food, but there’s no way I could have eaten 5 meals in a row from this place (esp when I wasn’t even working from home that week), so something was awry.

Herein lies the rub. If they send me the receipts (which include signatures), I can no longer dispute the charges because now I’m in possession of the sales receipts. Even if the signatures on the receipts clearly show an invalid signature, I have forgone the ability to issue a charge back. I asked the customer support if they could visually verify that the 5 signatures closely matched all my other signatures, but that was impossible. They didn’t have the ability to view the receipts.

I find this totally absurd. Granted, using a signature as a form authorization is incredibly fallible, the fact that it’s not even relevant when disputing a charge, raises the question why do we even need to sign the receipt at all? The back of my credit card is not signed, so that means that they would have been required to view a valid form of identification, which obviously wasn’t the case and is rarely ever the case. I suppose it’s all a moot point. BofA reversed the charges regardless, which was nice of them. I would have just preferred a more thorough process.

I forgot what it’s like when packages just don’t install. Remember, the days of RH6, where you’d have to spend a day tracking down all the dependencies only to discover that some tiny POS package prevented the whole install. That’s kind’a how Fedora is today. In fact, I don’t notice any improvements over the old Redhat package management system. Yum runs about the same speed as it did on my 486; quite a remarkable task given that the processing power on my new system is equivalent to a small server farm of 486 units. How can they make something so slow? Having used Debian for the last few years, I feel entirely spoiled.

I’ve been an avid Thunderbird user for sometime. One of the biggest draws was its Bayesian JMC. It works for the most part, but hasn’t stood its ground against the constantly evolving spammers. Stock/Image spam being the most effective at escaping detection. I’d say about 5% of spam get’s through. If you take that as a part of the 1000 daily spam emails I get, it’s significant. 50 spams is like what we used to get in ’97 without filters… and that was annoying!

Thus, I’ve decided that I can’t be bothered any more by the constant email notifications of new spam! This whole class of problems has virtually disappeared for me by creating a simple filter that checks if the sender is in one of my address books. I keep one for automated emails (like those from eBay or mailing lists) and one for personal contacts. Any mail that’s not in one of these lists and isn’t already flagged as spam get’s shoved into a “Unknown Senders” folder that I can check periodically. Since most of my good email comes from known sources, this wins out over the Bayesian filtering.

This is nothing new. The solution has been around for about as long as spam has been. And I still love the JMC in TB. I didn’t disable them; infact, I still keep training them with those emails that end up in “Unknown Senders”. The benefit is now I it’s just easier to flag them as spam and I can do it once a week instead of once an hour.