blogs.perl.org

There's DBI_TRACE, but sometimes I just want to see the queries that are used in $dbh->prepare(). Here is a simple dip script to do that.

dip -e 'before { warn ARGS(1) } call qr/DBI::.*::prepare/' foo.pl

We have changed the domain for YAPC::NA 2012. It was yapc2012.us. It is now yapcna.org. The reason for this change is that we want to start a tradition of handing down resources from one YAPC::NA to another so that each new conference organizer need not start from scratch. So after YAPC::NA 2012, we will hand over this domain and a bunch of other resources to the YAPC::NA 2013 organizer, and they will hand it down to 2014 and so on.

Therefore we have a bunch of new links for you:

Blog: http://blog.yapcna.org

Twitter: http://twitter.com/#!/yapcna

RSS: http://feeds.feedburner.com/yapcna?format=xml

Facebook: http://www.facebook.com/pages/YAPCNA/222065877826581

June proved to be an eventful month for CPAN Testers. We had several updates and passed a couple of significant milestones.

Firstly, the updates. As well as the blog and wiki updates earlier in the month, David Golden also released a new version of CPAN-Reporter. This release is notable for two reasons. It now defaults to using the Metabase, rather than the email transport method of old, and also attempts to automated as much of the Metabase ID creation as possible. In order to encourage new testers, simplifying the setup process is a must. David made significant changes to CPAN.pm regards auto-configuration, and he's incorporated the same ideas into CPAN-Reporter. Ultimately we'd like to see a common client, which uses the APIs of CPAN-Reporter and CPANPLUS-YACSmoke, and can abstract away much of the configuration and processing of smoke testing. The aim being to encourage more casual testers to send us reports from the real world, as distributions are installed or upgraded.

I've just recently released my first Perl-related screencast, Fun with clouds.

It details how to install and build your first Mojolicious web application. I'd like to create more, just let me know what Mojolicious-related topics you would like to hear about on http://mojocasts.com. The more feedback I get, the more I'll release.

Mojocast #1 Fun with clouds! from glen hinkle on Vimeo.

Enjoy!

Hm, seems that ironman is not picking up my new, selfhosted (and selfpowered) blog, so this here is just a short ad for my post there:

http://domm.plix.at/perl/dancer_and_postgres_on_dotcloud.html

Announcing ElasticSearch::SearchBuilder

In Perl, we like to put important things first, so the ElasticSearch query language has always felt a bit wrong to me. For instance, to find docs where the content field contains the text keywords:

    # op        field       value
    { text => { content => 'keywords' } }

To me, the important part of this is the field that we’re operating on, so this feels more natural:

    # field        op       value
    { content => { text => 'keywords' }}

So, in the spirit of SQL::Abstract I am proud to announce ElasticSearch::SearchBuilder, which is tightly integrated into the latest ElasticSearch.pm version 0.38.

