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.

My profound thanks to everyone who invited me to visit them during my spare week in Europe. After much discussion and contemplation I have accepted two invitations for the week. The first of them is to visit Oslo.pm

Salve Nilsen wrote to me as soon as I announced I was available, and reminded me that Oslo.pm has already invited me several times to visit them. They have waited patiently for several years now, so the week before YAPC::EU seems like the perfect time to accept their long-standing invitation.

So I'm going to be in Oslo on August 11 and 12. We'll be offering a free
public talk on the evening of Thursday August 11, the details of which will be announced soon on the Oslo.pm website.

We'll also be running two 1-day classes on August 11 and 12 at Redpil Linpro, with some of the proceeds going directly to help fund the activities of Oslo.pm.

I'm very much looking forward to my first visit to Norway.
Jeg håper å treffe deg der!

How do you decide to move to another version of Perl? Some people use the latest version right away, some people make big jumps once a decade. Some never upgrade. What's your style?

I made a SurveyMonkey page for it: http://www.surveymonkey.com/s/DX5HW95.

Pass it around, tweet it, facebook it, buzz it, bump it, do whatever you crazy social kids do. Retweet it.

You don't have to justify anything. I don't really mind if you are using an older perl and I'm not going to tell you that you are wrong. There's room to explain yourself if you feel the need. Or, if you have a good restaurant recommendation, let me know about that too.

So, I got an invite to Google+ so I logged in and had a look around. I do like the rotary phone style addition of people to a “Circle”. Overall, it has the normal Googlely look and feel, which I like. However, there are problems, mostly due to lack of integration with the rest of Google. It is as if the team had no clue about any of the other piecemeal attempts at social networking that Google has tried.

Yesterday I announced the release of my Perl-accessible bindings for CUDA. CUDA is marketed as a massively parallel, high-performance computing architecture. When you think about Perl and high-performance computing, I would hope that PDL, the Perl Data Language, comes to mind. :-)

PDL is a CPAN distribution that gives Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing. Today I will discuss how CUDA::Minimal and PDL talk with each other. (In case you're curious, tomorrow I discuss error handling in CUDA::Minimal.)

domm writes:

The Perl 5 Core Maintenance Fund aims to raise $25.000 to to pay for Nicholas Clark and Dave Mitchell to work for 3 months on the Perl 5 core, fixing bugs and making other improvements.

Vienna.pm decided to set aside $10.000 as "match funding" - ie for every $1 that someone else donates, Vienna.pm donate $1, until $10,000 + $10,000 is raised, and only 20% remains to reach the target. The hope is that "match funding" will encourage people to donate a bit more themselves than a simple unconditional donation.

Dancer is moving (or dancing?). There are some news (some more relevant than others) that I would like to share here.

First some less relevant, but nevertheless useful features. Starting from 1.3060 you can access parameters values using a similar syntax with CGI:

   get "/foo" => sub {  my $name = param("name"); };

Not a killer feature, but handy. Also useful, there is an accessor for cookies:

   get "/bar" => sub {  my $cookie_value = cookie "cookie_name";  };

The location and name of the log file can be defined in the configuration file, or directly on your code. Use variables log_dir and log_file for that:

   set log_dir => "/var/log/dancer/", log_file => "app1.log";

You might also notice that set can set multiple variables at once.

Hi Folks

Check out the demos for GraphViz2 V 1.06 and Graph::Easy::Marpa V 0.90.

It's official, MadMongers has won the bid to host YAPC::NA 2012 if Madison, WI. I wanted to share a few quick links with you:

The official blog of YAPC 2012.

The official RSS feed of YAPC 2012.

The official Facebook page of YAPC 2012.

The official Twitter feed of YAPC 2012.

I like DTrace and wanted to have at least part of its power for Perl progams, beyond the DTrace probes already provided by perl. So I used Aspects to create dip.pm. Allow me to quote from the manpage:

Since my first blog post back in December I've written and made thorough use of a simple Perl interface for CUDA. Today, I've posted it on github, and in this post I'll give a relatively simple example of how to use CUDA with Perl via Inline::C. (In case you're wondering, CUDA is a technology provided by nVidia that lets you compile and execute highly parallel code on your CUDA-capable video card.)

First, of course, you'll need to install ExtUtils::nvcc. At the moment this only works with Linux (maybe with Mac OSX, definitely not yet with Windows). It has only been confirmed with Ubuntu. See directions on the ExtUtils::nvcc wiki. (If you manage to install it on other systems, please let me know and edit the wiki or send me your notes!) If you have that installed, installing CUDA::Minimal is just a simple CPAN install.

First Script

So, at this point I will assume you've installed CUDA::Minimal. What can you do with it? Here's a simple example:

(For those people who don't know about it yet - ubic is a flexible, powerful, extensible perl-based service manager. Something like upstart or daemontools, but better.)

So.
Lots of cool stuff happened in last few months.

First, ubic is now cross-platform and runs on *bsd, Mac OS X and pretty much any posix-compatible OS out there (no Windows yet, sorry).

Second, installation is now as easy as possible. Just do "cpanm Ubic && ubic-admin setup", and you are done. (Pass "--batch-mode" to setup command if questions annoy you). It's even possible to install ubic in home folder without root access and use it with perlbrew or whatever you like. Even on shared hosting, if you have the ability to edit crontab there.

Third, 1.30 release finally got some new manuals. They are far from perfect, but I believe they are much better than old PODs with which it was pretty obscure for new user to figure out where to start.