Much of February was taken up with monitoring updates and watching for any unfortunate consequences. Thankfully the improvements seem to have done their job. The report submissions in January dropped from previous months, which is normal going on past experience, and sure enough the submissions increased again last month. Despite this the builder has managed to stay on top of the page requests. Some fine tuning has taken place and currently the builder stays at most about 2-3 days behind, but is average in only 1-2 days behind. We'd prefer to have updates even more frequent than this, so over the next few months we'll investigate further what improvements can be made.
We have a non-Moose class but want to make a Moose subclass of it.
First, step back and consider if we really need a subclass.
Don't subclass
There are probably some good arguments against subclassing non-Moose classes with a Moose class that center on principles of good design, and applying the most suitable design patterns. From a practical standpoint, though, there's a very simple reason to avoid it: using Moose to subclass a non-Moose class is fraught with "gotchas." We'll see some of these problems in an upcoming post, but for now let's look at an alternative to subclassing.
Perhaps a better option is to simply create your a new class and use delegation to call methods on an accessor containing your non-Moose object.
Let's say we initially wanted to subclass Date::Handler, but we decided to try delegation instead. After reading through Moose::Manual::Delegation we come up with the following:
How much do perl distributions diverge from or augment the Standard Library? Lately I've been doing a lot of work with distributions that augment their standard Perl installations, so although I'm restricted to the distribution's Perl and its modules, most of the good stuff is already there. However, we don't have a tool like Module::CoreList that knows about vendor distributions.
Although I don't have the time to write it myself, I'd really like to have a tool that can report module presence and version for either the current operating system or any that I name:
$ corelistng --debian -a Scalar::Util
$ corelistng --macosx -v 5.10.0
This would be pretty handy when I have to put together a private MiniCPAN.
For the guy who wrote the test harness currently ships with Perl and has commit rights to an awful lot of the Perl testing toolchain, I sure do seem to do a lot of stupid things while testing. That being said, sometimes I need to do those stupid testing tricks. That's because there seem to be roughly two types of developers:
Those who work in a perfect world
Those who work in the real world
I say the latter with a bit of bitterness because invariably I keep hearing YOU MUST DO X AND NOTHING ELSE where "X" is a practice that I often agree with, but it's the "and nothing else" bit that really frosts my Pop Tart (tm).
This dealt with tests at the unit or method level. At the class level I was able to use tests that compared module results against actual XML from an Excel XLSX file. The following is an extract from an example test case. The XML in the DATA section is from an Excel file, pretty printed via xmllint.
I've released a (very preliminary) development release of a new project, App::htrepl, a commandline REPL for more easily debugging HTTP applications. It was inspired by a similar project for Node.js, the link to which I can't find at the moment. You can find the repository at github here, and it will be hitting your local CPAN mirror soon.
REPL means read-eval-print loop. App::htrepl provides a commandline script, htrepl, which makes it easier to talk to your HTTP applications. The only dependencies are LWP and Term::ReadLine; the code is otherwise designed to be as lean as possible.
You may remember that I first asked that question in the introduction to Mastering Perl, so I've been thinking about this since 2005. I posted it on use.Perl in 2007 and Stackoverflow in 2008 (and Jeff Atwood picked up on for Stackoverflow Podcast #73 (around minute 47), although I'm not sure that. I might have picked it up from 5 things I hate about Ruby, which is about the same time that I would have been writing that for Mastering Perl.
Almost everyone fails this question though (and Jeff's answers are very weak). Most people don't think about it long enough, so they answer with very superficial, stylistic things that don't prevent them from doing anything but that is just their pet peeve.
Perl is tired, old, crusty, and ready for the farm where its spirit can run free with the likes of COBOL and Fortran.
Or at least that's what some people outside the community say.
We know this couldn't be farther from the truth: Perl 5 is alive, "Modern Perl" is buzzing on everyone's lips, Moose has brought Perl OO into the 21st century, frameworks like Catalyst and Mojolicious tame monstrous web projects, and ORM libraries like DBIx::Class make database interaction fun again!
A widely held view of Perl in the realm of large-scale software development, however, is that the language and community are dying. Despite the obvious absurdity of this to those of us in the Perl trenches every day, the perception of Perl can and will become self-fulfilling. Perception is -- or at least begets -- reality.
Once again another release of Padre the Perl IDE has been uploaded to pause to hit cpan in due course.
Padre 0.82 comes after a long and interesting look at how we manage our releases.
Padre has nearly always been released directly from trunk, simply because it meant that the process of building the release was kept simple. But it also meant a 'freeze' to commits made to trunk while the release was being put together. While for the most part this was really only a matter of a couple of hours, it meant that translations wouldn't make it into the next version.
To alleviate this, every now and then we'd 'freeze' trunk for a longer period of time, of course the moment you freeze trunk, you stop any developers out there itching to get their changes back to the main repository. This isn't a good thing.
This is the first O'Reilly video I downloaded. Technically this course
has been recorded in optimal conditions. You won't be disturbed by
noise nor bad images. O'Reilly did a great job at mixing the video
with full-screen laptop screen and the room.
By downloading the course you'll get more than 5 hours of interesting
course. The course is divided in well-organized chunks. Each chunk
handles a specific item of git, which makes it great for later review.
I'd like to publicly thank Bram, the previous owner of http://yapc.eu/.
I asked if we could transfer it over to the Perl NOC team so that it becomes an official community resource (he was already redirecting it to the yapceurope.org domain).
He was more than happy to do so, and has been so helpful in the process.
At the same time I'd like to thank the Perl NOC guys for taking this on. You probably don't realise just how much infrastructure these two guys run on our behalf, and how much more they are taking on!
I'd also like to thank the ACT team who run most of the Perl conferences websites and have setup yapc.eu on their server.
Today, I found out about a new release of Image::Thumbnail , which has support for Image::Epeg , a library coming from the Enlightenment desktop manager. Likely, epeg is quite fast, but it didn't build and test right under Windows. Conveniently though, Tokuhiro Matsuno maintains the module on github, so it was just a matter of forking and cloning his repository, and then trying to find out what made it break.
The breakage itself was three parts:
A build failure where the symbols were not exported. It seems the epeg library wants -DBUILDING_DLL , which I supplied as a cc_optimize_flag through Module::Install, because I couldn't find a better way.
Some test failures because binmode() was not used with the test image files. Easily fixed.
These two tests made it into v0.11 , released about 30 minutes after I told tokuhirom about the patches.
The remaining problem was that a function call crashed Perl with
I think, after a load of floundering around, that the way to use DBIx::Class::DeploymentHandler has finally clicked - I have no idea why it seems to have been so hard for my mind to work out how to use it, but this module has really made my head hurt!
So, I am aiming to put together a few blog posts on using Deployment Handler to manage upgrades (and theoretically downgrades, but I have never tried those). I should get something produced around the end of next week (minor issues like stage managing a play in theatre all next week allowing!).
codepad is an online compiler/interpreter, and a simple collaboration tool. One can test code and share results. Currently, it supports 13 programming languages including Perl.
I've been writing and rewriting Nama[1,2,3] for several years now. It's been my introduction to intermediate concepts in computer science.
Nama is an audio recording, mixing and editing application, using Ecasound[4] as the audio engine.
I'm proud of how it has evolved. At first it was all procedural, driven by a command processor loop. Then I added a Tk-based GUI, my first GUI. I added a text interface with a command grammar based on Parse::RecDescent. I introduced OO to separate the code for two different UIs. Then I added classes for tracks, buses and other entities. I added an event system (actually two), serialization, a help system, tests. I created a build system to automatically generate parts of the grammar, the help system, and to merge various files. The code for audio routing has gone through three different design interations: hardcoding, routing by rules, and now, routing by creating and transforming a graph.
By default, Mojolicious will send debug messages to a log/[mode].log file; if the log directory does not exist, messages will default to the terminal console.
You can use any of the four logging groups for customized messages:
With Mojolicious::Plugin::ConsoleLogger, you can log these same messages directly to your browser console.
Declare the plugin:
And view all your log messages directly from your browser:
That's all well and good, but let's take it a step further. You can even see error messages when the template is missing:
Or when there's a template error:
Even when there's a Perl compilation error:
As always, Mojolicious installs in about a minute: sudo -s 'curl -L cpanmin.us | perl - Mojolicious::Plugin::ConsoleLogger'
Disclaimer:
Implementation stolen from Plack::Middleware::ConsoleLogger
I had always wanted to perform some analysis on all the posts that Reddit gets. I searched CPAN for a module that does something similar, and found nothing. So, I decided to write my own. This is still a work in progress, and currently only allows you to fetch and parse the data in XML.
