As I mentioned in my last post I rewrote one of my personal apps (WebCritic) to use Web::Simple over the Thanksgiving holiday. It was exciting, writing one of the first apps to use the brand new Web::Simple. Of course, that also meant that I had to read incomplete doc, deal with examples that didn’t work, and in general just deal with the whole hassle of an immature project. Of course that was rewarding though, because I got a chance to help beef up the doc some, fix the broken examples, and convince mst to add a basic feature that will allow me to run the server standalone.

There are two cool, unqiue features of Web::Simple that I’ve used so far. The first is the use of HTML::Tags, which is undocumented so far, but super easy to use. See my last, and already linked to, post for an example of that one. Or if you are curious see my use of it. The nice thing is that I can write my html all nicely formatted or whatever, and the server outputs it without extraneous whitespace.

The other feature I’ve used allows really dumb, static serving for a Web::Simple app. Normally that would be discouraged, but because my app is meant to be run by devs from the commandline I kinda need this. Check it out:

So basically the static matcher just reads in a file under the static location and spits it back out. I haven’t checked what happens if you put ‘..’ in the path or anything like that, but again, this is for local usage, so I won’t stress much over it.

And because Web::Simple isn’t really geared to be a standalone server, I also redid the view part, which was entirely ExtJS, to use jQuery. Basically to use the Ext Grid I was loading the largish Ext javascript, the Ext css, and numerous images. jQuery really solves different, more basic problems, whereas Ext is an entire UI framework. I love Ext and think that all commercial, large scale projects should consider it. On the other hand, Ext has a weird license which makes me nervous including it in an OS project. Technically that’s ok, but if someone were to use my OS app to make money, I think they might have to pay the Ext people, which doesn’t sit nicely with me. Also it’s a huge framework that I was using probably 5% of for my project.

So instead of using the Ext Grid I just have a sortable table with columns that can be toggled. I do still miss the qtip (nice mouseover text) and general organization that I got from using the Ext framework, but I think the former can probably be solved with some research, and the latter is just my lack of knowledge coding “bare metal” javascript. Of course it’s not really bare metal since I’m using jQuery, but it’s certainly much closer.

In general this has been a lot of fun. Normally I’m a fan of large frameworks. At work we use (and I love!) ExtJS, Catalyst, Moose, and DBIx::Class. All of them (except maybe DBIx::Class) are probably the largest frameworks in their respective fields. But I get some perverse pleasure (and I do mean perverse) from using such a minimalistic toolset. I’d say that the switch to jQuery was warranted as Ext can significantly slow down the browser. The switch to Web::Simple over CGIApp was pretty much just for fun, but I learned a lot, and that’s certainly worth something.

Lastly, since revisiting this I realize that I should release it to CPAN. Once it’s complete (which depends on the next release of Web::Simple) I’ll release it. I’d expect my end of that to be done before the end of the week. As for Web::Simple, I’m not sure what else needs to be done to consider it release worthy, but I’ll be doing what I can to make that happen as well.

Ok, you guys asked for it. I have updated WebCritic to be a lot leaner and meaner. Get the new version at the same great place.

It now runs entirely in it’s own lightweight server. No apache or mod_perl needed. It now uses CGI::Application::Server. It no longer uses CGI::Application::Dispatch, as my end goal no longer requires it. CAS fills the gap that CAD did for me. I also removed all of the lines that needed perl 5.10 because I wasn’t actually using any perl 5.10 features. If I ever do use perl 5.10 features though I will leave it as an exercise to the user to backport the code. Because it’s a user run server I no longer run a separate critic server. This makes the whole system a lot easier to run as a user. It defaults to criticizing the directory that it is run from and port 5053.

I plan on making a real page for it soon and putting it on CPAN in less than a month. Enjoy!

I like to continually move towards perfection in my code. perlcritic is a tool based on the book Perl Best Practices by Damian Conway. It’s basically lint for perl.

perlcritic is fine as it is if you spend all day on the console, but I usually spend my whole day in Firefox and vim. The only use for my console is checking in source and using irssi. There are a few other things I use the console for, but the point remains, I spend more time in Firefox than I do in the shell. The same is true of my coworkers: we are a windows shop; without installing cygwin using the console is fairly painful. And if it’s a hassle for me there is no way I can convince my coworkers to use it.

So I developed WebCritic. At some point I’ll make a real website for it, but for now this will have to work. I have other things I want to work on more, but I am using this daily at work so I presume that people might use it . Anyway, it depends on:

After checking it out from github you’ll want to start the critic server. It’s just a tiny server that keeps criticisms around for files that haven’t changed. With a fairly small codebase that took the load time down by a factor of 10. It also means that you don’t have to give the world access to your code. Just have the user owning the code run the server and your real webserver will talk with the mini server.

Now as to how to set up the real webserver…

I’ve been using Apache for the whole thing, so it’s been fairly simple getting it all going. If you want help getting it going with IIS I can help. Just leave a comment. Anyway, the config that I use for apache is in the devdocs dir in the repo. Just Include it in your main apache conf file. In ubuntu you only have to make a symlink to it in /etc/apache/sites-enabled.

You also need to start my mini server. I haven’t set up any script to autostart it as I prefer to start it as a user. Basically all you need to do is cd into the repo dir and run

The first time that it checks through the code it will take a while (mine takes 15 seconds,) but after that it should be pretty quick.

After getting all this going you should just have to go to http://localhost:5000/critic and you’ll get a nice listing of all of the criticisms from perlcritic. You can put a .perlcriticrc file in the dir that the server monitors to customize perlcritic. Note that all the columns are sortable and there are more columns that are hidden by default. Most importantly, the javascript will automatically query the webserver for data every 30 seconds, but if you want to know now press Alt+R while the page has focus and the page should reload the data (but not the page itself!)

Enjoy!