Home » Programming » Archive by category "Perl" (Page 4)

Finished reading: The Definitive Guide to Catalyst

A couple of days ago I finished reading The Definitive Guide to Catalyst which for a technical book (or any at all) I read through quite fast. I’m not going to write a full fledged review about it but I can recommend it to anyone interested in working with Catalyst. For those who don’t know it Catalyst is a web application framework written in Perl.

Although the online documentation is very good the book is a nice addition to it. It’s more than just a collection of some code examples. The chapters follow a certain thought process to write maintainable and extensible code, complete with tests and all. Common in the book is that the example code will get a rewrite later on in the chapter to reach this goal. I consider this a nice feature of the book as it shows why that refactoring was needed and is the better solution to the problem.

There are only a few small complaints I’ve got about the book. The code indentation isn’t always consistent and there are occasionally some errors in the code. But looking more at it from a conceptual kind of view it’s clear what the author intents. I also don’t really understand the choice to include Reaction in the final chapter. Documentation is scarce and it seems abandoned. I’d much rather see some Catalyst::Runtime core modules described in there, such as Catalyst::ScriptRunner (did it even exist at the time of writing?), Catalyst::Request and Catalyst::Response. I know the latter 2 are well documented, but they weren’t even mentioned in the book.

Other than that it was a great read and am glad I bought it :-).

My first proper introduction with Mojolicious

The first time I took a look at Mojolicious was almost a year ago if I’m not mistaken. My Perl was really rusty back then and the Mojolicious’ documentation, or rather the lack of it, didn’t help much either. Still, with interest I followed the project through GitHub. Development on the project, and especially the last few months has been very active. The author, Sebastian Riedel, seems very devoted to the project and his productivity is very inspiring.

By now Mojolicious has matured a lot in my eyes. Documentation is a lot better than it was and is still being improved. To my understanding he’s nearing a feature freeze which means a proper stable 1.0 version will be out soon. This also means for me that I can start using Mojolicious without the agony of backwards incompatibility with every small update.

What I like about Mojolicious is that its pretty lightweight, has no dependencies besides core modules and is already supporting HTML5 features like Websockets. Now, I don’t know yet precisely what Websockets are good for (the Wikipedia entry isn’t very helpful either), but it shows that Mojolicious is geared toward support for modern techniques. To my understanding it allows for the browser to keep a connection open with the webapplication so you don’t need a polling system to retrieve updates. Which is something Ajax is being abused for at the moment.

Because Mojolicious doesn’t use any other modules it has its own templating system as well. It’s pretty feature complete, but I can’t coop with the syntax. Others have blogged about this as well. Templates look horrible and are unreadable. Which is a shame. A more Template-Toolkit like syntax would’ve been nicer. But that would also mean reinventing the wheel, again. Which is what Mojolicious is doing quite a bit (e.g. Mojo::JSON). Nothing wrong with that though, as on of the key points for Mojolicious is to be independent of other modules, except for core modules.

Luckily, it’s easy enough to replace the default renderer with another one. MojoX::Renderer::TT nicely wraps up Template-Toolkit. Inside the startup method of your application it’s easy enough to set it up as the default renderer.

One tiny thing I’m missing, and maybe I’ve overlooked it, is a standard way of using configuration files. I’m used to the Catalyst way of doing this, which is a breeze, but so far haven’t found a standard way to do this in Mojolicious. I suppose I can easily fix this with using Config::Any myself.

So far my hands-on with Mojolicious has been small, but it did the job for me. All I needed was a simple web application that can log usage through a REST API. Together with Test::Mojo writing tests was a breeze. I did have to go through the documentation quite a bit to figure out where and what everything was. But this is no different with any other framework you’re learning. Whilst testing I had run into a tiny problem which turned out to be my fault, not Mojolicious’. Still, Sebastian was kind enough to promptly respond to my question at IRC and was very helpful.

I didn’t use Mojolicious::Lite by the way. Whilst it would’ve worked perfectly for my use case I don’t understand yet how it’s easy to convert a Mojolicious::Lite webapplication to a normal structured Mojolicious webapplication. It would’ve made implementing the REST API easier since Mojolicious::Lite has routines for setting up PUT, POST, GET, DELETE and HEAD requests. But since the webapplication will scale to something bigger in the future I don’t want to rewrite the Lite edition to a structured version. I don’t have time for that.

Compared to my experience from a year ago it was fun to use Mojolicious this time. I’m certainly going to use it for more small and low traffic webapplications. For now I’ll stick with Catalyst for the big webapplications. But that’s because there are already a lot of extra modules for it, has excellent documentation, it’s highly configurable and I bought an expensive Catalyst book (don’t worry, I like it and ordered it through the Catalyst website so the Enlightened Perl Organisation gets a donation).

My first Perl 6 code

Rakudo Star, a useful, usable, “early adopter” distribution of Perl 6, was released today. And later this evening a MSI installer for Windows was released.

