Another test play date in the Dist-Pen today.
― Ambrose Bierce
hmm criticism, of a fashion, but not much good to us in the Perl world, I much prefer;
“Criticism may not be agreeable, but it is necessary. It fulfills the same function as pain in the human body; it calls attention to the development of an unhealthy state of things. If it is heeded in time, danger may be averted; if it is suppressed, a fatal distemper may develop."
…
Playing with tests in the Dist-Pen today.
On part of Dist::Zilla that I do find intriguing is the way it does its testing. As I discovered in my last post some things only work at release time and that is true of testing as well. Dist:Zilla take the newer extended testing model as a default. In the old days we would call these optional tests and usually hide them in a folder someplace, but the more common usage today is to put them in an '\xt' directory on their own.
One can see the logic behind this as I remember a few times having to do a force install of a CPAN mod as…
Well in the Dist-Pen today I am going to start to play with linking my Distro back into GitHub.
There are a good number of Dist::Zilla plug-ins to be found in CPAN that work with Git and GitHub in one way or an other. Unfortunately source management and system admiration are skills that I have always lacked, so I am hoping that a few of these plug-ins added to my '.ini' will help me keep my GitHub source both up to date and st…
YAP, Yet another Post-ette here at the Dist-Pen today.
There seem to be a never ending list of the chores that are involved with creating a distribution for CPAN. This is my eight post dealing with these little chores and hopefully the last in this vain. So today I am going to see if Dist::Zilla can help me with the README file.
This file normally contains detailed instructions on on how to install the module, not really requirement for a simple Moose module like mine, but something like DBD::Oracle, it uses XS and an external data driver, the README is essential. Anyway I …
Well another post-ette day again here in the Dist-Pen getting rid of one more chore.
Yep getting rid of one more chore the programmers least favorite thing next to code-reviews documenting your code. As good Perl programer we like to use POD as our format of choice and there are quite a few Modules out there that will help you a bit and some will get you started but alas the days of self documenting code are still not here.
Dist::Zilla does have a few plug-ins to help with documenting your code and as I really just want to get rid of some of the more boring chore work of do…
Another Post-ette here in the dist-pen today.
As we have seen in my last post Dist::Zilla is really good at doing all those boring yet important chores for you distribution, today I am going to look at another the Changes file. All distributions should have a changes file though I would guess there are quite a few without. I do not think there is any standard format out there but usually it is just something akin to
Revision history for xxxx
Change…Just a post-ette today on the Dist:-Pen
A few more little plug-ins to add to my '.ini' today and again these are largely house-keeping chores and like all chores they are never fun to do and easy to ignore or bugger up.
What I am talking about are the Meta files that should be released with each distribution to be put on CPAN. The first files I am going to look at are Meta.yml and Meta.json which should both contain the same data but only differ in format. Sometimes I have made a mistake and forgotten to update one or the other or forgotten some important information in th…
Today in the Dist-Pen I am going to have another crack at a different Versioning technique.
In my last post I had a look at using Dist::Zilla::Plugin::PkgVersion and I found it very useful but in the end I ran into a problem with putting all my Database::Accessor classes into my Accessor.pm file.
I wanted to see if I could have differing versions within the same file and the short answer was 'No' but the long answer was …
In the Dist-Pen today I am looking at another plugin to help with my many versioning woes.
In my last post I had a look at a Dist::Zilla plugin that helped me out with versioning my distributions. Today I am going to see if there is a plugin that will help me out with my Module versions as well. So a quick look about and I see we have a few options so I will start with the most likely candidate 'Dist::Zilla::Plugin::PkgVersion'
Like all the Dist::Zilla plugins I have used so for this one is quite simple; Ju…
Today in the Dist-Pen I am going to try and get all my version numbers in a row.
Doing some more investigation on how Dist::Zilla will solve another of my distro pains and that is Versioning of my package. I did learn a lesson on version some years again when I though I was doing someone a favor I did a quickie release of DBD::Oracle where the release tar ball didn't match up with the release name.
Go a whole bunch of heat over that breaking a few things that other people where doing. I guess going from 1.23 to 1.24a…
Just a quickie post here at the Dist-Pen today!
One thing that has been pointed out to me in the past it that I neglected to includ a license file on some of my CPAN distros. I have even forgotten to include a copyright notice, not a mistake one should really be making.
Dist::Zilla already has a rule that compels me to add in a license, as we saw that in this post and I think with only a few quick changes to my '.ini' file I will be able to get the license file in there as well.
In my …
So today in the Dist-pen I am going to add in a few more plugins into my Dist::Zilla just to see how bad my Kwalitee is.
One of the things that has always caused me problems when creating a perl module distribution are the 'required' modules that sometimes may be unknowingly buried in the code or just forgotten when the distro was created. My Database::Accessor package has a large number of required mods so I will have to be careful when creating my Dirstro
Just of the top of my head I have some ten or eleven in the Data::Accessor class and then there are my test cases wher…
Well today in the Dist-Pen I am going to get a little deeper into the basic plugins of Dist::Zilla.
I left off in my last post with Dist::Zilla I needed to add in an 'Abstract' to my dist.ini file and this I did ad first a pod entry
=Abstract: CRUD Interface for any DB
package Database::Accessor;
So the dilemma today is to decide what to call my next series I guess Dist-Pen would be an apt name and now to come up with some catchy titles and imags.
I spent a good little while looking at the fancy new (at least to me) distribution helpers out there and I have made a decision on which one I am going to use with accessor.
Well I have already abused 'ExtUtils::MakeMaker ' over the years so I will not lear much from playing with that one.
As for Module::Build I did play with that for a bit because it is Pure Perl and I have a Windows box but it did not play out the …
Well there comes a time in every playpen where it is time for bed so this will be the last moose-pen for a little while as I am all out of Moose to do on my Accessor project and I have to start getting it ready for CPAN.
So my love affair with Moose is ending, for the time being, and now I start working on the part of creating packages I dread the most 'Distribution'.
Up to this point in my career I have been lucky the only complex CPAN dist I ever worked with, DBD::Oracle, came with an extensive MakeFile.PL that I really only need to tweak every once an a while. At some 2800…
So in honour YAPCE 2018 it's shiftin bobbins day here in the Moose-pen.
Carrying on from where I left off in yesterday's post I decided it was time I cleaned up a little more of my code. Seems I do this
use Moose;
with qw(Database::Accessor::Roles::Base
Database::Accessor::Roles::Comparators);
use MooseX::Aliases;
…Yep. You guessed it. Yet Another Moose Post. Today in the Moose-Pen just a quick bit of code cleanup
I stumbled upon some of my early notes for this project today and it seems I forgot to include a MooseX I was keen on using from the beginning, I guess I forgot about it, so a little back programming today.
The MooseX is called 'MooseX::AlwaysCoerce' and it does what it says, forces all of your attributes to have
coerce => 1,
/users/byterock/2018/02/index.htmlWell the Moose-Pen is not dead yet as I still found some Moose to blog about, and I though I was so close.
On thing that really bugs me about Perl is the fact you can have a lovely interface like this
my $thingy = $object->get_some_thing();
$object->set_some_thing(“Not my thing”);
my $thingy = $object->{some_thing};
$object->{some_thing} = 'Not my thing';
Today in the Moose-Pen I am going to solve a little problem with Moose.
So cleaning up a lot of Moose poop over the last few days and part of that effort is to ensure some of my proposed features with this post. Now I have re-factored that a little today into this sub
sub _need_condition {
my $self = shift;
my ($action,$required) = @_;
my $is_required = $required || 0; die "Attempt to $action without condition"
if (
$is_required
an…
Well there still lots of life in the a little Moose-Pen today seem I still have plenty of poop to cleanup.
Well in my last post I cleaned up a little moose poop and today I am going to take a major step forward and clean up allot more. So far most if not all the poop I have been generation comes from my efforts of either
Well one would think there will be a large amount code to cover in a single post but thanks to Moose I really only have to add
="pr…Well sometimes the Moose-pen is empty and sometimes it is filled up today I am sort of up in the air what state I am in today.
One thing we have seen in many of my posts is great lines of I like to call moose poop or the lines upon lines of error reports. Many times they even confuse me and send me running down all sorts of Moose holes.
So I am going to try to clean a few of them up. The first one I am going to get after is not even an error just a waring telling the programmer that a DAD cannot load which we first saw in this ="https://blogs.perl.org/users/byterock/20…
Well not much moose in the moose-pen again. Like I said in my last post I am getting nearer to that programmer nightmare (at least for me) of documenting and packaging up my project to get it ready for CPAN. But there is still a little Moose left.
One of the neat things about test driven development is all the bugs one find and squish long before you code ever gets out there, today is a good example.
I decided to add in a few more features to my Accessor, (yes I know scope creep) namely I want it to be hard to do a update or delete without having either a static or dynamic …
Well after 1001000 days and getting close to the programming phase of my Accessor.pm I think I might as well do a quick state of the Moose-pen post
Well for a quick recap
I gave the background story of Accessor, some of the planning and some API/design related posts
Well today in the Moose-pen I do not have very much moose to look at as I am getting close to finishing off the Accessor.pm at least code wise, hey I even started to write up the POD for it so the end game is near.
So for today cleanup I noticed that in an earlier post I planed this
00~09 basic sanity tests
10~19 Database::Accessor Classes sanity test
20~29 DAD load tests
30~39 Accessor.pm static tests
40~49 Accessor.pm dynamic tests
50~69 Inte…
Today in the Moose-Pen I decidedt to fillan give another go at trying to enforce my DAD writers to include a sub like this
sub retrieve {
my $self = shift;
if ( $self->alias() ) {
return $self->name() . " AS " . $self->alias();
}
else {
return $self->name();
}
}
in their DAD drivers that would be added in this case to the Database::Accessor::Element class. This you might remember from my earlier ="…
Well looks like clean up day again on the old Moose-Pen. Well I hate to say it but 90% of today's post is on types again as my cleanup found a little problem with my 33_conditions.t test case. I know it was running fine yesterday but that changed when I discovered that I had commented out a good hunk of my tests before I though I was finished.
So looking back I did say I no longer needed the from hash-ref on my coerce of ArrayRefofConditions it seems I did not notice that I had commented out the test for a single hash coercion so I added that back in and my test failed. So I had …
Today in the Moose-Pen I am going to have a quick look at some very Moosish behavior when playing with types. I known you must be getting tired for Moose Types, but I think today you will see something that may save you time if you ever go deeply into Moose Types and coercion.
So to set this up say I have a look a new test I added to the 33_condtions.t test case
$da = Database::Accessor->new({view => {name => 'People'}});
$in_hash = {conditions=>[{left =>{name =>'last_name2',
…So carrying on from where I was yesterday in the Moose-Pen I played with a few ideas today on how to solve my problem of not being able to get dynamic attributes down to the DAD from my DA.
In my last post I had the example of a canned 'client' that I wanted to do this to
my $client_da = Data::Tier::Clients->new();
$client_da->add_conditions(...
$client_da->retieve($mongo,$into);
$client_da->retieve($dbh,$into);
Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations
