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.
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?)
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
Over the past few of months, various fixes and improvements have been made to the Builder process, which builds the pages and support files on the CPAN Testers Reports website. As mentioned in the last summary, this has made a noticeable improvement in the performance of the server. However, there were further fixes and enhancements planned.
Several updates ensued during January, not just for the Builder, but across several parts of the eco-system, both to speed up processing and to reduce the amount of file and database access. Previously several processes recreated their current view by reading the full result set from the database. As we now have over 10 million reports, this can take more time than is reasonable. With the use of the JSON files to record a snapshot, we can now start from a known point, thus meaning we only need to scan a few thousand records. This method has been utlised in other processes, even with smaller database tables and datasets, and the performance improvements have been significant.
I just got back from FOSDEM 2011 last night and had an absolute blast, especially on Sunday when I spent the whole day in the Perl devroom. Thanks to everyone who came!
I gave a talk called Introduction to writing readable and maintainable Perl and I thought I'd share my slides here.
I missed the Parse::Stallion and most of the Intro to Dancer talks because I spent it talking with olegm and perigrin.
I really would have liked to catch them but it is always interesting to talk with folks.
perigrin is a fellow player of Lacuna Expanse and it was good to meet him.
I then mostly listened to olegm and perigrin compare notes about putting on a workshop, relative costs...generally what perigrin was going to talk about after the Intro to Dancer talk. :-)
The most interesting comment was when perigrin said he would like to see a conference/workshop in each state in the US. It seems like every country in Europe has one so why not each state.
A very compelling idea, especially when you consider that Perl Oasis costs about $2,000 to put on an attracts around 40 attendees.
