The meeting will be held on Wednesday 20th March at 7pm, and for this first occasion we hope to have two talks with a short break.

The venue is Reading Enterprise Centre on the University of Reading main campus. Refreshments and light snacks will kindly be provided on the evening by our hosts, Opsview:

http://www.readingenterprisecentre.com/#/location
http://www.opsview.com/

Please confirm your interest in attending by dropping a note to peter.finnan@opsview.com, including your full name (required for access to the building). If you wish to volunteer a talk of up to 25 minutes, please also provide a summary and the title.

I also urge you to join our mailing list to keep up to date with this and future plans:

http://mail.pm.org/mailman/listinfo/thamesvalley-pm

Looking forward to seeing you on the 20th!

I've put together a very short survey to work out how many might be interested. If you live in this corner of the UK and/or fancy coming along, please let us know:

http://www.surveymonkey.com/s/QNPF2V8

[1] the offer comes from Opsview, a company based at the University of Reading campus who use Perl in their main product (and might be scouting for employees).

Drop a note to oliver at cpan dot org if you have any questions. Many thanks!

main_module = bin/fooapp
; btw, semicolon leads a comment, in case you forgot how to do that

Any Module::Install converts reading this should note the bin directory, not script.

In bin/fooapp itself you also provide an additional metadata hint (next to ABSTRACT):

# PODNAME: fooapp

Which results in nifty Metacpan links such as:

• https://metacpan.org/module/nfflowd

Finally this hint to the POD munger will allow a section to be pinned in place above the SYNOPSIS:

=begin :prelude

# POD here...

=end :prelude

I hope these tips are helpful to some…

Nothing was going to happen however before I could work out how to do one thing: achieve independence from DBIx::Class as a “storage engine”. I love DBIx::Class, but it would be much more cool to support any data storage system able to represent a table+column paradigm (even things like CSV, as a test case).

So SQL::Translator hit me like a thunderbolt. Of course, that’s exactly what it does - introspect some data storage and provide a neutral, class-based representation of the tables and columns (fields). It’s a little rough around the edges, but certainly good enough. The Translator provides a metadata structure which AutoCRUD’s web front-end can use, independent of any particular storage engine such as DBIx::Class. This also paves the way for development of display engines other than the bundled ExtJS and simple HTML offerings.

Right now there’s a developer release of AutoCRUD on CPAN, and I hope shortly to have a production release. Whilst the web side might not look much different, the fact is that it can now support significant features such as tables with composite/compound primary keys, or no primary keys for that matter, database views, relations to self, multiple relations to the same table, and so on.

Alongside that, I’ve taken the opportunity to fix a few quirks of the web interface, and chomp my way through the outstanding wishlist. The updated code is now running on a DotCloud instance, so please go and have a play!

• http://demo.autocrud.pl

p.s. a cron job will restore the demo’s databases at the top of every hour

• adds -TRIAL to the name of the distribution archive being produced
• sets release: testing in the META.json file which is parsed by CPAN services

It came to my attention that using -TRIAL is actually pretty bad for you and your system, and other users, even though it's one of the two naming conventions CPAN services use to identify developer releases.

The problem is that the actual $VERSION of your code is unaffected. This means once installed, you can't ask your computer the version of an installed distribution and work out from that whether it's a developer release, or not. A secondary issue is that in sites such as metacpan.org there's nothing really obvious about the release which highlights its status as "development", in the list of available versions.

An alternative way to signal to CPAN services that a dist is a trial release is to use an underscore and a secondary version number at the end of $VERSION, like _001. This is still a bit crappy but at least humans can really easily see what's going on.

Back to Dist::Zilla. If you use the AutoVersion plugin, a better alternative than using --trial is to set the DEV environment variable when you build or release the distribution. This has the effect of:

• (sprintf '_%03u', $ENV{DEV}) being added to the end of $VERSION
• sets release: testing in the META.json file which is parsed by CPAN services

Otherwise the best thing to do right now is to set the version manually, for developer releases. I hear from chatter on IRC that there are plans to change the --trial feature of Dist::Zilla to alter $VERSION if necessary (that is, if no underscore exists) - a good compromise, I reckon.

The App::local::lib::helper scripts make this really easy. As per the docs, I combine the helper with App::cpanminus (cpanm) for all installation.

