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.
They told me it was evil. They told me it was not maintainable. They were right.
But the alternatives were painful. They were clunky. They required me to change the way I approached HTML. They required me to abandon the hipness of css selectors I had embraced with javascript libraries, and ignore the many years spent perfecting my css-foo.
HTML::Parser, HTML::TreeBuilder, I'm sure you're brilliant in your own way. I'm sure you have conquered many lands, and for those who wanted to adapt to your mindset, you brought much happiness.
I wanted a simpler way. jQuery taught us that css selectors are that better way.
Fortunately, Mojo::DOM sprouted up out of the land of cookies and rainbows and unicorns.
Seriously, have you ever seen HTML retrieved, parsed, and processed so nicely in Perl?
Dancer's engines is really cool. You wanna know how cool? Here's an example.
If you like Mojolicious' templating system and you want to use it with Dancer, our interchangeable templating engines allow you to use a template engine of Mojolicious, if it exists.
And if it doesn't exist, you can write it. Oh wait, someone already did!
Check out the source to find out how silly easy this is.
So, if there's another template engine you want with Dancer, try to write it! If you have issues, talk to us on IRC (#dancer on irc.perl.org) and check out other template engines.
For over a month I have been working on a little project called QueryHunt.
it is a questions and answers search engine powered by yahoo BOSS.
Why did I decide to use Perl for this project?
When I started working on this project I had just started to learn Perl, I was planning to write the site in PHP.
Perl had a lot of promising features that would make the development process easier in the long run
some of this features are
Easy XML parsing
Regex support (Vital to discard results that were neither a question or an answer.)
DBI (in case I decided to give PostgreSQL a try compatibility issues wouldn't be an obstacle)
so for obvious reasons I ended up using Perl, The site has now been running for about 2 months and I'm more than happy with it.
I'm not on vacations anymore so I don't get to work on it so much but I have a lot of ideas and I have started to work on a home-made crawler that I will be more than happy to share with Perl programmers.
I will keep updating this post to write about obstacles I face and other things that might help programmers that are working on similar projects.
Following the lead of Mike Doherty (DOHERTY) I've moved my own Dist::Zilla Author PluginBundle into a new namespace:
Dist::Zilla::PluginBundle::Author::OLIVER
Having Author PluginBundles is a great system for saving me time and allowing others to build my modules with ease. However I had to agree to Mike's point that polluting the Dist::Zilla::PluginBundle:: namespace wasn't so cool. It also makes things more clear in the dist.ini file:
[@Author::OLIVER]
If you have an Author PluginBundle, please consider moving it into this new namespace. You can of course keep the old one around, in parallel, until code using it has moved off to the backpan.
Dave Rolsky has written a compelling post on how not to write a changes log. It's ironic (or is it? the meaning of "irony" is illusive) that while I have much criticism for the changes log of others (and have commented on them to people in the past), Dancer's changes log is not up to par with what I think it should be, nor what Dave thinks it should be (which is close to what I think).
Understanding Dancer's changes log
Dancer's changes log has two primary goals: mark down changes for Dancer users, and giving credit to the people who do it.
This means that in each version we have who did what change, and additional credit for whoever helped in any way.
While the current format of the changes log is not optimal, we cared more about maintaining the current state, and did not optimize it. Truth be told, it was a bad habit and none of us advocate the current style be remained.
Yes, it's true. Even though I live on the southern edge of the Australian mainland, the floods have hit here. I'm in Melbourne, the capital city of the state of Victoria.
Last night, about 9 pm, the floods from other parts of my suburb, Murrumbeena, backed up, and drowned my car to about halfway up the windscreen. The car was parked in the street, in front of the house.
Luckily, the house is on a slight slope down to the street, so the floodwaters stopped about the height of 1 (one!) brick below the floorboards.
This morning I was on the phone for about 10 minutes to roadside assistance (a commercial service) who say that since water got inside the car, it's an insurance matter. So, they transferred me to another department, and after another 25 minute wait I lodged a claim.
Since the car won't start, it's going to be towed to a local crash repair shop. I've been warned by the insurance company that there's no guarantee it'll be salvagable.
