So, I was reviewing one of my happiest perl-hacks, the Roskilde band finder, and due to a combination of perl line noise and my own inadequate design I simply failed at extending the hack like I wanted to. That's not what your goto quickfixer tool is supposed to offer you, and so I was disappointed and it felt like I lost some ability right there, as perl refused to be friendly to the task at hand.
I was a bit dismayed, because I have after all done a lot of nice little things with perl, and more so, because of the convenience of habit I have after a decade of perl scripts. I've moved a lot of my scripting to ruby, but ruby fails at delivering the level of brevity I have in perl. Or, ruby used to at least. Lately I've been rethinking that point of view. For sure, I'd rather write Eventmachine servers than POE servers. ActiveRecord outside of Rails isn't so bad. And I just discovered mashup-artist HTTParty. Decide on a "one file only" web framework* and I'm pretty much there.
I still need a couple of niceties** - but I think some DSLy goodness fixes most of what I'm missing. But I'm going to start migrating the Roskilde tool and I'll let you know what it ends up looking like.
* I think just Sinatra with erb will do fine.
** Something that does AWK inside ruby, basically - perl is what does AWK inside perl all on its own.
[UPDATE: Morten tells me the config is the same on a mac, so I rewrote the script so it should also run on a Mac with perl installed]
[UPDATE II: The player is here! I can now remote DJ with Spotify!]
Inspired by Morten's suggestion for a DJing feature in Spotify and by the source code for Scrobblify, the Last.fm hack for Spotify, I decided to have a go at making just the feature Morten requested as a hack.
I started looking at the config-files for Spotify, found a file that is continuously updated with the track currently playing. It took a little figuring out to convert the internal hexadecimal ID to the Base62 encoded IDs used in the URLs but I figured it out and here it is - the very first rudimentary Spotify Auto-DJ for Windows.
I am running a version of this perl script which subscribes to file change notifications for the config file with the "now playing" track ID and then submits the latest track to this web server.
You can always find the current track I'm playing here or listen right away here. The web player automatically loads new tracks when I start listening to them.
Via a Jon Udell post I came upon this monster perl script by Jamie Zawinski. One of the authors of the original Netscape Navigator and therefore now a gentleman programmer and nightclub owner. The script generates the event calendar for Zawinskis club - and does so by doing everything itself withing wimping out and installing stuff from CPAN. It' all there: HTML generation, HTML parsing and cleaning, calendar and event logic including leap year calculators, tons of date parsing (which is what brought Udell to the script)
The cost: It's 6500 lines long.
Just a quick little problemsolving exercise I did this afternoon, revolving around the discovery of the ScriptInterpreterSource apache directive.
The setup: I develop on a Windows laptop and deploy my stuff to shared hosting on Linux (specifically Site5, which has good perl support and are happy to install modules). I'm just running small scale stuff, so I just roll out plain CGI. Simpler and faster and works for small values of n. I have shell access and subversion running and that combo Just Works. What was before right now a little annoying was local Win32 test of the scripts without modification, because apache cgi uses the hashbang line to determine the cgi executable - which I also need on the host with a different setting. Thankfully, adding
to the CGI config deals with that. Now Win32 apache looks for the string valueScriptInterpreterSource Registry
in the registry instead of the hashbang and Bob's your uncle.HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command
<DirectoryMatch cgi-bin>directive helpful, regex matching against 10 parallel cgi subdirectories, so I don't have to set each one up separately. And a little gotcha I encountered:
- remember the FollowSymlinks or the ExecCGI is disabled (? or so it seems from error messages)SetHandler cgi-script
Options ExecCGI FollowSymLinks -Indexes
I thought I'd spend a couple of minutes recounting how I got into scripting languages since it was quite a quirky way to get there. When I got started with computing (post "BASIC on an Amstrad") I was using the turbo products, notably Turbo Pascal on the PC which was a really nice environment. I truly miss the simplicity of that interface many many times, in particular I miss how extremely simple it was to write simple graphics to. Those were the days.
Anyway, Turbo Pascal and later Fortran at the university, running through compilers and all that, instilled the notion "software is difficult" in me, which of course is really stupid. Latex and Tex, other environments one is heavily subjected too when doing math, didn't change that perception. I worked a little in matlab and also in mathematica and really, really liked mathematica. Mathematica uses just what you'd expect from functional programming if you're a math major and the convenience of that tool was for me unrivalled at the time.
After University I needed a job, and luckily one was available, but still in the "software is difficult" world, namely doing derivatives pricing in C. The company I worked for had a department for doing systems engineering however. They had done a lot of tooling for our development process - an intricate make based cross platform build system, documentation compilers, memory leak checkers and more. What they were doing was all based on unix tools - but unix tools from way back when. Their celebrated platform of choise consisted of korn shell scripts embedding AWK scripts as HERE documents for text manipulation when required. It wasn't pretty, but they had grown accustomed to it. Intrigued by this I stared learning AWK, which is really a nice language, even if it is kind of limited.
At first I did mainly reporting stuff and the occasional total file or variable renaming, but after a while I started doing heavier stuff. A particular thrill was when I built a code generator, which could take C-style type definitions and output all the boilerplate required to present these C types as structured data to Excel formulas. We used this to replace a horrible handwritten mass of Excel interface code. This was clearly one of the finer hackathons I've taken part in: 2 guys 2 days, 16 hours per day. Total workload 64 hours. And it's just so much easier to get right in 2x2x16 tan in two weeks done by one guy.
All of this was done in AWK, including the parser for the template output generator. Clearly the mix of AWK limited capabilities and my limited experience did not produce a very maintainable result.
I did one other very nice project in AWK though, which was a LaTex code extractor that would take sample code from LaTex documentation, wrap the sample code in setup and teardown code and run unit tests on the code. In this way we always knew that the sample code in the product manual compiled and ran as described.
It's still easy to remember the thrill and almost sinful enjoyment in not having a compile cycle. towards the end of my time at Simcorp we were working in template heavy C++ using Visual C++ and the compile times and tremendous ugliness of the error messages was just painful.
Finding AWK restrictive, I turned to perl and has since spent many happy hours with perl. And many painful gutwrenching "I just don't get why this doesn't work" hours too. The plan has been for a long time to switch to python or ruby - we're using ruby at Imity - but recently I have to say that it seems thaty python/ruby just isn't far enough to go. It seems that its time to go fully functional, only I have to admit I haven't yet been able to choose a language to invest in.
So Tim Bray was giving a larger architecture argument why AJAX was good, as opposed to the usual user experience goals: Better distribution or resources - you can do simpler faster requests on the server if the server doesn't have to render the interface, but can leave that to the client. To help in that process Brian IngersonIngy has moved even more processing onto the client by adding an implementation of the Template Toolkit common in perl web applications.
Of course it really gets crazy when people start taking the various "Javascript as VM" seriously. The perl 6 via Haskell effort Pugs has a javascript backend so you can run your entire application client side.
It's interesting that all of this can actually sensibly be combined with web linkyness and RESTful principles to make a truly application dissociated web - like the one we've been dreaming of for a couple of decades.
I'm trying to run Catalyst on my ancient Red Hat webserver, and boy does that suck to install. It requires everything and the default scripts for installation just don't work out of the box.
I finally got it to work, and when it's clean I'll write it up.
As I'm cleaning it out though my main problem is mod_perl itself: When you load a module, it only get's loaded once - so if you have several apps and they, for convenience, maintain their old ancient "backwards compatible" versions of modules, with mod_perl you're sunk.
I would love to hear of any cures for this problem
Meanwhile, Catalyst itself is really easy to use. You write very little code and accomplish a great deal with the code.