blogs.perl.org

Fix a little bug day here in the Moose-pen

One of the great things of tests based development is you are always finding new bugs as you progress. Yesterday I found yet another;

Yesterday, I described how I had approached developing PearlBee by reworking the data models and writing tests. That worked fine until a point, where the pipeline of user interaction was fairly obvious.

For example, it’s easy to write tests for a “reset password” feature. The user is supposed to go to the login page, see a link to reset password, click that. They should then submit their email or username in a form, and get an email with a link to a reset password form. All pretty obvious, since we’ve all used that several times (at least until password managers became popular :) ).

When I moved into the admin section of the website, though, it became a lot more subjective how it was supposed to look like. Not even from a design perspective – from a test perspective. What am I actually testing for?

It is me, or is it internet? When you are organizing events, people respond later and later every year. You buy a book on internet, and it is delivered next day. The washing machine dies, but you do not have to leave the house anymore. But meeting organizers can not deliver in a single day.

We need to see each other every once in a while. For me a must; meeting weird Perl people challenges my own ideas. I get so enthusiastic seeing the projects which other people undertake. It gives me energy to work on my own plans. To meet people for Perl, I visit the monthly meetings of the Amsterdam Perl Mongers (great!), all European Perl Conferences, and often the German Perl Workshops. Very cosy events, where I see my traveling family.

Well, in NL we also organize our own yearly Workshop. The best place to meet "local" Perl addicts. Melinda (Damnlie) and me (MarkOv) warmly invite you all. Read more at http://perlworkshop.nl

Test postette day here in the Moose-Pen

Been a few days since I did a bottom up test on Database::Accessor and seeing it is a rainy Saturday I figure I could do a quick on.

Starting with Database::Accessor I do not suspect much to go amiss as I only had ' 2 files changed, 41 insertions(+), 6 deletions(-)' but one never knows;

Can't locate MooseX/Enumeration.pm in

All tests successful.
Files=29, Tests=524,

About a year ago, I submitted a grant proposal to TPF to revitalize this platform, blogs.perl.org. It was supposed to have taken only a few months, but it's still not ready. In the meantime, I have been completely silent, at least publicly. What's going on? Is it ever going to be delivered?

Indeed, I should have started writing here months ago, with traditional timely updates on the developments on the grant. What discouraged me to do so was that these developments have been somewhat irregular. Some moments of uncertainty on the best course of action, and others of simply not being able to dedicate enough time to it. Still, I assure you, dear BPO reader, the project is alive and well!

In the interest of being more open, then, I'll make a series of posts this week saying all that I've been working on and what's my overall plan for blogs.perl.org and PearlBee.

Let’s start with the beginning.

Shutter, a powerful application for taking screenshots is possibly soon to be removed from Debian, taking with it the last desktop Perl application in that ubiquitous distro. That is a shame, but there is hope, I guess, some brave soul with take up the effort required to make it fit with GTK3s new APIs. That person is not going to be me. I don't have the skills or the time to do this. But hey, I am the author of the world's simplest GUI generator( probably). Surely it can't be that difficult to cobble together a few applications to make the world's simplest Screenshot tool? Does not need to be fancy, but needs to have a ton more features than the basic Screenshot application in Ubuntu, and be generally useful for day to day use even as a proof of concept.

Requirements

tl;dr: If you care about DBD::Oracle at all please test this unauthorised trial
release.

Its get back to 'da_result_set' to-day in the Moose-pen.

Getting back on track with 'da_result_set' I still have two JSON which should be quite straightforward and Class which could be problematic, so I am going to JSON first.

$da->da_key_case('Lower');
$da->da_result_set('JSON');
ok($da->is_JSON ==1,"return set is a JSON");
cmp_deeply( $da->result()->set->[0], $user_db->new_person_data->[3],"JSON returned with correct data");

Back in 1999/2000 when I was first learning Perl, I read an article by a Perl advocate in which he said he believes Perl would become the best language to do XML with. Having been impressed by Perl’s power and ease-of-use (coming from C and Pascal) I imagined how great it would be if Perl’s strengths and ease of use were applied to XML-processing.

However years passed and I couldn’t find a module easy and intuitive enough for me for processing XML. So in 2006 I made my own pure-perl module for personal usage, called XML::MyXML.