To bootstrap a new local::lib area, I wrote this simple shell script:

#!/bin/bash
# script named "new-ll"

if [ -z $1 ]
  then
    echo 'pass the distribution name, please'
    exit
fi

echo "creating local::lib for $1 ..."
sleep 3

curl -L http://cpanmin.us/ | perl - --notest --quiet --local-lib \
    ~/perl5/$1 \
    App::cpanminus \
    Dist::Zilla \
    App::local::lib::helper

.
Entering the correct environment for a distribution uses another helper script:

#!/bin/bash
# script named "go"

if [ -z $1 ]
  then
    echo 'pass the distribution name, please'
    exit
fi

~/perl5/$1/bin/localenv bash

.
Which means my workflow for a new distribution is:

$ new-ll New-Dist-Name
$ go New-Dist-Name

.
Any Perl distributions installed in that shell (for example from dzil authordeps | cpanm or dzil listdeps | cpanm) will be placed into the new local::lib. It’s a simple ^D to exit.

However it’s not obvious that you’re within this special environment, so editing Bash’s $PS1 variable (the shell prompt) to include the following, can help:

echo $PERL5LIB | cut -d'/' -f5

.
My deep thanks to the authors of the distributions used to create this neat setup.

One option is to use Cygwin and just dive into there for everything. However I do want some of my code to work natively under Windows so there is still a need to run Perl tests at a Windows console. I might as well develop there too, if I can. I’ve ended up with the following steps, which are in places bodgy hacks, but show the principle works at least:

1. Git for Windows
2. Strawberry Perl
3. Vim fix
4. Windows Console
5. perldoc fix
6. local::lib
7. cpanm installer
8. Local CPAN mirror

First thing is to install Git for Windows, known as msysgit (don’t alter any of the Windows PATH settings at install time). It’s a great little system which ships with Bash, Vim, and a suite of other handy tools. On this platform you probably want to set the End Of Line character(s) to ensure consistency. I have the following in my ~/.gitconfig:

[core]
    editor = vim
    eol = lf
[color]
    ui = true

The bundled Perl in msysgit is a little ancient (5.8.8). Download and install the excellent Strawberry Perl distribution. Our goal is to have perl within the msysgit environment be Strawberry Perl’s perl. Move C:\Program Files\Git\bin\perl.exe out the way (to perl-g.exe) and copy C:\strawberry\perl\bin\perl.exe in its place (there are no symbolic links under Windows).

By changing the Perl though, you knacker parts of Git which use Perl (for example git commit --interactive). The way to fix this is to keep a copy of the original msysgit perl (as above) and then edit any of the scripts in C:\Program Files\Git\libexec\git-core to have #!/usr/bin/perl-g at the top. Here’s a list:

• git-add--interactive
• git-svn
• git-difftool
• git-relink
• git-send-email

The msysgit bundled Vim also needs some help, in the form of syntax files. I downloaded and installed GVim for Windows, and copied the .vim files from C:\Program Files\Vim\vim73\syntax to C:\Program Files\Git\share\vim\vim73\syntax but perhaps there’s a less brute-force way. At the least, you should get hold of perl.vim and pod.vim.

The Windows console program leaves a lot to be desired. I found a reasonable alternative in the form of Console2, an open source project hosted on Sourceforge. Download and install that (well, copy to Program Files). You’ll definitely want to edit its Settings so under Hotkeys, set Close tab and Rename tab to an alternative, or None (by doing Clear then Assign for each). Also under Settings in the Console section I set the Shell to be C:\Program Files\Git\bin\sh.exe --login -i and the Startup dir to be a folder I created in my user area for Perl development. Now, pinning the Console2 application to the Start Menu means it can be opened straight into msysgit’s Bash.

At the shell I installed my own vimrc file to ~/.vimrc, and created a ~/.bash_profile containing the following:

alias ll="ls -l --color"
alias view="vim -R"
export TERM=vt100

Strawberry Perl ships with many useful tools in its bin directory. Some of them are Windows batch files (.bat) because the expectatation is that you’re running Perl from the native Windows console. In this setup we’re within a Bash shell so they don’t work. One thing you’ll probably miss is perldoc, so create a ~/bin directory and in ~/bin/perldoc put the following:

