Well getting close to the end of this little series and today I though it would be good to do a little code review to see if I could fined any holes.
So there was some suggestion about a new namespace 'CheckCallerRoles' and another 'AllowedMethodRoles' but I think as I cut down on the number of files I need I will just keep the present setup besides it is easy to understand.
Now there is the question of the actually API names themselves
requires and
one_of
Now looking at the semantics of these two I think a change may be in order. Now I do have the option 'requires' is a another word for 'needs' but that doesn't read too well and 'must_have_roles' is a no good either. I could also try 'required' which is a little less in the passive voice so I think I will finalize on that.
Image::Magick is great, but it's a pain to install if you are using perlbrew, or if your system's Image Magick library is out of date. After some googling I found that this was the best technique, but cpanm support is missing, making using Image::Magick very difficult to include in your application's dependencies.
A couple of weeks ago, PerlTricks ran a little article on using KeePass (as a file format) to secure your data, which prompted me to dust off and finish some code I'd started sometime last year.
The problem with using File::KeePass (as astoundingly fantastic as it is!) is that the point of using KeePass in the first place is to keep you from having to see passwords at all (once you've started the KeePass utility and logged into it, anyway). If you want to use KeePass to store a username/password pair to pass to LWP (say), though, you've got a problem - you still need to enter your KeePass password to decrypt the database.
The
MetaCPAN
site has a constant flow of new features. Some are small, some are big, but almost none of them get in the news. The recently added
news page
will provide this missing piece. It also comes with a
feed
.
Well in my last post I created a very small API of a two keys
requires and
one_of
Now I have to get down and dirty and write up some code to handle this API. Now the logic will be in the same place namely 'MooseX::Meta::Method::Role::Authorized' and in a rewritten 'authorized_do' sub.
This is another "recent hacktivity log" of some of the open source
work I've been up to lately.
New Command-Line App: App-Du-Analyze
App-Du-Analyze
(with its command-line script of "analyze-du") is now available on CPAN. What
it does is allow you to analyse the output of the UNIX
"du" command,
get results based on a prefix and a depth, and sort them. It is my preference
for a disk usage analyser, with the benefit of being able to run several
queries on the same data, by keeping the same du.txt file - a
feature which I found is often lacking in GUI disk usage analysers.
On my recent project, fsql, I want to detect (preferably cheaply) whether a (short) piece of text is JSON, YAML, Perl, CSV, TSV, or LTSV. The JSON/YAML/Perl would contain an AOA (array of arrays) or AOH (array of hashes).
File::LibMagic gives me "text/plain" all the time, so that's useless.
Here's currently the algorithm which I'm using. It's far from perfect, but perfection is not a goal here. Good enough (or even half as good as that) is okay, since most of the time, the file type will be inferred from the filename extension. And it's okay to be wrong as long as we can be right often enough.
1. If first line contains tab character, it's either a TSV or LTSV. Type is LTSV if first line contains colon (:).
2. If text contains => it's probably Perl (but this is useless for AOA).
3. If text contains a bare word element in a comma-separated list, e.g. foo, bar, it's probably YAML, since YAML allows that kind of thing.
Well in my last post I decided to use a hash-ref rather than an array-ref as a way to expand my little MooseX and let the user set have a set of required roles and or a set where only one role is required from a set.
I figured this made the API a little eirer to understand and even read inline.
Now how to implement this?
Well I start first with 'MooseX::Meta::Method::Role::Authorized' do this
I have been working on the project now called Dezi, in one form or another,
since 2005. The actual kick-in-the-pants to make a Product, rather than a Loose Affiliation of Modules, came in an exchange in the comments of a blog post about metacpan.org.
Dezi has gone through several releases in the last few years. Now I'm preparing for a big, new release (0.3.0) that represents (for me) a seismic shift in the way I'm thinking about the product. It has to do with social coding.
Way back when, I started using the Rose family of Perl modules for work. I developed many CPAN modules against the Rose suite. I continue to find the Rose modules well-built, well-documented and very fast. I rarely find a use case that has not already been anticipated.
Well just a sort one tonight as other got in the way,
I did talk in my last post yesterday about adding a little enhancement to my first little MooseX and after talking with some of my co-conspirators they though it would be useful that the requirements are as follows
Have at least one the indicated roles
Have all the indicated roles
Have a mix of 'Required' and at least one indicated role
So how to add that in??
Well the it does not look very hard rather than pass just a simple array to the sub why not pass a hash that has the data classified for me. On can do this in a number of ways by adding here are a few'
A hash with the keys as the roles and the values indicating it is required or not
You missed as a point "People don't know that the grants exist" and "People don't think their ideas/plans are appropriate for a grant". TPF should probably advertise them more.
Let's talk about the marketing aspect.
"People don't know that the grants exist"
To improve the situation that "People don't know that the grants exist", we did the followings in the past few months:
Changed the rule to make it more attractive for prospective grantees (grant limit, grant cycle).
Reminded each Grants Committee member to advertise the program more, which became: 1) talk given at a local Perl mongers meeting 2) more appearance on social network sites 3) more appearance in personal blog and mailing list
Started this blog to make the grant program known by blogs.perl.org readers and search engine crawlers
It is my pleasure to report that all five proposals that we selected for the Google Summer of Code on behalf of the Perl Foundation have been accepted for inclusion in the program this year.
Well in my last post I manged to get rid of numerous bits of the original MooseX::Authorized Methods and get it down to what I find is just what I need the bare-basic check if a class has a role.
Now digging ever deeper into the 'clone' of Authorized Methods I have the 'MooseX::Meta::Method::Role::Authorized::HasRoles' class and I can just delete that one as I moved its functionality into the 'MooseX::Meta::Method::Role::Authorized' class so that leaves me with 'MooseX::Meta::Method::Role::Authorized::Meta::Role' and here that is
It is my pleasure to report that all five proposals that we selected for the Google Summer of Code on behalf of the Perl Foundation have been accepted for inclusion in the program this year.
