Well back on the Moose path again and today a little post on my next test for my first little Moosex. Like I said in my last post I like my tests to be simple and functional.
I did have look at the test suite for MooseX-AuthorizedMethods and for me it was a little too Mooseish fro my tastes, I guess he was very keen on testing to see if bits of Moose worked rather than focusing on the functionality of the modual. For example I did not see test of using a Custom Verifiers at least one that I could figure out. Like I said in a previous post, one of those would been nice.
So lets just stick with the basic functionality no need I think to get into all the Moose side of stuff with the meta etc.
Are you a lone Web developer who has a great idea for an app but you're intimidated by the idea of getting a Web server, maintaining the OS, installing the database, handling DNS, keeping up to date with security patches and so on? Instead, you can try a Platform as a Service (PaaS) system and let them handle the system administration stuff while you focus on just writing your code.
A year and a bit ago I wrote about measuring the coverage not of the code I was testing but of my tests, and how doing so had helped me find some problems. Today I dived further down that rabbit-hole.
As I mentioned then, we ran all our tests under Jenkins. Because we're testing quite a complex application, which needs configuration data, databases and so on, we've got a wrapper script that sets up all that jibber-jabber, runs the tests, and then tears down the temporary databases and stuff that it created. But that script had a bug. Under some circumstances, if one of the test scripts failed, the wrapper script would eventually exit with status 0, which is the Unix-ism for "everything went as expected", and so Jenkins would say "all the tests passed, hurrah". We need it to exit with a non-zero status if anything went wrong so that Jenkins will know that it needs to kick up a fuss.
A while ago I was playing around with Win32API::ProcessStatus which provides an interface to psapi.dll on Windows. It had an undeclared dependency on Win32API::Process and needed just a minor correction to get it working on cygwin, so I emailed the author on February 6, 2014 with the changes and offered to adopt the module if he didn't have the time or interest in maintaining the module for himself.
As per advice from the CPAN FAQ I am posting my interest in adopting this module, in case anyone including the original author has any concerns.
well not that bad just a little frustrating and not very productive for about 3 hours of time.
Was playing about with Test-WWW-Selenium and going at it great guns after about a four year absence since I had to use Test::WWW::Mechanize in the last place I worked that was doing a little testing, Needless to say I was just a little rusty in my Selenium skills and I didn't have my code base from when I used it last but I was glad to see one can get the Selenium server running headless on ubuntu.
So I get into the programming swing of things and the I get stuck. I have to test all the links on a page to make sure there are no bad ones. So easy I remeber how to do that just
Well reaching the end of the road here now that I did my code review I think it is now about time I sit down and write up my first .t files for my Moosex.
I always think it is best to keep your tests simple and small, but not too small so I usually use Test::More as that give me just a few dependencies but a good load of extras. I am also little old school with my testing style as I like the good old numbered and named test that cover only one part of functionality.
So to start off I am going to start with good old 00-load.t
#!perl -T
use Test::More tests => 1;
use_ok('MooseX::AuthorizedMethodRoles');
Today i tried to rebase my dev branch of OpenGL.pm on the latest changes and found that a segfault in OpenGL::Array was assumed to be fixed, despite still being alive and well. With nothing (haha) better to do i decided to poke at it and see if i could fix it. I foregrounded #xs on irc.perl.org in my IRC client and set to work. My first stumbling block came surprisingly soon:
How to print debug messages in XS?
Since i can't just step through XS in the perl debugger, i had to debug via printing to the command line. However the XS in OpenGL.pm seems to swallow all output to STDOUT. Leont suggested it might be the test harness, but at that point i wasn't even running in a test harness. Even with bulk88 weighing in nobody actually knows why it does that, however the solution was fairly easy:
In XS croak() and warn() are provided and even work akin to printf.
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.
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.
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
.
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 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.
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.
