The BBC team I'm currently working on has a very, very slow test suite. On my box, it was generally taking about 2h10m to complete. Between Johan Lindström and myself, we've shaved half an hour from that. Johan used transactional savepoints for his part. This allowed us to roll back some database changes rather than rebuild the database tables. My part involved subtests and a very strange use of Test::Class.

I mentioned http://www.simile-widgets.org/timeline/ on #yapc IRC channel this morning, saying it would be nice to see all the old YAPCs as well as the new ones.

The wonderful Philippe Bruhat (BooK) then asked:

14:21 <@BooK> ranguard: http://www.yapceurope.org/events/timeline.html # is that what you had in mind?

How cool is that! - there really have been a few conferences - how many do you remember?

So, mst wrote up strictures which basically bundles the "Kensho" pragmas, so to speak: strict, warnings (FATAL!), no indirect (vpit++). It plans for clean separation of different versions so you can maintain compatibility using specific versions of the pragma. How nifty is that? That's right, very nifty!

I'm using Dist::Zilla with Dist::Zilla::Plugin::CriticTests and Dist::Zilla::Plugin::PkgVersion. These are plugins that add Perl::Critic tests to my distribution and add a $VERSION variable automatically when building, respectively.

Now two problems occur:
1. Perl::Critic doesn't know about strictures and basically thinks I don't have "strict" on.
2. Since I'm using PkgVersion, I don't have to put a $VERSION variable. PkgVersion puts one right below the package declaration. This means that some code is written before my strictures.

Both are very easy to fix.

For the first one, I just add this to ~/.perlcriticrc:

[TestingAndDebugging::RequireUseStrict]
equivalent_modules = strictures


Voila! Now Perl::Critic known that "strictures" is basically as good as "strict" for any testing purposes.

The second one is merely putting the strictures usage as the 1st line, before the package declaration:

use strictures 1;
package My::Kickass::Module;


Voici! Now strictures is added before the injected $VERSION variable PkgVersion adds.

• strictures
• indirect
• Dist::Zilla
• Dist::Zilla::Plugin::PkgVersion
• Dist::Zilla::Plugin::CriticTests
• Perl::Critic
• Task::Kensho

Graciously taken by Julian Cash Photography.

Ever wanted to do a quick diff on some perl code and see it colored like in in vim ?

Fortunately, the Kate editor has a good colorizer and Gabor Szabo ported it to Perl. We can join that up with Term::ANSIColor to create a filter program to colorize perl code snippets on the fly:

Day zero

I arrived in Pisa in the afternoon of the day before. After settling in my hotel it was soon time for the pre-conference meeting at a typical Italian piazza near my hotel. Fortunately for me the bunch of unfamiliar perl hackers were recognizable as such from a distance. I ended up meeting a lot of people, including some familiar names. It was also my introduction to drinkers.pm, the ad-hoc perl monger group assembling on evenings around Perl conferences ;-).

Day one

Because of deadlines, many programmers create Quick & Dirty
(Q&D) code rather than doing things The Right Way. This
leads to many problems.

• Deadlines cause bugs

When programmers write Q&D, they often ignore edge cases. This means the code reject things it should process and process things that is should reject.

• Deadlines cause delays

Because of the bugs, the code doesn't work when the deadline arrives and the deadline has to be extended.

• Deadlines undermine the confidence of the programmers

IBM sets its sales quote so that 80% of its sales force will meet them. When was the last time you heard of a manager setting the deadlines so that 80% of his programmers meet them? In fact, many managers set their deadlines so that their programmer can't possible meet them. They assume that this will make their programmers work harder. And it does. They work harder but are less productivity in their work. That's because repeats failures undermine their confidence which increases stress and reduces productivity.

• Deadlines undermines any sort of company spirit

I have been delaying my posts on the 2nd and 3rd day of YAPC::EU for quite a while. How can you sum up so many experiences, so many lessons, so many cool people and new friends?

If you thought that my post on the first day was long, just imagine a post that covers more than thrice the amount of stuff spanning across two whole days. I can't.

I will say that I've learned a lot about Perl, XS and technology in general, but I've learned the most about community and how important it is. For that I wish to thank the YAPC::EU organizers and everyone who helped organize, gave talks, commented on talks, wrote about it and attended.

Perl is my community.

Hi, I've had a long-standing interesting in having a nice way to browse through perl's memory space. Here's today's attempt. It almost works great except that the two introspection modules Devel::FindRef and Devel::Gladiator don't know enough to stay hands-off from each other.