#!/usr/bin/perl
require 5;
BEGIN { $^W = 1 if $ENV{'PERLDOCDEBUG'} }
use Pod::Perldoc;
exit( Pod::Perldoc->run() );

I always use a local::lib area for the modules used in my development, and Strawberry Perl ships with this module. Simply run the llw32helper program from the normal Windows console and it’ll ask you for the new local::lib location then set Registry entries appropriately. One reboot later and perl -V should include this new library path.

From Strawberry Perl’s CPAN shell (perl -MCPAN -e shell) I only install one module - App::cpanminus. This provides a new tool, cpanm, for installing modules. Note that since the previous local::lib setup, App::cpanminus is installed to that location rather than Strawberry Perl’s standard library path.

The final step is to have a local CPAN mirror. This means I can work on the Windows 7 laptop from a remote part of a Scottish Hebridean island, for instance, fully off-line. This uses the CPAN::Mini and CPAN::Mini::Webserver modules, both installed via the cpanm utility. The minicpan command line app will create the mirror for you. The minicpan_webserver app fires up an interface at http://localhost:2963/. Here are example commands used with this setup, which I’ve made into Bash aliases (also set your ~/.minicpanrc as per the docs):

minicpan -l /path/to/local/minicpan -r http://your.cpan.mirror.example.com/
cpanm --mirror file:///C:/path/to/local/minicpan --mirror-only -v Module::Name

A remaining niggle is that cursor keys don’t seem to work in less (Ctrl-N and Ctrl-K are alternatives). I’ve not yet found a fix for this; however they do work in Vim. Another issue I found is that, bizarrely, cpanm sometimes fails unless the -v option is provided. Also with cpanm it seems more successful at unpacking dist tarballs when treating the local platform as UNIX rather than WIN32 so I hacked the script to do that. I wish I were more capable on this platform to begin to debug this (please email me if you want to collaborate).

That’s pretty much where I’m at, right now. I’d welcome constructive feedback on this process in the comments (at blogs.perl.org if you’re reading a syndication). My deep thanks and respect to all the developers of the above tools and libraries, who have made this possible.

Dist::Zilla::PluginBundle::Author::OLIVER

Having Author PluginBundles is a great system for saving me time and allowing others to build my modules with ease. However I had to agree to Mike's point that polluting the Dist::Zilla::PluginBundle:: namespace wasn't so cool. It also makes things more clear in the dist.ini file:

[@Author::OLIVER]

If you have an Author PluginBundle, please consider moving it into this new namespace. You can of course keep the old one around, in parallel, until code using it has moved off to the backpan.

Dist::Zilla's MetaResources plugin allows you to set these links in the distribution config, but I wanted something a little more automagical. This can be done because I've set up my GitHub repositories with consistent naming and layout.

So my new plugin, Dist::Zilla::Plugin::MetaResourcesFromGit, is a drop-in replacement for the standard MetaResources plugin. It automatically generates four resource links based on the name of the distribution and the remote git repository settings. Simply use the plugin in your dist.ini file:

[MetaResourcesFromGit]

The default links are equivalent to:

homepage        = https://github.com/<account>/<repo>/wiki
bugtracker.web  = https://rt.cpan.org/Public/Dist/Display.html?Name=<dist-name>
repository.url  = git://github.com/<account>/<repo>.git
repository.web  = https://github.com/<account>/<repo>
repository.type = git

Any other resources provided to this Plugin are passed through to the MetaResources Plugin as-is. If you wish to override one of the above, some formatting codes are provided (described in the documentation) to assist. If you wish to suppress the appearance of one of the above resources, set an empty value.

If you want to know more about my Dist::Zilla and GitHub workflow, I discussed it in an earlier post on this blog. I wrote this plugin to assist me, and it's also shown how great the Moose-based Dist::Zilla architecture is for extending features.

The Plugin is GitHub centric at the moment, but I'd be happy to accept a patch to work with other cloud-based Git services (Gitorious, SourceForge, etc).

Like many, I want to host my code on GitHub and then periodically publish to CPAN. Dist::Zilla helps in both these by providing plugins to automatically push releases to GitHub, and then also upload to CPAN.

What bothers some is the stage at which these things happen, and also how the branches and tags are represented on GitHub. In particular, folks might want:

