What if a CPAN mirror wasn't stationary? How would we track it? Would people make Google Earth maps to show its path? Could we dynamically adjust capacity without additional servers? Would we have to get FAA approval?
Ricardo and I started talking about CPAN mirror data, mostly because Ricardo was relaying messages to me from Adam Kennedy on IRC. That turned into a discussion of what work we could give Adam as part of this hackathon, and since he's not here. Steffan Müller quickly wanted in the fun of porposing work we could heap onto Adam.
Some time ago I searched for constant hash algorithm at CPAN and found nothing. So I wrote one. Here it is - distribution can be found on CPAN, development tree is on github.
The algorithm is well-known and shared by most of constant hash implementations. At Last.fm they have written a C library called ketama. The algorithm I have implemented is the same but written in pure perl with only one dependency - String::CRC32.
Here are some scenarios I have used it in mass-hosting environment project:
Despite my being on the other side of the world, I hope to remain at least somewhat as productive as if I was at the actual event itself (even if this is not particularly achievable).
I've made it something of a tradition for myself that I use time spent in airports to work on modules and algorithms that make it easier to write programs that deal elegantly with being offline, or being in nasty network environments.
This year I've been revisiting one of my biggest successes in this area, LWP::Online.
I originally wrote LWP::Online in response to the rise of "captured" (my term) wireless networks in airports. Captured wireless networks allow you to connect without a password, and appear to have working internet, but all requests result in a redirect to some login, advertising or paywall page.
If your feature request is complicated or I'm just too dumb to understand it (more common than I like to admit) and you don't a patch or tests to send me, there's a good chance it will be ignored. My bandwidth is limited enough even with patches (which I have to read, evaluate, apply, test and release).
I'm in Amsterdam now, the morning of the first day of the 2011 Perl QA Hackathon, and about to be pulled in by the black hole of Perl developers that is Booking.com. Curiously, this is the first trip in a long time that I haven't used Booking.com for my reservations.
Every year that I come to one of these workshops, my list of things to work on get longer and longer.
Last year I sketched out, with David Golden's help, a possible new CPAN client. We held off last year to see which direction Miyagawa would go in, but this year I don't think our tools really overlap. His tool, cpanm, appeals to the people who want the tool to not only make most of the decisions but also hide the details. It's started off as zero-conf, and you can still use it like that, but it is starting to get some knobs and dials.
I've been lurking on the various ARM Linux boards for a while, so when I saw a hackable ARM appliance for $40, I grabbed it.
Honestly, setting up (Arch) Linux on it was the easiest Linux setup ever. [By cracky, back in my day we didn't even have ZEROS in our binary!] After installing a few Perl packages from the PlugApps repo, I decided, "Why not try to kill this wee Linux box and its THUMBDRIVE filesystem with PostgreSQL and some heavy DBI action?!" Surprisingly, it'd actually probably be usable as a tiny PostgreSQL server. The L'ane test suite, which takes about three-ish minutes on my Core i5 Thinkpad took just under nine minutes on this tiny, silent, USB-DRIVEN box. While a third of the speed might sound like a deal-breaker, the test suite really hits the database with bulk data loads that aren't realistic under normal use. I'll have to whip out my minimum-wage-worker-simulator to see if this (did I mention it's pink?) lil' box can actually hold up to a "real" workload.
AMD released Tapper to github and CPAN, a test infrastructure for all aspects of testing including Operating Systems and Virtualization. It provides independent layers to adapt to different levels of QA requirements, from simple tracking and presenting test results to complete automation of machine pools multiplexing complex virtualization use-cases with detailed data evaluation.
Tapper includes:
Automation
Machine Scheduling
Command line utilities
Web Frontend application
Support for writing tests
Powerful result evaluation API
Testplan support with TaskJuggler
Technologies used:
Test Anything Protocol (TAP)
Core system written in Perl and CPAN
DB independent, developed on MySQL and SQLite
Language agnostic testing (e.g. Perl/Python/Shell test suites)
The Catalyst cookbook provides two recommendations for adding RSS feeds to your application:
Create an XML template, populate the stash with data, let your template view render it, then override the Content-Type: header of your view with Catalyst::Response.
Use an XML::* feed module to render the XML, manually set the Catalyst::Response body, then set the Content-Type: header.
The former almost makes me angry, and the latter, although saner, puts view-specific responsibilities on the shoulders of the Controller.
Catalyst::View::XML::Feed
Catalyst::View::XML::Feed is an attempt at something cleaner, and more in the spirit of MVC, which makes the nitty-gritty details of presentation entirely the responsibility of the view. Using it is pretty much what you would expect from any view:
Put your data in $c->stash->{feed}
Forward to your View::Feed (or whatever you called your Catalyst::View::XML::Feed subclass)
It attempts to be as intelligent as possible, allowing you to supply data in a wide range of formats to the feed value in the stash. These can be XML::* Atom or RSS objects, custom objects, plain hashrefs of values, etc.
As always, any recommendations or other feedback are warmly welcomed.
The response to my original Ouch post has been overwhelming. Based upon the number of responses it got and the number of emails I personally received about it, Ouch must have struck a cord.
I've taken the feedback I've received and released Ouch 0.03. New feature details after the jump.
If you have a regular look on blogs.perl.org, you will have noticed a certain newcomer around here who keeps posting uncommented Perl scripts. I don't mind a noob asking stupid questions. Heck, I don't even think that noobs can ask stupid questions. But can the Perl community afford to have really bad code on a domain named 'perl.org'?
I have recently replaced my perl news bot for IRC (#news@irc.perl.org) and Twitter (@perlnews) along with the server where it resides. Now it is powered by AnyEvent (it was a Plagger bot before), and its repository goes to github as well. If you find anything wrong or if you have any feeds to be included, send me a pull request. Enjoy.
For the past many years I've been using Exception::Class to create rich, object-oriented exceptions. However, I've always disliked it, but I never found anything better. I felt like it was just too verbose and seemed to get in my way more often than it helped. Finally I created Ouch, a minimalist exception handling system. Details after the jump.
So the 2011 Perl QA Hackathon is happening here in Amsterdam and sponsored in part by my employer, Booking.com (what? You want to sit by a canal here in Amsterdam, eating bitterballen, drinking Grolsch and loving life as an expat? Drop me a line because we're still hiring). This will give me a chance to catch up on a fair amount of code I've been neglecting (testing related and otherwise). Of course, I think I have a damned good excuse for not being as "present" in the community as I otherwise could be the last couple of months:
That being said, I still want to apply some long-neglected patches to Test::Differences and other modules.
I also have a few other ideas up my sleeve, but we'll see how much time we have.
This is mostly a note to myself in case I ever need to do this again. I’ve already got a git managed puppet config and need to remember how to deploy it on a new server.
Pre-Requisites
Debian based server (Debian, Ubuntu)
git repo for existing /etc/puppet
if you don’t have an existing repo, you can turn the default /etc/puppet into one later
On your server
You’ll need to install the tools and your configuration:
Installing Puppet Master
sudo aptitude install puppetmaster vim-puppet
Install git managed puppet repo
Don’t forget to change the repo name where necessary!
I had been sitting on my data "visualization" idea App::ffeedflotr for some time already, and had just started writing and publishing it on github. That dataset pushed me to write a short tutorial / showcase of the application.
The screenshots were produced by WWW::Mechanize::Firefox, the charts produced by the flot library, and the Javascript manipulation also came through MozRepl::RemoteObject. It's nice when your tools conspire to surprise you in a good way!
It seems I wasn't paying attention to the CPAN Testers Statistics site when writing the March Summary. A little over 11 weeks after our last milestone, on 11th March we pass the 11 millionth report, as can be seen on the Interesting Stats page. As always, many thanks to all the testers who have help to contribute to this milestone.
Congratulations to Andreas J. König for posting the 11 millionth report. It was a PASS for Parse-ErrorString-Perl-0.15.
This post is one of
a series
prompted by
an exchange of papers on the Internet.
That exchange discussed what it would take to produce
an acceptable replacement for yacc
and the entire family of LALR-based parsers.
My first post
concentrated on speed and
power -- the ability to parse all context-free grammars in O(n**3) time,
and the ability to parse just about every
grammar in practical use,
including all yacc-able grammars,
in linear (O(n)) time.
This is the second of two posts
about error reporting.
Error reporting is often ignored,
but it is extremely important.
In
a previous post,
I suggested that its poor error reporting properties are
the real reason why production parsers are abandoning the once-dominant LALR
in favor of hand-written recursive descent.
LALR's feedback on grammar errors could pass for
low-grade encryption.
Анонс выпуска №1
Perl программист, CPAN-автор, один из разработчиков популярного web framework’а Mojolicious, организатор локального Perl-сообщества Ростова-на-Дону - RostovOnDon.pm, человек который живет по принципу: “use Perl or die;” - Анатолий Шарифулин в гостях у Yet Another Perl Podcast.
Свои вопросы Вы можете писать в twitter: twitter.com/yapp_ru, по почте: yapp_ru@gmail.com, в jabber: yapp@demond.org или в комментариях к данному анонсу на blogs.perl.org по адресу: https://blogs.perl.org/users/perl_demon/
