If you know interesting things about how you can work with IPv6 in Perl nowadays, you are more than welcome to submit a talk to YAPC::Europe.
I believe there're lots of pieces to talk about in that field. The talk can be as detailed as the recent answer about using UTF-8 on stackoverflow, or it can be a five-minute lightning talk. Please share your experience!
Given the large amount of commentary on my first A/B testing post, I was surprised that there was none for my "A/B testing and local maxima" post. That's when I discovered that when you start a post and publish it several days later, if you don't update the date, it keeps the start date and thus gets buried in the queue. So, if you haven't subscribed to my atom feed, you may not have seen it on the front page. This is just a heads up that I took the time to answer some questions people had.
Bundlefly is a hack I've written to build a graph of a bundle's distributions and install them in optimal order. It accelerates the installation of entire library suites for new Perl builds and perlbrew instances. As with App::PipeFilter, it may end up on CPAN if there's interest.
Autobundle snapshots are comprehensive by design. They list all installed modules at a particular point in time. We should rarely be asked to confirm "unsatisfied dependencies" while installing them. The dependencies are almost always somewhere in there.
To compound the suck, we're often asked to install the same fundamental dependencies repeatedly. ExtUtils::MakeMaker and Test::More immediately come to mind. We shouldn't be asked once, yet we're asked several times by the end of the day.
One problem is that autobundle snapshots list distributions alphabetically, and CPAN's shell installs them in that order. Test::More, a distribution used to test a large portion of CPAN, is installed relatively late—after it's already been prepended to the install queue as a dependency of several other distributions.
Bundlefly's dependency graph allows it to install dependencies before dependents. The only "unsatisfied dependencies" one should ever see are those introduced since the last CPANDB build and which aren't listed in the autobundle snapshot.
its a small idea and a module. in fact I wrote the core code in a minute on a slide of my talk I held 2 weeks ago in Berlin. Now it becomes "real" :). from the "doc":
use Tie::Wx::Widget;
tie $tiedwidget, Tie::Wx::Widget, $widgetref;
# instead of say $widgetref->GetValue;
say $tiedwidget;
# instead of $widgetref->SetValue('7');
$tiedwidget = 7;
untie $tiedwidget;
Its just the simple idea to reduce visible syntax, but will become more usefull in combination with the next planned module that takes you XRC-produced widgettree and gives you a similar tied hash, so you have not only a simple API for your basic IO but also all locked in the namesmace of a hash variable which you can much easier pass around when creating event driven subroutines. if the widgets dont have name attributs i will have to be more tricky.
Please post your thoughts on that. I plane some even bigger surprises.
A few months ago there was a rumor of Richard Stallman coming to Palestine, and I contacted him to suggest giving a few talks in Israel as well. He inclined and there were 4 lectures/speeches booked:
One at Shenkar College in Ramat Gan, Tel Aviv (which is where TelAviv.pm meets)
One at Tel Aviv University
One at a DIY venue for political activists
One at Haifa University
I booked the Shenkar College one (for the Tel Aviv Perl Mongers and anyone who wanted to attend) and the one for political activists. I've slowly been collecting a group of people to help me organize the first meetup (which should have been in front of 300 people) since I did not want any organization or company (except for TA.pm) to be behind it. I wanted complete freedom, excuse the pun. :)
Back in February I did a presentation for the Birmingham Perl Mongers, regarding a chunk of code I had been using to test websites. The code was originally based on simple XHTML validation, using the DTD headers found on each page. I then expanded the code to include pattern matching so I could verify key phrases existed in the pages being tested. After the presentation I received several hints and suggestions, which I've now implemented and have set up a GitHub repository.
Registration for the Intro to Moose training session on Thursday is now available. This is an excellent class if you are just starting out with Moose. It covers the fundamentals well and the exercises are brilliant. It is highly recommended.
The class description is available in the schedule.
What I am most afraid of in the kind of A/B testing I've seen is that it seems very prone to getting stuck in local minima. In that image, imagine you're in the place marked with the red arrow. Taking small steps and adjusting for the test result each time, you're never going to reach the optimal place (blue arrow) since once you're in the local minimum, all small steps you can take actually produce a worse result.
I'm happy to report that version 1.00 of Aspect.pm has been uploaded to CPAN, and so Perl's Aspect-Oriented Programming toolkit is now officially done.
The API should remain stable for some time (until the notional 2.00 with it's major rewrite into opcode manipulating XS). Most future changes in the 1.00 series should comprise additions of keywords or features, and code written now should be forward compatible.
But what is Aspect-Oriented Programming, and what it is good for? The standard documentation in AspectJ is full of jargon and most of the code samples are notional at best, and make it hard to connect to any real world situations.
The simplest way to describe the Perl Aspect.pm is that it provides a way of hijacking functions or methods with very little code, and in a very precise and controlled manner.
OK. I've released Set::FA V 1.00 to CPAN. The code passes the same tests as the previous version, V 0.101.
The docs have been re-written from scratch, for both Set::FA and Set::FA::Element.
There have been many changes due to the fact the code no longer does direct access to an internal hash, but uses getters and setters. I have not changed any of Mark Rogaski's code which implements the logic of the modules, I've only made it work in a new OO environment.
Also, I've dropped support for Log::Agent, and provided a parameter to new() called logger, so you can supply any type of logger, and have the code call
$logger -> log($level => $message)
at various points. All this is documented extensively.
Another new parameter to new() is die_on_loop, so otherwise run-away programs can be self-limiting.
I've been waiting for this blog post for a few good months now.
We've finally released Dancer 1.3050 (codename "The Captain Hook Adventure", named after Franck Cuny, who will forever be known as Captain Hook!) which carries our new hook system, written by Franck. Special credit goes to JT Smith who pushed the design and implementation of this system (and had great input and feedback) until it saw sunlight.
So what's the new hook system? Basically Dancer (and Sinatra, and Flask, and others) have a before and after modifiers (or sometimes called "filters"), which are basically hooks for running code before and/or after your request has been handled. This is a good place for running checks, auth-related stuff and special logging or whatnot.
While these hooks were very useful for people, they weren't enough. People needed more. For example you might want to override the error handler, or perhaps to add special data before a auto-serialization process. Hell, maybe you want to even create your own hooks! :)
We're currently working with the resort to resolve the issue of booking rooms. We've made contact with them and their advice is to call 800-733-3211 to reach in-house reservations or to leave voicemail messages, or email reservation inquiries to reservations@hulsinghotels.com. Further, waiting until next Tuesday when the resort can reassess the inventory might be the best course of action.
Around Christmas 2009 I took over Aspect.pm, a first-generation implementation of Aspect-Oriented Programming for Perl based on Hook::Lexwrap
Over the last year and a half I've expanded functionality, cut back dependencies to a minimum, optimised the hell out of it, and written a ton of documentation and a comprehensive test suite.
This second-generation implementation has now reached about as far as I can take it without resorting to exotic XS code to replace some of the exotic Perl code. So after a final 2 week sprint to smooth off some ugly corners, in the next few days I'll finally be releasing version 1.00 of Aspect.pm.
I'll be talking more later about some of the more interesting things you can do with Aspect-Oriented Programming. What I'll also be trying to do is focus on actual useful things, and avoiding as many as possible of the utterly batshit insane things that Aspect.pm lets you do.
A couple of weeks ago a ran into a real life situation where Perl 6 was able to greatly simplify my life. I was in the process of importing some Canadian postal codes from a PDF document where the data was presented like this:
Each postal code, or postal code range, was tied to a zone. To store this to a database, I wanted to expand out each of these ranges to capture each value. Causing the first line to be represented as:
A0A => D13
A0B => D13
A0C => D13
... some more ...
A0R => D13
Using the Perl 5.12 range operator (..) I thought I could use easily accomplish this goal.
Thanks, everyone who was interested in App::PipeFilter. Your interest motivated me to clean it up and send the very first release to PAUSE. It'll be on CPAN once your favorite mirror catches up. Check out the snazzy documentation, which consumed most of my time since my last announcement.
So I've read and very carefully considered the words of Douglas Bowman and his decision to leave Google and much of this was about Google's use of A/B testing ... Google's extensive use of A/B testing. Google engineers clearly valued function over form. He complains about a situation where 41 shades of blue were tested for optimum response (see page 3) and makes it clear that he felt constrained. No matter what he did, how simply he did it, he had to "prove" it worked. He simply wanted to build something beautiful and not worry about extreme micromanagement of every aspect.
I can understand that. Many times I want to just "make stuff happen", secure in the knowledge that I know what I'm doing. I look at how foolishly code is implemented and I think "what our customers really want is X!". And A/B testing shows me, over and over again, that I'm wrong. It's humbling. It's humiliating. And if you really care about being the most effective you can be, you'll love it, but only if your pride can handle being proved wrong on a regular basis.
I've uploaded a new version of autodia to PAUSE and it should be available on CPAN shortly.
Highlights of this release are :
* added Mason handler provided by Peter Franke
* new ASP Handler provided by Dalton Mackie
* improved tests (and made some tests author_only)
* A bunch of minor fixes and barely noticable improvements