Dutch Perl Workshop
Last weekend I spend a few nice days in the Netherlands, thanks to the Dutch Perl Workshop 2011. It took place in Den Haag at the very cool Relevation Space (the pinball machines! the Space Invaders carpet! the LackRacks!)
Last weekend I spend a few nice days in the Netherlands, thanks to the Dutch Perl Workshop 2011. It took place in Den Haag at the very cool Relevation Space (the pinball machines! the Space Invaders carpet! the LackRacks!)
It just got official today, although already listed in Dancer Web Site for some time. Livro-Aberto, is a Dancer website to track current progress of Portuguese on Gutenberg Project and Distributed Proofreaders. Therefore, it is written in Portuguese, sorry.
There isn't much that I can say about the website. It still lacks a backend (we are editing the database directly) although one is planed, using Dancer::Plugin::SimpleCRUD. Current database access is performed using Dancer::Plugin::Database, emails are being sent with Dancer::Plugin::Email and all templates are Template::Toolkit powered (through the respective plugin).
It is running in Apache fast-cgi (fcgid), and the database is MySQL.
What are the Perl modules you immediately install when you get a new Perl? Jesse Vincent, the Perl 5 pumpking, opened the door, albeit slightly, to possibly considering maybe thinking about provisionally expanding the Standard Library. Is that modally weak enough for you? (Jesse tells me I misread him, so, maybe the door is not open and never was).
Larry designed Perl 5 to be extensible, which is another way of saying that he designed basic Perl 5 to be small. CPAN is great, but we also know that through various social and technical factors, mere mortals struggle with the idea of having to get their wheels, fenders, and mirrors separately once they buy a car. Distributions such as ActivePerl and Strawberry and popular partly because they come with the extra bits. Non-perl people with their fingers in the pie tend to think about those included parts differently than the "third-party" parts.
Чуть подробнее про Rakudo (Rakuda-do — путь верблюда)
ДокументацияLondon Perl Mongers organises technical meetings every two months. The technical meetings are a chance to find out what has been going on in the Perl community, what techniques people are using and how Perl integrates with other software.
The next technical meeting will be on the 10th March 2011 from 7pm to 9pm (you may arrive earlier, please sign in at the reception). You have to sign up to attend, see below. It will be hosted by NET-A-PORTER.COM and held at their offices in Westfield London
Shopping Centre. Many thanks to James Hudson, NET-A-PORTER.COM and everyone involved for allowing us to use this wonderful venue. We have the following wonderful speakers:
Zefram - The new extendability features that are going into Perl 5.14
Dave Hodgkinson - Perl, Hudson and Selenium
Pete Sergeant - Something testy
James Laver - Spark Form
For more information and to sign up, please visit:
http://londonpmtech.appspot.com/
See you there, Leon.
I wanted to write up on the February TA.pm meeting we had two weeks ago but kept delaying it. I think it's about time!
As with every TA.pm meeting, we try to mix both beginner and advanced talks, in order to have something for everyone. It's proven very effective so far. We've also started doing lightning talks, which I really wanted to do for a while.
The beginner talk was done by Gabor Szabo, giving an introduction on how to get started contributing to an open source project. There were a lot of laughs and a lot of fun. We also got to see new faces, and that's always great.
Then we had a round of lightning talks, one by Shlomi Fish on how to solve a very specific problem in a ton of different ways, and one by no speaker at all, on how to write a nifty website in under a minute using Dancer.
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
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.
Checking the file source quickly with
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 the ground up to be a flexible, extensible, responsive JavaScript application 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:
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 offer.
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:
Please send your questions, letters of intent, and proposals to venue@yapceurope.org.
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:
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:
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:
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).
Test Driven Development of Excel::Writer::XLSX Part II
In the first part of this post we looked at how I used auto-generated code and tests to speed up the re-write of Spreadsheet::WriteExcel into Excel::Writer::XLSX.
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.
Here are some examples of how it can be used:
I've uploaded the slides for my Frozen Perl 2011 keynote, in which I answer one part of the question "What are five things I hate about Perl?"
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.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.