It was so easy even I could use it. And I happily develop it until today.

Among other things (parse XML), it lets you treat XML as easily as JSON.

Here’s an example:

OK, so this is my first ever public blog, so be patient with me.

I've written a few Perl related Genealogy programs including gedcom (https://github.com/nigelhorne/gedcom) and ged2site (https://github.com/nigelhorne/ged2site). One of the things that these do is to check the validity of your family tree, and one of those tasks is to verify place-names. Of course places do change names and spelling becomes more consistent over the years, but the vast majority remain the same. Enough of a majority to computerise the verification. Unfortunately all of the on-line services have one problem or another - most either charge for large number of access, or throttle the number of look-ups. Even my modest tree, just over 2000 people, reaches those limits.

The first part of this series described Test Hierarchy, a hierarchy of test classes that mirrors the classes under test, and explained why it’s an antipattern. Part two explored what makes a good unit test and why Test Hierarchy does not. This third and final post reflects on why programmers use Test Hierarchy and why these reasons aren’t persuasive.

Even more API fun day here in the Moose-Pen

When I left off yesterday I had everything working nicely but I was left with a little problem;

What should I do about the case of hash-keys returned from the DB?

Now in DBI I have three choices

• NAME
• What ever comes out of the driver, could be upper, or lower or mixed depending on the query, driver and DB.
• NAME_lc and
• all keys in lower case
• NAME_uc
• all keys in upper case

while in most other NON SQL dbs I really do not have any choice. Though it seems in Mongo they always want you to use lower case for field names though you can used any case you want, while RethinkDB, at least when I used it some time ago, it only allowd lower case field names.

Perl allows pretty much any value to be evaluated in a boolean context:

if ($something) {
   ...
}

No matter what $something is, it will safely evaluate to either true or false. (With the exceptions of a few edge cases like blessed objects which are overloaded to throw an error when evaluated as booleans.)

So when a Moose class does something like this, what does it mean?

has something => (
   is  => 'ro',
   isa => 'Bool',
);

"Why is parsing considered solved?" is the newest entry on my Ocean of Awareness blog.

It is often said that parsing is a "solved problem". Given the level of frustration with the state of the art, the underuse of the very powerful technique of Language-Oriented Programming due to problematic tools, and the vast superiority of human parsing ability over computers, this requires explanation.

On what grounds would someone say that parsing is "solved"? To understand this, we need to look at the history of Parsing Theory. In fact, we'll have to start decades before computer Parsing Theory exists, with a now nearly-extinct school of linguistics, and its desire to put the field on strictly scientific basis.

As part of my project to create a tutorial for XML::LibXML, I created an XPath Sandbox tool that allows you to try out different XPath expressions directly in your browser. I've recently enhanced that tool to add a couple of useful features:

• 'Upload'* your own XML files, and query them
• Namespace support, including registering your own prefix mappings

When working with the built-in sample files, URL parameters can be used to: select a file, specify an XPath expression, override the default namespace prefix mappings. Here's an example link that does all three!

* I used the term upload in 'scare quotes' because it's a client-side app, nothing actually gets sent to the server.

It still fix API day here in the Moose-pen

Yesterday I left off with a new attribute for may Database::Accessor and DAD, 'da_result_set' and I was just going to play with this in my Driver::DBI but before I go and do this I better change one test a little;

...
    else {
        my $dad = $da_new->result()->error;
        ok($dad->is_ArrayRef ==1,"DAD is_ArrayRef is true")
     }

rockyb’s recent post about B::DeparseTree contained several insights on testability and writing good tests. Here are my takeaways.

As we entered the sixth month of the year 2018. So what have I achieved in May 2018? In short, plenty. Let me share the details.

May 2018 has been the best month so far in the year 2018. In this month, I submitted 60 Pull Requests. Only two occasions in the past where I had better number than May 2018. It was 77 Pull Requests in December 2016 and 63 Pull Requests in January 2017.

As of today, 2nd June 2018, I have submitted 858 Pull Requests. Of those 575 Pull Requests have been merged successfully. I am hoping to get to the magic number 1000 before the next London Perl Workshop, which is the 3rd Nov 2018. I am keeping my fingers crossed.