I've been thinking that a code journal of some kind would be nice. You know, the stuff that doesn't matter enough to spend days agonizing over whether I'm being too advanced or too simplistic. My other blog is okay, but I like the MT interface.
Why blogs.perl.org? I realize it may not be cool to say in some crowds, but I like Perl, Parrot, and Rakudo. This site seems like an excellent place to write about writing in those environments.
To be an institution, or to represent an institution, is not a simple task. Namely, I represent The Perl Foundation (TPF), and specifically, I represent TPF Grants Committee (GC).
We, at TPF GC, receive quartely grant proposals on Perl, to be funded by TPF. We can't fund all (and we do not want to fund all). So, they are posted publicly for community discussion and are voted by the GC. We try to have in consideration the relevance of the grant to the Perl community (taking into account community comments), the grant proposal clearness (if it is clean, probably the proposer knows how to make his task), the amount requested (if it is worth the work proposed) and the proposer curriculum. This last item is, probably, the most abstract. But if the proposer has the skills and has previous contributions to the Perl community, that is usually enough. It is also important to analyze the proposer past on TPF Grants. If he failed any grant before, probably that will be taken into account.
I recently wrote about 100% Test Coverage. I was pointing out that in a personal project, I was working on increasing coverage and everywhere where there wasn't coverage, there were bugs. Here's the flip side: if it's covered, it doesn't mean its bug free. I've talked about this on my old use.perl blog, but it's worth repeating for new readers.
I was looking for a way to send a Google Talk message (via Perl) whenever a certain something occurs, and thought it'd be a simple task since Google Talk uses the Jabber protocol, XMPP and all that.
Boy was I wrong.
I found some code on the 'net which used Net::XMPP::Client to create the connection to talk.google.com, authenticate and send the message. It just didn't work.
Turning some debugging on revealed I was getting an "incorrect-authz" error from Google. The username and password weren't at fault (that'd be another error).
As from this page the reason for the authorisation failure has to be found in the feature called "JID Domain discovery".
This is an example of the string used to authenticate to gtalk:
Fayland Lam apparently got tired of me sending him patches so I released his Dist::Zilla::Plugin::ReadmeFromPod on CPAN today with some fixes, yay for GitHub powered collaboration.
Fayland previously released version 0.05 with a patch of mine which replaced IO::Scalar with an in-memory open(). This fixed an issue with PODs with non-ASCII E<> characters but introduced another one.
For some reason using in-memory open() like this yields a POD that's cut off, here's a test for it via Gist. I couldn't find out why in-memory open() behaved like this so I just used temporary files instead and released that as 0.06.
Theoretically I could have avoided all this by using Pod::Simple's output_string method to save the processed POD to a string instead of a filehandle, only that brought me right back to square one since that too has encoding issues.
Project manager: we've chosen a new ticketing system.
Developers: which one?
PM: I'm not telling you.
Devs: What? Why not?
PM: Because you're just going to argue about it.
I can actually understand the business person's frustration, but this was a recipe for disaster. It was a blatant example of what seems to happen all too often: the people who choose software are often not the people who use the software.
The latest heavy project at $work makes me miss C a bit. There's a lot of Moose objects, KiokuDB, MooseX::Getopt (which is evidently much lighter than I thought) and more. To display all the entries I have in a KiokuDB SQLite database, it takes roughly a second and a half!
Profiling with NYTProf 3.0 (FTW!) shows that Moose takes the most. I don't want to use Mouse for various reasons which I won't go into. Moose::Compile, MooseX::Antlers, nothing near production yet (but I'm keepings my fingers crossed). I tried to rewrite the MooseX::Getopt part and use Getopt::Long manually, but it only speed it up by 30ms. Oh, and yes, everything is immutable. Requiring KiokuDB::Navigator only in the part that loads the navigator gained me 300ms.
I can start rewriting everything with clean Perl objects. It could take a while, but I could get it done. However, that would be losing all the fun and power I get from Moose. Instead I thought of a different idea.
The mentor org activities for this year's Google Summer of Code are getting underway.
Now is the time to get involved if you are interested in mentoring or helping The Perl Foundation find students to hack on perl, parrot, or cpan modules this summer.
I just released a new version of Cantella::Worker and I'm really happy with the improvements. I updated Cantella::Worker::Manager::Prefork and added a couple of options to add a little more fine-grained controls to the worker processes, such as whether the workers should detach from the manager's session or not and a way to adjust the priority of worker processes. More importantly, I added the "program name" attribute and functionality and I made children automatically shut down if their manager dies, so that you never have an unsupervised worker pool. Special thanks to Rocco Caputo for his help. So, here's an example so you can see the progress made:
Lately I've been learning ExtJS (which I might write about separately sometime) to try and create a UI for a small application I'm writing for a friend.
The application uses Dancer and KiokuDB. They're both easy to work with and I spent little time working on the backend. The problem lies in the frontend, where I need some UI. I've chosen ExtJS because it has built-in widgets.
I've played with tutorials, general documentation and (tried to) read the not-as-friendly-as-I-thought API. I was able to create a grid, a form and even a viewport. However, it kept feeling like it's stuck. Not stuck as in "this is going slow", but stuck as in "not moving at all".
Safe.pm, originally released with perl 5.002, has been an experiment to bring compile-time safety to perl. It allows to compile a (usually user-provided) snippet of perl code and execute it, while forbidding a configurable list of operations -- for example, all perl built-ins that would require disk or operating system access. Moreover, Safe "chroots" perl's main:: namespace, so the real program's variables can't be overwritten by the ones created by the code executed from Safe.
It's pretty clear that Safe does not provide absolute safety. For once, even overly restricted, it can be abused to execute code that allocates gigabytes of RAM, or goes into an infinite loop. Also, Safe is forced to share a small list of variables and functions with the main program; $_ is an obvious example, being the default topic for a lot of built-ins; functions from the UNIVERSAL:: and utf8:: namespaces also come to mind.
P****, the P*** I**, apparently has a blog. Unfortunately, it has a "please socially network me" crapstain (1) on every post, and requires Javascript and cookies to post. Color me not surprised.
I had the opportunity to help out the Perl::Staff at this years CeBIT. There was lots of interest in Perl, and we had lots of talks with people about what they are using Perl for, and how to bring the community and the companies using Perl closer together. This is quite a long post so I’ll put it behind the jump.
Major release of Dancer finally out. You can read about it on Alexis' blog.
Basically this version provides a lot of improvements to Dancer:
Alexis Sukrieh worked hard on refactoring and optimizing.
David Precious did a lot of awesome work on documentation: we now have a cookbook and a deployment manual for various situations you might encounter. He also added a session backend with clean recursive dumps.
ExtUtils::CBuilder supports C code compilation mechanisms whenever a C compiler is available. That is true on most Mac OS X installations and other UNIX flavors like Linuxes. Unfortunately that is not so common for Windows, but Strawberry Perl includes a GCC-based C compiler and a standard libc library.
This means that if a C compiler is available it should be possible to compile a C program, and to compile a C library. And that is true. Unfortunately ExtUtils::CBuilder includes method to compile bundle libraries and not common dynamic libraries. If you do not know what that means, probably you are using a common Linux. For Mac OS X we have that difference: the libraries created by standard Perl modules are bundles and not full featured libraries.
