Xerox System Integration Standard - Internet Transport Protocols (aka the "Gray Book")

My friend and colleague Mike Peltzer found this on the NextSpace free counter this morning.  Back when I was a lad at 3Com this was my bible for about 6 months.  Known as the Xerox "Gray Book" it is officially titled Xerox System Integration Standard - Internet Transport Protocols (Xerox, Stamford, 1981). The book specifies the core protocols of the Xerox Network Systems (XNS) protocol suite. Among other things I used it to implement the Sequenced Packet Protocol (SPP) on Mac OS. I'm happy to have this fine, thin volume on my work bookshelf in the nostalgia section.


iUI Source on GitHub

The iUI source code has been mirrored on GitHub for a few months now.  Although both GitHub and Google Code support Git, it has become more clear to me that GitHub provides a superior user interface and workflow.

One feature of GitHub that is particularly nice is the network graph visualizer that graphically shows all commits in a network of repositories (e.g. the iUI repo and forks created by users/contributors.)  The lack of this feature on Google Code makes it much harder to keep track of what is happening on the various "clone" repositories on Google Code.  (Google Code uses the term "clone" repository for what is analogous to a "forked" repository on GitHub.)

The pull request feature of GitHub looks like an improvement over Google Code which has no web user-interface for requesting that code from a clone repository be pulled in to the master.  For iUI we have asked that pull requests either be done via the iui-developers Google Group or via the Google Code Issues Database.

The iUI project is ready and I am anxiously awaiting the first pull request on GitHub.  After a few successful pulls and merges on GitHub it is likely we'll make GitHub the preferred place for forking, pulling, and merging code changes to iUI.  However, we'll continue to use Google Code for it's wiki, issues, and downloads features.


How (not) to do an HTML 5 WebView Mobile App: Facebook vs. LinkedIn

As a user I've long been annoyed by the current Facebook iOS App (especially on my original-model iPad.)  As a developer I've also been disappointed by what a poor example of an HTML-based mobile app Facebook has provided.  Hacker News has a post today which links an article called Here’s why the Facebook iOS app is so bad that explains why.

Among other interesting commentary on the Hacker News post, is a link to an article by LinkedIn about LinkedIn for iPad, that provides some details about their architecture. If you haven't tried the LinkedIn app, it's worth looking at -- if only to cure the feeling of sadness you get from the Facebook App.


The Bootstrap Revolution

Twitter's Bootstrap CSS framework has been wildly successful.  I am using it on some (behind-the-firewall, unfortunately) consulting projects and am very happy with it.

Like anything else successful in tech, it has its detractors, but I'm truly surprised by the lack of substantial criticism. The biggest complaint, which I've made myself and have cautioned clients about, is that if you're not careful your site will end up looking too much like all the other Bootstrap sites that are out there.  This problem occurs if you don't take the time to customize Bootstrap -- something that is relatively easy to do with a little tinkering with LESS.

In Why Bootstrap might be very important Dave Winer argues that this apparent drawback is actually a good thing and draws a comparison between Bootstrap and the original Macintosh Toolbox.  In short, he's reminding us that UI standardization is beneficial.  Read the whole (short) thing and skim the Hacker News discussion it spawned and draw your own conclusions.

Another valid complaint is that sites that use Bootstrap don't completely separate content from presentation in part because key Bootstrap CSS classnames describe layout, not content.  In practice this is only a minor issue and is probably unavoidable with a CSS framework, but it might upset a Semantic Web pilkunnussija.

Bootstrap (and LESS) have changed my perspective on front-end development.  I'd like to apply some of the lessons learned to the iUI Framework, but that's a subject for another time.


Grails Ajax Proxy Plugin

The Grails Ajax Proxy Plugin is now on GitHub.

Over 2 years ago I asked on the grails-user list if there was a Proxy Plugin available for Grails that was suitable for Ajax apps to work around the same origin policy.  I was told that nothing was available, so with a tip from Matt Raible's blog, I quickly wrote one using the proxy servlet from EdwardsTx.net.  It worked for my needs at the time, but nobody on the list had expressed much interest in it and I had a bad experience trying to publish an update to the Grails iUI Plugin, so I gave up.

Recently, I needed the plugin on another project, so I told my client that I'd put the source on GitHub in case they ever needed to modify it.  This week, I mentioned it on the grails-user list and on Twitter and Burt Beckwith submitted a pull request that cleans things up quite a bit.  He also changed the name to Grails Ajax Proxy Plugin.  (I renamed the GitHub repo accordingly and GitHub doesn't provide forwarding -- so if you get a 404 looking for it you're using the old URL.)

With Burt's help, we may even get it published into the Grails Plugins Portal.

(It's enough to make me consider updating the Grails iUI plugin after we release version 0.4...)