Almost a year after I first wrote about dancer, I finally got around to building my first site with it. Overall, it is a pretty nice little framework. If you are already familiar with perl and/or the template toolkit, then I highly recommend this for quickly deploying projects.
In my case, I was able to build and deploy a management interface for a smartos zone server in just a few hours. I fleshed it out over the course of a week or so, and how it is in production managing dozens of zones quite easily. The interface talks to a mysql database, a node.js server I wrote as part of the same project, and even manages a local haproxy instance. All of this in such a tiny space that I keep getting weirded out.
In the future I’ll document some of the pitfalls and oddities that I experienced. I found that once I came around to the dancer way of thinking, it got pretty easy and I’ve rarely had to address the documentation since.
in the past couple of weeks, i’ve started looking into the dancer framework. so far, i like what i’ve seen.
the most obvious difference between this and, say, catalyst, has been the simpler nature and availability of server implementation documentation. it is also structured very much like my homebrewed framework i’ve been using for years, which made it relatively easy to jump into.
setting up an app with by-url authorization and simple authentication was really easy, and having public and private parts of an app is pretty simple as well. the really nice thing is that all the objects and packages i’ve written for other web apps will be able to plug into this with a minimum of fuss, so the migration pains will be relatively minor.
with this in mind, i’ve paused most of my ongoing projects while i look into porting all of the code over to this new framework. turns out this isn’t a huge problem as i’ve had a bad case of coder’s block lately. but this has gotten me excited about a couple of new projects i want to start, so i’m going to be digging into it a lot more over the next few weeks.
while working on my webgame project, i found myself wanting to graph some data. since i like perl, i poked about looking for the best module to use for this purpose, and rediscovered Chart::Clicker. i also remembered why some of the docs for it looked so familiar – i wrote them.
this is actually a pretty sweet module, though it isn’t exactly fast or easy to use. being slow is an issue with clicker that appears to have gotten better over the past couple of years, but it still isn’t snappy enough for live web usage in some cases. being hard to use is more a problem with charting software in general. that’s the curse of charting modules on cpan; none of them are easy to jump into. those that are pretty simple are either no longer maintained, or break once there’s a version increase in one of their dependencies.
i’m ok with each module having a different way of doing things; that’s why we have different modules. i’m even ok with some of them being undocumented, though this shouldn’t be taken to mean that’s a good thing. i can read the source if i have to, and 10% of the time i’ll actually get that far without discarding the module in frustration. examples of both code and the generated images are super useful for these modules, but only a couple actually seem to make that effort.
too bad, too. in my particular case i’ve tried three different modules for what i’m trying to do, and each one has some flaw that makes it undesirable for production deployment. this is the kind of thing that makes people roll their own and upload another charting kit.
this is a quick and dirty little script to help 2 people play twister. it uses the ‘say’ command in OS X to call out the spins.
Continue reading “twister”