I already blogged about RFID readers but now I really need to replace antique 3M software with something better. So, basically, I started with specification:
User should put RFID tag on reader and get output from Koha
Nice and simple. However, readers are connected to Windows machine. And we need some way for reader to push data about new tag to browser. Hmmm... push? Sound like Comet, doesn't it?
Let's see what we need:
Comet server to display page in web browser and push updates
RFID reader program installable on Windows to communicate with serial port and push messages to Comet server
User with a browser
Again, seems somewhat reasonable. Can perl do it? It seems it can:
Meteor server provides perl comet server which required one additional file to provide integration with Koha.
I needed comet server to deliver Koha data because of single origin security in browsers which doesn't allow me to make AJAX requests to Koha directly. On the other hand, this gave me excuse to try out HTML::Query to extract part of page which I needed on server.
I liked this split between Koha and Comet server (even on different boxes and/or network segments), but it came with a price: every page generated in Koha took more than 2 seconds, which was just too slow for nice interactive demo. So, I implemented on-disk caching which is also really nice for debugging. In production version, requests for Koha data might be implemented as forkers (since browser uses AJAX request for it, it makes sense) or I will issue queries directly over Koha's database.
Next step was to add push from my perl RFID reader to Meteor.
This also turned out to be simple: one socket connection to Meteor, and few revisions later I had more or less following protocol which reader could push to comet server as pipe | encoded string:
I also needed web interface in browser.
When I need to do something quickly I often turn to jQuery as long time readers of my blog already know. One additional javascript file in Meteor's public_html directory and we have a working interface.
At first, I created JavaScript object (like hash in perl :-) to keep track of visible tags on screen. But, since each tag is div which has id set to SID of tag, it was easier (and shorter) to just use jQuery to ask DOM if there is element on page. KISS wins again...
So how does it look, you might ask? (You might want to turn volume down, because AudioSwap feature of YouTube should be really considered harmful :-)
This might help solve question is perl dead. Only if it means dead easy. it's 4k of perl code, 4k of JavaScript and 4k of CSS.
I'm preparing walk-through screencasts for workshop about virtualization so I needed easy way to produce console screencasts.
First, I found TTYShare which displays ttyrec files using flash, but I really wanted to copy/paste parts of commands and disliked flash plugin requirement.
It seems that I wasn't only one who wanted JavaScript client for ttyrec. jsttplay can produce screencasts like this one about OpenVZ using plain copy/paste friendly JavaScript within browser.
But, for some parts (like Debian installation under VirtualBox) I really needed movie capture. x11grab option from ffmpeg seemed easy enough to use:
but getting right window size isn't something I want to do by hand. So, I wrote small perl script record-screencast.pl which extract window position and size using xwininfo and pass it to ffmpeg so I don't have to.
We have few mp3 players which no longer work, but are still under warranty. So idea was to pick another device (which will hopefully work longer). However, on-line shops leave a lot to be desired if you want to just do quick filtering of data.
As a very fortunate incident, I stumbled upon Exhibit from SMILE project at MIT which brought us such nice tools as Timeline and Potluck.
So, I scraped web, converted it to CSV and tried to do something with it. In the process I again re-visited the problem of semi-structured data: while data is separated in columns, one column has generic description, player name and all characteristics in it.
In the end, it is very similar to the way Dabble DB parses your input. But, I never actually had any luck importing data into Dabble DB, so this one works better for me :-)
This will probably evolve to universal munger from CSV to arbitrary hash structure. What would be good name? Text::CSV::Mungler?
This is a first post in series of posts which will cover one hack a week on my blog. This will (hopefully) force me to write at least one post a week on one side, and provide some historic trace about my work for later.
No pager is actually a small project consisting of novel idea to share one hash between perl CGI (or stand-alone server, but it doesn't exist yet) and JavaScript. It does so by implementing small subset of HTML::Mason (well, only single-line <% something %> markup), just to look familiar (or syntax-highlight correctly :-)
Proper explanation of that would have to wait for some serious documentation writing...
Update: new upstream version of jQuery (1.0.1) fixed problems in Safari on Mac. Isn't that cool?
I decided to re-implement WOPI, web poll generation software
which I was working on since 2001 (first commercial, and later available
under GPL). With new, totally web-based
user interface. Try it and tell me what you think. This is HTML and
Java Script only, so save doesn't work!