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.

While working on the database abstraction layer for one of my toy projects, I came to a sudden realization. Why bother? I know SQL. I think in SQL. I thoroughly enjoy the relational model and DBI does pretty much everything I need. I can tie myself to one database system, since it's just a toy project. Sure, there are some repetitive bits that I don't want to repeat all throughout the codebase, but I can abstract those away once and for all. It sounds like an enormous reduction of friction. Am I missing something?

• The Perl6 in the real world talk, by Moritz Lenz had, at much, two or three slides or Perl. These 20 minutes reminded me of physics classes. Not much detail was given to the module internals.The presentation ended up with a good question from the audience: why Perl 6? with the answer, "because I like it", and because of the Perl 6 introspection mechanisms needed to calculate the dependencies. After talking in IRC with Moritz he shown me the abstract of his talk, which made me rewrite this entry. If I wasn't lazy and I've read the talk abstract, I might chose another track, or at least, do not complain so much.
• Lech Baczynski shown some common error on Perl programming, like precedence problems. While not an excellent presentation, as most of the errors where too basic, it helped Perl programmers to remind some of the details on Perl parsing, operators and functions.
• While present at 'Searching Perl Workloads‎' talk, I was distracted with some code in my laptop. Therefore, no comments. Sorry.
• Finally, on the Lightning Talks, second session, I would like to stress Andrew Shitov talk on There Is More Than Way To Empty It (an array) that was very cool.

jared recently took considered - if mischievous - aim at the Modern Perl crusade:

http://curiousprogrammer.wordpress.com/2010/07/29/does-your-perl-suck-if-you-dont-use-moose

A recent post from chromatic was the inspiration:

http://www.modernperlbooks.com/mt/2010/07/a-checklist-for-writing-maintainable-perl.html

I'd go further.

No amount of automation, source control, testing, Moose or peer consensus will help unless you understand the problem at hand. And the pure fact is your understanding will change the more you work on the problem. Worrying about maintainability will widen your concept of your problem and make it more difficult to solve. Perhaps this is justified (what little empirical evidence there is suggests that re-usable code takes 3x as long to develop as code that is not consciously designed to be re-usable - see "Facts And Fallacies of Software Engineering" by Robert Glass) but even if it is exactly what can you assume about the future needs and skills of any others who pick your code up?