• a "clean" git branch which tracks CPAN releases
• another branch which is the "trunk" of development
• a user browsing the GitHub website to see the CPAN branch (with the README, etc)
• sane commit messages and tags

What I have configured is for the master branch on GitHub to be the one tracking CPAN releases. This makes it straightforward for most people to fork the distribution and tinker around without getting into trouble (i.e. they can build the dist).

My trunk of development takes place in a branch called devel, and that is from where I kick off Dist::Zilla builds and releases:

Tags are applied to the master branch automatically, with the version number which was uploaded to CPAN. So a user can again browse to GitHub, and when selecting a (version) tag they will see the CPAN dist at that version.

The commit message for the the master branch is also automatic, and contains the text of the latest section in the Changes file. Commit messages along my devel branch are of couse the everyday notes I make as I code. But following a Dist::Zilla driven release, one commit is done automatically on the devel branch to store the new header in the Changes file, and it gets the comment "Bumped changelog following rel. v%v".

Okay, this is all a bit abstract, so if you follow this link you can see the network graph for one of my modules. It clearly shows the two branches, how they are merged, and all commit messages.

I think this setup is really neat and tidy, and very intuitive for the visiting user who might not be familiar with Dist::Zilla. It's also almost completely automated so I really just stick to the devel branch and forget all about the rest.

Finally, let's look at a snippet from my dist.ini which drives it all. Note that the CommitBuild Plugin must come before the @Git Bundle:

[Git::CommitBuild]
branch =
release_branch = master
message = <contents of latest changelog entry>

[@Git]

commit_msg = Bumped changelog following rel. v%v

The CommitBuild Plugin is responsible for pushing the built distribution into a branch other than the one I've currently checked out. That is, I'm working in devel but the baked distribution is committed to master along with a nice comment, just at the same time as being uploaded to CPAN.

Okay, I have one confession. Getting the contents of the Changes file entry into that message variable does involve a wee hack, but you could equally just say something like "product of release %v" using the Git Plugin substitution variables.

I hope showing this has helped.

Some years ago I created the Net::Appliance::Session Perl module. It allows the user to automate interactions with CLI-based networked devices (think routers, switches) - a sort of Expect but with some helpful domain knowledge. The module has turned out to be quite popular (which is important to my story), in use by many organisations.

There is a shopping-list of problems with the code, though, which makes both bug-fixing and feature development really hard. I've been planning a rewrite for over a year, and finally completed most of that in the past few days.

The new version is completely different internally, but that shouldn't matter much. The problem comes in that I've engineered a new "phrasebook" system for the scripted CLI interactions, and also the programmers' API has changed. [Edit: I should add that lots of long-asked-for features are included, so the rewrite did bring benefits for the user.]

Now, I guess that if I release this as Net::Appliance::Session with a major version bump it could cause havoc some time down the line when an innocent upgrades their server and in comes the new package and some maintenance script fails. Perl doesn't make it easy to deal with this (nor do most operating systems, either, of course).

However I'm loathe to change the module's namespace. I like its name, and it feels like chasing my tail if I just rename a module to indicate an incompatible API change.

Alternatively I could write a BackCompat role, but for starters that's a lot of work (the old API was huge) and I worry that things like error handling simply work too differently in the new version to massage. Also, should that role be enabled by default or via a flag at use-time?

I'm not a professional programmer, nor a key part of some large projects like Catalyst, Moose, DBIx::Class which I'm sure have had to deal with such issues in the past. I don't really know the best course of action, and I also don't have much communication at all with my user base (using this module is a sysadmin-practice "smell" so many don't own up to it).

I need your help: please have a think and let me know in comments what you might do in this situation. Many thanks!

This moment cannot pass without thanking Andrew Payne and Peter Edwards for creating the ancestor to them both, CatalystX::ListFramework. I believe Peter had the thought to provide some kind of simple web access to database tables, and prodded Andrew into creating the ListFramework. Whilst out at a miltonkeynes.pm meet one evening, I discussed forking the code to make it more automagical and to allow the use of an AJAX UI which Peter had good reason for not wanting at the time. And so ::Builder was born.

I'm looking forward to the future of ::AutoCRUD. More time is available to me since I changed job recently, and there is a bunch of ideas waiting in the queue. If you have suggestions for AutoCRUD's wishlist, please do create a simple RT ticket against the module.

Once again sorry for the noise.