brian d foy gave the keynote this year. He talked about his talk from two years that was sort of based on Better Off by Eric Bende, his reading of Skeptic magazine and what this means regarding Perl.
As part of this he touched on the fashionable memes of why some hates or loves a languages, Perl in particular. Sometimes it's misinformed or ignorant hate or just as a way to validate their choice.
So he was thinking about why there is some much love, or hate, for Perl?
This led into an interview question, "What are 5 things you hate about Perl?"
This shows 3 things: real experience, depth and reach of knowledge, and workarounds used for those things.
This also relaxes the interviewee because it shows it is ok to criticise language being used/talked about.
brian then talked about what he hates about Perl. His list was things like: CPAN, licensing or reusability. He didn't go into any real detail about those.
Zed Shaw will turn the tables on our usual Perl centric meetings by giving us a few lessons in learning Python the hard way. Zed is a well known software developer who is noted for developing the Ruby webserver Mongrel, the successor Mongrel2, the Lua based framework Tir, and autho.me.
Lots of great stuff is happening with MetaCPAN. Here's a quick (and incomplete) list.
First off, Yanick Champoux has been doing some excellent work to add module up and downvoting to the MetaCPAN API. His work is on Github He has also created a Greasemonkey script to allow module voting to begin on search.cpan.org. We plan on incorporating it into the cpan-mangler as well, so that you can vote on search.cpan.org without needing GreaseMonkey.
Yanick's work will pave the way for module commenting, bookmarking etc. The great thing about this is that we'll be able to collect data on most loved and hated modules/distributions without being tied into any one particular search site or application. This is the sort of data which can make getting an overview of CPAN much easier. Yanick will likely post about his work in greater detail, but it's pretty cool stuff. It could change how you approach your search for new modules.
It's officially been 4 months since we launched the Perl based MMO: The Lacuna Expanse, so I wanted to take this opportunity to update you on its progress.
First, thank you. Without you Lacuna wouldn't exist. Many of you are playing it, and many others of you have built modules, techniques, and technologies that we used to build it. So thanks!
Three new jobs were created after launch to help serve the community. One of them was even a Perl job! So Lacuna has already started helping increase the Perl-based economy. This may not matter much to you, but it tickles me.
Padre has hit version 0.80. I guess it's not a big deal, but you need to lead with something.
Adam Kennedy is by far the most prolific contributor for this release, clearly there are a few things that need scratching.
It seems though that this release was rolled out just in time for him to injure his wrist skating, not sure if it was roller skating or roller blading, so we may see a slow down from Adam for a while. Time will tell of course:
I asked on the vim mailing list how to see the name of Perl's current sub/method in the status line and Alan Young, the author of PPIx::IndexLines has a great suggestion which unfortunately relied on PPI. I'm working with very large modules and PPI ground to a halt for me. As a result, I took his suggestion and worked out the following.
First, make sure that your .vimrc has set laststatus=2 in it. That will ensure that you always get a status line, even if you only have one window (i.e., don't have split windows). Then drop the following into your .vim/ftplugin/perl.vim:
Several years ago at OSDC::AU I was lucky enough to run into Rusty Russel three breakfasts in a row. He was at the conference to deliver a keynote on why C is awesome and all us scripter types should learn it.
I mentioned that I'd tried a few times to switch to C but I'd found the lack of any kind of CPAN pretty much crushed my soul each time I tried, because I kept wanting to make one because C and Perl are very similar languages (to me at least, compared to things like Python or Java or Haskell).
By the end of the conference he was hooked on the idea, had taken over development of libtap and written 8 or 9 patches for it. A week later we had mailing lists, and a basic design.
Today, CCAN represents what I consider to be the closest cousin of the CPAN.
I like to read. Over time, I've become quite a rapid reader - I remember a project at school where you would get a dignoria (star) for writing a book review during the summer holidays... and I had read 26 books.
During my short commute on the tube I like to read something. I used to bring paperback books and magazine on the tube. Before going on a weight-restricted holiday I had bought.a Sony Reader PRS-600 e-book reader.
This was quite neat, fairly small. Not a great screen or battery life and it would only charge on a computer's USB socket, not a generic USB one. There are a wide range of public domain e-books or you can create books with your own content and the useful Calibre e-book management software can scrape news sites.
Seems that DateTime module thinks 29.2.1900 didn't exist while Excel 2008 does. Which one is correct ? Well DateTime is OpenSource while Excel is payware. Think payware would be correct ? nope, DateTime is !
So the correct DateTime object for dates starting 1.3.1900 when using values from Excel is :
DateTime->new(year=>1900, month =>1, day => 1)
->add(days=>$THEVALUEFROMEXCEL-2)
This week I’ve been trying to switch us over to using mod_perl2. I wanted to cache database handles as much as possible so one of the first things that I did was edit my startup.pl and add:
use Apache::DBI;
Most stuff just works. When I find something that is only slightly broken, I fix it. When I find something that is horribly broken, I just create a Location in httpd.conf to tell Apache to run that as plain CGI and I’ll update them later.
The entire application suite feels faster. I suspect much of the speed up is due to caching database handles but I’d like to profile it. I have no problems profiling CGI with Devel::NYTProf. When I configure httpd.conf to use Devel::NYTProf::Apache like this I get issues.
This is very brief review of a marvellous book on JS, JavaScript: The Good Parts, by Douglas Crockford.
It’s a somewhat thin book, given that JS has quite a few features, but the author’s contention is that you should stick to a small subset of those features.
Some extracts from the Preface:
This is not a reference book.
It is not exhaustive…
This is not a book for beginners.
These mean he’s not trying to teach JS, but rather to guide us readers as to what components of the language we should restrict ourselves to, that we may write programs of much higher quality than would otherwise be the case.
For your entertainment, he’s called the appendices (which are worth the price of the book):
Awful Parts
Bad Parts
JSLint
Syntax Diagrams
JSON
Regrettably, JS has many parts which are very badly designed indeed, and the so author steers the reader away from those.
Highly recommended for all of us who sail on the JS Titanic.
Over the weekend I overhauled my personal project Fennec. Fennec is a testing framework for Perl that was originally meant to solve the shortcomings of Perl's other solutions. This release is a major simplification of Fennec, largely as a nod to the fact that Test::Builder2 will solve a majority of the "results should be objects" problems that Fennec formerly addressed.
Catalyst 5.9 is coming up, and the big change is a wholesale switch to PSGI, completely dropping Catalyst’s own engine system (outside of compatibility shims). This is bound to bring in new people wondering what PSGI and Plack are all about and what you can do with them.
I’ve been using Catalyst on top of Plack for a while now (with the aid of Catalyst::Engine::PSGI) and have gotten around to some nifty things with it. So here is my app.psgi for inspiration:
Lastly I tried to access files on a Samba share (running on a Debian machine) from Carbon Emacs running on Snow Leopard. The files where in a git-repo, so vc-git tried to do his stuff. This made Carbon Emacs hang while creating .#file.pm linked files. flymake had the same issue. So instead of disabling vc-git and flymake, I searched the internet.
The problem got solved by adding this line to the [global] part of the smb.conf file:
I have uploaded the source code for Yenta, our
highly-available key-value store to CPAN.
Yentas operate as a peer-to-peer network (there is no "master" node).
Nodes use gossip based protocols for distributing membership + status
information. Put() operations distribute data in a
network-topology aware manner. Eventual consistency is achieved by
data versioning and gossiping merkle-tree hash values.
At Solve Media, our web-site partners depend on
our technology. If we go down, they go down. Yenta is one of the
technologies we use to ensure our high availability at scale.
Sorry. No Perl in this post, but this appears to be such a common problem that I've decided to write up a simple description of how to convert FLAC to run in iTunes.
FLAC is the "Free Lossless Audio Codec". It's a fantastic file format, but there are a couple of issues. First, songs typically run 25 to 40 megs per song. This means that they take up roughly 10 times the hard disk space as a corresponding MP3. For extremely large music collections this could be a problem.
The other problem is that Apple has chosen not to support FLAC for iTunes. I tried many solutions listed online, including Xiph and Fluke and got nowhere. Finally I decided it was time to go "old-school" and fall back to the command line.
I downloaded the FLAC tools and installed them. That gave me access to the flac program. Then I installed the LAME MP3 encoder. I used MacPorts for the latter, but you can get it from the Sourceforge link I provided.
Having had Plack on my 'to looking to list' for a long time we've finally started using it at work. Yet again here is another of the 'modern perl' pieces of software that once you start using you'll wonder how you ever coped without it.
As first it doesn't seem like you have much that wasn't done in Apache (or what ever web server you are using). The moment you realise that you can put everything that was in Apache (rewrite rules, expiry headers, serving static content) into your app.psgi (web application configuration) file and that this will then run under any of the many supported web servers the light bulb goes on.
You can then try Starman or run everything using plackup in your development environment.
The simplicity of Plack's structure $ENV in, [ status, [ headers ], [ content ] ] out makes writing middleware easy and adapting your code to use this standard very clean (even if you don't use one of the many frameworks which already directly support Plack).
I've also added a white paper on Plack to Perl.org.
I've just read
a very thoughtful
description
of why one Perl
programmer switched to Python.
In this blog post, I'll explain why I did not.
When I started on the
Marpa
project, Perl was
not an automatic choice.
In fact it looked like it might
be the wrong one.
There was as much buzz for Python then
as now.
Maybe more.
I'd had my own
experience with Python,
and it was excellent.
I'd used Python to create a threaded mail client for
testing purposes.
I found Python to be easy to learn, fun to use,
and an effective way to accomplish my task.
Perl had another problem.
An important audience for
Marpa,
my new parser,
is academia.
Academics certainly use Perl.
My experience is that they even respect it in a certain sense.
But Perl does not fit neatly into the minimalist
paradigms which still rule academia.
If you speak Perl to academics, you are not talking
their language.
That means you run a great
risk that nobody will listen.
