patspam.com

Today I was debugging a Javascript bug in ExtJS + AIR, and I wanted to check rendering in another browser. I created a static html file with the minimal javascript test case embedded in it, but then realised that I needed to load in the ExtJS files from somewhere. With other JS libraries you can use freely available CDNs for this sort of thing, but because ExtJS has funky ideas about licensing, this isn’t an option. What I needed was a quick and easy way to serve up the ExtJS files, which were sitting in a folder on my computer, over http. This sort of thing happens frequently with custom code too, when you attempt to create a static (minimal test case) version of a live site.

Plack has a really neat solution to this problem.

Following a tip from day #5 of Miyagawa’s Plack advent calendar, serving up the current directory over http is as simple as this Perl one-liner:

$ plackup -MPlack::App::Directory -e 'Plack::App::Directory->new

Plack::Server::Standalone: Accepting connections at http://0:5000/

Or if you need the files served over port 80:

$ sudo plackup -MPlack::App::Directory -e 'Plack::App::Directory->new' -p 80

Plack::Server::Standalone: Accepting connections at http://0:80/

• Leave a comment... (0)

At about 11pm on the night before I headed off for the States, Ted the Vet and I sat down to talk Tarpo.

In case you’re wondering, Tarpo is an open source, cross platform Data Management desktop application for Dog Health programs in rural and remote Indigenous Australian communities, written entirely in Javascript.

The last time I blogged about Tarpo was way back in April 2008, and since then I haven’t really touched the code, but in the meantime Ted and his team of helpers have used it to record several thousand House Visits, Medical and Surgical Cases as part of the Maningrida Dog Health program.

Several other Veterinarians have started expressing interest in using Tarpo for their own Dog Health programs, and needless to say, we’ve accumulated a long list of bugs and feature requests over the past 18 months. So this afternoon, with a bit of spare time up my sleeve, I decided to get the ball rolling again.

Tarpo now has a proper project page, which you can visit at: http://pdonelan.github.com/tarpo

As you can see from the url, the code now lives on GitHub. Apart from the front page which has the all-important “Install Tarpo” button, the most important page on the GitHub project page is the Issue Tracker, which I’m hoping Ted and other Vets will use to report all Bugs and Feature requests. With a bit of luck, that will also make it easier for other developers to get involved too.

With these things in place, I started attacking the bit rot. Firstly I had to install Aptana and the Adobe Air plugin, which took several hours and reminded me how much I prefer doing development in Padre! On a side note, I spent a few hours trying to think if there was some way I could rewrite the entire app in Perl (I like Javascript in a twisted sort of way, but I’d rather ditch Adobe Air since it’s a proprietary framework) – but in the end I decided to stuck with the existing architecture, at least for now.

I though about doing it as a wxPerl app (like Padre), but I’d hate to lose the HTML widget set that ExtJS gives me.. hmm that gets me thinking (help me out if you’re reading Gábor or any of the other Padre gurus..) does wxPerl have a modern embedded browser that I could use? Maybe webkit-based one..? Then the backend could be rewritten as a standalone Plack-powered webapp and I’d have all of CPAN at my disposal.. hmm maybe that’s too ambitious, but it does feel like the sort of thing you *should* be able to do with Perl..

I didn’t have much time left to do any real coding after that, except for updating a few dependencies so that Tarpo at least starts up ok on the latest version of Adobe Air (a small victory). But at least now in a position to start attacking the ticket list, which means that real progress can’t be too far off..

• Comments Off

Miyagawa has posted up a screencast of his recent PSGI/Plack talk at SF.pm. I highly recommend it if you’re still getting your head round the whole PSGI/Plack thing or you want to watch a nice recap of recent developments.

I got a kick out of seeing Miyagawa pull up my blog post on PlebGUI in response to someone’s question about porting mod_perl applications (e.g. apps that pass around an Apache $r object) to Plack. For the sake of the guy who asked the question, the way I did it (at least for the first pass) should be equally viable for other mod_perl applications – just create a fake Apache $r object that delegates everything to Plack::Request and Plack::Response (your mileage will obviously vary depending on how much of the mod_perl API your app uses).

• Comments Off