Thursday, June 14, 2012

Beware of JavaScript Library Gluttony

While working on the CareTechSys portal today, I reached the point where I realized I was piling too many client-side APIs on top of each other.

My site uses the following client-side libraries:
I got to the point of adding client-side validation on some views, and quickly realized that this wasn't a trivial task, due mostly to the fact that I'm using the Knocking.js Mapping plugin. 

That plugin is a really great tool for taking json objects you shuttle over via ajax and updating the UI with them (and then to send back to the server for updating later).

The downside to using it is that it's a bit harder to do some custom things, including using the nice Knockout.js Validation plugin, or the jQuery validation plugin.

So I went down the road a bit towards using the latter, and at some point realized, "Man, I'm API pluggin-ing myself to death here." The web gets pretty tangled.

Oh, and I'd also implemented some of the nice new HTML validation features, too. Of course, given that some major browsers still don't fully support those (you'll never guess the main culprit...), I knew I couldn't rely on those too much.

So I went back and decided to, since I already had access to a very nice client-side view modelvia Knockout.js mapping plugin and my custom server side json classes, why not just do validations on those and have some error labels ready to be displayed in the html.

The result is probably less sexy than if I'd piled up yet another JS library plugin on top of the site and written some more crazy code to glue them all together, but at least the pattern is somewhat clear, and that's one less potential source "API-interaction" issues.

It seems like awesome, shiny, fancy libraries are being invented and embraced on a daily basis, and it's really tempting to use everything cool as often as possible and possibly all at once. I think I've reached a point where I've got a soft limit on the number of different third party APIs I'm going to use on a single project.

"All things in moderation". Words to live by, and that includes third party JavaScript Libraries.

Wednesday, June 6, 2012

Mercurial, Google Drive, and Missing revlogs

So I finally took the time to write something couldn't be done in 140 characters.

Today I was wanting to push a locally cloned Hg repo to my account on BitBucket. When I tried, I got hit with a message stating that revision logs are missing for a few files.

Googling it, I found that this means my repo was corrupt. Joy.

Doing a hg verify gave me:

data/CareWeb/jquery/demos/datepicker/animation.html.i@1: missing revlog!
 1: empty or missing CareWeb/jquery/demos/datepicker/animation.html

My first thought was: WTF did I ever check in jquery demo source? Oh well, anyway...

I started following the instructions here to fix my corruption. At some point I realized that Google Drive had renamed some of my hg revision date store files with a (1) in the file name.

I went into \.hg\store\data, found the files that had been renamed, fixed them, and that fixed me up.

In case anyone else is odd enough to use Mercurial and have their source also sitting in a Google Drive.