For the less classically trained Occam's Razor or to dumb it down even more, the answer is staring you in the face, is the topic for tonight.
Well to make a short story long, I was happily programming along, in the zone if you will, when I was flustered by a small problem. How to tell if something is an object??
The problem occurred in a class pre-loader, it gladly recursively searches though a name-space and loads in classes for future use. There is some sanity checking such as making sure the file at least ends in '.pm' as don't want any silly subversion or '.pl' files loading do we?
Anyway at the tail end of the process we do something like this
OK, so that's maybe not 100% accurate, but we are looking for students who want to get paid to work with us. How can you get paid to work on MetaCPAN? There are currently two really great options: the Outreach Program for Women (OPfW) and the Google Summer of Code (GSoC).
What MetaCPAN needs from you is to help spread the word to interested students who may want to participate. Here's the pitch:
There are lots of things you can learn by working on the MetaCPAN stack. Our stack includes Catalyst, Plack, ElasticSearch, jQuery, Bootstrap and nginx. We also use Puppet for deployment and Vagrant + VirtualBox for development VMs. We have integration with Twitter, Github, PAUSE, Facebook and Google.
If you need ordered key, value pairs, you can either use something like Tie::IxHash or a simple array of key, value pairs.
I found myself in the situation where I needed to extract just the keys from such an array.
There are a number of ways to do it, but which is the fastest? I tried a few pure Perl approaches, as well as List::Util::pairkeys (which as of this writing isn't yet in a stable release of Perl, assuming that List::Util remains in the core). The pure Perl approaches either use various means of flipping a binary toggle, or splice()ing through a sacrificial copy of the array.
Well my last post trying to work with MooseX::ClassCompositor was a bit of a bust as it is not what I needed. So onto the next one one my list 'MooseX::ShortCut::BuildInstance' so lets have a look and see what this one can do for me.
Well at first glance it seems a hybrid of the last two, it does follows the same basic pattern, give a base class add some roles and then get a instance. With this mod I don't have to build a factory class like I do for MoosX::Facotry but I can supply a base class which I could not do for MooseX::ClassCompositor so things look promising.
This one also has the best documentation but it still is very sparse but informative. The tests are a little more elaborate but still very basic and a funny thing he uses them in the synopsis in the POD haven't seen that often.
The upcoming subroutine signatures in Perl aren't needed so that Perl can be "cool" (we're long past that). They're needed to make your code more correct.
I have a client that I sometimes write code for and they have the layers of their application nicely defined. Their front-end code makes AJAX calls back to an API written in Perl. That, in turn, calls their backend code, also written in Perl. Much of their API code resembles this:
In my last post I had a look at how MooseX::Abstract::Factory worked and what it could do for me. Today I will continue down my little list and have a look at
'MooseX::ClassCompositor' and see if this one fits into what I am trying to do.
Well at first glance it seems this could really work for me. Start with an empty class and add in all the roles. So lets have a closer look. Like the last module the documentation is slim and the test suit contains little more than the synopsis so no pointers there.
Well this might be good for game time but I am not sure if it will work with my present class structure and trick. Seem I have to have everything a role. Well lets give it the old collage try
The smartmatch operator (~~) introduced in Perl 5.10 (and borrowed from Perl 6) has been the subject of much criticism. Its behaviour changes based on the types of its arguments (arrays vs hashes vs numbers vs strings vs ...). perlop lists over twenty different behaviours based on different combinations of arguments. Although the operator normally does what you want, what people would want from certain combinations (%hash ~~ @arr anybody?) is nor always clear.
(Aside: in Perl 6 which has a stronger type system, the behaviour of smartmatch is more predictable.)
For this reason, it has been proposed that the smartmatch operator be simplified, or perhaps even removed in a future version of Perl 5. To this end, Perl 5.18 has introduced some warnings about its experimental nature.
This is part 12 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at how to start putting it all together.
Last week I talked about the trade-offs of DWIM, and wondered if it might be time to try to make sense of all the various parts and perspectives. Thus, this is the end of the beginning.1 This is the convergence of all my reminiscences.
In my last post I identified three MooseX modules that might help me out and end the perhaps some tedious typing and bring a more structure design into my ADD game. The first of this is MooseX::Abstract::Factory.
Despite its name it does not actually create 'Abstract' classes in the sense of a class that cannot be instantiated like a 'Java Abstract Class'. I guess what they mean is a 'Factory that is Abstract' i.e. not tied to any one class or name-space.
I've received a number of 'Verify the email address associated with your Apple ID' emails in the past week targeted at phishing my Apple ID. Upon further examination, the list of email addresses in the to: line (yeah these guys are slick!) corresponds to a subset of the email addressed stolen when blogs.perl.org was hacked.
So if you have an apple ID and a blogs.perl.org account, watch out for these phishing attempts.
So of you might remember this post some weeks ago where I came up with a huge org-chart of all the different roles they I thought i would need for may AD&D characters.
Well I was just now getting into the actual instantiation of characters and having them do something well I ran into a number of differing choices that I sort of discussed here on this post. I found that the visitor pattern worked very well for character creation (that one is almost all wrapped up) now that I am getting to the other side of the game I have t0 make a choice of which design or pattern to use.
Chapter 1: Drone + Virus = Shock + Awe
Chapter 2: Using Drones to Hijack Government Policy
Chapter 3: Using Drones for Arson, Sabotage and Quarantine-busting
Chapter 4: A Child is Frightened of Drones
Chapter 5: The Drone Papers FAQ
-------
A note re Movable Type: Make sure you preview your articles 1 or 3 times. The 2nd time the display is blank, except for 2 buttons in the middle of the screen. Save and Re-edit entry.
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.1203 and 2.1204) aimed at squelching a bug exposed by a recent update to Module::Runtime. (See Ovid's blog post on the issue.)
