This month has been a good one for Alien::Base, and I’m happy to report that I believe that the grant is winding up. We saw a beta release and had a project night during which we hacked on a few issues, but also I was keenly observing people assessment of usability, which I consider key to the success of the project.

I think I have only a few issues to work out before I declare success:

1. Fix a bug which has crept up on OpenBSD - I am almost certain this is related to my implementation of a parser for pkgconfig files
2. Investigate a solaris bug reporting from the extended test chain (i.e. Alien::DontPanic and Alien::Ford::Prefect)
3. Polish up my Alien::GSL distribution and release to CPAN as an example. BTW this was my project on project night, though with all my activity I didn’t get a whole lot done (visibly)

I think that it is conceivable that these last issues can be addressed this month.

Building on my (second) example from my recent post A Simple Mojolicious/DBI Example, I thought I would take it just a little bit futher. One of my favorite features of Mojolicious is that it comes with WebSockets out of the box! In this example I show how you can take the example script and allow it to run without refreshing the window.

A friend of mine is learning database administration, but for the first time needs to connect it to a webapp. Having done most of his work in MS Access, he has no idea what a web framework is, nor how one would connect a database to it. To help him learn I wrote up a little application using Mojolicious and SQLite.

Ovid posted an interesting article about why one Perler (not himself) dislikes Mojolicious.

I have read several articles, and had several conversations about why people don’t like Mojolicious. I have been meaning to write an article about people’s dislike for Mojolicious for a while now, so I’m going to take this opportinity do so while responding to that article.

Mojolicious is Pro-CPAN

Some people don’t like it claiming that it is “anti-CPAN” and in fact this comes in two flavors. First, they believe that because a tool is available from CPAN that it should be used rather than reimplemented. Second, if one really can reimplement it better, this tool should be forked out of the project and uploaded to CPAN for everyone’s benefit.

While of course this first claim is a concern, it does seem that the Mojo devs take the task of reimplementing these tools very seriously. To the second point, I have seen this question asked at this year’s YAPC::NA and the response is, just install the whole Mojolicious package. At first you might think, “why should I install a whole web framework just to get that DOM parser?” Well, because its not that big of a framework. The Mojo devs feel that it would be a bigger maintenence burden to maintain all the modules separately then just keeping it one toolkit. I was skeptical too, its true, but it installs on my netbook in about a minute. With better hardware and parallel testing it installs on better machines in seconds!

One further argument down this line is that Mojolicious insists on using its tools internally. The person who made this argument wanted to replace Mojo::JSON with their own JSON module even while being used inside Mojolicious (both for logging and the speed of XS). They would prefer that the internal JSON engine be configurable to allow for such. While I can see this point, I also think that its the perrogative of the developer to use their own tools for internal use, that’s why they developed them after all. And hey, this is Perl, if you really want to override Mojo::JSON and replace it with your own, you can do it, there are no protected classes in Perl after all.

In fact you can use your own templating engine, you can use Plack middleware, you can serve via plackup or starman, it’s database agnostic. It uses several optional CPAN modules if you have them installed. This hardly seems anti-CPAN to me. Perhaps a different flavor of CPAN, but try it, its tasty.

The Developers are Really Friendly!

Edit: After several comment have been posted, I have decided to remove my history of the developer Sebastien Riedel’s departure from the Catalyst project as I am not really qualified to write it. My understanding of the situation came primarily from reading this mailinglist entry, which seems civil enough.

Personally I have interacted with him on occasion. In my experience, the IRC channel is friendly. I have submitted patches, and yes, he and the other devs are very particular about what is included, but again, that is their perrogative. I haven’t been the subject of any meanness at all, and several of my patches have been accepted.

Back to Ovid’s Article

The reason presented in this article is a new one to me. This developer doesn’t like Mojolicious ostensibly because it allows companies to shy away from using CPAN. The company can use Mojolicious as the backbone of a webapp, but invent everything else in house.

While this is certainly an interesting realization, I would take a totally different result from it. If there are these tremendously CPAN averse companies out there, and if Mojolicious did not exist, do you really think that they would instead reach for Catalyst? I don’t think they would.

It sounds to me (and I could easily be wrong) that Ovid’s anonymous source is one of those people who are against Mojolicious for being “anti-CPAN”, and thus when they see this happen they think that Mojolicious encourages an anti-CPAN trend. I would say the opposite. Mojolicious is for these companies what the shallow end of the pool is for a young swimmer; dip a toe into CPAN and see that it feels good without fear of drowning.

Or perhaps Mojolicious is that gateway drug, the one that might bring them to CPAN. “Oh its just a little framework. You know an ORM would be nice. Well handling dates is harder than we thought, is there some CPAN-drug for that?”

