The bonus deliverable "Perl 6 Numerics" Language documentation page was
merged to master. It describes all of the available Perl 6 numerics, their
interactions, suitability, and hierarchy.
The newest post on the "Ocean of Awareness" blog is
"Marpa and procedural parsing"
: Marpa's procedural parsing is more flexible and more powerful than recursive descent's.
There are still a few little things to clean up before I move away from record-sets. The first issue I think would be when I have asked for a 'Class' with 'da_result_set' but I have not supplied a 'da_result_class'.
In my Driver::DIB code I did add in this;
if ($self->is_Class() and $self->da_result_class()){
where it checks to ensure the class is present but I think in the way I am designing the API I should die well before this as I do in a number of other similar situations.
So to accomplish the above I will first write up a test in good old '20_dad_load.t'
Unit tests are great. They show that the code was actually designed
to a given spec.
Runtimeassertions
are great. They show that the code is actually running the way it
was designed when applied to real data.
Design by contract is
a great concept, but it's a bit of an overkill for most projects.
However, sometimes I feel an urge to just rip several lines from a unit
test and put them right into production code. Test::More
doesn't help here much since my application isn't really meant to
output TAP or run in a
harness.
If you follow the updates on KickStarter, you may know the Learning Perl 6 book is nearing completion, with the author planning to submit final manuscript to O'Reilly on
June 18th.
What this means is the July's Rakudo Star release will possibly be the release the first crop of readers of that book will be using (the next release after that is in October). I've seen several people say they're waiting for this book to get
published before they give Perl 6 a try. Coupled with the marketing the author
and O'Reilly will be doing for the book, I expect to see an influx of new
users.
For that reason, I'm making a call to action, for everyone to polish the
experience of the first steps those users will make in Perl 6.
How to Help?
There are several things you can help with, depending on your skillset. And
before anyone protests, don't worry, there's one thing everyone is able to
do…
I'm keen to work on more "intuitive" searches for Geo::Coder::Free. It occurred to me, for example, when looking for a local favourite watering hole of mine, that I wouldn't be likely to search for "Rock Bottom Restaurant, Norfolk Ave, Bethesda, MD, USA". Instead, I'd be much more likely to search for "Rock Bottom, Bethesda, MD, USA'.
So I've added support for that. As a proof of concept, I only work on Restaurants, however the Whos On First data includes a (admittedly unsupported field) of sg:classifier which I should be able to use for a more wide support. What that means is that is if a business type is included in the name of the business, I can remove it and anything after that and add it to the database. In simple terms that allows "Foo Hairdressers and Barber's shop" to be indexed as "Foo". And because you don't always know the street name, it's indexed both with and without.
I'm sure there will be plenty of cases were the above scenario doesn't work - I'll monitor Apache logs - but as a start it works surprisingly well, as shown by
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
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.
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.
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
opps; Better install that and try again.
After that was installed I got somewhat better results;
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.
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.
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.
I will need a test first of course so the fist thing I will do is add that into '20_result_sets.t'
$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");
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.
