Today I am looking at the I think the last section plug-in the [WarrantyDisclaimer] plug-in. This is your standard blurb type plug-in that will dump a bunch of legal words that is suppose to cover your arse if someone uses you code to control a self-driving car that goes berserk and crashes into a children's hospital causing a fire as the cute puppy store.
This plug-in has a number of subclasses that you can use to match up the license you are using to the correct subclass. So far there are six sub-clases
Default
Artistic
Custom
GPL1
GPL2
GPL3
Myself as I am using the GPL 3 so in my 'weaver.ini' file all I need to add in is
See part 1 and part 2 to get caught up. In our part 2 meetup (last night), we changed things up a bit. I decided that tackling the space mission to start was going to be a bit much (too much content), so I switched us to Action Castle, the first adventure in the Parsely series. And built out a mission config file with notes from the adventure using the structures that we designed in our first meetup.
After explaining the reason for the change, the group agreed, and we continued on our merry way. As we continued to define our mission spec, we figured out an API for plugging code calls into the spec. For example, you could replace an exit like this:
exits:
North : catacombs
With a code call like this:
exits:
North :
code: PluginNameGoesHere
params:
destination: catacombs
foo: bar
We built some sample code for exits, actions, and turns. None of this is final or anything, just building some samples so we could work through the the thought exercise.
You know, I’ve been trying to analyze my working patterns lately, and I think I’ve hit on something. Looking back over the past few years, it seems like I get obsessed with one particular project, work frantically on it and produce lots of great stuff, then I get distracted and next thing I know I’m obsessing over an entirely different project. And then sometimes I circle back around to the first project, but it’s usually a long time later. I’m actually starting to wonder if maybe I have some undiagnosed ADHD (not only because of the easily distracted, but also because of the hyperfocus, and SQUIRREL!). Anyways, that appears to be the pattern of my life, so I think at this point I’m just going to have to learn to roll with it.
Getting near the end of the section plug-ins I am looking at the [Template] plug-in. This one is much like the [GenerateSection] plug-in I had a look at in this post.
To use this plug-in to generate the same section I created in the other post above
=head3 Database::Accessor Tutorial
Welcome to Page xxxxx
I will first have to create that in a file with the {{}} in the right spots. So I created the file 'header.section' with this content;
Welcome to Page {{$name}} of the {{ $main_module_name }} tutorial.
Before we start: this is my first post at blogs.perl.org. Awesome that you're reading it despite me being a noob! :)
Three years ago, I started to change the way I think about logging in applications. Before that, to me it was just printing lines into text files, in order to later read and grep my way through them.
Then, a friend pointed me to ElasticSearch and Kibana, with its infinite ways to search through, and visualize, large amounts of textual data. Due to the nature of my $work, I was well aware of the benefits of a full text search database, however, it soon became clear that text alone was only part of the deal. The real fun in ElasticSearch begins when you add structured data into it, allowing filtering, grouping, and get all businessy with pie charts and world maps and whatnot. This would be where you'd start to gain knowledge that wouldn't be available anywhere in text-based logfiles.
Whether you are operations guy, devops or developer from time to time you deal with scripts development for various tasks - handy utilities, automation scripts, monitoring tools, so on.
Outthentic - is universal, language independent framework to encourage scripts development in easy and fun manner.
The blogs.perl.org site will be unavailable for a few hours during the night of February 16th to 17th 2017. The site will stop responding at approximately 21:00 UTC on the 16th, and is expected to be back by 05:00 UTC on the 17th.
The reason for this downtime is that the data centre where the site hardware is hosted is being closed, so our hosting company is transporting all servers in that data centre to a new location.
It is the big 'S' round-up here on the Dist-pen today.
Well just a post-ette today as I am a little hard pressed to find things to blog about. I am going to have a quick look at the three remaining section plug-ins that start with 'S'
[SQL]
[SourceGitHub]
[Source::DefaultGitHub]
SQL
This is a neat little plug-in that I might find useful when I go the write up my DAD::SQL. If you wrap any sql in you POD like this
Thanks to some sterling work by ehuelsmann, not least of which was badgering me to commit some code, Test::BDD::Cucumber now integrates directly into prove. This means you can run your feature files in parallel, and in a shuffled order more easily. This is a bit of a mouthful to achieve:
We've had a few questions and discussions about the toolchain summit since our announcement in January. In this blog post we'll address some of those: why the name change, what things are fair game to be worked on, and who decides who comes?
The Perl Toolchain Summit is the new name of the Perl QA Hackathon, an event organised for the first time by Salve J. Nilsen in Oslo in April 2008. In Salve's words from 2008: "The purpose of a QA hackathon would be to Quality Assurance-related problems that are easier to solve when everyone is gathered in the same physical location. This can include issues with packaging, testing modules, community support or with tools."
Over time, the event has grown in importance (it is now the major non-conference event of the Perl community), and moved around Europe, organized every year by a different team in a different European city. It is entirely financed by corporate and community sponsors interested in having a healthy and reliable Perl environment.
Well it is look elsewhere day here in the Dist-Pen today
Getting closer to the end of the road for Pod::Weaver::Section plug-ins I only have a few more to look at so I am going to look first at the ones I might find useful and then do a final wrap up of all the left overs.
Today I am going to look at the [SeeAlso] section plug-in. Fort my Database::Accessor project this might be a good one to have in there. As I will have a number of extra content I might want listed someplace, like links to the tutorial and manual and perhaps a link to a few DADs or a search for DADs
This plug-in does give you a number of options on how to enter the data for the section blurb. The most badsic is to add in the section your self in you pod and then the plug-in will convert them to a list.
Its on the 12.03.2017 12:00 in Room V5 and by ... me (you guessed it). It will have a small Perl 5 section handling 5.24 and 5.22 (since i've gone full P6 last year). Ant to not repeat myself i want to go more practical with Perl 6 this time. some nice alorythms and useful modules - answering: what can I do with Perl 6 today.
In my last post I had a look at the [Support] section plug-in and now I am going to have a closer look to see if I can create my own custom version of it.
The first thing I want to do is get rid of the 'perldoc' blurb and I can accomplish that by simply making that attribute false (0) in my 'weaver.ini' file
[Support]
++perldoc = 0
[Legal]
'Bugs' is the next blurb that I am looking at and I should be able just to turn it on by specifying that I want to use the 'metadata' rather than the default 'rt' so all I need to do is
Been away a while, and now I have a whole heap of bug reports to get through. But you, dear reader, I'm giving the inside track. If there's a bug in one of my modules and you want me to prioritize it, comment below.
Here’s another
example of code taken, terrifyingly, from a script that a contractor was paid
cash money to write. The contractor’s code included a script to remote into
another system and perform a command. Most systems required ssh, but we had
some older systems that required rsh instead. So the contractor made a
configuration file that contained client definitions:
In the script,
he looked up the client in question, and put its configuration into variables
like $method. So far, so good. But here’s the code that
decides which access method to use:
So this code omits
the sigil on $method—problem #1—and
thus treats method as a bareword
(i.e. the literal string "method"), then compares
that to the literal string "ssh", but does so NUMERICALLY—problem #2. Since both are
non-numeric strings, they are both treated as 0, and the comparison is always
true. Needless to say, this script did not turn on warnings or strict mode—problem #3. Luckily, the vast
majority of our critical systems required ssh, and on those systems, three wrongs
made a “right!”