I've just released a new module called
Action::Retry.
Use it when you want to run some code until it succeeds, waiting between two
retries.
A simple way to use it is :
use Action::Retry qw(retry);
retry { ... };
And the Object Oriented API:
Action::Retry->new( attempt_code => sub { ... } )->run();
The purpose of this module is similar to Retry, Sub::Retry, Attempt and
AnyEvent::Retry. However, it's highly configurable, more flexible and has
more features.
You can specify the code to try, but also a callback that will be executed to
check the success or failure of the attempt. There is also a callback to execute code on
failure.
The module also supports different sleep strategies ( Constant, Linear,
Fibonacci...) and it's easy to build yours. Strategies can have their options
as well.
To make the Debian-Perl module look-up more useful, there are now install instructions included. That means that all non-packaged CPAN dependencies and also all packaged ones are listed and it's clear what can be installed from packages and what needs to be installed from CPAN. Here's an example for App::TimeTracker:
Just a note that this works fine for Debian stable+testing+unstable. Which is not so common. Most installations will be stable or testing+unstable. Once Debian Wheeze (7.0) will become stable (hopefully soon) I'll split that search to two - one for Debian stable and one for Debian testing+unstable.
Does Moose eliminate the sin of False Impatience* by making it so damn easy to just add a dash of OO to your script in order to avoid messing around with data structures? That's how I've started, so there's bound to be a few contusions as I find the corners of my own ignorance, digging out the notes from Dave Cross' most excellent Perl School on the subject. It's not pretty, but it gets the job done.
This is a story about how hacking away at a script taught me some things that I should have known.
We will enable registration with payment soon and post more information about the Social Event soon on our website.
Company description in German:
Delticom ist Europas führender Reifenhändler im Internet. Gegründet im
Jahr 1999 betreibt das Unternehmen aus Hannover heute in 42 Ländern
über 100 Onlineshops, darunter ReifenDirekt in Deutschland, der Schweiz
und Österreich, mytyres.co.uk in Großbritannien und 123pneus.fr in
Frankreich. Die breite Produktpalette für Privat- und Geschäftskunden
umfasst mehr als 100 Marken und über 25.000 Modelle von Reifen für
Pkw, Motorräder, Lkw und Busse, außerdem Kompletträder, Motoröl und
Pkw-Ersatzteile und -Zubehör.
Delticom-Kunden genießen alle Vorteile des modernen E-Commerce:
einfaches Bestellen von zu Hause, hohe Lieferfähigkeit und nicht zuletzt
attraktive Preise. Die Lieferung erfolgt in durchschnittlich zwei Werktagen
nach Hause oder an jede andere Wunschadresse. Alternativ können
Kunden ihre Reifen zu einem der weltweit über 30.000 Servicepartner
liefern lassen (allein 8.500 in Deutschland), die professionell und
kostengünstig die Reifen am Kundenfahrzeug montieren.
To make a great conference, we need great talks. Today I'd like to encourage everybody to submit a talk to YAPC::Europe 2013. It's easy, just fill in a form on the conference site: act.yapc.eu/ye2013/newtalk.
This year there will be three parallel talk tracks. We plan to start at 10 a.m. with a keynote (single-threaded) and finish at 6 p.m. with a lightning talk session (also single-threaded). The time in-between will be filled with talks, food and communication :-)
We offer four possible length of the talks: 20, 40, 60 and 120 minutes.
20 minutes are intended for introductory talks, where the speakers gives some basic information about the topic and assumes that the listeners would like to get an idea of a new technology, or some new usage pattern, or new ideas in some area.
40 minutes are for general purpose talks, and the speakers are expected to talk about a particular topic in detail.
Grab the gist with the complete, working source code.
I often hear the question: "so, you're Perl guy, could you show me how to make a web crawler/spider/scraper, then?"
I hope this post series will become my ultimate answer :)
First of all, I compiled a small list of features that people expect of crawlers nowadays:
capability of concurrent, persistent connections;
usage of CSS selectors to process HTML;
easily modifiable source instead of a flexible OOP inheritance structure;
PDL::Graphics::Prima is a Perl plotting library written using PDL and the Prima GUI toolkit. It is targeted at PDL users with the hope of one day becoming the standard plotting library for PDL. PDL::Graphics::Prima provides a complete plotting widget, but one of the great aspects of the library is that it also provides a very simple interface for building one-off plots called PDL::Graphics::Prima::Simple. In this post, I use Mojolicious to pull down some weather data and plot it using PDL::Graphics::Prima. For the initial pass, the initial plotting code is just 1 line. :-)
Yesterday I had the pleasure of releasing version 5.17.8 of Perl.
Perl has had regular, time-boxed monthly development releases for about
three years now. This great improvement on the previous situation has been
accomplished partly by making the release process into something that can be
done even by people who, like me, are far from being experts in Perl’s
internals.
One of Perl’s long-standing traditions is that release announcements are
accompanied by an epigraph, chosen by the release victim volunteer.
Here are some notes about the epigraph I picked for 5.17.8.
I use state variables a lot. They're great for creating a private cache in a method. However, I was recently asked about using them with Roles. What happens when the role methods are flattened into separate namespaces? I suspected that they would share their state, but I wasn't sure, so I wrote a quick check.
I recently blogged about Ask, my new(ish) module for interacting with users via STDIN/STDOUT, a GUI, or whatever means possible.
Writing GUI code in Perl unfortunately requires you to compile non-core modules such as Gtk2, Wx or Tk. There is an alternative no-compilation-required approach though: most modern Linux and BSD distributions ship with (or at least package for separate download) a program called Zenity. Zenity is a tool for adding basic GUI dialogue boxes to shell scripts. You call it like this:
zenity --file-selection
And it will display a standard file chooser. Once a file is chosen, Zenity will print the file path to STDOUT and then exit.
Ask provides Ask::Zenity, a wrapper around Zenity, and will fall back to that if Wx, Gtk2, Tk, etc are not available. However, none of this really addresses Windows...
So I've been messing around with Calendars a bit for fly-half in order to handle events and stuff like that nice nicely... in a typical ADHD Yak Shaving event I ended up writing a new CPAN module for dealing with Calendars : Calendar::Model
You can see a nice Bootstrap calendar page in the examples on github with the end result looking like this image on twitter .. I haven't hooked the perl into generate it dynamically in the example yet, hopefully have that working nicely soon tho.
Fixed Devel::Loaded to not include itself in the output (thanks to NEILB@cpan.org for spotting this problem). As long as you don't have files like 'MyOwnDevel/Loaded.pm', you are good to go.
Patched pmeth to flag constants (thanks to jpierce@cpan.org). Note that XS constants are not yet flagged (needs some C-fu applied).
Patched for basepods now in 'pods' in modern Perls. I guess the patch was from a CPANgnome, as there was no Requestor :(.
At work I recently set up a Jenkins instance to run all our tests whenever someone pushes changes to the master branch of our git repo. And, after changing some stuff in our code that made the perl debugger cry*, I added Devel::Cover to the mix. So now, Jenkins not only notifies us by email whenever someone is naughty and makes the tests fail, it also generates a lovely report of how much of our code is actually tested.
Naturally, the first thing I looked at was how well-covered our tests were. This seems like a bit of a weird thing to do, but it has exposed bugs in the tests themselves. Let me explain just one example.
In many scripts,
we need to prompt the end user for information - this could be a prompt for a file name,
a selection from a list of options,
or an answer to a yes/no question.
The traditional approach to this sort of question is to print your question to STDOUT,
read a line from STDIN,
and apply some sort of parsing to the answer...
I guess the main reason I'm writing this blog post is because I feel guilty about it. There are SO MANY other similar modules.
I wanted to review them all, neilb style. I never found time to do it. Damn you, perfectionism.
I don't want to explain my issues with other modules here. I'm not sure if Lock::File is really much better than others, or if I'm just biased because I used it for years. You can look at Lock::File POD and decide for yourself.
But I finally realised that I have too much unreleased code and I've postponed its uploading to CPAN just because I didn't want to duplicate some existing code. Damn you, perfectionism.
Purdue's Course Signals provides instructors with an early-warning system for students who are struggling or otherwise in trouble in their courses. And it works! Possibly the coolest piece of educational technology I've seen in quite a while.
I started writing this as a response to chromatic's post at his Modern Perl blog. Short version: I think that the VM will be no problem for Moe, Stevan Little's new project to bring a Perl (or dialect) to the JVM.
Overall, I think chromatic's points are very good, and I agree with many of them, especially in the "What Moe Could Produce" section.
But I disagree with one point, in that the JVM has (at least to me) proven that it is an excellent platform for hosting dynamic languages. Well, at least one dynamic language.
Galileo is a simple but modern Perl CMS which is totally installable from CPAN. Just a few quick commands and the site is live and usable! The primary focus is small sites, which need immediate availability and easy (no?) administration. All content is written in a markdown editor in the browser and saved live via websockets with no reload.
This morning I released the newest version of Galileo with several improvements that have been in waiting for months. Among the most exciting is preliminary support for in-place database upgrades via DBIx::Class::DeploymentHandler.
In addition, Mojolicious author Sebastian Riedel made an extra effort to ease the testing of JSON messages passed via websockets. This means that Galileo’s two-way communications between the browser and the server are now even more robust and better tested. Further, this move has made unicode handling more reliable (since websocket unicode handling has its own quirks) so I can now say that Galileo should be unicode friendly! Thanks SRI!