Torsten Raudssus will give a talk at YAPC::NA 2012 described as:
Talk about DuckDuckGo and Perl. The application and infrastructure of DuckDuckGo and about the Open Source and GreyPAN movement. Also giving an overview how to contribute to DuckDuckGo. Good for beginners to dive into Perl and contribute to a real world service directly.
If you requested a payment from the Perl Foundation recently, you may have noticed a little bit of lag in receiving your check. Or, a very few of you were even unfortunate enough to have received a check and then asked not to cash it. Here's what happened...
"Much of what looks like rudeness in hacker circles is not intended to give offense. Rather, it's the product of the direct, cut-through-the-bullshit communications style that is natural to people who are more concerned about solving problems than making others feel warm and fuzzy." - Eric Raymond
I’ve worked out a deal with University Housing for the dorms for YAPC::NA 2012. They’re now accepting reservations for Sunday, June 10th in addition to the weekday reservations. This should help those of you who are coming in for the workshops or hackathon. Register for your dorm now, or update your existing reservation.
Every time I use perldoc for any term slightly unusual, I struggle. Have you tried to use it to find UNITCHECK? Now you can. Instead of remembering which of these to use (and none of these will find UNITCHECK):
In the last case above, the --all is needed to do a brute force search. Ordinarily, you just do perlfindsearchterm, regardless of whether it's a module name, function, variable, or faq keyword and it will return the first result found (searched in the order I just mentioned). Otherwise, it will tell you to use --all if you really want a brute force search to find out where that term is used.
Here's a gist I tossed out there. Patches welcome. I should bundle this up and put it on the CPAN (and handle older perldoc versions).
I mean creepy in the sense that results slowly creeping in. People who follow my tweets know that 2 smaller milestones are achieved: predefined subrules and regex quantifier are now all in place (in Index A and B). This was of course a byproduct of my upcoming Perl 6 Regex and Grammar talk.
So we not far away from 700 items in Index A (50 more than last time). Some bits other were done.
Hope you guys are not to impatient but since im doing this thing for years and still on it, its not far fetched that one day im ready with it. It's also like writing a book, which, when taken seriously, needs constant improvement. The quality and consistency of the entries grew all the time. They also explain some of the terms like LTM, role, runtime and so on. if you think that doesn't have to be in an index, please let me know.
When it comes to
user experiences with Marpa,
I confess to being a highly biased source.
I hope the following observations
will be useful nonetheless.
(Marpa, for those new to this blog,
is a new, powerful and fast parser and parsing algorithm.
To learn more,
check out its web page.)
Marpa does the job
If you've read user's accounts of work with BNF grammars over
the years
(I have studied many),
you know they follow a familiar pattern.
The user has some BNF.
He then tries tool X (for X substitute
yacc, bison, PEG, recursive descent, etc.)
and finds that it almost works.
Almost, but not quite.
The rest of the account describes the user
beating up his grammar in an effort to make
it fit the tool.
Perhaps 50% of the time, he reports that his effort
was wasted.
Graham Knop will give a talk at YAPC::NA 2012 described as:
In this talk I’ll talk about the massively multi-player video game written in Perl known as The Lacuna Expanse. I’ll talk about how and why it was built (some Perl internals). And I’ll also tell you a little bit about Lacuna’s achievements.
I have high hopes for this module as a tool to help authors provide the C libraries they need through CPAN far more easily than hand rolling an Alien:: module. As such I feel a deep urge to ensure that Alien::Base is robustly tested.
Unfortunately I’m finding that testing such a module is rather hard. Alien::Base is a very abstract concept. It only makes any sense when it is used as the base class for some other Alien:: module, and futher, THAT module is only fully realized when it is used by some other module which needs that C library.
Nathan Gray will give a talk at YAPC::NA 2012 described as:
Some of the benefits of working with other programmers are being able to absorb best practices, avoid pitfalls, have more fun, and write better, more consistent code.
We will discuss what works and what to avoid, and how to interface with brilliant, introverted people who want to get their own work done.
With over 120 developers in our teams, based in London and Cluj, Evozon offers custom software solutions, business analysis and project management across the widest possible range of technologies and platforms for web and mobile. Our clients rely on us for innovative bespoke or platform-based solutions.
Of our over 120 strong team in Cluj-Napoca, Romania, over 20 are full-time Perl coders that have in-depth experience developing Perl – using a wide range of frameworks. These technologies include mod_perl, Mason, Catalyst, Moose, DBIx::Class and Class::DBI with MySQL or PostgreSQL all architected in a high availability and scalable model with the best practices one would expect. Evozon also supports Perl by sponsoring and participating in YAPC Europe, London Perl Workshop and some contributions to CPAN.
The former is complicated, but suffice it to say TB2 cannot rely on Mouse or Moose or Moo. It's being solved by writing an OO compiler, something which will generate accessor methods and roles at build time rather than relying on a runtime compiler. This should also solve TB2's less than ideal startup time. It might be Mite or it might be Moo, but the problem is being taken care of.
The second is harder and is what I call "Test::Builder2 vs CPAN". Because Test::Builder has been around or so long, and so much depends on it indirectly, there's a lot of not entirely documented behavior being relied on. We've been using CPAN modules as a broad test suite right along for this reason. TB2 has the potential to seriously break a lot of module's test suites, so it's best to get it as right as possible before stable release.
Juan Natera will give a talk at YAPC::NA 2012 described as:
Attending a live entertainment event is a social experience, but at Ticketmaster we decided to take it to the next level by integrating with Facebook on our Interactive Seat Map. This Allows fans to see where their friends are seating, helping them to get seats close to their friends. In this presentation I will discuss some of the challenges we faced with this project, what we did to overcome them, as well as a live demonstration of the product.
Calling whatever happens to be lying around on a particular date a "stable release" is a laughably bad idea (the "rhythm method" is also lousy birth control). A "release" is something you want lots of people to use; "the stuff in version control on the first of the month" is something else entirely.
Perl releases used to take awhile -- so do releases of POSIX, HTML, C, and C++ -- and that was not a bad thing. It's the difference between a platform and a fad.
CPANDB is a pretty awesome tool, in my humble opinion.
It takes a whole variety of different data sets from the CPAN group of services, and cooks them down into a single unified SQLite schema that you can access via a convenient ORLite wrapper (or access directly if you wish).
This single database file can then be used both as a convenience for simple tasks, or to build deep and complex analysis metrics of the kind I used in the creation of the CPAN Top 100 website.
The biggest problem with this module has always been the problem of server resources. To generate the database originally required downloading the CPAN Testers database. Even today in it's updated form it needs the CPAN Testers summary database, and that doesn't necessarily calculate it's metrics the way that CPANDB likes them.
To make CPANDB a truly useful tool that other parts of the CPAN ecosystem can rely on it needs to become much more stable and be updated regularly.
The de facto standard way of constructing portable filesystem paths in Perl is through the use of File::Spec's catfile and catdir functions. Example:
my $path = File::Spec->catfile('dir', 'subdir', 'file.txt');
This method, or a similar one involving Path::Class, is the most recommended approach and has been adopted by application development frameworks like Dancer (which has a wrapper method for it, named path) and Catalyst (with its path_to method).
The slight problem that I see with this method is that it makes code a bit more complicated, and thus a bit less readable. Paths become lists of parameters and no longer look like paths.
I wrote a simple module that tries to address this by allowing you to write paths the traditional way -- as strings, using a directory separator of your choice (/ being the default), while the catfile stuff happens behind the scenes. You can just say:
my $path = path 'dir/subdir/file.txt';
What it does is it splits the path string on each occurrence of the forward slash and feeds the resulting list of path components to File::Spec->catfile, which reassembles them using the appropriate OS-specific directory separator, and constructs the OS-specific path that you want.
The module is up on Github, and should also be available on CPAN shortly.