Any method which takes a query or filter param (eg search() now also accepts a queryb or filterb parameter instead, whose value will be parsed via SearchBuilder:

Do a full text search of the _all field for 'my keywords':

    $es->search( queryb=> 'my keywords' );

Find docs whose title field contains the text apple but not orange, whose status field contains the value active:

$es->search(
    queryb => {
        title => {
            '='  => 'apple',
            '!=' => 'orange'
        },
        -filter => {
            status => 'active'
        }
    }
)

I'm tired hearing from people that perl is dead or slow.

But basically they are right. If you check out a popular language comparison,
perl is almost on the last ranks, if listed at all. Behind python, php and ruby. And we all
know that at least ruby is slower than perl.

Partially because those perl scripts are pretty lame, not optimized as the comparable scripts. And partially because perl is slower than C or LISP.

I started improving some of the slowest scripts which give us a bad reputation.
E.g. I optimized fasta from 7 sec to 2.3 sec
without any algorithmic improvement. Maybe others want to help out also.

Worthwhile targets are fasta, binary-trees.

As I found out adjusting the algo helps much more.
The official tracker contains a version which is 20x faster than fasta.perl by using pythons algo and is therefore 2x faster than python3. This is the range we are used to.

And I'm also working on the compiled perlcc versions with several optimizations.

And I'll try out the new ideas which I talked at YAPC::NA about. So far my typed perlcc versions are slower, because I copy forth and back too many lexicals. Needs more optimization improvements.

Task::Dancer is just a collection of everything-Dancer. It was started by Sawyer X, and now I'm helping maintaining it.

Being a collection of all modules (plugins, mostly) for Dancer, it is a good way to show external progress in the framework (the internal progress was blogged a few days ago).

This new release includes:

• Dancer::Plugin::Bcrypt, a simple interface to the bcrypt method,
• Dancer::Plugin::XML::RSS, an interface to parsing and generating RSS files,
• Dancer::Session::MongoDB, a session back-end using MongoDB,
• Dancer::Template::TemplateFlute, a wrapper to Template::Flute,
• Dancer::Logger::ColorConsole, is a logger back-end, mostly for debugging purposes, that colorizes the log accordingly with user-defined rules,
• Dancer::Plugin::Mongo is not a new module, but was disabled on last version, because MongoDB module was failing to install. It is a simple wrapper to MongoDB.

In our work project, there are lots of Test::Class-based modules, and they live in lib/ so other distributions can use them. Anyway, when writing a new module of tests, I don't start from an empty file but rather copy one of the existing test modules.

So I have to change the package name, but I've long felt that this can be automated - after all, if the module file is lib/Foo/Bar.pm, vim should be able to deduce that this is package Foo::Bar and change the package name accordingly.

The script below does that; it makes a few assumptions: that your modules live in a lib/ directory; that the package line already exists (but presumably with the wrong name) and that the package name to be replaced is in the first line that starts with 'package', followed by the name.

It's simple enough so you can adapt it to your needs. I hope you find this useful!

This article is about the tension between writing code and owning code.

We all know about working for some organization (hereafter 'org'), which
ends up owning our code. I think the tension arises because we pour some
of our heart into each program, especially those we feel are well-written.

But we're uneasy with the fact that the resultant code isn't ours.

So, how do we reconcile this tension?

I thought about this for years, until one day I had an insight which I
feel resolved this issue for me.

The first step is to take your focus off the program you're currently writing,
and look at your history. Almost certainly there will have been a series
of such programs, written for a variety of orgs.

Now, stop thinking of them as programs, and imagine they are a series of
poems, paintings, sculptures, magazine articles. See the similarity?

The next step is to see that a series of creations, poems or programs etc,
are simultaneously all similar and yet all unique.

Guy Steele is interviewing John McCarthy:
http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy

Experimentation is good? Do you think there is anything peculiar or special about the design of Lisp that encouraged that experimentation or made it easier?

Sure, there was no boss. I never attempted to be the boss. If we take Fortran or IPL, each of them had a boss - APL had a boss.

Nowadays Python has a boss, Guido van Rossum, and C# has a boss - there is Heilsberg - and James Gosling - he doesn't try to act as a boss to Java anymore but he is still considered a kind of boss.

If Lisp has any boss, it's you! You wrote the reference manual.

I've been trying to disclaim that boss ever since, perhaps instinctively following your example or just because I don't want to be a boss - I'm not sure. It's interesting that during the last 10 -15 years I think there has been a kind of a cult of bosses in programming languages and what you say, that may be a bad idea for the development of the language.

My first post on here, hope it's well received!

In light of recent database hacks (MtGox, Sony, etc) - How to safely store passwords is at the front of every developers mind.

Almost every dev knows that storing plaintext passwords is a bad idea, but most don't realise that storing a SHA hash should also be considered a bad idea.

The SHA + salt pattern has been widely adopted, however modern hardware can brute force such hashes in a reasonable time using CUDA. In the near future it's not inconceivable that arbitrary hashes could be brute forced in seconds.

Bcrypt solves the problem of hardware increasing in power, rendering your chosen hashing function obsolete. I suggest reading How To Safely Store A Password, by Coda Hale for the hairy details.

To use bcrypt in perl, you can use Crypt::Eksblowfish::Bcrypt.

To help people follow these best practices, I have wrote a Dancer plugin that simplifies created and verifying bcrypt hashes. Dancer::Plugin::Bcrypt. Any feedback is welcome :)

Someone sent me a bug report for the CP5.8.8AN mirror, where his CPAN client was failing to resolve a module dependency, despite that module having passed its tests on perl 5.8.8.

The culprit was the rather badly named "common::sense", which, if you look at the distribution is a bit odd. Notice that there is no .pm file anywhere in it! Instead there's a .pm.PL file, which ExtUtils::MakeMaker runs when you 'make' the distribution. Yuck.