For any gEdit users out there: A while ago I've written a perlTidy plugin for this editor.
It's written in Python. I know, I know. But it was either that or C...

For those of you interested, check it out at GitHub

This is a small list of stuff I learned at YAPC::EU 2010 in Pisa.

Since my last couple of posts, things have been done:

• Complete revamping of call logic
• Finished objects for basic C Types (int, double etc.)
• A fairly sound cast() function for Ctypes
• Array objects

Crap... when you list it like that, sounds pretty dire, don't it?

Don't beat me up just yet though. I'll definitely get Pointers done in the next 48 hours. Not sure how tricky Structs and Unions will be but they'll definitely be done by the deadline too. Anyway, instead of wasting more time worrying I want to talk a bit more about my favourite topic...

Type object API revisited

In a few days, I'll be giving a talk on roles at DevTank. The audience will be developers (and business people) from many different language backgrounds. I've tried assessing state of the art for roles/traits in other languages, but am falling short. I just don't know other languages/cultures well enough.

I might add that I was disappointed to learn that Scala's traits are just mixins. I wonder how they came up with that name. Surely it wasn't just misunderstanding Smalltalk traits?

Update: As preparation for the talk, I've written a short language-agnostic introduction to traits/roles. I put that on my personal blog instead of this one as I don't want people to see the blog URL and dismiss it as just a "Perl" thing.

This year's YAPC::EU in Pisa was nothing short of amazing. While I am not sure if it will outdo my experiences in 2008 and 2009, it was everything I've come to expect of YAPCs.

While the flight was delayed, the hotel room had air conditioning (that's a + compared to Lisbon... ) and we went for some nice food in a restaurant near the river.

On the first day we walked a couple of meters to get to the YAPC buses (seriously, what a great arrangement) and met osfameron and some other attendees. We were at the hotel in 10 minutes and I just remember meeting a lot of people and attending talks, of which the keynote talk was the most surreal.
By the time we went to the evening dinner I felt like I'd been there for a week already.

Yes, the title is provocative. That's my idea. Now that I captured your attention, let me explain what's going on. I have a project, Quiki, that is requiring Perl 5.10. This because I use the given/when construct.

Meanwhile we received a bug report from Adam Kennedy asking to back port the project to Perl 5.8.8 because there are some Linux distributions that still use it. Note, I am not against this request from Adam. I totally understand it, and I am willing to help, back porting Quiki. But this makes me think. If Perl 5.10 is dated from December 2007, and we can't use its features yet, when will we be able to use Perl 5.12 features, or the new planned Perl 5.14 features?

Probably this means that we, as Linux users, should heavily complain for old releases. I suspect Adam was using CentOS. Probably we should make all CentOS Perl users fill in bug reports, and foruns, complaining of the old version of Perl that is shipping.

My slides from my talk at YAPC::EU 2010, "ElasticSearch - You know, for search", are now available here:

http://clintongormley.github.com/ElasticSearch.pm/ElasticSearch_YAPC-EU_2010/

So last month saw the big announcement that we have now enabled CPAN Testers 2.0, and we have started to see a shift of testers over to the new HTTP submission system. However, there are still a number who are submitting high volumes that we shall now start pestering to move over. Although the regular testers are fairly easy to help setup their smokers to use the new system, it's the infrequent testers that are going to a little trickier to catch.

CPANdeps and cpXXXan will be down for a few hours from around 2015 UTC on Sun 29 2010 until the morning of Sun 30 2010. This is for a datacentre move.

Following on from a conversation at the Pisa-London.pm Social last night about vim syntax highlighting useful words in perl files like TODO and how it might also be useful to highlight other useful words, like HACK and BODGE, I decided to have a go.

I knew the initial solution would be fairly simple - hack /usr/share/vim/vim72/syntax/perl.vim.

That seemed to easy, so I investigated a $HOME/.vim/ solution.

Initially I copied the existing perl.vim into my local directory:

cp /usr/share/vim/vim72/syntax/perl.vim $HOME/.vim/syntax/

edited the perlTodo line to include the new tokens.

I opened my test file and it worked!

Going Further

I’ve had a long-standing urge to handle tokens followed by an evil colon. I prefer:

# TODO: something shiny

over

# TODO something shiny

To me it looks nicer when it isn’t highlighted.