In my last post I had a look at the [Collect] section plug-in and how you can use it to gather up similar parts of your POD in to one section in a document. Useful when you want to keep the POD next to the code but you have a mix of function attributes and subs in the code for other valid reasons.
Today I am looking aI would guess would be the simplest plug-in to use [Leftovers]. As the name implies it dump any Pod that has not been put into another section.
In the case of the [@Default] template it is here;
This is the C::Blocks Advent Calendar, in which I release a new treat each day about the C::Blocks library. Yesterday I compared C::Blocks to other TinyCC-based Perl libraries. Today I will focus on a fun diversion: hacking on the parser with a bit of C::Blocks code.
I must admit that some of yesterday's results have me a bit depressed. I've put a lot of work into this library, and I am really surprised and worried about the performance cliffs I illustrated yesterday. Today, though, we're going to have some fun.
Your early holiday gift from the Dancer Core Team has arrived - Dancer2 0.204002 is on its way to your favorite CPAN mirror. This release provides the following:
A fix for public_dir: When using public_dir , Dancer2 now waits for the configuration to be read before deciding where static content should be served from
A new plugin helper method, find_plugin(), that lets you import another plugin’s DSL for use in your own custom plugin
A variety of documentation fixes and enhancements
Make sure to check out the Dancer Advent Calendar! It features a number of great articles not only from the Dancer Core Team, but a number of our community members too.
The Dancer Core Team would like to thank all of our contributors and community members for another great year. Simply put, you are the reason we keep working hard at Dancer, and we are grateful to have such a great community of users and developers around us. Here’s to a great 2017… Hope you all have a safe and happy holiday season!
In my last post I looked at the rather plain but useful [Generic] section plug-in, that lets the Pod writer control where any section of POD that begins with =head1 can be moved to anywhere on the page. Today I am going to look at another of the often used plug-in the [Collect] section or plug-in.
This section is used to gather, group collect or otherwise gather together items under a named '=head1' tag what have the same POD tag. Looking at the [@Default] template again you will see there are three of them;
After almost 3 years of development and more than 2 years in production, 2 talks at YAPC::EU (Granada and Cluj) and one talk at the Dancer conference last year in Vienna, I think it's time to announce Amusewiki on blogs. perl.org as well, as I consider it more or less feature complete and robust enough for a larger audience.
Amusewiki is basically a CMS, but it's not "yet another one". Its main feature is that it creates for each published text various PDF (via LaTeX) and EPUB (for e-readers and mobile devices) files, along with an HTML version. It's also able to produce slides. Also the bookbuilder provides a way to extract, merge and customize the texts stored in the archive. You may want to give amusewiki a try if you're interested in publishing and distributing texts. If you just need a wiki or a blog for posting code snippets and lolcats, you probably want to look elsewhere. Amusewiki is suitable for publishing whole books as well.
After a couple of years of more or less "maintenance mode" on DBD::mysql - we had a hand full of people contributing occasional fixes and a whole slew of drive-by contributors - we now have a prolific contributor again: Pali Rohár.
It's great to see some more long-standing issues taken care of!
This time around, in the new development release 4.041_01 that is on CPAN now, there are some important fixes for some Unicode-related issues that I would like to point out. The sections below I have distilled based on the descriptions made by Pali.
Automatically converting to UTF-8 for bind parameters
Before this release perl scalars (statements or bind parameters) without UTF8 status flag were not encoded to UTF-8 even if mysql_enable_utf8 was enabled. This caused perl scalars with internal Latin1 encoding to be sent to the mysql server as Latin1 even if mysql_enable_utf8 was enabled.
Sorry still on the all POD diet here at the Dist-pen today
In my last post I had a look at custom [Region] section and how that section lets you define your own custom tags you can use in you POD. Today I am looking at one of the often used sections and one of the more simple ones the [Generic] section.
If you look at the [@Default] template you will see no less than fours calls to this plug-in
This is the C::Blocks Advent Calendar, in which I release a new treat each day about the C::Blocks library. Yesterday I dug into the details of writing a type that can be used with C::Blocks. Today I explain how to use C::Blocks in multithreaded Perl code.
This is the fourth article in a series about MetaCPAN. The first article described the two main parts that make up the MetaCPAN project: the API and the search interface. The second article gave a high level overview of how the API uses Elasticsearch to hold and search information about CPAN distributions and authors. The third article showed how MetaCPAN fits into the rest of the CPAN ecosystem.
In this article we'll show how you can use the MetaCPAN API to get information about releases to CPAN. We'll start off with a very simple query, then gradually refine it to narrow down which releases are returned, and what information you request for each release.
This article is brought to you by Elastic, who were a Gold sponsor for meta::hack. We were very happy to have their support, especially given the central role that Elasticsearch plays in MetaCPAN.
In my $dayjob at GetResponse I have to deal constantly with time dependent features. For example this email marketing platform allows you to use something called 'Time Travel', which is sending messages to your contacts at desired hour in their time zones. So people around the world can get email at 8:00, when they start their work and chance for those messages message being read are highest. No matter where they live.
But even such simple feature has more pitfalls that you can imagine. For example user has three contacts living in Europe/Warsaw, America/Phoenix and Australia/Sydney time zones.
So in my last post I had a look at a the little more complex [Version] section plug-in for Pod::Weaver and Dist::Zilla. How the user can change the format of the section and even use some passed in variable, identified with a '%' in a section template.
Today we are going to look at one of the Meat and Potato sections the [Region]. This section allows you to place you own custom section or 'region' where-ever you want in your document. This is accomplished by using Pod::Weaver 'tags' which are simply text starting with a ':'
I've been researching recursion lately and in particular, permutations algorithms. This interest was spurred by a real-life case where such an algorithm would come in handy (combinations of @clients, @users, @tickets). I came across Wikipedia's entry for Heap's algorithm and the pseudocode illustrating the algorithm. I found the non-recursive version even more interesting specifically for its lack of needing to call itself, so I chose that version of the algorithm to study.
In this post I am going to show how you can use Sparrow to test Mojolicious applications.
Sparrow approach to test things differs from convenient unit tests approach, practically this means:
A tested code is treated as black box rather than unit test way where you rely deeply on inner application structure.
A sparrow test suites are not a part of CPAN distribution ( the one you keep under t/* )
A sparrow test suite code is decoupled from tested application code and is better to be treated as third party tests for your application
Sparrow tests suites have it's own life cycle and get released in parallel with tested application
Sparrow acts like toolchain to choose proper tools and then analyze script output
IMHO writing sparrow tests sometimes is much simpler and takes less efforts and time, but I don't say you don't need a unit tests but sometime it worths it to take an alternative testing approaches / tools and see the difference , so if you are interested , please read below ...
This is the C::Blocks Advent Calendar, in which I release a new treat each day about the C::Blocks library. Yesterday I explained how to use C::Blocks in multithreaded Perl code. Today I will compare C::Blocks to other TinyCC-based Perl libraries.
In a script I recently wrote, I employed a few features of Perl 6 that I'd like to highlight. I'm using Mash to create a distance matrix of samples (usually metagenomes or genomes) to each other, either in a complete pair-wise fashion or some set (like the Pacific Ocean Virome) to some new set of samples.
The output of Mash is a tab-delimited file. The first line contains the column headers, and the first column is the literal string "#query" followed by all the sample/file names which include the relative path information. Here is a sample:
All the other lines are the reference samples (with relative path information to the index) followed by a value between 0 and 1 indicating the distance (shared genetic content as determined by k-mers in this case) between the samples where "0" indicates identical samples and "1" is completely unrelated:
.svg?q=202)
