A question I relly have to ask myself more often. Well today I really got tired of my little solution to yesterdays Moose woes. I just couldn't take the sight of all of these
authorized bin_swap => [qw(Product::BRULE::Bin ], sub {
...
},(verifier=>Product::BRULE::Authorize->new())
instance calls in my nice clean code base. I did try a few little changes such as a global variable uck, and a singleton not bad but in the end I bit the bullet and decided that I need to add in some code of my own under MooseX.
The main reason is I liked how this worked and in a very elegant solution to to my code-base that can essilly extended with only a minor code change to a few roles if need be.
Finally pushing my first release of this distribution is a special moment to me.
Its original author, Iain Truskett (SPOON),
died on December 29th, 2003.
He was 24. Back then, I didn't know him, had never interacted with him,
or even used any of his modules. That was ten years ago.
Last year, Alberto, who ran the Grants Committee at that time, published this blog article to ask what we can do better. I read the comments repeatedly to think about our improvement options. In the next few entries, I will discuss what we did and what we will do to make the grants program more useful.
The first one is the removal of $3,000 limit (see #2 of the announcement).
From the comments made at Alberto's article:
I think the grant limit is an issue. I have projects I could submit, but I think they'd take too much of my time, and $3,000 just wouldn't cover it. Basically, I think I'd need to be able to take weeks or a months off of my job to get done what I'd like to do.
A smaller issue is the grant size - I did not have in mind grand plans like autarch, but I can easily see this being a month of work. $3k/month is rather limited.
So after my little crash yesterday I had to revisit my decision to use 'MooseX::AuthorizedMethods' as I was using it totally wrong. It seems to have been defaulted to use a 'User' class of some sort that has a roles method on it which is checked against a passed in array-ref of roles.
Here I was thinking it was checking for 'Moose::Role' classes applied to the calling class and doing all sorts of neat Mossey stuff when in fact this is more 'Instance/Application' code rather than foundation code. Well looking at Daniel's other CPAN offerings I could see how this could be a very very useful default for him. Anyway my bad I should of looked at it closer.
So what to do?
Well after much trial and a whole lot of error I finally got the 'verifier' to work (an example in the POD and or a test would of helped, hint, hint, nudge, nudge, wink wink).
I also pepper use Data::Dump; dd $something; in my code a lot! So many that I created DD and DDC to lessen the typing. But this trick is better because I don't have to put the use statement at all. Plus I get some safety (I do accidentally check in these debugging print statements from time to time).
But putting -MData::Dump or -MData::Dump::Color on the command-line or PERL5OPT will only work for the code in the main package. What if I pepper debugging statements in some module? That's where another nice module written by Brock Wilcox comes in: everywhere. This module lets you use a module, well, everywhere. It works by installing a coderef at the start of @INC that will trap every require statement and import the modules you want to import everywhere to the target module. By the way, this @INC handler trick is also employed by some other cool modules, among others: App::FatPacker and PAR.
So now you can just put "dd" statements in your modules and test your application with:
perl -Meverywhere=Data::Dump yourapp.pl
or some shorter alias which I'm sure you'll soon create if you use this often enough.
Often we hear people talk about making your programming more "data-driven". When you can convert procedural code to a data structure (generally with a small procedural driver), instead of replicating procedural code, you just add another entry to your data structure. This is great with dispatch tables, repetitive chunks of code and state machines. However, there is a hidden benefit of it which will not only make you a better programmer, but it will make later maintenance programmers fail to notice a common flaw that your code lacks. They'll curse you if you have the flaw, but if you don't have it, they'll find that data-driven sections of your code are so easy to work with that they won't even think about it.
May round schedule will be similar to the March round, with several changes as below.
Longer period to solicit community feedback
Longer voting period
Shorter CFP period
In the long run, CFP period should be shortened further as every round will look the same and preparation can be done beforehand. Or even easier, we may always keep the CFP open and evaluate the applications every two months.
The following data is from a 64bit perl-5.19.10 (i.e. 32 bit jenkins - corrected from 64 bit siphash - which randomly shuffles the 2 first entries of collisions), running the core test suite with -DH.
My last few posts you may of noticed I have been using Moose with a more professional end in mind rather than my usual playing about with AD&D so I figured I might as well keep going on with it a bit as these are real world (well at least my world) situations rather than contrived gaming stuff. As well my latest round of work is a great source of posts.
Well on the platter today is 'MooseX::AuthorizedMethods' char broiled au jus with in season mixed vegetables with Gorau Glas served on the side.
So this module really doesn't do a whole lot it simply add a little more sugar to your Moose stew, by exporting the "authorized" declarator so now you can stop the invocation of a method if the invoker does not have a specific role.
The following is posted on behalf of Roman Filippov and Al Newkirk, kindly share your thoughts on the mentioned points.
I would like to propose the following items for discussion, in no particular order. This is just a brain dump of the ideas I have been thinking for a while now.
Well I was busily writing some tests for a large processor interface where you would pass an object too it and it will merrily process away on it. Well all of the object I was passing into it are written in Moose and I did not need to test the 'State' or 'values' of these object, what I needed to tests where some of the lower-level admin functions in the interface, that really had nothing to do with the objects themselves more about reading config files connecting and alike.
The problem I was having was to test the 'Interface' I had to give it a valid 'object' as that was a 'required' attribute. That I could live with it was all the objects I was was going to pass into it needed to be instancates and they all had a large number of 'required' attributes as well.
My current contract is lovely. I'm having a lot of fun and the environment is awesome. However, it's a short contract. I took it, in part, because it was a problem space I wanted to do more work in. Because it's a short contract I'm already working on negotiating my next contract (a perpetual hobby for freelancers), but I thought I'd experiment with a different approach: asking you to reach out to me. If you think I can help your company and you're not in a position to hire me directly, go to those who are and talk to them. If you want to hire me or one of the talented developers who works with me, drop me a line (I can't guarantee that I'm available, but you never know). If this approach works, I can do more work on open source or Veure instead of spending all of my "between" time negotiating contracts.
That being said, I don't always get contracts I negotiate for and sometimes I turn them down. However, if you're an individual considering freelancing, I thought it worth discussing some of the obstacles I've faced.
I recently updated a client called WebService::Geocodio for the Geocod.io geocoding service. Traditionally, geocoding means turning a mailing address into latitude/longitude coordinates (or the reverse operation, turning latitude/longitude into a mailing address.)
In a recent update of the upstream service they included the ability to fetch additional data fields including timezone, congressional district, school district and so forth. Is there a good CPAN module (or a recommendation) to take a Perl data structure like a hash and turn it into a Moo(::Lax) object "automagically?" I had a look but I didn't find anything especially suitable.
These data structures are purely informational in nature and just have getters for their attribute names. This would be less difficult to accomplish using Moose (obviously) but I'm wondering if there are any suggestions for something that installs getters for hash keys dynamically and is Moo-friendly.
It's common knowledge that on Windows, a line of text generally ends with a \r\n characters sequence, and on a POSIX system a line of text will end with \n.
Less well known is Perl's support for the escape sequence '\R'.
What's \R?
It's definitely not the inverse of \r.
It's a pattern (so for now its only useful in regexes) that matches Unicode's TR-13, The Unicode Consortium's guidelines for what counts as a newline. It's useful in a regular expression to match \r, \n, \r\n, or a few other character sequences that are used to represent newlines, so you don't have to remember them. It's worth noting that it is a character sequence, not a character, so it doesn't really make sense in a bracketed character class.
