After doing this post on comparison of Perl serialization modules, I intended to continue with other comparisons, and even thought on setting up a wiki or creating/maintaining a section on the Official Perl 5 Wiki, which already has a Recommended Modules section, although there is not much comparison being written for each recommendation. (Btw, I just noticed a change of domain for the Wiki, from perlfoundation.org to socialtext.net).
But of course other tasks soon took precedence, so until the Wiki idea is realized, I thought I'll just continue posting on the blog as usual.
There are **seriously** too many Perl logging frameworks out there. As the Log4perl FAQ mentions, "Writing a logging module is like a rite of passage for every Perl programmer, just like writing your own templating system."
So I'm not going to pretend like I've evaluated even half of logging modules that are on CPAN. Instead I'm just going to include a few worth mentioning.
In october a fellow Monger, Wolfgang Kinkeldei, made a talk about "Couch-DB" for the ERLUG, the Erlangen Linux User Group. One of our Perl-Mongers organized a room for the at the computing center of the university Erlangen-Nuremberg. Therefore the Erlangen Perl-Mongers recognized this talk and could attend as well.
CouchDB is a famous NoSQL database system that got quite some attention lately. It is a project hostet at apache foundation and follows a document oriented approach. CouchDB uses REST and JSON as a powerful but easy interface. Furthermore, it provides a web-based administration interface out of the box. And with its ability to use Javascript as its internal procedural language you can easily create simple web applications on top of CouchDB without other technologies. Wolfgang told us about these features and showed us some of those things live.
Wolfgang did the talk only as an exercice, he will do the talk in front of mor people at the anual KNF-Kongress in Nuremberg.
Besides the talk the people of ERLUG and the Perl-Mongers Erlangen got the opportunity to meet each other, to share thoughts and to learn about the other group. So maybe the one ore the other meeting we will get new attendies at our meetings.
After some kind member(s) of Vienna.pm brought the server back to life, and some anonymous coward sent me an email via an anon remail asking for fresh data, I got my lazy ass off my chair .. wait, no, actually I stayed seated in my office chair .. so I got my lazy mind off other things and started a complete CPANTS reindex yesterday morning. It took all day, but since of yesterday evening there should be new and up-to-date data available on cpants.perl.org.
Of course the code that's generating the data is rather out of date, especially with regard to stuff like Moose, Devel::Declare and even newer Perls (i.e. > 5.10). The code is on github...
I don't expect to spend any time on fixing / improving the code in the next few months. And the best thing to do would be to rewrite/refactor the whole beast to make use of the metabase and to also store the generated data into the metabase.
I'm converting Marpa
to XS and have started to use Cweb.
Cweb is
the C version of the "literate programming" system pioneered
by Don Knuth.
I'm pleasantly surprised by it.
Cweb adds fun to the programming experience
and is helping in more ways than the phrase
"literate programming" would suggest.
One very important feature of Cweb
is something that would seem to be a nuisance,
or at best an implementation detail.
The .w file
which contains the Cweb is now the "source".
The
.c and
.h files are now "built files".
I am no longer working with the C language
"translation units".
("Translation unit"
is standards-committee-speak for
the text which is
directly input into the C compiler.
The term is used in attempt to distance the standard from
file conventions.)
The front content was WYSIWYG'd by their previous ISP. Prolific position:absolute CSS makes that content painful to edit. But links to the shiny new backend are all Catalyst, Template Toolkit, and lots of jQuery.
After about a week of waiting for an official review, iCPAN was reviewed, approved and published to Apple's App store earlier today. There are no code changes in this release, but the modules are up to date as of Nov 8, 2010. This release also includes manuals and cookbook POD like Moose::Manual.
I had hoped to get this release out in September, but real life got in the way. In the meantime, I've streamlined the way the POD is processed and future releases will be easier and hopefully much more regular.
Very happy that f00li5htweeted to me about the Vi::QuickFix module. In vim, my leader is the comma and when I type ',c', I now execute perl -MVi::QuickFix -c % and that creates an error.err file which vi's quickfix mode can read. :cf will take me to the first error in the fix and :cn will take me to the next error. It will even jump to the correct file, as needed. See vim's :help quickfix for more information.
However, I've done more than that. See a bunch of problems in your files? Try running this:
On our code base, that takes around 25 minutes to run. Then I have this in my .vimrc:
" quickfix for Perl error formats
set errorformat+=%m\ at\ %f\ line\ %l\.
set errorformat+=%m\ at\ %f\ line\ %l
Those two formats match the Perl errors I'm getting (note how one ends with a dot). With those, I can now jump to all errors and warnings that compiling our code generates.
I have just finished a re-write of CGI::Session, called Data::Session, and started wondering how best to test it.
I've always disliked setting all the env vars to make its tests work for MySQL, PG, etc, so I hit CPAN looking for A Better Way.
I found Test::Database, which seemed to be a good idea. But examining the code was discouraging, so I decided to re-write that too.
I soon realized that one thing (among many - see below) which bugged me about Test::Database was its handing of DSNs.
So I decided to split that out into a separate distro, using an INI-style file, so I could add extra attributes to the DSN, such as active and use_for_testing. I might add use_for_production too.
That's why I've just released to CPAN DBIx::Admin::DSNManager V 1.00.
Now I'll use that in the re-write of Test::Database, which I'm going to call Test::Admin::Database.
Padre 0.74 has been uploaded to pause and is in the queue for indexing and replication to your favourite CPAN mirror.
So while all that happens, lets take a look at what has been happening since 0.72.
Well, plenty of fixes, and a fair amount of work done with the Plugins and converting them to Dist::Zilla by Ahmad Zawawi. The changes file doesn't really show the work that goes into the Plugins, but keeping one eye on the irc logs shows plenty of commits from Ahmad between releases.
Many of the plugins for Padre reside in the same SVN repository as Padre itself, so if you find an itch that needs scratching, you don't have far to look to start scratching.
Zeno Gantner is finding time to work on bits of Padre even with a rather hectic sounding life at the moment.
I'm about to start writing about a bunch of stuff that will definitely show my lack of a computer science background. Unlike many of my posts, this is your chance to correct me rather than me explain things to you. This has been on my desktop for awhile, so I'm cutting bait and posting what I have instead of working on it more.
He ist lead dev of Scintilla the edit component, Kephra, Padre and Kommodo are using. And I was very happy to read that he will open up the internal API. So Perl editors will be able to do even more.
You can do some fun stuff with this module - it allows easy preparation of data for use with the Google Visualization API - ie: any data source you can access in Perl, you can easily spit out as one of a number of awesome and often interactive graphs and charts.
If you make something pretty with it, let me know!
Yesterday we had some troubles setting up a client that should post some utf8 JSON to a web API. The problem was, that the data kept showing up as latin-1. After lots of "fun" with hexdump, wireshark, the debugger and Devel::Peek we verified that we were in fact passing a properly utf8 encoded JSON to LWP::UserAgent like so:
After adding encode_utf8 in random places, it worked. So I dug into google and found this posting containing this advice:
If you want the string UTF8 encoded, then say so explicitly:
$req = HTTP::Request->new(POST => $endpoint);
$req->content_type("text/plain; charset='utf8'");
$req->content(Encode::encode_utf8($utf8));
It seems that HTTP::Request, when stitching together the actual text representation of the request, will downgrade the content to latin1, no matter what you say in Content-Type, unless one explicitly calls encode_utf8 on the content.
Mistake #4, "Use of Adhoc Queries", seems to be true only when you have a large, heterogenous development staff (like 10+ developers). Smaller development groups don't seem to suffer from allowing ad hoc queries by developers. (Perhaps it is mainly a communications problem, rather than just an allowing ad hoc queries problem?)
I've always been an avid hater of uninitialized variables. I'll hunt them down, catch them and beat them to a bloody pulp and then shoot the remains.
Too much, you say? No need for the bat AND the gun, you say? Oh, quite the contrary.
Here is an example of a recently discovered Linux kernel issue. An uninitialized memory segment. The fix is really simple: to initialize it with zeros. This was done in a patch that only adds the following command:
+ memset(mem, 0, sizeof(mem));
Oh, but I can hear you snicker behind your monitor "this won't happen in Perl because Perl protects you from such stuff!"
You're right, this won't happen in Perl. But here's a Perl example:
At $work I've written a program that runs checks on servers (rest assured, it's not a Nagios replacement) and creates an array of the results of each server that was tested. The array contains timing and whenever there's a timeout, it contains an "undef" to indicate a penalty.
I'm looking for a Catalyst or other Perl based application framework that will do standard CRUDS (CReate, Update, Delete, Search) functions. I've seen a few of the online writeups about how different people put these together in as few lines as possible, but I'm more looking for one that I can just install via CPAN, configure a database connection, and start the server.
(This is a long time overdue post in Ubic series. Previous posts can be found here.)
Last time I explained how any kind of service start/stop/status behavior can be encapsulated in an Ubic::Service subclass. But what if you have many similar services, and want to generate the service list dynamically?
For example, sometimes you already have a directory with daemon configs, and want to run them all without creating additional "service description" file per daemon.
Or you may wish to start ten instances of one processing script.
Or maybe you keep the list of your services in SQL database on another host.
In all these cases, multiservices come to the rescue. Multiservice is a container object which provides part of the service tree.
For example, let's assume you have a dir /usr/share/psgi-apps/ with some psgi apps in it:
I was doing a lot of work on Dancer lately. We've been experiencing a few test failures on Windows with the upcoming big release. I'll admit we are usually reluctant to go to Windows-land and fix issues, but Alias sure made it clear how important it really is, so it was something that had to be done at some point.
While investigating this situation, I've noticed Cwd's realpath() function was complaining a path for a test did not exist. The path did not exist for Linux or BSD either but the test wasn't failing there.
After checking out Cwd more closely, I've noticed it had an XS version for Linux, BSD and other operating systems and a few Pure-Perl implementations of realpath() for some (OS2, MSWin32, DOS, VMS, for example). Upon inspecting the XS code and the Pure-Perl code it was apparent that the versions were not exactly the same. On Windows if a path does not exist, it will croak but on Linux it will continue running.
Blessed are the CPAN Testers, for they show us the bugs!
