Now that I have things mostly sorted out let's actually do some code or at least some pseudo-code on how I going to make it work.
I could go the pure Perl route and do the same sort of thing DBI does, an interface then drivers under it following this design pattern
I have cloned out and customized the DBI code and pattern in other applications and it really works well when you want the common glue on-top approach.
One thing I want to avoid is API deviation or sub bloat as I like to call it. It is an all to common occurrence with this design pattern. I am guilty of it myself when I added Scrollable Cursors into DBD::Oracle. Nothing in the DBI spec about these and I recall a little note from Tim asking to explain why I didn't create a generic DBI version before I added into DBD::Oracle.
The QA Hackathon (QAH) will be kicking off on Thursday morning this week, starting 4 days of intensive work on the CPAN toolchain, test frameworks, and other parts of the CPAN ecosystem. The participants will be gathering from all over the world on the Wednesday evening.
The QAH wouldn't be possible without the support of all of our generous sponsors. In this post we acknowledge the silver, bronze, and individual sponsors. Many of the Perl hackers taking part wouldn't be able to attend without your support. On behalf of the organisers and all attendees, thank you!
Yes, it does indeed! The not-so-well-known
Git configuration parametercore.whitespace is quite versatile in this respect. It supports different
values, even tabwidth to tell how many space characters an indentation (tab)
must be equal to.
core.whitespace
: A comma separated list of common whitespace problems to notice.
git diff will use color.diff.whitespace to highlight them, and git apply --whitespace=error
will consider them as errors. You can use prefix ”-” to disable any of them (e.g. -trailing-space):
My little API exercise in my last post I noticed that I may be missing an important part of the puzzle and that is some sort of generic connector function.
We're still hacking away on the Veure MMORPG and things are moving forward nicely, but I thought some folks would like to hear more about our development process. This post is about our test suite. I'd love to hear how it compares to yours.
Here's the full output:
$ prove -l t
t/001sanity.t ... ok
t/perlcritic.t .. ok
t/sqitch.t ...... ok
t/tcm.t ......... ok
All tests successful.
Files=4, Tests=740, 654 wallclock secs ( 1.57 usr 0.20 sys + 742.40 cusr 15.79 csys = 759.96 CPU)
Result: PASS
Let's break that down so you can see what we've set up. You'll note that what we've built strongly follows my Zen of Application Test Suites recommendations.
[This is a post in my latest long-ass series. You may want to begin at the beginning. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.
IMPORTANT NOTE! When I provide you links to code on GitHub, I’m giving you links to particular commits. This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post. Just be aware that the latest version of the code may be very different.]
Last time
I talked briefly about the raft of failures that CPAN Testers threw up for me to look at. I mentioned that there were roughly 3 groups of failures, and that one of them was bigger than the other two. I even gave a hint as to what it was in one of my examples:
I'm a sucker for early access to free APIs. So I quickly went forward when
Backblaze opened up access to their B2 storage API, and implemented a client
for it, Backblaze::B2. I feel a bit guilty for releasing a module without having a use case
for it myself, but instead of letting it rot on my filesystem, I'm putting
it out for others to use.
So I have sketched out my test suite lets have a look at the API I am trying to express.
For me the API is the most important part design. Have a good workable general purpose one it will become a de-facto standard, like DBI, do a very narrow one it will languish in the niche that is was designed for. It has been said many times before, but it bears repeating here, that any API should be
Easy to Learn
Easy to Use
Easy to Extend
Consistent and
Hard to misuse
Well on the higher level my Data Accessor will be easy to use with just the basic four CRUD operations so that should be easy to use and learn.
where the <oct> capture represents things that
need to be run through the oct built-in, and the
<float> capture comes from perlfaq4.
The problem here was that the <float> expression
matched things like '09', which was not what I wanted. What
I wanted was to have the entire expression fail if it got past the
<oct> expression and found something beginning with
'0', other than '0' itself.
We're very happy to announce that SureVoIP are supporting the QA Hackthon as a gold sponsor.
SureVoIP® (Suretec Systems Ltd.) is an Ofcom-registered Internet Telephony Service Provider supplying Hosted VoIP solutions, SIP trunks, UK inbound numbers, International SIP numbers, a partner program, public API (powered by Catalyst) and other related VoIP products and services.
Having failed to find a working profiler on npm I ended up webpacking nqp-js-on-js and profiling it directly in Chrome.
It turns out the first big slowdown was the lack of multi caching.
I implemented them.
The second big slowdown was actually the slurp() function.
MoarVM doesn't handle concatenation large amounts of huge strings very well so the cross compiler so instead of concatenating bits of javascript code it's often much faster to write them to disk and then slurp it back in.
On the nqp-js-on-js due to a misset buffer size slurp turned out sluggish.
Due to profiling a webpacked version (which doesn't do IO as it runs in Chrome) this has baffled me for a bit.
Changing the nqp::readallfh buffer size from 10 to 32768 speed up stuff a lot and I'm back to compiling rakudo.
Based on the output of the profiling there seem to be a few low hanging fruit optimalizations for bunch of easy ~5% speedups but I'll work on them later on as having actual Perl 6 running instead of NQP will give me a better vision of how we want to optimize things.
Well lets see as I am in a testing mode right now lest have a quick look at the DA.pm's expressed API to see what I should test or at least how I should organize my tests.
Always start with the basics so I will have
00-load.t
that will do your basic load checks to see if it will work on the perl that is trying to run it. No need to go into details there.
As well I will add in a
02-base.t
And this will test just a little more than load. Perhaps the use of a driver and some basic set and get checks of the higher level stuff.
I think subroutine signatures don't need arguments count checking,
because performance is more important than utility.
Subroutine signature should be optimized from performance perspective, not utility.
Arguments count checking is one logic, so it damage run time performance.
And I like simple and compact syntax.
sub foo($x, $y) {
...
}
# same as
sub foo {
my ($x, $y) = @_;
}
I have updated perlmodules.net with an important feature.
PerlModules.net is a site that notifies you whenever your favorite Perl modules get updated.
Up until now, it let you track changes to your favorite modules through an RSS reader. If you wanted to receive email updates instead, you had to use an RSS-to-email gateway, but that didn't work too well (important color and styles were lost from the text, and the emails were full of advertisments).
From now, perlmodules.net sends its own emails to the users. It is opt-in, so if a user doesn't provide their e-mail address and check a checkbox at their feed's page, they won't receive any emails, plus all emails sent contain an easy unsubscription link at the bottom.
Although YAPC::Europe::2016 preparations are well underway in Cluj, it
is time for the venue committee of the YAPC::Europe Foundation (YEF) to
think about the location of the 2017 conference. YAPC::Europe wouldn't
exist without dedicated teams of volunteers, and we are always excited
to see the enthusiasm and learn about the new ideas the community has to
offer.
Further information about preparing a complete application can be found
on our website.
Proposals submitted to the venue committee will be added to
this public repository (you may provide
private information separately) to benefit future organizers.
The deadlines which apply to this portion of the procedure are:
Friday, 20 May: Deadline for sending a letter of intent. This letter
simply expresses interest in hosting the conference and provides contact
information (both email and telephone) for at least two organizers. This
is an optional step but it can be to your advantage to alert the venue
committee of your proposal.
Thursday, 7 July: Deadline for sending proposals to host YAPC::Europe
2017.
If you do not receive a confirmation for your letter of intent or
proposal within a couple of days, please personally contact a member of
the venue committee.
Please send your questions, letters of intent, and proposals to
venue@yapceurope.org.
Well I would not be a very good CPAN programmer if it did not think of a set of tests before I started any project so let take a look at what I have.
Fortunately for my Data Accessor (still haven't come up with a new name for it) I have inherited a rather large test suite of about 200+ tests. Unfortunately for my Data Accessor I have inherited a rather large test suite.
In which I show the tools that I use to clean up and cut releases
In the 12 years I've done CPAN releases, I have acquired my share of experience
through botched releases of modules. Much of that experience has dribbled
into tools and a release process that is mostly automated to allow me to release a module
at the end of a hacking session without needing any mental strength to remember things. My judgement also gets clouded when I'm fixing a module in anger, so having Perl keep me honest and preventing the more obvious failure modes is highly convenient then.
Logdog is yet another sparrow plugin to analyze various log files.
One my use logdog for various tasks like finding errors in nginx/apache logs or inspecting suspicious entries in your sshd log file.
One killer feature of logdog is it parsing log lines for the given period of time. Like one can ask to find only entries for last hour or for last 2 days or even 15 minutes. It is very handy as often this is probably what you need - to identify what have happened recently and to not re-examine all the events happened a long time before.
Let's see how one can monitor BAD ssh logins using logdog. The rest part of this blog will look like a formal documentation, but I hope you won't be frustrated! :)
Installing logdog
First of all we need sparrow and a minimal prerequisites:
I've gotten a bit of grief over the title of a TechBeacon article I recently wrote: Why Perl 6 is the "Game of Thrones" of programming languages. I wrote the article, but the editors chose that title based on a throwaway line a couple of paragraphs in:
Like A Song of Ice and Fire (Game of Thrones), which was started back in 1991 and is still being, ahem, "developed," good things come to those who--well, you know.
To be completely honest, I could have objected and the editors at TechBeacon would have changed it back. However, I didn't object because I was honestly curious what the reaction would be. The general reaction so far has been "great article, awful title." I've no idea if that clickbait title helped draw enough traffic to offset the bad impression of the title itself.
We're very happy to announce that 