I've volunteered to pick up maintenance of the HTML-Format module, which has been lacking love recently (last update 2004).
Initial intention is to do maintenance on it - its currently causing warnings about UNIVERSAL::Can on recent versions of perl and there are a number of RT tickets for it.
I am converting it to use Dist::Zilla for release management (although my CPAN volume does not really justify this, the fact that it manages the bits I would otherwise forget does!). Source - including imported versions of all the previous tar files I could find on backpan, is now in git on github.
A trial release has gone out, although I intend to further work before pushing out the next proper release - specifically improving the documentation and tests.
Over the weekend I released Dancer::Plugin::Database 1.10, incorporating a couple of bug fixes thanks to Christian Sanchez, Michael Stiller and crayon.
I've also added a quick_select feature; it seemed odd to not have it since quick_insert, quick_update and quick_delete were all provided.
It lets you do simple queries very quickly:
# In scalar context, returns first matching row as a hashref:
my $user = database->quick_select('users', { id => $user_id });
return "Hello there, " . $user->{first_name};
# In list context, returns all matching rows as hashrefs:
my @users = database->quick_select('users', { category => 'admin' });
It's intended for simple queries, so if you need to retrieve only certain columns, sort results, do joins etc; since the database keyword gives you a normal DBI handle, you can just do it however you like. For simple queries, you might enjoy the simplicity, though.
The Perl booth, maintained by Ann Barcomb, El-Che, Gabor, Liz and Wendy, did exceptionally well! More than 20 copies of the Modern Perl book were sold, all copies of Perl Moderne (an original french Modern Perl book, written by Sébastien Aperghis-Tramoni, Philippe "BooK" Bruhat, Jérôme Quelin and Dancer core developer Damien "dams" Krotkine) were sold, over 300 tuits were distributed, and plenty of information flyers. This took a lot of work and dedication by those that maintained the booth.
It is a good example of why it is important to come to these meetings. An average room has between 70-200 people. That's a lot for a single room! The booth saw, met and spoke to roughly 800 people!! When have you ever seen such high numbers? An amazing effort that was able to market (or "spread", or "discuss", or "outreach", or "promote", or "inform", or whichever expression you prefer to use) and showcase Perl to people.
I hope to attend many more conferences, and I do intend to attend the next FOSDEM.
And well done to all those who helped out in the booth! You did one hell of a job!!
I'm at work right now, waiting for some code to run in the Perl Debugger and I got to thinking. Right now I've set a break point and I've hit "c" for continue executing, and in the background the debugger is doing all these checks on every single line and slowing down the execution of my program like crazy. I know it's doing something because if I hit ^C is halts properly at its current point of execution. What if there were some way to speed this up?
I'm thinking...
DB > b $condition
DB > $DB::breakpoints_only_mode = 1;
DB > c
Setting $DB::breakpoints_only_mode essentially promises the debugger that you won't hit ^C or anything silly like that. The implementation would be something like...
Set up a hook of some kind for all existing breakpoints, which turns debugger flags on, then checks the breakpoint, then turns debugger flags back off again.
Turn off the debugger flag(s?)
Continue running the code as normal
What do Smarter People Than Me think of this idea?
(of course it's entirely possible that the debugger isn't actually slowing down my code all that much... but it feels like it is?)
Over the weekend I threw together Dancer::Plugin::SMS, which uses Adam Kennedy's SMS::Send to easily send SMS messages.
Using it from an app can be as easy as:
sms $destination, $message
# or with named params:
sms(to => $destination, message => $message);
Configuration for which SMS::Send driver to use, login details etc are all read from your Dancer app's config, so if you decide to change provider, you need only update your content, and you're done. There are SMS::Send drivers for a whole host of online SMS text messaging providers so you'll likely find one for whatever service you plan to use; if not, writing one is pretty trivial. There's even ones for using a phone connected to your machine, if that's what you plan to do.
Some time ago I wrote Test-YAML-Meta. At the time the name was given as a compliment to Test-YAML-Valid, which validates YAML files in terms of the formatting, rather than the data. Test-YAML-Meta took that a step further and validated the content data for META.yml files included with CPAN distributions against the evolving CPAN META Specification.
I've been working with ElasticSearch over the past months as part of the MetaCPAN project. Using ElasticSearch as our back end has worked out really well so far. The reason is that, out of the box, it provides a REST API. So, in our case, we've been able to concentrate on writing code and not on designing an API, defining its behaviour, arguing over URL schemes etc.
To be clear, ES is not written in Perl, but there is a handy Perl module you can use to get yourself up and running in *minutes*.
On February 5th, my wife and I celebrated the birth of our lovely daughter, Lilly-Rose.
Needless to say, this has impacted my posting here :)
At one point before the birth when we were both rather bored, I was trying to get some work done, but I had some code which I could not load because I lacked an Internet connection. Not all modules were present on my system, config files were missing, etc. However, I desperately needed to unit test my code and I quickly got fed up with my standard bag of tricks for forcing modules to load. Thus, I wrote a module to handle that bag of tricks for me. Later, after releasing it to github, I thought about dedicating it to my wife and newborn daughter, but I didn't think they'd like the Package Butcher dedicated to them.
Today, I moved the development place of one of my incredibly simple yet incredibly useful data munging tools from http://perlmonks.org/?node_id=598718 to Github . I hope that by moving it there, it becomes easier for people to submit patches.
I haven't given much thought about putting the program onto CPAN as well. The packaging is already done, but I'm not sure if I want to split out the meat of the program into a module, or maintain two versions, a module-using version and the stand-alone version that I currently have. App::Ack did maintain a monolithic version for a while, but I'm not sure whether it's worth the effort. There also is a version of this file that reads and produces Excel files, thanks to Spreadsheet::WriteExcel and Spreadsheet::ParseExcel. I haven't decided on whether to import that version into this tree, a different branch or what else to do with it.
I have an issue somewhat related to Steven Haryanto's concern about bloated apps. I can live with a command taking a second longer to run when performing work, but I absolutely detest waiting that long for the usage message to be generated. I am constantly running commands without arguments (eg Git) to get an overview of sub-commands and/or their options. A slow Perl command line app (eg dzil) is a pain in comparison. It is sometimes quicker to load the manpage.
But it doesn't necessarily have to be that way. App::Dispatcher is a tool for constructing command line applications
written in Perl. It is specifically designed to handle applications
with multiple sub-commands and will generate code to display usage
text, validate options and arguments, and dispatch commands. Its main
strength is that the usage and validation does not load any
command classes with their possibly heavy startup dependencies.
On the 1st January 2011, I released the first Open Source version of Labyrinth, both to CPAN and GitHub. In additon I also released several plugins and a demo site to highlight some of the basic functionality of the system.
Labyrinth has been in the making since December 2002, although the true beginnings are from about mid-2001. The codebase has evolved over the years as I've developed more and more websites, and got a better understanding exactly what I would want from a Website Management System. Labyrinth had the intention of being a website in a box, and although it's not quite there yet, hopefully once I've released all the plugin code I can put a proper installation tool in place.
It seems to me that the folks who say that aren't programmers. If they are, they've never been the sole responsible party for any application. When there's no one to pass the blame to, TDD is no longer just an idea, it's time & money.
Once you get the hang of it, the peace of knowing that your code works has a value beyond measurement.
It's for this reason Mojolicious makes it easy to test your web apps in a clean, simple manner.
Now that's easy. But there's more.
Test::Mojo tests are chainable, so you can keep your tests in a clean group:
Now that's pretty. But wait, there's more.
Using Mojolicious' built in JSON parser, you can test JSON output using an equivalent decoded Perl structure:
On a side note, Mojo::JSON is the fastest pure-perl JSON parser available. Thanks to chansen, it recently became even faster, outperforming JSON::PP by 3x.
There is one very advanced feature in Tempate::Toolkit called META variables. META variables are variables that you define in a processed template, that are later available to the WRAPPER template. That means that you can set, for example, the title of the page in the main layout from the inner content template. That's also what it's usually useful for.
However, since Dancer provides its own "layout" option, it basically separates these two processes (rendering a WRAPPER and rendering an inner template), making Template::Toolkit unable to simply define a WRAPPER. So... how does one get it to work?
Well, it's possible to kindly ask Dancer to step aside for a bit, and give you more control over the templating, which means you can do some more advanced stuff, like using SET to set variables in the WRAPPER, or using META variables. Here's how easy it is:
blogs.perl.org is awesome but it has a few issues. Anyone out there to fix them?
For example there is no "previous articles" link on the front page but there are 82 other open issues as well.
I am sure there are some people in he Perl community who know or want to learn how to fix issues with Movable Type. You can fork the code on Github and make many Perl bloggers happy.
I am especially looking at you who endlessly complained about use.perl.org and that you could not fix issues with it.
I've just pushed out a new release of WWW::Mechanize::Firefox , my favourite interactive web scraping module. The changes in this version are:
->eval_in_page() raises errors from perspective of the caller instead of raising errors in Firefox.pm.
This was an especially annoying error, as it always pointed to somewhere deep within Firefox.pm when I tried to access an non-existing Javascript variable or had Javascript disabled in Firefox.
Added ->by_id() method and { id => $id } option for
conveniently finding elements with names that ->selector
interprets as CSS selectors.
As the main application I am automating at $work uses fancy names and ids in forms and values, like _id1:foo , I found myself constantly selecting elements through
->click( { xpath => q{//*[@id="_id1:foo"]}, which is not only unsightly but also does not respect the value ->current_form(). This change introduces `id`, which is a shortcut for Just That. I also added more tests testing those names.
One
. Improved tests checking fields with fancy:names
or fancy:ids
Thanks to the many, many contributors to this version. Please see the
summary of changes below, along with a special dedication for this
release to Randy Kobes.
You can get mod_perl 2.0.5 at one of the following urls, including the CPAN:
The mod_perl PMC dedicates this release of mod_perl to Randy Kobes, who
passed away in September 2010. Randy was a member of the mod_perl project
management committee and a co-author of the mod_perl Developer's Cookbook.
His work helped many Windows mod_perl users. His work with ppm files, and
Win32 perl users will be sorely missed. He was kind, bright, and always
willing to lend a hand on the mod_perl user's list.
Prepare modperl for the upcoming perl 5.14 [Torsten Foertsch]
At the second day of FOSDEM, the Dancer core crew pretty time took over the Perl dev room! We are 4 developers, and we gave 5 talks: SPORE (by Franck Cuny), "Code, release, market" (by Alexis Sukrieh), Curses::Toolkit (by Damien Krotkine), Moose (Sawyer X) and Dancer (Sawyer X). Somehow, all those talks mentioned Dancer, whether it was by the speaker noting the projects he works on, or by using it as an example in the talk (like Alexis did). The amount of noise and buzz we created around Dancer was very positive!
There were a lot of good talks in the Perl dev room (such as DTrace, XML::Compile, Packaging Perl), but I'll try to cover just a few:
Now you can switch frames with Meta+arrows. Works like a charm on macosx !
There's another kind of library like this called "windowmove", which does the same to windows as "framemove" does to frames. Both can be integrated (look inside the framemove.el file for configuration).
Today I even have Emacs start with 2 frames by default ! Tell me about changing opinions ;)
A few weeks ago, I got annoyed by the fact that one of our command line applications was getting slower and slower to start up (the delay was getting more and more noticable), so I thought I'd do some refactoring, e.g. split large files into smaller ones and delay loading modules until necessary.
Sure enough, one of the main causes of the slow start up was preloading too many modules. Over the years I had been blindly sticking 'use' statements into our kitchen sink $Proj::Utils module, which was used by almost all scripts in the project. Loading $Proj::Utils alone pulled in over 60k lines from around 150 files!
After I split things up, it became clearer which modules are particularly heavy. This one stood out:
% time perl -MFile::ChangeNotify -e1
real 0m0.972s
% perl -MDevel::EndStats -e1
# Total number of module files loaded: 129
# Total number of modules lines loaded: 46385