Final thoughts

I’m not sure where it came from or why it started, but I see lots of people who are opposed to Mojolicious. Are there really people who hate a framework? We all love CPAN, but Mojolicious isn’t anti-CPAN, it adds to CPAN! Catalyst is great, but Mojolicious isn’t trying to kill it (or Dancer for that matter), certainly we can have more than one framework on CPAN. Go ahead use Mojo::DOM in your Dancer project! Or use JSON.pm in your side of a Mojolicious project. Someone might look at Test::Mojo (or at least its underlying Mojo::UserAgent) to test their webapp, whichever framework you use.

At times it seems almost prejudicial. There seems to be a lot of “I hate it and I won’t try it” or even worse, steering others away from Mojolicious because you have heard one of these criticisms, not because you have a real tangible concern. Again, I say “Try it!”

There’s no reason not to get along.

I am happy to announce that Alien::Base (GitHub) has seen a beta release, version 0.001. It seems that my design change that I previously blogged about has indeed fixed (well avoided) the problems that I was having supporting Mac.

This is not to say that Alien::Base is quite completed. While I have released two testing modules which are an Alien:: module (Acme::Alien::DontPanic) and a dependent module (Acme::Ford::Prefect) these are very simple modules. To be sure that the API is flexible enough and that the loader mechanisms are robust enough Alien::Base needs to be used in the wild.

This week’s Chicago/WindyCity.pm meeting, our monthly Project Night, will feature (though not exclusively) creating these modules. I personally will work on porting Alien::GSL to the Alien::Base system. I hope that if you are in the area you will consider attending or if not please attempt to wrap your favorite C library using Alien::Base and let me know how it goes.

Also, please try installing Alien::Base, Acme::Alien::DontPanic and Acme::Ford::Prefect (in that order, though installing Ford should just work), and let me know how that works on your system. I have been developing on Linux and have run some tests on Mac obviously. I have seen some conflicting reports on different Windows/Perl combinations, so this remains to be seen.

I am very happy to have reached this point, and I want to thank the Perl Foundation and my grant manager Makoto Nozaki for their patience with me. This was supposed to be a short project and it has become a much longer one than originally proposed. Hopefully the community will find it useful.

Recently on stackoverflow, I answered a question that I thought worthy of a highlight here on the blog. In this forum we all know that one should never parse HTML with a regex, but if we agree on that, there are still many options available afterward. The question as posed was given some HTML, remove all <style> tags and contents. The question was later amended to include that he needed to also remove <style> tags with attributes (the nail in the regex coffin) and <link> tags to stylesheets.

While you could use an XML parser or an HTML tokenizer, personally I like using the Mojo::DOM parser. This is a Document-Object Model interface to your HTML and it supports CSS3 selectors, making it really flexible when you need it. The original problem is solved as easily as:

#!/usr/bin/env perl

use strict;
use warnings;

use Mojo::DOM;

my $content = <<'END';
<html>
<head> <title> Example </title> </head>
<style>
p{color: red;
background-color: #FFFF;
}
div {......
...
}
</style>
<body>
<p> hi I'm a paragraph. </p>
</body>
</html>
END

my $dom = Mojo::DOM->new( $content );
$dom->find('style')->pluck('remove');

print $dom;

The pluck method is a little confusing, but its really just a shorthand for the doing a method on each resultant object. The analogous line could be

$dom->find('style')->each(sub{ $_->remove });

which is a little more understandable but less cute. Further, to really understand that the call to find returns an instance of Mojo::Collection, a container object that has array-filtering methods as you would expect, but also can backflow back to the original DOM object. Thus when we remove the resultant tags from the collection, they are gone from the DOM object!

Now lets say that the $content variable also contained these lines

<link rel="stylesheet" type="text/css" href="$url_path/gridsorting.css">
<link rel="icon" href="somefile.jpg">

where you want to remove the first one, and not the second. You can do this in one of two ways.

$dom->find('link')->each( sub{ $_->remove if $_->{rel} eq 'stylesheet' } );

This mechanism uses the object methods (and Mojo::DOM exposes attributes as hash keys) to remove only the link tags which have rel=stylesheet. You can however use CSS3 selectors to only find those elements, however, and since Mojo::DOM has full CSS3 selector support you can do

$dom->find('link[rel=stylesheet]')->pluck('remove');

CSS3 selector statements can be joined with a comma to find all tags matching either selector, so we can simply include the line

$dom->find('style, link[rel=stylesheet]')->pluck('remove');

and get rid of all your offensive stylesheets in one fell swoop!