… JT Smith opened the conference with his annual State of WebGUI speech, in which he highlighted many upcoming features in WebGUI 8. In addition, the Contributor of the Year and Colin Kuskie Award for community contributions were announced. This year’s Colin Kuskie award went out to Patrick Donelan. Patrick was recognized for his contributions to WebGUI 8, in particular for single-handedly increasing the performance of WebGUI by over 300%. This year’s Contributor of the Year award recognizes an outstanding business contribution. United Knowledge won the Contributor of the Year award for their dedication to the Template Working Group, which is working towards standardizing all WebGUI asset templates…

via plainblack.com

Thanks guys!

I spent the pre-conference hackathon working on getting WebGUI 8 to run under Mongrel 2, thanks to lestrrat‘s experimental Plack::Handler::Mongrel2. Since WebGUI 8 is a Perl Plack app, it wasn’t an overly complicated task – I spent most of my time getting up to speed on Mongrel2 itself and learning why a language-agnostic web server rocks (ZeroMQ++). Along the way I found a bizarre bug where Image::Magick was causing the server to hang – but apart from that it was smooth sailing.

The pay-off was being able to show off a live demo of Mongrel2 running WebGUI alongside a Python / JSSocket chat app and a streaming MP3 server all on the same domain as part of my “Plack and the Post-Apache Future of WebGUI” talk the next day (the streaming MP3 server meant that I was able to include a You Am I song in my talk which probably no-one at all in the audience recognised..). I also did a live demo of gugod, clkao and c9s’ very cool XDFighter WebSocket demo (again mounted in the same domain as a WebGUI site), with help from Andy who controlled one of the stick figure fighters from the audience via his iPhone.

None of which was very WebGUI-centric, but that was kinda the point: every cool thing that happens in the Perl PSGI/Plack world is now a WebGUI feature by default

The rest of the conference was spent enjoying Wisconsin’s unfair abundance of fantastic locally brewed beer (and fried cheese curd!) and hanging out with all the awesome American and Dutch members of the WebGUI family – many who have attended more WUCs than they can count on one hand (a good reflection of how much fun the WebGUI conferences are).

I’ve submitted a modified version of my talk for the Pittsburgh Perl Workshop (PPW) in October titled s/modperl/plack/, with the intention of ripping out the Plack introduction (people can get a much better version of that at PPW from the horse’s mouth) and replace it with more specifics on how we decoupled WebGUI from modperl (replacing it with Plack) as an example of how others might convert their own legacy modperl applications.

Many thanks to JT and everyone else at PlainBlack for organising yet another awesome Perl / WebGUI conference, you guys rock.

For the next few months I worked through the process of turning the proof of concept into something core-worthy. Primarily that meant removing PlebGUI’s faked Apache2::Request object, completely eliminating any mod_perl dependencies from the WebGUI core and instead baking in WebGUI::Request and WebGUI::Response which are thin layers over Plack::Request and Plack::Response.

By about April most of the basic pieces were in place, performance was looking good, and I’d started the fun task of refactoring WebGUI to take advantage of the value-add features that Plack brings such as Middleware and stealing liberally from other Plack projects such as Tatsumaki‘s streaming API. But there was still lots of work to be done getting the test suite passing again and smoothing off the rough edges. Progress was slow due to my work commitments and frequent travel.

Then three of the main WebGUI committers got involved, first haarg++, then perlDreamer++ and preaction++. The pace accelerated dramatically. This week we officially merged the PSGI branch into the main development branch, meaning that the next major release of WebGUI will officially be a PSGI app!

Huge credit and thanks to haarg, perlDreamer and preaction (and anyone else who contributed too) for getting us over the hump. These guys are also the main driving force behind the other awesome features that are being baked into WebGUI 8, so if you like anything you see in the next version, make sure you buy them a beer or two.

Here are some screenshots of WebGUI with the Plack::Middleware::Debug bar turned on.

Previously, in debug mode WebGUI would append all debug output to the bottom of the page. Now, thanks to haarg’s custom Plack::Middleware::Debug panels, debug messages are contained within the “Logger” panel. Notice also the “Asset Performance” panel, which displays WebGUI::Asset performance metrics. This is only the beginning.

It’s such a buzz to have the PSGI branch merged in; now the real fun starts! I’ll be speaking about the WebGUI PSGI branch at the WebGUI User Conference in Madison in September, and at the rate things are going, who knows how much fun stuff we’ll be able to show off..

I’m also really looking forward to attending YAPC::NA next week (my first YAPC on American soil) and meeting/hanging out with lots other people who have been doing awesome things in the Perl web app space (and beyond). Vive la renaissance Perl!

# app.psgi
use Plack::App::JSP;
Plack::App::JSP->new( js => q{
[ 200, [ 'Content-type', 'text/html' ], [ 'Hello, World!' ] ]
});

# displays: Hello, World!

Given the similarities between Perl and JSON you can’t actually tell if I’m cheating or not from the above snippet.

Let’s try something more convincing:

Plack::App::JSP->new( js => q{
function respond(body) {
    return [ 200, [ 'Content-type', 'text/html' ], [ body ] ]
}

respond("Five factorial is " +
    (function(x) {
      if ( x<2 ) return 1;
      return x * arguments.callee(x - 1);
    })(5)
);
});

# displays: Five factorial is 120

I just pushed Plack::App::JSP to the CPAN.
Thanks to Salvador Ortiz and Miguel Ibarra whose recently released JSP module makes this possible.

Supposedly most Lenovo laptops contain a fingerprint reader that works nicely in Ubuntu via ThinkFinger. However my Lenovo T400s uses different hardware (Upek) that isn’t supported by ThinkFinger.

You can find out what hardware your fingerprint reading is by running:

$ lsusb | grep -i finger
Bus 004 Device 002: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor

If yours says Upek line mine does, you can get it running under Ubuntu (and Fedora etc..) by installing fingerprint-gui. The installation process is a little tedius, but it’s worth it to be able to login/sudo/etc.. with a swipe of your finger.

Probably worth getting a few friends to test how susceptible the reader is to false positives though.

So, perlsharedhosting.com is now officially up and running.

Rather than wasting my time building a web app for the site before the idea has been proven, I decided to use a simple CMS and focus my energies on the content instead (there’s a wonderful irony in using a PHP CMS to deliver content about Perl shared hosting..).

I’ve added quick-start guides on how to install the following core technologies on your shared hosting account:

• local::lib
• cpanminus
• Task::Kensho (the “We support modern Perl” badge of honour for hosting providers)
• Plack
• Dancer

These pages are not in any way supposed to replace the official documentation sources. Ideally, they just tell you what the tool/lib  is, why you need it, and how to install it with minimum fuss. In reality, we also need to list any issues you may run into when using them in a shared hosting environment, but the idea is that we feed this information back to the upstream projects so that workarounds become unnecessary.

I’ve tested two different hosting providers, neither of which I’m going to mention by name here because I’m not trying to actually promote their brand.

• The first one had a major limitation – no access to cc and hence the inability to compile XS modules (their tech support has offered to install CPAN modules on request, but it’s less than ideal).
• The second one has so far passed all tests with flying colours – “cpanm Task::Kensho” works flawlessly, including all the XS modules. This is perhaps not all that surprising given that this is the same hosting provider that I used last year to get WebGUI running under PSGI on a shared account.

I started playing with Dancer for the first time, and soon had live demos of Dancer running in both CGI and FastCGI modes. Those URLs will change in the future but the idea is that we set up live versions of each web framework running on each hosting provider. Maybe in the future we could use a monitoring service to track the reliability and response time of each combination.

So already, the Perl Shared Hosting site has step-by-step instructions for how to run Dancer web apps on a shared hosting account for less than six bucks per month. That’s not half bad.

If you have a shared hosting account on a provider that isn’t listed (or you work for a shared hosting company and want to get yourself listed) then please contact me to get involved.

Next up, we need to add more information about resource limits. I also plan on adding more web frameworks such as Web::Simple, MojoMojo, Catalyst, Tatsumaki, ..

Once we have an idea about what features are most important, I’d like to then turn it around and start contacting the providers to ask them if they will add support for certain features to match (or beat) their competitors. I think there’s real potential for communicating back to the shared hosting providers that there’s a large market for modern Perl hosting, and ideally, what features we need/want. The site may also be useful for feeding back to the Perl toolchain/framework people what rough edges people are running into in shared environments.

• FilePump – speeds up your front-end performance by maximising your YSlow score
• Passive Analytics – a system for analysing website usage data

These features are both now part of the WebGUI core.

Recently Padre::Plugin::Plack, my Plack (the Perl Web Server) plugin for Padre (the Perl IDE) was translated into Dutch, Brazilian Portuguese and French.

I always get such a buzz when I find out that something I’ve worked on has been translated into another language. It sends a clear message that someone found your work useful enough to go to the effort of translating it so that a new community of people could use it. That’s an awesome form of positive feedback, and a great motivator for being involved in open source software.

Thanks translators!

Here’s a silly example:

# A Perl one-liner for the iPhone generation
plackup -MPlack::App::Directory -e 'builder {enable iPhone; Plack::App::Directory->new}'

That makes your current directory browsable as a web app, with some special iPhone meta tags injected so that the viewport is appropriately resized & fullscreen mode is enabled when you launch your “app” from your Home Screen.

Here’s a slightly more usable one – your own personal mobile.search.cpan.org:

plackup -MPlack::App::Proxy -e 'builder {enable iPhone; Plack::App::Proxy->new(remote => "http://search.cpan.org/") }'

You can customise things too:

# app.psgi
use Plack::Builder;
use Plack::App::Proxy;
builder {
    enable "iPhone",
        statusbar => 'black-translucent', # transparent status bar
        startup_image => 'loading.png', # displayed as the app loads
        icon => 'icon.png'; # cutom app shortcut icon
    Plack::App::Proxy->new(remote => "http://search.cpan.org/");
};

Here’s an actual app that I have running on my phone to display the New York subway map (images courtesy of the MTA website):

