Perl has so many useful builtins that most people who use the language probably only use a fraction of what's available. Every year or so I like to peruse perlfunc and perlsyn as a refresher. Yet in years and years of hacking Perl code, there are a few in there that I will never use. I surprised myself the other day by reaching for the loop control command redo. It occurred to me that while I use other loop controlling things like next and last constantly, I couldn't remember a single time before when I have ever had to redo an iteration. For the curious, here's the astonishingly simple scenario where it came up.
It's frustrating to me that I have limited bandwidth right now. A new job, a new country, a (soon to be) new baby, and a new blogging venture have all conspired to ensure that I don't have as much time for writing software outside of work. However, I've been working hard on Role::Basic and following a suggestion from Stevan Little, I've started [a branch with Moose::Role tests](
https://github.com/Ovid/Role-Basic/tree/moose_tests) and have started working through them. Some are clearly inapplicable (for example, Role::Basic has no notion of attributes), but a few have given me pause. I wasn't sure if they were supporting original traits behavior or if they were extensions for Moose. Since I've already ready the original traits paper (pdf) several times, I decided to move on to Traits: The Formal Model (pdf) to make sure I hadn't missed anything. There are some interesting bits there.
After half a day of yak-shaving that started with having to port yet another Makefile.PL to the dist.ini format, I am now finally able to post this small snippet of elisp code to blogs.perl.org from within emacs (more on that later):
I don't think this is documented anywhere, so let me blog about it before I forget it. Install the module CPANDB. See if it works by running one sample program, maybe:
use CPANDB;
use YAML::Syck;
print Dump [CPANDB::Distribution->select
("order by volatility desc limit 1")];
It may take a while but you will get something like this:
SslAuth uses the recently added TLS certificate authentication support in Mojolicious 1.01.
The first argument passed to the callback sub is the IO handle, giving you access to whatever IO::Socket::SSL provides. (get_cipher, for example).
ParamsAuth is very basic, its purpose being to keep your params-based authentication uniform with other auth-types.
The arguments passed to the callback are the values from the named form or query parameters.
BasicAuth has been around for a while, and uses a similar interface:
If you're looking to be hip with the latest oauth goodness, Marcus Ramberg recently released Mojolicious::Plugin::OAuth2.
...
On a side note, Вячеслав Тихановский (vti) updated MojoX::Validator only days ago. It is, to date, the only form validation helper that doesn't make me think Amway would have been a better career choice. It can be integrated into Mojolicious or used separately. And, like Mojolicious, the code is easy to understand and contribute to. Join up!
Once in a while I have something to tell about Perl and me. I used my very own server for years and sometimes I even used use.perl. Since the shutdown of the blogging interface at use.perl it seems that most bloggers moved to blogs.perl.
A friend, Ido (ik_5) put up a post (in Hebrew) about the last TA.pm meeting, and although he misspelled my moniker twice, he raises two interesting points.
First of all, he complains about being mocked when everyone introduced themselves and he said he works with Pascal. Secondly, he asks why don't people program in Pascal? What's so bad about it?
So, apologies have to go to people you've offended. Even if you didn't mean to, even if they didn't get a joke you thought you were sharing. When feelings are hurt, it's time to pause and apologize. So, hopefully Ido is reading this and might be less upset now.
Right now, if you get yourself a copy of CPAN (or check out a mirror) you won't find a lot of information about CPAN authors. You'll find name, email, PAUSEID and, in some cases, an URL. It's good, but it's not really comprehensive. It doesn't tell you how to find an author on Twitter, Github, Stackoverflow etc. Sure, you can find that stuff out with some research, but how hard should you really have to work for this information?
An important consequence of the choice of parsing algorithm
is the
handling of parse-time errors.
It's often overlooked.
Perl's use of LALR based parsing puts severe limits on its
ability to locate errors,
limits which the Perl interpreter is sometimes able to overcome.
Consider the following erroneous piece of code.
my $lyric =
'Sloopy wears a red dress, yeah
As old as the hills
but when sloopy wears that red dress, yeah
you know it gives me the chills
Sloopy when I see you walking,
walking down the street
I say don't worry sloopy, girl
You belong to me';
print "$lyric\n";
Some of you may have spotted this as the lost third verse of the
October 1965 US #1 hit, "Hang on Sloopy".
Others may notice that the single quote in "don't"
is going to make things come out pear-shaped.
On this latter point,
the Perl interpreter's performance is uncanny, if a bit noisy:
There have been a few bits of ARM related news which I thought were interesting. We like the ARM architecture (RISC is good) as it is low-powered and yet getting pretty powerful.
The alternative title for this post would be Best Holiday Ever where I got to show my family some of the parts of Indonesia I visited as a child, and where we got to visit a hotel in a national park in Borneo in which my family has a business interest. In case you think this is a shameless plug, the vast majority of the income generated by the hotel goes back to the local people -- the investors are facilitators, for whom there may be a long term return.
First of all: Finally accept that there are two Perls now. 5 and 6. Period. The world needs more Perl - here we have it. :) None of the two will go away. That's a good thing.
None of the following is new, but my suggestion would be to do it more in sync and at the same time and as a group to create a more event-style *cough* collective experience *cough* (think GSoC). It might also bring back people who have abadoned Perl but still keep an eye on the community. Considering how people sometimes talk about Perl on reddit or in Hackernews threads I bet some of them just need a little nudge to come back. (Many have never left in their heart.. *sniff* :)
Traditionally, the humanities journal has relied on Peer Review much like many academic disciplines. I believe firmly that Arxiv.org or something very much like it will replace the humanities journal in the near future, much like it has in the sciences. One of the main objections to this direction in the humanities is “what about peer review?” This is a major sticking point. The other is “will it count on the RAE/whatever management insanity we have to deal with at the moment?” I cannot answer the latter but I will give a vision of a solution for the former.
On my previous post, Ron Savage has commented on the way he uses File::ShareDir with Moose, to be able to use data files in the author's code directory.
While I probably won't use this method since File::ShareDir specifically has the ability to use @INC (which makes my - and kmx's - solution possible), it does raise a very important note. You must make your code testable.
Some of it is done by separating your code into smaller parts that are easily testable and can easily be overridden. Please refer to the Modern Perl Book, and the Modern Perl blog on learning more on this.
However, sometimes it's not enough. In that case, you'll need to assist your tests a bit, from your application code. Let me give you a small example.
On September 9, 2009, WebGUI 8 was announced. Since it was the
first major API change since WebGUI 7, we started planning WebGUI 8
with high expectations. Over the course of the last 16 months:
This Perl marketing thing you know.. I'm really thinking about it every day. I've always wondered how those mechanism of "being THE it-language" or "the tool the cool kids use these days" or "success" in terms of "spreading everywhere" really works.
I've started with Linux in 1995 in Germany and I remember for example how the increasing database support on Linux was celebrated ".. and now XY is available under Linux" and how the success of Linux went hand in hand with the raising success of the Internet and the Web of course. Those were fascinating times.
Over the years I've done something else but Perl but then I went back at a point when I felt "Web is cool again" - and then I had to realize that PHP basically took over the Web. Bad. That's abolutely not what I wanted to spend my time on - coding PHP. So of course I had to notice Ruby.
Just about anyone can help out with CPAN Testers. You can be a heavy-weight tester submitting thousands of reports a month, or a casual tester submitting reports for the distributions you install. You can also help promote CPAN Testers on your blog, or join the group on cpan-testers-discuss mailing list (or associated channel on IRC) and help answer questions testers and authors may have.
However, there is a further way you can help, which is a great way for new testers to get an idea for what and how they can contribute, as well as getting to know the whole CPAN Testers eco-system, and that is by updating the CPAN Testers Wiki.