Noirin Plunkett will give a talk at YAPC::Europe 2012 described as
The Apache Software Foundation provides legal oversight and technical
infrastructure for about 150 projects with more than three thousand
committers. There's much more than just a web server: Apache projects
run the gamut from distributed computing and big data processing to
end-user office software.
But there is one common Open Source paradigm that's absent at Apache:
the benevolent dictator. Meritocracy, community oversight and
consensus have been the hallmarks of our projects for more than a
decade, and they seem to be working. It's not the only way, but it is
another way.
If you've got some code you'd like to see grow and flourish, be useful
to an ever-wider audience, or attract new contributors, why not come
to this talk, and learn a little more about this alternative model?
Perl's motto says "there's more than one way to do it"; at Apache, we
say "try it and see"!
There are two main differences from the regular set of events. First, this time we are ready to offer a Partner programme. Second, there will be no attendees dinner, we propose to make a river cruise instead.
Karen Pauley will give a talk at YAPC::Europe 2012 described as
Over the past year The Perl Foundation has continued to work on its goal of advancing Perl and supporting the community. This talk will provide a review of our recent successes and failures, and take a brief look at the plans for the year ahead.
Edit: MojoCMS has been renamed to Galileo and released to CPAN. Enjoy!
Over the holiday break, I decided to have a little fun learning some things about the web. I usually get my Perl fix through science, but several upcoming projects might have some web involvement; so I thought I should brush up. The following are some reflections on that experience.
The task I set myself was to make a micro CMS (it is currently named MojoCMS, but I’m not sure I like that), leaving most of the heavy lifting to freely available Javascript libraries. I didn’t think I would be especially good at writing the actual interface, but rather the routing and functionality would be my task. In a strange way, the result was a kind of nostalgic Perl experience; Perl was the glue in my project again, not the main/only language involved.
If you're ever in the position of needing to convert a large (in our case around 32000 revisions) Subversion repository to a Git repository, you should know
git svn is agonizingly slow, and falls over at regular intervals (apparently memory problems; symptom is "git svn died with signal 13")
The KDE version of "git2svn" is written in C++, requires that QT4 be installed (so you have "qmake"), and requires a local copy of the SVN repository. If you have it, it is apparently blindingly fast - in my case I didn't have direct access to download the whole SVN repository.
So for my conversion I used the "svn2git" Ruby gem. It works very well indeed, and is screamingly fast. My current import has been running for 12 hours and is about halfway done - this may seem slow, but the "git svn" version, even wrapped with a Perl program to restart it when it fell over, ran for over
three weeks
before hitting a situation where it couldn't continue, with the import imcomplete.
I'll update the post once the import completes - or if it doesn't!
By googling I found many sites, but they all require you to click on a long list of links to step through the alphabet, so I'm thinking: Ask first, and as a last resort write a scraper.
Darko Obradovic will give a talk at YAPC::Europe 2012 described as
In this talk the SNA::Network module from CPAN is presented. It allows the fast and flexible analysis of network structure data, which is present in many Web 2.0 Internet platforms, not only in the social networks.
We present state of the art centrality and community identification algorithms, and compare the performance to Graph.pm.
We also show how to easily extend it with own algorithms, data fields and import/export filters with a very simple plugin mechanism.
In the accidental quest of conquering the logging world with Log::Any, presenting Log::Any::For::DBI. I needed something like DBIx::Log4perl but for Log::Any, so I wrote one. Internally it's much simpler than DBIx::Log4perl currently and only logs method calls like connect(), prepare(), do(), selectrow_hashref(). Suggest or send a patch if you want more features. The module builds upon the more general Log::Any::For::Class.
To quickly demonstrate it, we'll use something like Log::Any::App to show logs to the terminal:
The bad news we heard today about ZERO number of proposals for 2013 made us active enough to produce good news: we decided to make a proposal for hosing YAPC::Europe 2013 in Kiev (still no visas required for EU/US/UK/RU citizen).
"We" are the Kiev.pm + Moscow.pm groups, namely, the guys who made the recent fantastic YAPC::Russia in 2012 (100+ people) in Kiev and myself. We'll add up the facts about the venue, prices etc. to our proposal in the following few days, definitely long before Frankfurt event in August, and well public full text soon. We've got a venue in mind already.
As an organiser of YAPC in Riga and from the attendees feedback I have some ideas of where we failed and how we can fix that. And of course, all the great things that worked should be repeated.
MDK is the man! A big thank you to Mark Keating for a great post about how to donate to the CPAN Testers Fund. I have received some feedback about how to make the fund and the donation process a little more prominent on the websites, and I plan to address that in the coming months. I have also been very encouraged by some of the feedback, and hopefully we shall see more donations and sponsorship in the coming years too. Aside from asking your company if they can donate, or writing on your blog about how CPAN Testers have helped you, if you're so inclined, you might want to add a note to your README or POD to tell users how they can donate. There are plenty of other funds you might want to advertise too, so don't feel restricted to the CPAN Testers Fund. CPAN Testers can also benefit indirectly from the other funds, so its all good.
Salve J Nilsen will give a talk at YAPC::Europe 2012 described as
Whatever you call a technical community (mongers, masons, monks, mongrels or misfits), there's some work behind organizing one. The speaker has been involved in one of these groups - Oslo.pm - for almost 10 years, and in this time gathered a few impressions on what works and what doesn't.
In this talk we'll explore some of the events Oslo.pm has organized, share how they turned out and try to figure out why they went well - or didn't. We'll touch upon topics like money, volunteering, burn-out and the importance of fun.
But this isn't an Oslo.pm talk only! We'll also make room to for other .pm group members that have something to share! Bring your experiences, or if you haven't any - bring your questions and curiosity.
If all goes well, we'll end up with some ideas for an even better community! :D
The deadline for submitting proposals to host YAPC::Europe 2013 was a few days ago (5th July, see the Call for Venue), but no group submitted one.
If nobody steps up, there might be no YAPC::Europe 2013!
(unless I can convince the responsible parties that in case there is no group hosting the next YAPC, the current group is forced to has the honor to do it again :-)
It's really not much work, and all reports from previous organizers stating otherwise are grossly exaggerated!
Here's the whole Call for Venue, and here is a detailed document on what to do to bring YAPC::Europe 2013 to your wonderful hometown. And for even more organizers know-how, check out Perl Jam an upcoming book about "How to organise a conference ... and live to tell the tale." by barbie et.al. (also available on github)
The last update on the news feed for
The Perl Beginners's site was almost a
year ago. While the site continued to improve, I neglected writing a new
entry until now, so I hope this one will compensate for that.
So without further ado, here is what is new:
We now have a page about Perl
Humour, which was restored from a page in the now offline perl.net.au
wiki.
One person asked what the sponsors use Perl for. Here you can find the first answers...
Webfusion
Here at Webfusion, Perl is at the core of our business. It delivers web pages, communicates with internal and external APIs, builds servers, registers domains, configures products and services, and even makes the tea! (That last bit might not be true ... yet!). Our systems are developed in-house, using the best of CPAN, including Catalyst, Moose, DBIx::Class, Plack among many others. Our websites are delivered via Catalyst and mod perl applications, and most of our underlying system and networking tools are written in Perl.
All our customer's domains are registered and managed using Perl. All our server hosting is implemented using Perl from building the basic servers, to managing the applications installed as part of our shared web hosting packages. We make use of many 3rd-party products to help you design, develop and protect your website, create and use online mailboxes, all of which are configured and managed using Perl.
I happen to be a TDD proponent. Now, right there I’ve probably lost about half of you, and the rest are probably going, “okay, yeah, get on with it.” TDD is one of those things that people either love or hate. For a full meditation on the ins and outs of technical hype, I’ll refer you to my other blog. In the meantime, if you’re one of those people whose sneer at the thought of TDD is still stuck to your face, I’ll ask you to indulge me for a few more paragraphs (two of which are only one sentence long). After that, if you still feel like TDD is the stinkiest thing to come along since Pepé Le Pew, you can either jump over to the link above, or just continue on, mentally subsituting “TDD” with some technical process you actually like. Or, you know, find something else to do entirely.
At the French Perl Workshop (and probably elsewhere before), Matt Trout talked about why and how some ideas could succeed and most other fail. An interesting talk. The last part was a rant against the numerous modules on the CPAN to parse command-line options. His proposal was to do the same thing to command-line programs (CLI) than PSGI did to web applications: formulate a generic specification, that developers can use to build applications and not depend on a specific implementation.
A very interesting idea. We were a few (BooK, cmaussan, niels and myself) to begin thinking about what this PCLI specification could look like. I wrote down on paper what I've been doing in the numerous CLI programs (for a broad value of the terms) I wrote over the past years.