I immediately installed it on my laptop after I had fetched the installer and started up Rakudo REPL, an interactive Perl 6 shell. After a quick peek in the Using Perl 6 PDF I tried the following code.

  1. > say "test";
  2. test
  3. > my $line = ‘la di da’;
  4. la di da
  5. > $line.split(‘ ‘);
  6. la di da
  7. > $line.split(‘ ‘).join(‘+’);
  8. la+di+da
  9.  

I know it’s a completely useless example but it’s cool how it just worked on my first try. Think I’ll experiment some more with Rakudo this weekend.

Is there a way to share loaded Perl modules amongst users?

I was wondering if there’s a way to have a Perl process share some commonly used modules (such as DBI, DBIx::Class and Template) amongst different users? I’ve looked at FCGI::Spawn but it didn’t seem to me it was capable of it. What I’d like to do is run a single Perl daemon which has some modules preloaded and is able to spawn other processes (e.g. a Catalyst application), sharing the same memory block for loaded modules. I know that’s possible, Starman does it for example, but that’s meant for a single user.

Instead of a single user I want this process to do what suexec does for Apache. suexec Will only launch a CGI/FastCGI script if the owner and group are defined correctly. Once launched the process will launched by the owner of the script, a normal user.

My current problem (well, not current but in the future it’ll be) is that through suexec you can run many webapplications, like Catalyst, Dancer and Mojolicious. The thing is, the commonly used modules will be loaded by each process. So if there are 3 users with a Catalyst website using Moose, DBIx::Class and Template that means for every user process these modules need to be loaded into memory. They can’t share the same module space (for some modules this would be bad, of course). When running a few dozen of smallish websites this will eat up RAM quickly.

I’ve came across Plack::App::Apache::ActionWrapper which partly solves this problem for a single user with multiple PSGI application. So far I haven’t been able to make it work for a single user, let alone multiple. But I had hoped it would be possible to use a single wrapper like this, preload some modules, and use this single wrapper for all users.

I suppose I have to ponder a bit more about it. Although I wonder if it’s even possible though. Yes, mod_perl can preload modules but this means executing Perl as the user running the webserver process. I prefer PSGI or FastCGI.

How a programming language influences your mood

For over 3,5 years now I’ve been programming professionally in PHP. First in PHP4 and about half a year later we finally converted to PHP5. At first I was excited because I could use a lot of new features PHP5 offered such as proper OOP but also Zend Framework.

I started using Zend Framework from 1.5 (currently it’s at 1.10) and have very mixed feelings about it. Yes, it does have a lot of useful libraries such as MVC, basic ACL, Authorization, Input Validation & Filters, Views (with PHP as the templating language, which it essentially was designed for) and more. But ZF had a steep learning curve for me so far has been successfully used in about 5 big webapplications.

However, PHP’s inconsistent function naming, unpredictable order of expected arguments (needle and haystack anyone?), lack of closures/anonymous functions, namespacing, lexical scope and what not makes using PHP a true nightmare. Yes, PHP 5.3 finally supports closures and namespacing, but have you looked at the syntax for both? What a joke. On top of that, PEAR is even a bigger joke. Is someone using it at all?

Running into these issues day by day and knowing it can be easily solved in Perl is very, very depressing. It has totally taken away my desire to program, influencing my desire to program at all and has made my motivation disappear. I’ve truly been wondering if a programming job is really something I want.

The turnaround came when I had a talk with my boss about why we’d still use PHP for future projects. Yes, code reuse is one them but compared to Perl all the additional code I’ve written in PHP that is being reused already exists in Perl at CPAN. To my understanding the use of backslashes to define a namespace in PHP wasn’t really a design choice, but was forced upon because it was too hard to use the double colon or a dot, like many other languages do. On top of that, last time I checked, PHP6 development has been halted because they just can’t get Unicode to work.

Perl already supports Unicode, Perl doesn’t have a weird separation character for namespaces, Perl supports closures/anonymous subroutines, Perl supports lexical scoping, the core list of functions is small, easy to remember and the order of expected parameters is consistent. And it has CPAN.

I was able to convince my boss to start using Perl for future projects because of these given points for both Perl and PHP. What helped though was that he knew of Perl and we’ve also developed some applications in Perl already. One of them a Wx application, a newsletter mailer and some other small scripts. Difference now is that I can use it for webapplications as well.

Now that I’ve gotten the green light to go with Perl for future projects I’m much happier again at work. I’m more motivated to finish the current PHP projects so I can finally start doing some proper Perl work. Programming Perl makes me happy. Moving from PHP to Perl doesn’t mean we’ll be fully dropping PHP. That would be bad and ignorant. Existing stuff will still be supported, improved and extended with new features.

No matter how much you dislike one of the products you support, it’s part of the job. Having stuff you dislike is good actually, because it makes the fun stuff even more fun. For me, PHP makes Perl more fun :-).