I've patched CPAN::ParseDistribution to understand these files, and most of the mirrors should update overnight. Those with date-stamps in their names will take longer.

In the last few days I've been introducing my CUDA bindings for Perl that I've put on github called CUDA::Minimal. CUDA is a framework for writing and running massively parallel code on the highly parallel computing architecture that is your video card (assuming your card is capable of CUDA in the first place). Today I am going to discuss error handling in CUDA.

Error handling is a boring topic, but it's important, so I'm going to motivate it a bit. Consider this statement from version 4.0 of the CUDA C Best Practices Guide (which you can find here):

Code samples throughout the guide omit error checking for conciseness. Production code should, however, systematically check the error code returned by each API call...

In CUDA::Minimal, you don't have to sacrifice conciseness for error-checking...

After attending YAPC::NA at asheville I got an email for the YAPC feedback survey. I filled it yesterday and later thought of something that could be tried but am not sure if it's a good idea so here is a brain dump :-).

The idea is to combine social as well as technology aspect together to make it fun for the participants as well as being a learning experience since you actually get to try out something .
Lets say there are 200 attendees.
Reserve a 50 minute (or less) slot for this in the main hall

- Specify a task (or many tasks like an exercise in Modern Perl, Moose , Plack, Event Driven, MVC framework ... )

-100 people are designated places and they have the pre-requisites (modules ? ) installed on their laptops

- The other 100 people join the people and pair program or one works while the other watches , discuss for 10 minutes or argue over why their ide is better

In August 2011 Damian Conway will spend a few days in Zurich teaching Perl courses.

Oetiker+Partner is organizing the courses together with the IT services of ETH Zurich. Courses are held in the area of the ETH main building (ETH Zentrum), the exact locations will be announced later. The courses will be taught in English.

We have setup a webpage giving all the details on the courses.

In my spare week before YAPC::EU, I am making a return visit to one of my favourite cities in Europe: to Lisbon.

José Castro is a good friend. As soon as he heard I had a some extra time this year, he wrote and invited me to come and visit Lisbon.pm. And who could resist the beautiful weather and city and people of the Portuguese capital? So I am delighted to have the opportunity to catch up with many friends and acquaintances in Lisbon this summer.

I'll be giving a free public talk to the local Mongers (and, we hope, to the wider Open Source community) on the evening of Monday 8 August. We are still working out exactly which talk that will be, but the details will be announced soon on the Lisbon.pm blog as well as in other local news channels.

With respect for perl jobs, here are a few things that have struck me as odd, and I’m curious if I’m the only one who seems to experience it:

I’ve seen the following both recently and in years past; it never seems to change.

Erez Schatz has proposed that each released version of Perl be referred to as a code name.

Besides the fact that "Erez Schatz" is a cool name by itself, I think he's on to something.

Since it's clear that the Perl6 moniker is going to remain, and most folks are too curmudgeonly to change the name of Perl5, this seems like a good compromise. It allows for a clear marketing difference for each release - one that obviously works elsewhere in the tech industry.

• Perl 5.8 Zombie (because it never dies, haunting us until the end of days)
• Perl 5.10 Onion
• Perl 5.12 Camel
• Perl 5.14 Llama
• Perl 5.16 Butterfly

(You know Sebastian's going to jump at the chance to design a nifty logo for each one)

Peter Shangov's idea is also worth pursuing - a Perl distribution with all the modern toolkits included. Given the recent logo activity, it should be called Raptor. It would be easy enough to start referring to "Raptor", just as "Rails" is a rallying cry for the Ruby folk. It could be downloadable from http://raptor.perl.org, of course - possibly even installable via perlbrew:

$ perlbrew install raptor

Here's what happened.
A few weeks ago, the Mozilla Foundation have pulled a Microsoft by releasing what is essentially Firefox 4.0.1 as Firefox 5. This had the added benefits of getting some corporate IT guys to throw their hands in the air and shout that they cannot migrate to Firefox 4 now that it reached it's so called End of Life,

This would've been glazed over as yet another evidence that corporate IT is brain-dead, if it wasn't for the idea that the Perl community need to win over corporate IT to become the key player it once was.
Sadly, catering to one's insanity can only cause even more insanity.
And so, trying to find logic in the madness has brought forth the irrational thinking that "all we need to do is drop the 5 and 6 from Perl 5 and 6".

Now, this might be the silver bullet, it's so crazy it might work. But you don't have to actually do anything.