blogs.perl.org

Greetings!

On April 20, 2013 we'll be having another DC-Baltimore Perl Workshop! Like last year, this will be a 1-day, 2-track conference celebrating all things Perl! The venue is very close to the train station in Baltimore, so it should be pretty easy to get to.

Now is your chance to submit a talk -- we're looking for either something you think is fun or interesting or useful for our main track, and tutorials for our second track. If you're looking to get some experience giving a tech talk this is a great way to do it... and for the tutorials we have some existing talks that you can build off of (or use verbatim).

You are of course invited to sign up as an attendee as well :) . And if you have any contacts who might want to be a sponsor (good advertising, helps a good cause) feel free to have them email sponsors@dcbpw.org for more info.

Come one come all! http://dcbpw.org/

Recently Ovid broached the topic of allowing a future release of Perl 5 with a version number greater than 6; this is not a new argument. He further explicated the problems:

I just got back from FOSDEM and heard, again, for the umpteenth time, that since Perl had 4 “major” releases (1,2,3,4) in its first few years and hasn’t had a major release since Perl 5 about 20 years ago, it’s clearly “dead”. I hear this every time I go to a conference that’s not dedicated to Perl.

…

Meanwhile, in the minds of, of, virtually every developer on the planet who’s not in our echo chamber, Perl 6 is, logically, the successor to Perl 5. Since even Duke Nukem Forever managed to get released prior to Perl 6, Perl 6 just isn’t being taken too seriously be many devs. In other words, they think Perl 5 is dying and its successor is DOA.

I agree with him. As I commented:

We're glad to announce another sponsor for the German Perl Workshop 2013 in Berlin:
think project!

Thanks!

Company description in German:

Die internetbasierte Projektplattform think project! wird in 40 Ländern
von namhaften Bauherren, Projektentwicklern, Projektsteuerern, Bauunternehmen sowie
Architektur- und Ingenieurbüros eingesetzt – bis heute in über 5.000 Projekten mit mehr
als 90.000 Benutzern. think project! vereinfacht die Zusammenarbeit in Projekten, sorgt
für eine lückenlose Dokumentation und kann direkt über das Internet genutzt werden.

think project! unterstützt ein effizientes Projekt-, Informations- und
Risikomanagement und hilft so, Zeit und Kosten zu sparen.

think project! setzt bereits von der ersten Softwareversion an auf Perl.
In mehr als 14 Jahren wurde diese Entscheidung immer wieder bestätigt, da Perl und CPAN
für die gestellten Anforderungen immer die geeigneten
Lösungen bieten.

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: