Nat Pryce wrote a fun little library the other day called code-words. It rips your source into words, and turns the words into a wordcloud. In short, a visual representation of the most common words in your source, and using font size to indicate the more common terms. The aim is to give an introduction into the concepts the code speaks about. And in playing around with it I noticed something interesting.
I’ve been playing around with Meteor recently for an internal LShift project in which I wanted the browser to have a read-only live view onto some timetracking data from TimeTracker as it changes. When a developer records time spent on a particular task, a row is inserted into a Postgres database. Simples.
One of Meteor’s selling points is its transparent client-server data
synchronisation through its powerful Collections API, which is backed by
MongoDB on the server side. This poses a potential challenge for us: how can we leverage the reactive Collections of Meteor yet feed it with Postgres data?
Well, I did manage to wrestle my fork of Bevan Hunt’s (a Meteor contributor!) excellent Meteor Angular Leaderboard demo into live page update as database insertions occur on Postgres. You could extend this to deal with database updates and deletions as well, an exercise left for the willing.
We like parsers. One of the things that really kills the vibe with parsers is a rubbish error message.
Given the technical interestingness of parsing with derivatives, can we get useful error messages out of them?
You are currently browsing the LShift Ltd. blog archives for February, 2013.