blogs.perl.org

At the risk of starting a massive flame war, I have only one question: what are the pros and cons of releasing Perl 5.20.0 as Perl 7.0.0?

If you are in the area on March 22 and need another reason to come to Swiss Perl Workshop 1, here it is...

Ladies and gentlemen, we are very pleased to announce that Damian Conway will be attending our first workshop in Switzerland as a speaker, participant, and godfather!

Damian is well known for his talks, his modules (I am happy not to have run this post through Acme::Bleach), and he was also the winner of last year's YAPC::EU "The Speaker I Missed Most" contest.

Damian will be giving two talks during the day, only one of which (he promises) will be brain-meltingly weird.

You can sign up for SPW1 here.

I'm delighted to announce that, once again, I'll be teaching in Zurich...next month. My good friends at Oetiker+Partner and the amazing team at Eidgenössische Technische Hochschule Zürich ("ETHZ" to its friends) have organized four days of Perl and presentation skills training, to be held on March 18-21 (just before SPW1).

I love teaching in Zurich. I enjoy the city itself, of course, but the real attractions are the remarkable people who come along to the classes there. They're invariably smart, motivated, humorous, practical, and challenging: a joy to teach.

For that reason alone, over the past few years almost every new class I have created has debuted in Zurich. And this year is no different...

In the past few days Paul Venezia has written a pair of articles for InfoWorld repeating the familiar poorly supported "Perl is dead" nonsense. The articles can be found here (I'm not going to link to them, as I don't want to drive traffic to poor reporting):

• http://www.infoworld.com/d/data-center/perl-isnt-going-anywhere-better-or-worse-211580
• http://www.infoworld.com/d/data-center/making-the-case-perl-212077

I decided to write up my response here, as it got a bit long for a comment on their site. Consider it an open letter to people writing about Perl based on poor research or outdated information.

Mr. Venezia,

I'm not surprised that you received some responses that disagreed with your article, nor that some of them were a bit blunt with their disagreement. I know I personally considered responding, although I eventually decided it wasn't worth my time.

Here is the official Call for Participation:

From March 13th to 15th the 15th German Perl Workshop will take place at the Betahaus in Berlin.

I’ve converted a number of distributions from $something to Dist::Zilla for release management, and every time I forget something … so this time I’m making notes as I go along.

Worst case, future-me will thank present-me (or will that be past-me?)

What follows is the transition for WebService::NotifyMyAndroid. It might have a couple of places where common sense needs to be applied, but it’s ‘good enough’.

Prerequisites

I’m assuming you’ve already got a perl distribution and that you’re managing it with git.

I’m also asssuming you already have Dist::Zilla installed.

Custom dist.ini

My distributions are minted using this file as a template for dist.ini.

Let’s Go!

Just to be safe we’ll work from anew branch based on our current master:

git checkout master
git pull --rebase
git co -b dzil master

Now we’re ready to rock and roll!

Create our dist.ini

Looking forward to Dave's PerlSchool on Saturday. I was satisfied with the format of his Moose school and found myself going back through the notes for how to set a default hashref for an attribute. Got me thinking of how I could really use a cheat sheet. There's a lot of documentation for Moose, certainly enough to get you started, but it saves time if somebody sits down and organizes the information into a flowing story with just enough examples to suggest some use cases. At the other extreme, when I wanted a quick answer to a simple question, sifting through 15 perldoc pages or 165 slides was less satisfying. I've got an idea for an A4 cheatsheet with every possible option which I've started in a GoogleDoc. When it's half-decent, I'll post for comment.

I've been invited to speak at QCon London next month. I'll be giving two keynotes: my infamous Fun With Dead Languages talk plus a one-hour mini-tutorial entitled Instantly Better Presentations. I'll also be offering the full one-day version of that second talk as a tutorial earlier in the same week.

