As I reviewing some of my code for 'Case' statements I had chanch to stop and think about why I was using a Param class for the message on a case. Right now I have something like this;
{
left => { name => 'Price', },
right => { value => '10' },
operator => '<',
message => { value => 'under 10$' }
},
Before I had that just as a simple string like this
Its test post-ette day again here in the Moose-Pen
I guess I am following a very predictable pattern The weekend is here and I just do a post on test results. Well why spoil a good thing?
Since my last test round I have changed a good number of things about but I am fairly sure that Database::Accessor is in good shape though I am not looking forward to see what sort of state Driver ::DBI is in.
As I suspected there was only very minor problems with Database::Accessor;
Looks like you planned 2 tests but ran 6.
t/15_case.t ................. Dubious, test returned
I just have to update that test count and now I get
This month, I was tasked with implementing FIDO/U2F support for two factor authentication for a client. U2F two factor authentication requires a FIDO/U2F hardware key that you insert into your devices USB port and press a button to complete two factor authentication. There are many different vendors that make these devices, such as Yubikey etc. Thanks to the excellent Authen::U2F module by CPAN author ROBN, and Google's u2f-api.js library, implementing support for this proved to be fairly straightforward, but the process for doing this is not the point of this blog post.
The point of this blog post is that, at the time, there was no easy way to write any kind of automated tests for this. As a result, I ended up writing Authen::U2F::Tester. Authen::U2F::Tester acts like a virtual hardware device to complete FIDO/U2F registration and authentication (known as signing in U2F terms) requests.
During the ongoing development of graphql-perl, I have found it valuable to generate data structures, and to compare those with expected values. Often, these have been highly detailed rather than a subset, because I wanted to know when anything changed.
When, however, something does validly have to change, it might change quite a few "expected" outputs. If those all need updating manually, that is a lot of repetitive activity. What if the computer could do that instead? What if Perl had "snapshot testing" as used in JavaScript frontend development, most popularly in Jest?
use Test::Snapshot;
my $got = function_generating_data();
is_deeply_snapshot $got, 'test description'; # could also be in a subtest
I wrote an article about the maths behind the game Dobble (known as Spot-It in some countries). It has no pretense of strict formality but it works for reminding me the though process that leads to designing Dobble-like games. The whole process prodded me to write Math::GF, a module on Galois Fields that can be used together with Math::Polynomial, so... there's also Perl in it!
I've tried to make this blog post copy/pastable as valid perl and valid markdown. So with luck it can be copy/pasted into an editor if you want to use this.
Confluence. I don't really like it, but the major thing it's got going for it is that it's not Sharepoint. As I am spending the summer holidays doing some documentation at work, one of the things I wanted to do was to make confluence less hateful. So I cracked open the REST API to see how far I could get.
There used to be good tools, but atlassian got rid of the XMLRPC API not that long ago.
Progress I made was:
Got a list of all spaces, and all pages in each space.
Worked out how to obtain the content of a page.
Worked out how to change the content of a page (for when the time comes).
Where I got stuck:
Working out how to round-trip the confluence markup to/from markdown.
The rest of this post describes the script I put together. It's not useful enough for me to put on the CPAN but it's worth putting up somewhere.
Back in the day, when I came upon a particularly juicy tip/hint/trick/kludge/etc. I would write it down somewhere (way back -- in a paper notebook; more recently, somewhere like TiddlyWiki). But I don't do that anymore -- why?
The answer is Stack Overflow. When I have a question, a web search often has 1 or more Stack Overflow answers at the top - answers that usually help me fix (or work around) the problem I have. It really is impressive how often Stack Overflow has just the answer I need and in just enough detail. (Disclosure: I answer questions on Stack Overflow on a semi-regular basis.)
It is another head case day here in the Moose Pen.
So yesterday I left you hanging on how I was going to incorporate the 'case' statement into Database::Accessor hopefully today I will find some solution for it.
To start off my attempts to use the present class structure ended in failure and from my analysys of the problem I have one of two choices.
Add in new attributes
Add in a new class
The main disadvantage of the first solution is I will have a number of attributes that will be useless 99.99% of the time. The advantage is this will most likely be the least disruptive to my code base and use the least amount of code.
The second solution has no disadvantages that I can see but it will increase my code base a little.
Sitting on my TODO list has been a refresh (resurrection perhaps?) of the FormFu website.
In 2017 the various contributors consolidated into a single Group on GitHub - authors of related modules are invited to donate them into that group for future maintenance etc.
Having some time off has allowed me to get through much of that aforementioned TODO list and over the last few days, the FormFu website has been ticked off of that list.
GitHub has a "pages" feature, which is based upon Jekyll. This is a convenient system for generating a static site from templates and content from Git - which also includes the hosting part for free. Everyone in the group can make changes, with 3rd parties able to use Git's normal mechanisms to send PR's, issue reports etc.
So I donated a funky new .rocks domain and used the GitHub pages to create simple new website for FormFu. Any and all feedback is much appreciated.
Looking back year 2017 brought many sweet moments, both at professional and personal front. On personal front, I have been blessed with twin girls, Aabia & Aania. Raising twins without family support is not easy for me and my wife. I am told to be prepared for more surprises.
On professional front, there have been many positives to talk about. First I completed third consecutive years of CPAN PullRequest Challenge without missing a single month. I hope to carry on with the same spirit in the year 2018.
Took part in Hacktoberfest challenge, third consecutive years, and submitted 40 PR. Recently received the specially designed T-shirt, Thanks Digital Ocean.
I also completed 24PullRequest, again third consecutive years, and submitted 34 PR.
On the same line, submitting PR, I planned to do at least 1 PR each day on average most of the months in the year. Before year 2017, I was able to do that in 3 months at the most (in the year 2015).
Well I am getting close to running out of things to add into Driver ::DBI as I have all the operators covered, functions, expressions, elements, etc etc so I do see and end in sight maybe I won't get a year of blog posts in after all??
Today I am going to try and tackle on of the much abused SQL commands the 'CASE' statement. The question is where to test this one as it can appear anywhere a predicate can so in a 'sort/order by', 'element/field', even a 'link/join'. I was thinking the best spot for it would be back in 32_where_operators.t but the most common form of case I have seen is in SQL like this
Thanks for reading my report. In the last report I included a mini tutorial
about string quoting methods in YAML. This time I've written an introduction
into YAML Schemas and Tags.
In December I have been working about 60 hours on YAML::PP, YAML::XS, libyaml and the Schema article.
See also my previous reports on
blogs.perl.org
(Aug/Sep,
Oct,
Nov
)
and news.perlfoundation.org
(Aug/Sep,
Oct,
Nov
).
HTML::Tagset is a popular module on CPAN and has nearly nine thousand descendants in the "River of CPAN". Unfortunately its last version was in March 2008, nearly ten years ago, so it doesn't feature the HTML5 tags yet. There has been some discussion on the HTML tag set bug tracker but so far that has not come to fruition. As an alternative to HTML::Tagset, I made the module HTML::Valid::Tagset, which incorporates the data tables of the "Tidy HTML5" project.
It's partly based on HTML::Tagset's interface, so it can substitute for some of that module's functionality, and it also has specific tag sets for each version of HTML, including HTML5.
Having the Tidy HTML5 data tables means I was also able to add a function attributes which returns a list of valid attributes for a tag, and tag_attr_ok, which returns true or false depending on whether a particular tag can take a particular attribute. This is part of a larger distribution called HTML::Valid, based on the Tidy HTML5 project.
Development of Rakudo Perl 6 is quite fast-paced, with hundreds of
commits made each month to its five core repositories. Users undoubtedly feel
some impact from those commits: bug fixes may break code that relied on them,
backend changes may have unforeseen impact on the user code, new useful features
may be implemented that users would want to know about.
In the past, for things with very large impact, we made blog
posts, but there
are lots of small things that fly under the radar, unless you actively
pay a lot of attention to Rakudo Perl 6's core
development.
To help all of our users to be aware of important issues, we're
announcing introduction of P6lert service: tweet-sized alerts from Perl 6 Core Developers.
The Goods
The P6lert service primarily consists
of alerts.perl6.org website, but with it come
a variety of ways to receive alerts posted on it:
