We've now accepted the second round of talks. Thank you to everyone who has submitted so far! As for the first round, please be aware that just because your talk hasn't been accepted yet, it doesn't necessarily mean that it won't be.
You've got almost three weeks left to submit talks before the deadline on the 24th. We need many more still to fill out the available slots! Don't make us start volunteering people on IRC. ;)
As a bioinformatician and software developer of many years and avid Perl programmer and supporter, one thing I've noticed over the past few years is that Perl has been needlessly losing ground to Python in the major areas of scientific and financial computing, areas where it used to be *the* high-level interpreted language of choice. I am constantly having to correct people on blogs and forums that state incorrect Perl shortcomings when compared to Python or they were shortcomings from many years ago which don't exist anymore in the current language and ecosystem. If they spent two seconds researching Modern Perl and Enlightened Perl they would say WOW look where Perl has come!!!
This came up in a post-work discussion last night
How do the links to methods appear at the top of module documentation?
Are they automatically generated?
A specific example of POD that does this is DBIx::Class::ResultSet
Since I wasn’t sure what the exact behaviour is off the top of my head, I thought I’d investigate.
As you may have already seen, the web-rendered version of the POD has a table-of-contents list of “stuff” at the start of the document.
perldoc doesn’t produce the same table-of-contents. This makes sense to me, there’s not much scope for a clickable list of headings in text output
What magic markup makes this happen?
The simple answer is, “there’s no magic markup required”.
As long as you’re using pod2html, or something that behaves in the same manner you just need
to use ’=head1’, ’=head2’ and friends in your own POD.
The DBIx::Class::ResultSet pattern
Checking the file source quickly with
perldoc -m DBIx::Class::ResultSet
By far the biggest change we've made in WebGUI 8 is the new Admin Console.
Though parts of it may look familiar, it has been completely rewritten from
making calls to JSON services in Perl.
I could talk about how to use the admin interface, but I don't think that's
why you would read this blog, so instead I'm going to talk about how you can add functionality to it.
Since Assets are the basic unit of both application and content in WebGUI,
much of the Admin Console is spent interacting with Assets. It does so by
calling out to Asset Helpers.
By default, every asset has a helper to Cut, Copy, Duplicate, Delete, and
more. When a helper gets called, it returns a JSON data structure explaining
to the Admin Console what to do next.
We can simply show the user a message:
message => 'The work is done, here's what happened.'
error => 'Something went wrong.'
Although YAPC::Europe::2011 preparations are well underway in Riga,
it is time for the venue committee of the YAPC::Europe Foundation (YEF)
to think about the location of the 2012 conference. YAPC::Europe wouldn’t
exist without dedicated teams of volunteers, and we are always excited
to see the enthusiasm and learn about the new ideas the community has to
Further information about preparing a complete application can be
found on the YAPC::Europe Foundation website. Proposals submitted
to the venue committee will be added to this public repository (you
may provide private information separately) to benefit future organizers.
The deadlines which apply to this portion of the procedure are:
- Saturday, 30 April: Deadline for sending a letter of intent. This
letter simply expresses interest in hosting the conference and provides
contact information (both email and telephone) for at least two organizers.
This is an optional step but it can be to your advantage to alert the
venue committee of your proposal.
- Thursday, 30 June: Deadline for sending proposals to host YAPC::Europe
Please send your questions, letters of intent, and proposals to
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.
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:
has 'date_handler' => (
is => 'ro',
isa => 'Date::Handler',
handles => qr/.*/,
Just a head’s up that my employer—Grant Street Group—is hiring more Perl developers. Most Grant Street Group developers telecommute.
The company is great, the quality of people I work with are top-notch, and the work is challenging and stimulating.
For more information, see this post on jobs.perl.org: