I adopted PDF::Report a couple of weeks ago after contacting the authors, who were happy to provide me with the privs I needed on pause, since then I've created a github repo but not had a chance to do any of the work I've been planning.
Before I start messing around with PDF::Report too much though, I'm doing housekeeping.
- so first task is to apply the patches in the current rt.cpan.org bug queue and close them (2 down, 1 to go).
- also, now that it's on github I've added the metadata for that and the perl license to the Makefile.PL so that it's a bit nicer.
- I've also updated the pod so that it's got more of what you expect - a SYNOPSIS and more detailed pod will follow in the next release (and/or possibly the next one)
Often when deploying application one may face the risk of divergence between testing and production environment.
Even though you have a stage servers `like production one', it'd be reasonable to check distributive in
production environment before release is happened. I would call it `early` testing. Yes, of course, some
subtle bugs will arise only in runtime phase, and unit test cannot cover it all, I say here about
prerequisite unmet issues. In perl world unit tests and prerequisites checks are executed in standart way. One follows standard procedure, when installing things.
I put here
example for Module::Build based project, but with ExtUtils::MakeMaker it's almost the same:
perl Build.PL # check dependencies and generate build file
./Build
./Build test # run unit tests
So, why not to automate this process in continues integration approach, like for example Jenkins does?
Note: this post assumes you have Test::Class::Moose version 0.06 or higher (on its way to the CPAN now).
By now you may have heard of Test::Class::Moose. I wrote this to solve a need that many people have: they want the awesomeness of Test::Class, but the modern OO facilities of Moose.
Test::Class::Moose isn't for testing Moose classes, it's for testing anything you would have previously used Test::Class for, except that now you get Moosy (Moosee? Moosey?) goodness to go with it. I'll be attending YAPC::NA 2013 in Austin and I've pitched a Test::Class::Moose talk and, even if it doesn't get accepted, I figured I should at least write the slides. One of my most common uses cases (and and itch I always rescratch whenever I use Test::Class, Test::Class::Most or, now, Test::Class::Moose) caused one of my slides to have too much code.
So now it's fixed, released to the CPAN, and available for everyone to tell me it's "too magical" (a complaint I've heard in the past). Here's the problem and how I solved it.
Perlnews.org has been going for about 2 years now and keeps going well, but we want to ramp it up... a bit... (we want a couple of stories a week really). We are now feeds www.perl.org homepage as well.
So if you have a big event in your Perl project, new major release, or you hear of Perl being used for something that warrants publicity - please let us know.
http://perlnews.org/about/ lets you know about our rough submission policy - but if in doubt please submit and we'll let you know from there.
We are also on the look out for editors - let us know if you are interested.
Slowly, but the Perl Maven site is gaining popularity among people looking for information about Perl. I'll write about the stats later.
Last week Felipe Leprevost asked me if I'd agree for him to translate the Perl Tutorial to Portuguese. I was happy to say yes as I believe having a decent introduction to Perl in your native language can make a big difference, even if later on you'll need to improve your English.
He made the translation and we already made the first article public: Instalando o Perl, imprimindo "Olá Mundo".
There were also several people who offered their help. This is awesome!
Thanks Felipe for your initiative!
The source of Perl Maven on Github
In order to make it easier for us to collaborate I set up Github repository for the Brazilian Portuguese files, and I also made the source of Perl 5 Maven available to make it easier for him to fetch the original English sources. The format is the horrific result of combining PODish with XMLish.
One of the most challenging aspects of website design is presenting information to users in such a way that appeals to the majority. But when advertisers are also part of the equation, a balance needs to be made between the end user's experience and the needs of advertisers. Because of this, we decided to use Perl for our image rotation needs.
Although in the past we used Perl on a variety of websites to rotate images, this task was a bit more complex. We needed a lightweight solution to serve rotated banners to tens of thousands of visitors daily. With an overhaul of our previous rotation code, now written for 5.16.3, we were able to develop a server friendly image rotator that works well in a shared hosting environment.
Again a lovely bike ride to the venue, this time with some air pressure trouble in the front wheel. Then a great day with talks, chatting and again excellent food.
chris fedde asks How do we know when a CORE module is deprecated?. I don't know what was there originally, but it set off a lot of fingerpointing and posturing, and nobody answered the Perl question for the rest of the universe that finds it that post through Google!
As of Perl 5.12, deprecated features and modules warn the user as they're used.
There's the deprecate module which provides this warning. A module is deprecated for at least one cycle before it's actually removed. That doesn't help much if you skip over several perl versions.
And, as one commenter, mentioned, the fallback is for people to read the perldelta pages to find the changes between the version they are using and the version they want to upgrade too.
The information is out there, and as programmers, we have everything we need to play with it however we like. :)
I have mentioned before how much I like CPANtesters! Here is another story.
Yesterday I got an email from them listing a number of failures from Galileo, my CMS. I had recently pushed some bugfix releases, but it had some new, and as yet unused code and tests for that code in it. The tests passed on all my Linux systems, so I wasn’t worried about the release. Yet the failures came in. Some on Linux, some on other platforms, but not all the tests were failures and I couldn’t figure out a pattern. CPANtesters put me on to a problem but for this I needed faster results.
I've spent the last year or so of my daily commute building a social bookmarking site that for me has now replaced my use of delicious, and I think offers more than other services such as diigo, Google Bookmarks et al.
The original site at bkmrx.com was mainly built in PHP & MySQL, however since finishing that site I've taught myself how to use Mojolicious, and did a fairly comprehensive rewrite of the website into a Mojolicious and MongoDB stack. As such it's not a full replication of the features available on bkmrx.com (see the about page for a comparison).
Now with a new job on the horizon, I want to spend less time on building out a better bookmarking service, but at the same time don't want it to stagnate.
To that end, I've released the code for bkmrx.org on Github, and uploaded a live version of the site at bkmrx.org.
This is the first time I've released a relatively big project onto Github and since I'm by no means a full time developer, go easy on me :) However I'm hoping there are others in the Perl community who might be interested in contributing to, forking or otherwise using the code.
You can read more details on my blog if you're interested.
I like writing code. I like writing tests. I don't like:
Trying to figure out where the tests are
Writing boilerplate
Finding yet another package without tests
That last one is particularly vexing when you discover that your code is failing because another package doesn't load, but it doesn't have tests. So I fixed that.
Some of what follows is a repeat of things written in previous posts, but it's important enough that it bears repeating.
Best of all, the talk itself was written in Mojolicious! As Joel was talking, he was able to edit the code and display the results, showing off various features of Mojolicious like:
Websockets
Easy testing (even of websockets)
Helper scripts
Mojo templates
There are quite a few interesting parts of Mojolicious that make it worth giving a look to, and I hope to be able to do so with some web projects that have been sitting in my queue for a while (I wrote a nice ticket tracker with AngularJS, but the backend is Python, I'd like to fix that glaring mistake).
Today I was quite busy $working. I was a bit tired, too, because a group of young and cheerful boys and girls (possible future Perl hackers?) had their small hotel party on the floor outside my room. After a short bicycle ride (numerous places of interest again) I reached the Betahaus (many current Perl hackers).
Just because I was curious I took a peek at various fellow Perler's computers displays. Quite familiarly with hacker's displays there was lots of text; not a small amount white on black.
Today however I learned that there are people using light-blue to dark-blue on black as their favourite colour scheme. Like so:
Perl projects have all manner of ways of declaring their dependencies. CPAN releases usually include a file called META.yml or META.json listing their dependencies (though Makefile.PL or Build.PL is also supposed to generate a list of dependencies when it runs; this allows the release to dynamically decide on different dependencies based on the machine it's running on). Non-CPAN projects can declare their CPAN dependencies using cpanfile too.
Once the dependencies are declared, this information is used by CPAN clients, by metacpan.org (to show the list of a release's dependencies), by http://deps.cpantesters.org/ and so on.
However, this only works where you want to declare dependencies on CPAN modules, or on a minimum version of Perl itself.
To help CPAN authors keep track of who is using their modules,
we could introduce two concepts: "follow module" and "I'm using this module".
Both would be similar to the 'following' and +1 features found
in nearly all social media services, and ++ in MetaCPAN.
Templating Modules are a bit like editors. Every web application developer has a favourite one. And every template system is someone's favorite.
Mine is Mason. But not because the Perl MVC tutorials are full of examples using Mason. Not because it's the fastest (use xSlate if you want to trade speed for flexibility). Not because it's the most popular. It's my favourite for a very plain reason: It makes me more productive and allows me to develop web GUIs using all the powerful features a programmer should biterly miss if they are taken away. That includes writing Perl code :P
I never heard of a business that went down because they didn't have fast enough CPUs, so I'm not fussy about trading a few CPU cycles for elegance, ease and speed of development.
Yesterday evening I got onto the CityNightLine and spent a most comfortable night in my small single cabin, sleeping to the soft rocking of the moving train.
After arriving in a freezing cold Berlin I rode my bike along Brandenburger Tor, Checkpoint Charly and a dozen other places of interest to the Betahaus where the Workshop takes place.
Thanks to the organisers, I immediately saw many signposts which guided me to the venue.