On February 28th I will be presenting an “Introduction to Mojolicious” to the Chicago.pm meeting. If you are in the area I hope you will stop by; it won’t just be an introduction despite the name. If you are interested, here is the Meetup link.
I haven’t decided, but I might try to “self-host” the talk, writing it as a Mojolcious app! To do that I had to resurrect one of my earliest CPAN releases Mojolicious::Plugin::PPI. This module does just what the name should imply, providing syntax highlighting via PPI and PPI::HTML in a handy Mojolicious plugin.
Whether or not I decide to use this for my talk, it still is handy to have around. Here is a cute example, a simple “quine” which you can run:
After being dormant for longer than I can remember, the Thames Valley Perl Mongers mail list woke up recently when someone[1] offered to host a meeting.
I've put together a very short survey to work out how many might be interested. If you live in this corner of the UK and/or fancy coming along, please let us know:
[1] the offer comes from Opsview, a company based at the University of Reading campus who use Perl in their main product (and might be scouting for employees).
Drop a note to oliver at cpan dot org if you have any questions. Many thanks!
Bad news. You've a brand-new CEO and he has a reputation for having a short temper. He knows about his reputation so he's decided to win over the employees by offering all "underpaid" employees a salary increase of $3,000 per year. You've been tasked to write the code. Fortunately, it's fairly straight-forward.
foreach my $employee (@employees) {
if ( $employee->salary < $threshold ) {
increase_salary( $employee, 3_000 );
}
}
Congratulations. You just got fired and have to find a new job. Here's what went wrong and a new way to make sure it doesn't happen again.
The following is my view on the subject (and also first, hopefully not last, blog post here), a comment to About the Grants Committee.
Whenever someone is about to submit a grant proposal, that proposal goes through one's "internal review" first. And in that internal review one asks yourself: "Why should I ask to be paid for what countless of others just CONTRIBUTE to Perl community? The Perl itself and tens of thousands of modules are literally millions of hours, hundreds of years of work just contributed. Why should I ask for pay?". This is the perfectly right question to ask. And this makes the one's internal review quite picky, and the result is what we see - no proposals. And, though surprisingly it may sound, this is the right thing.
To be financed with grant there must really be a tangible, important benefit to community at large that cannot be achieved without grant. And this criteria leaves VERY FEW things appropriate to be financed with grant.
So Tumblr, well known blogging platform, has this feature where you can set up a simple site and then invite people to ask you questions. I thought it would be fun to try out doing this for Perl.
No idea why the anonymous poster did not approve my long comment for his post, having allowed another three comments after mine, so I copy my reply here.
Seriously (why did you post anonymously?), every small step in recording conference video is easy. All together it is a pain in ass for the organises.
1. Cameras are cheap indeed. In Riga we had a few HD camera that cost less that 200 €. Transporting cameras with tripods is a hassle (OK, I admit that most organisers really live in the city where the conference takes place, and this is not a problem).
2. You need a dedicated cameramen for each camera (thus, three of four additional persons in the stuff). One of the cameras in Riga was stolen. You'd better pay these cameramen and do not ask the attendees as it is difficult for them to sit the whole day in one room.
Is there a reason The Perl Foundation does not take charge of a central hosting repository for videos from larger YAPCs? Or an initiative to focus on quality recordings? I'd love to see(and hear) more high quality recordings. Looking over the 2012 YAPC:NA videos it appears they were recorded at 480p resolution making text reading difficult. Audio is often not ideal either relying on the facility's broadcast capabilities.
Could we get some interest or a mechanism(fundraising?) to improve this? I realize there is a fear of losing attendance if the material is readily available but I think the actual number of Perl users able to attend key YAPCs compared to the userbase is significantly insignificant.
Many smartphones can capture video at 720p/1080p. Audio capture can likewise be done with a separate smartphone recording at the podium or close distance to the speaker. Dedicated digital videocams and digital audio recorders are not likely to be that expensive if purposed and shared for the large events.
I'm rereading Allen B. Downey's Think Python, but this time with an eye for writing the equivalent code in Perl 6. I am not sure how deep I'll dig into this, as I am limited by spare time and tools from the book like Swampy would have to be made accessible to Perl 6 somehow. BTW, Think Python is available under a CC-by-nc 3.0 license.
Just using this space as a public scratchpad at the moment. I've got $RAKUDO_HOME/install/bin on my path to simplify things.
$ perl6 --version
This is perl6 version 2012.12 built on parrot 4.10.0 revision 0
I just posted an entry about how CUDA::Minimal was behaving weirdly. I hadn't dug around to figure out what was going on, and I went so far as to modify the way the code was compiled and linked to get it to work! My previous post raised concerns about how I would continue with the newly-chosen path.
Well, I decided that I should really figure out what was giving trouble. After many hours (and staying up later than I ought), I figured it out. I highly suspect that these problems are due to interactions with C macros defined by nVidia, but I'm not sure. I'm going to post them here, and possibly also the the perl-xs mailing list, in hopes that they might help somebody solve problems.
There were two big changes. First, all XS code that uses ExtUtils::nvcc has to include this in their boot sections:
Short Version: I’ve released version 2.04 of Debuggit. It allows you to substitute Data::Printer for Data::Dumper when dumping variables.
Long Version:
If I’m known for anything on CPAN (and I’m not saying I am), it’s probably for my work on other people’s modules: my co-maintenance of Method::Signatures in particular, or perhaps my co-maintenance of Test::File (both of which I’ve talked about before). But the first CPAN module I ever released was Debuggit.
I wrote a post upon the occasion, on my other blog. I didn’t put it here, mostly because I hadn’t started this blog yet. But also because it was more of a philosophical musing on procrastination than a useful commentary about CPAN or my particular module.
The debate about the naming of Perl versions has been started by events which allegedly sprang from Ovid’s visit to FOSDEM a couple of weeks ago. The premise is that Perl lacked punch as a brand. It couldn’t get noticed.
Perl at FOSDEM
I was at FOSDEM too. I’d said some things on the London PM mailing list about how important it was, so I thought I’d better go. I took the afternoon off work and drove down to Dover with my partner and jumped on the Dunkirk ferry.
I didn’t get to any of the evening socials. We didn’t arrive in Brussels until late on Friday. I left Carol on her own to explore Brussels for all of Saturday. I didn’t think it was fair to drag her along to an evening meal with a bunch of programmers so we ate together. We had to leave at noon on Sunday to drive back to Dunkirk.
Edit: I got my original approach to work, see my follow-up.
A week ago I wrote about how I though play-perl was great. I put up a bunch of ideas and waited to see what others would encourage me to do. Two of my ideas got two votes each (some others got single votes), one of which involved revising CUDA::Minimal sot it works again. (CUDA is a means for executing massively parallelized code on your video card.) Well, it compiles now, but it doesn't quite work the way I had hoped and I am facing some basic architectural redesign issues. Herein I describe the old way things worked, and why that won't work anymore. Can anybody offer some ideas for how I might move forward?
For some time now, the Space Track web site, which is the official source for satellite orbital elements, has been working on an upgrade to a REST interface. This interface is scheduled to go live on February 20.
My module Astro::SpaceTrack retrieves orbital data from the Space Track web site. To track this change, I intend shortly to release a new version of Astro::SpaceTrack which uses the REST interface by default. My understanding is that the old, screen-scraping interface will be available for an indefinite (but finite) time. For details, click on the post title for the extended version of the post.
The thing is that people posting different--both long and short--messages online in their blogs, or commenting other people's opinion are doing one common mistake. They do not want to hear others.
Scan through the texts appeared after FOSDEM (yeah, I never liked that conference :-) most of them have the following common structure: I propose A, as B is completely insane.
I can easily enough skip personal offensive comments found in my email or tweets to me which are just rude. But what is really wrong that everybody wants his own solution to become a standard. This does not give the right to say "we the community" in these cases. That will just not work for the Perl's success.
We are all different and it's what we have to adopt and exploit rather than killing ourselves from within the group of Perl users.
