I’ve been writing tests for a web service in which one of the methods would occasionally take an inordinate amount of time. The amount of time was inconsistent and it would be useful to capture some timing data to provide the vendor. But, I didn’t want to litter my test files with code to calculate the elapsed time. Eventually, the bugs would be worked out and the timing information would just be noise.
So I wanted to somehow hook into the test framework itself to give me the timing data.
I am happy to announce that Galileo CMS is now available from CPAN! This project has been my on-train side-project, but its come a long way in a short time. The most exciting thing for me is that its entirely installable from CPAN. To try it out, simply do
$ cpanm Galileo
$ galileo setup
$ galileo daemon
of course, you can also run it using the servers provided by Mojolicious, or using your favorite psgi-compliant server (as long as they support websockets).
Authorized users edit pages using markdown with a live-preview. All updates to pages, menus and users are sent via websockets. Styling is courtesy of Twitter’s Bootstrap library.
Some things that are still on the list:
The Portuguese Perl Workshop is back, the event will be held on September 28th in Braga, Portugal.
Check the workshop website for more information.
The first issue of the Perl Weekly was sent out on 1st August 2011. Almost a year ago.
In case you don't know what it is: It is a weekly e-mail with a curated collection of links to the most intersting, Perl-related articles of the previous week. As seen by myself.
I wrote about it several times on this forum, but I think this might be a good opportunity to mention it again. There was also a suggestion that people should brag about the stuff they build. I totally agree.
If you are already a subscriber, let me thank you for your support!
If you are not yet a subscriber, let me invite you to check out the web site, the archive and to subscribe to the Perl weekly newsletter.
Plugin-based architectures can be a bad idea.
Not always. In user-facing applications, where the list of installed and enabled plugins is clear, then plugins are often a good thing. This article is concerned not with end-user facing applications, but with libraries. Libraries that allow their functionality to be extended through plugins. In particular, libraries that automatically detect and load all installed plugins.
Plugins aren't always obviously plugins. In this article, I'm defining a plugin as a software module that adds additional functionality or modifies the externally observable behaviour of the existing functionality of the core piece of software. Call it a "plugin" or an "optional dependency" - it's the same thing.
Here's a simple hypothetical example:
Recently, Steven Haryanto blogged about articles which compare modules, and made an impressive start with this wiki entry.
I've added a similar page to my web site.
I've called it 'Module reviews' rather than 'Module comparisons' so as to allow for related articles which are not exactly comparisons.
If you have any recommendations regarding similar articles, let us know.
Lastly, please link to either or both these pages. The more links to Perl stuff that the search engines stumble over, the more visible we'll be.
Just an FYI, if you're using Business::Shipping in your app and also Log4perl, then Business::Shipping will clobber your Log4Perl config with it's own. A quick work around for this is:
Basically clobber Business::Shipping right back.
If I get some round-tuits I'll submit a patch to fix this problem. If the author of Business::Shipping were using something like Log::Any then he could spew out his logs, and the consumers of Business::Shipping could simply load the appropriate adapter rather than having Business::Shipping clobber the Log4perl global config. I guess technically this could be a bug in Log4perl using globals too. Anyway, this little work around should get you by in the mean time until a patch can be authored to remedy the problem.
I just uploaded to Crypt-SSLeay 0.60 to PAUSE to address RT #77167 and CPAN testers failures with the previously released version. The former was due to the fact that SSL v2 is no longer supported on various platforms, and the latter due to the fact that LWP::Protocol::https was not specified as a dependency.
Most of the changes leading up to 0.59_03 were similarly minor and straightforward. However, one addressing RT #64054 attempted to deal with incomplete reads and writes in a better way, and is a significant change from the original codebase.