QCon is an incredibly eclectic conference with a strong real-world focus. The presentations in this year's schedule discuss development in C++, Erlang, Groovy, Grails, HTML5, Java, JavaScript, MongoDB , NoSQL, Scala, and Perl (guess who), ranging over a vast range of topics including: agile development, cloud computing, startups, distributed Systems, REST design, mobile computing (iOS and Android), open data, system architecture, test-driven development, general problem-solving techniques, functional reactive programming, hiring skills, the Pi platform, and programming in Latin (guess who, again).

(I originally wrote this in a post to qa@perl.org, and I apologise for the profanity in the title, but I felt it is needed in this case.)

So why am I writing this? I used to feel guilty about not being conscious of the distinction between the various scopes of tests, like unit tests vs. integration tests vs. system tests vs. functional tests etc. when I wrote the tests. I just noticed that I need a test here (as a regression test for a bug, or to TDD (= test-driven develop a new feature, or after implementing a new feature, etc.), and wrote it using Test::More or whatever. However, now I feel that trying to philosophise about the distinction between all those is not so useful for the people who are actually trying to write the tests.

Tests are good, mmkay? Just freaking write them!

chromatic has expressed some sentiments against the so-called "Behaviour Driven Development" (BDD) Domain-specific-languages (DSLs) such as cucumber.

This week's post by Viacheslav Tykhanovskyi:
showmetheco.de/articles/2013/2/yapc-europe-2013-week-minus-27-current-progress.html.

A little while back I wrote a pair of applications that used Path::Class::Rule to do the file finding. I selected this module because I like the interface for building up rules. I started to run into speed issues as the source directory grew larger and larger. Along comes rjbs's the speed of Perl file finders article and his speed chart backs up my findings that more files equals a marked increase in time.

This is where I found out about Path::Iterator::Rule which was just released by David Golden. It works the same as Path::Class::Rule but returns strings instead of objects, which gives a massive performance boost. Path::Iterator::Rule is a drop in replacement for Path::Class::Rule so updating my programs required very minor changes.

With Path::Class::Rule my application took an average of 66 seconds per run. Now the Path::Iterator::Rule version only takes 5 seconds with the same input. A full minute saved on each run, it feels good.

I am reminded of a quote from Brad Frost's article Performance As Design in which he states "Good performance is good design" and while the article context is web development, I think it applies to any kind of application.

Hi
I am a biologist not a bioinformatician, I have two group of sequences (they are nucleotide and in fasta format), each group includes around 40,000 sequences ranging from 100 bp to 12 kb. I want to know how can I align the sequences from a group to the another and find the best pair for each fragment. Can I do it through Perl? if so how can I do that? is there any softwares that can I use?
second Q
how can I find secondary structures of the sequences in each groups? which program should I use?
Thanks
MS

Prologue

So, once upon a time I had a crazy idea: to put an almost complete resource meter into the tmux status bar. You know, the clock is so boring. Let's add a battery indicator there. And the load numbers. And the memory usage...

Needless to say, this resulted in an unbearable user experience:

a:2.96G c:4.37G f:5.41G i:2.98G l:0.65/1.73/1.41 23:47

Actually, the data is OK, the "gauges" work fine on every Unix I tested them. If only it was a bit fancier...

Puke rainbows!

Then I discovered Battery. And then, Spark. I just couldn't resist myself, so I revamped my messy Perl usage data parser to output this gorgeous ANSI art scrolling chart:

It was tested on Mac OS X 10.8.2, Ubuntu 12.04, Ubuntu 11.10, Debian 6.0.6 and works fine with the default system Perl; there are no external dependencies at all.

Liked it? Go ahead, grab your copy and follow the installation instructions: https://github.com/creaktive/rainbarf

Hello Perl bloggers,

I have released my first module: POE::Component::IRC::Plugin::Vim::Tips, a plugin for the IRC client module POE::Component::IRC.

When a user types !vimtip (or !vimtips) in a channel that your bot has joined, my plugin will scrape the first page of tweets from the Vim Tips Twitter feed and reply back with a "random" tip from that list.

Example:

curtis !vimtip
vimbot curtis: ggguG will lower case the entire file (also known as the Jerry Yang treatment). http://is.gd/4xZW

A lesson learned from v0.01: Don't forget to list dependencies in Makefile.PL!

Links:
CPAN
Github

I finally stopped to think about how I’m numbering my developer releases for various modules I have floating around.

Two theories

Until recently I’ve always thought:

v0.0.5_1 is the first developer release leading up to v0.0.5

Something (sorry, I can’t remember what exactly) I read recently got me thinking about this and I started to think that maybe I’d got myself tied up into knots.

I started to wonder if the correct interpretation was actually:

v0.0.5_1 is the first developer release AFTER v0.0.5; working towards v0.0.6

I’m sure this is blindingly obvious to some people, but it was something I’d never stopped to properly thing about.

Investigation

After writing a quick script I came up with the following output:

I have previously written about Test::Class + Moose, but now it's on the CPAN. I've added a few things to the initial version:

• Add class/method skipping.
• Rename almost every overrideable method to /^test_/.
• Add a time reporting class. You can now fetch real, user and system time for each class or test method.
• Make sure we have hi-res time reporting
• Move statistics gathering into its own classes
• Add include/exclude test method filtering
• Skip a test class if we don't find any test methods
• Most attributes pushed into Test::Class::Moose::Config
• Added "randomize" attribute per Udo Oji.

Let me know your thoughts or if there's anything else you think it needs.

Dear YAPC::Europe attendees and those who is still considering attending it,

First of all, let me inform you that we are looking for volunteers who will lead the Partner programme. I hope that in a few weeks we will be able to announce the programme or its absence.

Then, a couple of days ago, R Geoffrey Avery, YAPC's permanent Lightning Talks organiser, opened submissions of lightning talks. There will be three lightning talk sessions, one at the end of each conference day. The three sessions of 60 minutes will include ten five-minute talks and short announces in-between.

To submit a lightning talk, please use our online submission form.

If you'd like to know more about what lightning talks are, please read the detailed description available on the site.

Just to list a few ideas for talks of that kind, here's a quote:

One of the things that brian d foy worked pretty hard on for Perldoc inside of 5.16 was better UTF-8 support. We found that there are a huge number of variables for getting good Unicode support out of the "man" formatting pipeline. perldoc internally uses the "podulators" distribution to turn POD markup into man pages, HTML, XML, etc. But with the "man" formatting, the pipeline of operations looks something like this:

perldoc (a tiny little wrapper around the Pod::Perldoc module) finds the appropriate pod markup (either embedded in a .pm or a .pod), passes it to Pod::Man, takes the output from Pod::Man and then invokes the "nroff" implementation (which is usually groff) and sends it to your pager (less, more, etc) where it's displayed on your screen.

That's a lot of places where UTF-8 can go sideways. And it usually does.

I’m always forgetting what pieces I need to make this happen, so I’m writing a note to my future self.

Ubuntu Packages

Install:

• libncurses-dev
• libreadline-dev

Perl Packages

Install:

• Term::ReadLine::Gnu

Save a little time with puppet

Include these somewhere and run a puppet update

class libncurses-dev {
    package { libncurses-dev: ensure => latest }
}

class libreadline-dev {
    package { libreadline-dev: ensure => latest }
}

Save the history to a file

Add this to ~/.perldb

&parse_options("HistFile=$ENV{HOME}/.perldb.hist");

After a busy Christmas season and being engrossed in my upcoming thesis defense I have found it hard to find too much time to focus on Perl projects. Still Alien::Base has been on my mind, and happily it has been on the minds of others too!

In this report I want to focus first on the high points. Far and away my high point has been that in my apparent absence others have taken up the mantle. I have gotten bug reports and pull requests from preaction, giatorta, amannb, mokko, tobyink and as always productive conversations with David Mertens. It helps in a tough project like this has been to see the excitement of other developers, waiting for me to finish this project.

Several bugs have been fixed, others have been identified. I hope to have another dev release out soon. Further I plan to release a version of Alien::GSL which depends on Alien::Base to CPAN not long after that.