<!-- index.html -->
<html>
    <head>
        <title>NYC Map</title>
        <style>
            body, img { margin: 0; padding: 0; }
        </style>
    </head>
    <body>
        <script>
            window.scrollTo(300, 700); // Initially zoom in on my local area
        </script>
        <img src="sub1a.gif">
        <img src="sub2a.gif">
    </body>
</html>

# app.psgi
use Plack::App::Directory;
builder {
    enable "iPhone",
        icon => 'icon.png',
        manifest => 1,
        viewport => 'initial-scale = 1, maximum-scale = 1.5, width = device-width',
        statusbar => 'black-translucent',
        startup_image => 'loading.png';
    Plack::App::Directory->new;
};

Use plackup to run the site on your local network, connect via Safari on your iPhone (via wifi) and then use the “Add to Home Screen” option to add an app shortcut to it on your phone. Your 57×57 icon.png image will be used as the app icon, and your 320×460 loading image will appear as the app loads. The viewport string sets the initial zoom scale and limits how far in the user can zoom. Nice and shiny.

With the manifest option enabled, Plack::Middleware::iPhone automatically generates a manifest file and injects the appropriate html to enable HTML5 offline web app caching on your iPhone. This means that your app keeps working once you Ctrl-C the plackup server and walk out your front door. And it keeps on working when you’re stuck in the New York subway system without phone reception, trying to figure out what train you’re supposed to catch to get home.

If you’ve just started exploring how to build iPhone apps with web technologies, I suggest you check out Jonathan Stark’s book “Building iPhone Apps with HTML, CSS, and JavaScript” (online here).

Latest Web::Simple master (git://git.shadowcat.co.uk/catagits/Web-Simple.git) is now using Plack, the perl web server directly for CGI and FastCGI and I hope do do another release shortly with notes on deploying as both on shared hosts (more specifically Dreamhost but with an invitation to bitch if they don’t work on other budget hosts).

mst,  ”Oh Subdispatch, Oh Subdispatch“

Every time someone mentions a cool new web framework like Web::Simple, Dancer or Tatsumaki, my immediate reaction is to start thinking up cool little niche web apps I could build with it. You know, the kind you imagine yourself whipping up during your lunch break, that will probably never get more than 10 curious users but just might turn into the next big thing if only you got it up and running on a public server. And that’s when the second thought immediately arrives: where am I going to run this thing? Do I really think the idea has enough legs to justify paying for a virtual server plan? Can I be bothered going through the pain of figuring out how to deploy it on a shared hosting provider? And normally that’s the point where I sigh wistfully and go back to reading my RSS feeds.

The thing is, with the advent of things like local::lib it’s getting a lot easier to deploy Perl web apps on shared hosting. And with most web frameworks adopting Plack/PSGI, the work required to deploy Perl web apps on budget hosts is converging into a similar sequence of steps.

So this time during my lunch break I started envisaging a centralised, SEO-friendly information source (hello perlsharedhosting.com) that cobbles together all of the currently available information into an easy to digest form to make it ridiculously easy to choose a shared hosting provider, deploy your web app and troubleshoot common problems.

A site that works like this:

• The front page contains a list of Perl-friendly hosting providers, with a meta-score based on how many features they support (+) and how many unresolved issues they have (-), and maybe user review scores thrown into the mix too
• Each hosting provider has a page of its own, listing in full which features are supported (used to compute the meta-score). Users can post comments on each of these pages, to leave testimonials (“I am currently running a Web::Simple site that gets x hits per hour on this host”) and note unresolved issues (“module X::Y fails to install on this host”). As issues get solved these become tips.
• Each technology/feature/technique also gets a page of its own, with links to the official man pages, shared-hosting specific notes and again user comments
  • dependency related: local::lib, cpan, cpanm, ..
  • environment related: locating and running perl, paths, daemons, viewing error output, ..
  • web deployment related: CGI, FastCGI, ..
  • framework / web app related: Web::Simple, Dancer, MojoMojo, Catalyst, Tatsumaki, ..

I haven’t decided yet what engine would fit best.. MojoMojo is a front-runner, and in fact the Catalyst Friendly Hosting page runs on MojoMojo does a large chunk of what I’ve described above.

The site would be very “cookbook” oriented, since we’re specifically targeting people who can’t be bothered learning the ins and outs of 10 different technologies (not to mention figuring out how to get them to play nicely together) for the sake of deploying toy web applications on cheap shared hosting. Just the essentials: this is what you need, this is how you achieve it. And if you want to learn more, go here.

With that in place, we’d end up with a single, visible, place to research and document the complications of running Perl web apps on shared hosting. And if the site became popular, hosting providers might even take notice and start offering more Perl-friendly shared environments. We could have live demo pages running on different hosts, possibly even donated by hosting providers if they see it as a way of showcasing their Perl-friendliness (mojomojo.dreamhost.perlsharedhosting.com, dancer.resellerzoom.perlsharedhosting.com, etc..).

I got as far as registering the domain name; I was planning on getting a simple MojoMojo prototype up and running, but I got side-tracked researching how to deploy it on my shared hosting account…