We’ve set up a site specifically for you to submit and vote on ideas for YAPC::NA 2012. Whether it be ideas for about speakers you’d like to come see present, or the subject of talks you’d like to see, or maybe a social activity you’d like to participate in. Any idea is welcome. And then everyone can vote on those ideas so that the most popular ideas will float to the top.
Sometimes I wish I could apply a filter named "only list serious modules" when browsing through CPAN. More and more people are mis-using CPAN as a personal storage for modules that are not usable for other people. Other useless modules (aside from those in the 'ACME' namespace) act as a pun on common modules like 'Moose'.
Especially when teaching newcomers how to use the CPAN this leaves a bad impression.
Experienced people quickly learn to skip those things but taking the archive more serious would be nice.
Well, so the Yen is at a historic high. Japan's hotels are expensive. We have a record low number of foreign visitors.
Historically, we asked fellow mongers (like Dan Kogai) to accomodate foreign guests, but we have never really spent money for foreign speakers who come all the way to Japan just to talk at our conference. I think it's a shame, but we have no mone...
Oh wait: we have almost 100 individuals who paid a little extra to become Individual Sponsors this year. We have a record-breaking 27 Corporate Sponsors.
Hmmmm... Okay!
During June this year, in Asheville, North Carolina, YAPC::NA assembled 251 people together to learn and discuss Perl, Perl projects and meet Perl people. The YAPC conferences are a perfect opportunity to tell the Perl community of your latest project, or to talk to other Perl developers face to face. YAPCs have now been running for 12 years, and each gets more focused and exposure than the last. In part in this thanks to all the previous organisers who have gone before, offering help and advice where they can. However, the YAPC Conference Surveys also help to provide value feedback to future organisers.
For YAPC::NA 2011, the survey results are now online.
If you make any posts about YAPC::NA 2012 and wish to tag it, please use #yapcna2012 as the official hash tag.
At tomorrow's DC.pm meeting I'll be giving a talk similar to one I gave a long time ago at Phoenix.pm - a behind-the-scenes look at AJAX, targeting beginners. We'll discuss the history and cultural norms (aka Best Practices), as well as diving briefly into what is really going on (watching HTTP dumps). All wrapped up by "ok, now go use JQuery", though I suppose I shouldn't reveal the punchline.
Oh, and of course with Live Coding and using perl for the server-side bit :)
Come one come all!
For those who are not aware, there is a newish methodology called DCI (Data, Context, Interactions) which attempts to solve the problems of OOP. DCI was designed and proposed by the same guy that created the MVC concept that has become hugely successful. DCI is an attempt to group methods with their use cases so that interactions used by business logic and algorithms are more predictable.
The key to DCI is a separation of concepts:
I have created the DCI dist which includes helpers for writing Contexts and Interactions (DCI uses the terminology roles, but to avoid conflict with other perl concepts of roles I have called them casts.)
The DCI perl package can be found here:
If iframes are supported, this should show the synopsis for a common example of DCI.
Here are some links to information about DCI.
All was going well last month, we had a few problems balancing the feed and database inserts, but with some help from Devel::NYTProf, we had improved performance and were getting back on top of things. We also had two presentations at YAPC::Europe by myself and Léon, and were heading for 1 million test reports submitted in a single month ... when.....
The CPAN Testers server hard drive developed a fault. Tthis wouldn't have been a problem had the mirrored drive, which had failed earlier in the year been correctly replaced. Alas the first failed drive was still absent, with the second drive failing and switching to read-only mode almost immediately on reboot. As such I had just started to backup in case we lost the drive completely, and then it did fail completely :( Our hosting company required us to accept complete data loss before replacing the two drives.
It’s the first Tuesday of the month, so that means it’s YAPC::NA Planning Meeting time. If you’re in the Madison area, or don’t mind a drive there is a YAPC planning meeting tonight at the Essen Haus at 7pm. As always the food and beer are sponsored by Plain Black, and the room is sponsored by Essen Haus.
We’ve got a lot to discuss so the meeting will probably last until around 9pm, but you’re free to come and go as you please.
I wanted to comment on kevin spencer's perlbrew intro but my blabbering grew so long I chose to make a separate post instead.
I used to use the #!/usr/bin/env perl trick for shebangs until (when reading about packaging executables with dists) I learned that ExtUtils::MakeMaker (and Module::Build) will automatically rewrite a full-path shebang to point to the interpreter used during install, but it specifically does not do this with the env trick.
I inadvertently combined 'env perl' with local::lib once and found that the script (reachable from my local::lib bin/) would die because I was trying to run a script in my path with a perl that didn't have that module installed (I must have switched perls in the meantime).
Having continuous integration is incredibly helpful and setting up a Jenkins server is surprisingly easy. However, configuring Jenkins to run your Perl unit tests is a wee bit harder, although it may seem easy at first. Here are a couple of issues I ran into and some things I learned:
We all know that Perl unit tests, aided by Test::More and prove produce results in TAP format. But since Jenkins is Java and someone once dictated that Java shall only read XML and only write XML, Jenkins expects test results to conform to the JUnit XML format. Well, OK, if they want XML, let's give them XML. So you turn to your favorite search engine and ask it how to transform TAP to JUnit. You will, of course, find something. And since that something was actually written by Justin Mason of SpamAssassin fame, you stop searching at that point and download that conversion script.
Last week was a short week for me because I was doing a lot of work up at camp for the Scouts. So here's a two-week update:
TPF:
cPanel is one of those critical pieces of infrastructure that you often don’t think about, but that makes the world a better place for so many people. It’s available from web hosts around the world to make hosting a painless point and click experience rather than a frustrating conundrum of editing config files.
I’m pleased to announce that cPanel is our first Diamond Level Sponsor for YAPC::NA 2012. And they’re also hiring!
Why work at cPanel?
We speak Perl
cPanel & WHM is developed in Perl. cPanel has and will remain a proud supporter of the Perl community. At cPanel, we welcome both seasoned Perl Developers and promote internal advancement of learning Perl through various venues such as attending YAPC::NA, in house training, Perl Mongers and working side by side with Perl experts.
Benefits
I’ve used Moose regularly now for a couple years, but really only so far as most people do, as a handy accessor generator and type checker. But my most recent project has called on me to delve, first into Roles, which are a lovely way to teach old classes new tricks, but I found I wanted to do deeper magic…
Now, as I wrote about before, my project is a Node.js style event system for Moose. Moose classes have two types of things associated with them, attributes and methods.
I allow users to declare that their class will emit a particular event through a helper method. You just write:
has_event 'connected';
An event can't be done without them and every organizer ist happy when there are lots of these people - the volunteers.
Only a few minutes after the announcement that we host YAPC::EU 2012 some people came to me to offer their help...
Getty will do all the social media stuff, Wendy offered to help at the event (help with registration desk, help people to find the rooms, ...), and Steffen, Roman, and Gabi offered to help with stuff that can be done remote.
There is enough to do :-)
We'd like to say thanks in advance. You rock!
This review of perl modules for looking up the location of an IP address is now hosted elsewhere.
This contest is a no-holds-barred match, and is scheduled for one fall. In the corner to my left, hailing from vim.org and weighing in at an awkwardly anemic 9.1MB - Vim! In the corner to my right, hailing from gnu.org and weighing in at a morbidly obese 46MB - Emacs!
At YAPC::NA 2012, we will once and for all declare a definitive winner in the decades old battle between Vim and Emacs! Two editors go in, but only one comes out. Be there to witness this history making event!
Telling people in the Perl ecosystem that YAPC::Asia 2011 is happening is a good start to let the world know about our beloved conference. Obviously people in that community are eager to hear about when the festivities are going to begin.
If your entire intention is to have fun with old pals, this is probably enough of a marketing. I'm not saying this is a bad thing, but I have something else in mind: I want people who have never been to a YAPC before feel the energy of our community. Yeah, so nobody can deny that we have a relatively old codebase, but just see this thriving community! I want people who don't really care what language they use to see that what kept me with Perl for over a decade.
So, what do we do? Well, neither JPA nor I have that kind of reach to people who aren't in the regular meetups. There there's only one thing to do: Go get somebody else with that reach to promote
Yesterday I stumbled across an error message of perl5 I've never seen before:
Can't locate loadable object for module X in @INC
I was trying to test a module A that uses a module B that isn't installed. The perlmonks told me that it had something to do with DynaLoader.
I already had a
use lib "'MODULEB/blib/lib";
in my setup.
What made it work was an additional
use lib "'MODULEB/blib/arch";
The reason is that module B is XS based and results in a moduleb.so. DynaLoad looks for this moduleb.so and is only able to find it if the "arch"-directory is in @INC.
Since the application has lots of modules that use each other, I've come with the following snippet I include in every test:
BEGIN {
my $fh;
# this is the directories where all modules are in seperate directories
my $dir = '..';
opendir($fh, $dir) || die "can't opendir $dir: $!";
my @entries=sort readdir($fh);
closedir $fh;
# get rid of '.' and '..'
@entries= grep { /^[^.]/ } @entries;
# add the directory name to get a name we can give 'use'
@entries= map { "$dir/$_" } @entries;
# we only want directories ...
@entries= grep { -d } @entries;
# expand @INC
for my $dir (@entries) {
# Perl-only modules
eval "use lib '$dir/blib/lib'";
# modules with XS
eval "use lib '$dir/blib/arch'";
}
}
That naturally gives me a quite impressive @INC.
diff -qr dir1 dir2
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
