Some of you might remember an earlier post where I was playing about with ARIS Express and created an org chart to map out some of the roles that might be used in my AD&D Character class.
At the end of the post I mused about reading the ARIS file and gleaning out the data I just typed in and generating roles with them. Well I did spend a little time puttering about and even looked at 'FreeMind' and even at a new one called jsULM2. Well all of those where nice but each requires me to do a good deal of fudging to get anything out. Mostly silly little things like calling a UML 'stereotype' or 'multiplicity' a moose role and really It would be confusing to use.
Also had a quick peek on CPAN and found Padre::Plugin::Moose so I had to look at that. After I installed it I found 'Moose Assist' under the Tool menu and it looks like this;
Nothing makes a lazy programmer happier than discovering free software that makes her or his job easier. Here are three of my favorites that I use on the daily:
Devel::SimpleTrace
Devel::SimpleTrace will add stack traces to 'die' and 'warn'.
If you've ever seen library code that you don't recognize throw an error you don't
understand this module should be in your toolkit.
SYNOPSIS
#adapted/copied from the pod
$ perl -MDevel::SimpleTrace program_with_strange_errors.pl
or just put a 'use Devel::SimpleTrace' anywhere.
Basics of reading stacktraces:
Skim from top to bottom.
Stop when you see files that you wrote/recognize, and find the edge between files that are in your control and files that are out of your control.
Work from there outwards until you identify the problem.
Welcome to Planet Moose, a brief write up on what's been happening in the world of Moose in the past month, for the benefit of those of you who don't have their eyes permanently glued to the #moose IRC channel, or the MetaCPAN recent uploads page.
If you'd like to contribute some news for next month's issue, you can do so on the wiki.
Moose
There have been a couple of minor releases of Moose this month (2.1201 and 2.1202) but nothing especially exciting.
I never liked cheats and while playing with Acme::Moose I figured out I can easily cheat by setting any of my values or peeking at them while I was playing. As we are able to do this sort of thing
my $moose = Acme::Moose->new;
$moose->feed;
if ( $moose->happiness ){
...
Of course as my variables are 'rw' this little problem is all my fault.
In the original Acme::Llama the internal global variable hash value
I just got caught by a change in Dancer 1.3118 and so I thought I’d share with you. As of 1.3118 Dancer no longer sets default variables for template toolkit if you subclass it. You’ll want to add these variables to your config.yml file in the engines template_toolkit section:
ABSOLUTE : 1
ANYCASE : 1
INCLUDE_PATH : /path/to/views
These variables all used to be set automatically, but when you upgrade you’ll get this error:
absolute paths are not allowed (set ABSOLUTE option)
I'm just putting the final touches on another speaking tour through Europe (so expect more posts as I nail down destinations and events). I seem to be working backwards though, because the very last event of the visit—in Switzerland in early April—is already solid.
Once again I'll be offering a week of public classes at ETHZ, including:
I left off with the idea that I could use a test that tells me that I have extra attributes in my 'class'. Not being much afraid to muck about in source code I had a look in 'Test::Moose::More' to see what would be involved in creating such a test.
Well after a few min of poking about I settled on just extending the 'validate_thing' sub by adding in a new Key, 'no_extra_attributes', on the attributes hash. If this key is present then my little test will kick in and report any attributes that are not on the list passed in via the 'attributes' key.
Following Steven Haryanto's post on how he tracks his time, I thought some people might be interested in the time tracking solution I'm currently using.
My colleagues and I are required to track our daily activities for billing purposes. Ultimately the information needs to end up in the company work-request management system ('WRMS') but that system's user interface for timesheeting is somewhat frustrating. In response to this, two colleagues (Martyn Smith and Nigel McNie) wrote a Perl script called TKS. This allowed people to enter their activities in a plain text file in a format similar to Steven's. Then they could run the TKS script periodically to sync the contents of the file into WRMS (a modular architecture allows different backend systems to be supported).
An example of a day's entries might look like this:
chromaticjust blogged about the perils of fatal warnings pushed down CPAN by the otherwise exceedingly useful Moo perl library. Since his comment system is perpetually broken, with his permission I am moving the discussion here, where the comment system is... right, anyhow.
What follows is the verbatim text of chromatic's post. My own thoughts are going to be in the form of a comment.
I was just reading the docs of
Email::Address
when I encountered this warning. I know this is not the only place where the behavior in scalar context is undefined, but I wonder. Wouldn't it be better to throw an exception or at least print a warning when a function such as the
parse
method of Email::Address is called in scalar (or void) context?
That would eliminate the incorrect usage faster probably also reducing the questions asked by users. It will also make it easier to add a different functionality later on, without surprising the people who used the method incorrectly.
The title of this entry will only mean something to a very select few in the world and if you think it has anything to do with perl look below
Anyway I just finished my version .02 of Acme::Moose as I totally botched version .01 as it is a llama not a moose.
However, that is another story. At least I decided to add in a little testing to this version and what the heck I might as well use the fancy new Test::Moose::More and see what it has to offer.
So after about 10 mins of installation from CPAN I was ready to give it a try.
Well at first glance it took a few mins and a couple of runs of my .t to figure out that 'Test::Moose::More' is really just for testing Moose classes so you have to fall back to something like 'Test::More' if you want to run regular type test, but no matter.
First off, I'd like to compliment Yuji Shimada on his fantastic module WWW::YouTube::Download. I'm sure the module requires a lot of maintenance (as sites like YouTube can change their design quite a bit) and for that I'm grateful.
Now, the module worked perfectly for my downloading needs *except* that I could not fetch age-restricted videos. Instead I received a message that the module could not find any video URLs. The bright side to this problem was that Shimada's module made it *very* easy to come to a solution, thanks to the module's ua method which accepts a LWP::UserAgent object.
TL;DR - cookies
In my case, I was using Mechanize, so I passed the Mech object to the ua method, like so:
Pinto is a powerful tool for creating and managing a private CPAN. Pinto make it easy to control your dependencies and ensure your app is built with the right module versions every time. The latest release (0.099) includes a boatload of exciting enhancements. Here are the highlights[1]:
If you love Perl and are interested in MongoDB, we want to hire you. Feel free to drop me a line at friedo@mongodb.com if you're interested, or take a look at the official posting here. The full job description is below.
I currently maintain several DarkPAN's. A DarkPAN, as some of you might already know, is a CPAN-like repository but which is not CPAN. The "dark" term refers to the fact that it is not being published on the Internet, but usually behind a corporate firewall. The most common use-case is for companies creating their code as Perl distributions and wanting to use the CPAN toolchain to deploy modules. In my case, some of the DarkPANs are not actually "dark" because I publish them on the Internet.
There are two general ways to create a DarkPAN. First, you start with an existing CPAN mirror and then "inject" additional modules (you can use CPAN::Mini::Inject for this). Second, you start empty and create the CPAN-like structure using modules like CPAN::Faker and OrePAN.
The inject way is not really proper (akin to monkey-patching) but works with the old standard CPAN client. The latter is supported by cpanminus using multiple --mirror options. For example:
This is part 8 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at the ongoing evolution of Perl.
Last week I closed with the observation that it’s difficult for other languages to evolve beyond Perl because Perl keeps evolving. And it does: it evolves at quite a bewildering pace, compared to other languages. Take a look at the evolution of C, for instance. Oh, sure: we can talk about C++, and C#, and D, and even Java, as evolutions of C, but they are different languages, far more so than Perl 6 is a different language than Perl 5. If you look at the C language itself, it’s changedseveraltimes throughout its history, but the C we have today doesn’t look that different from the original K&R. It’s no more different than, say, American English is to British English.1
