"tong() method can connect to database"
"tong() method can disconnect from database"
"sha() method can delete an existing file"
"sha() method fails when deleting a non-existing file"
or:
"tong 1"
"tong 2"
"sha 1"
"sha 2"
They are both rather extreme, but if I had to choose, I would still rather go with the shorter ones. I tend to treat test names more like unique IDs, and when things go wrong I just look up the actual test code.
I wouldn't mind verbose test names though if they can somehow be automatically generated (a future Google Translate project, perhaps?) from code, because they are just repeating what the code says.
The Icelandic Society For Digital Freedoms (Icelandic abbreviation:
FSFI) is organizing the annual Nordic Perl Workshop, this year, in
Reykjavik, Iceland. It will be the first time the workshop is held in
Iceland.
Nordic Perl Workshop 2010 will take place over the weekend of May 1st to
May 2nd.
FSFI has now opened for registration and submissions of presentation
abstracts. We encourage anyone who is interested in sharing their
experience or ideas to submit their abstract. Registration fee is €100.
Included in the fee is a workshop dinner at "The Perl" restaurant
(http://www.perlan.is).
Was writing a script and stopped just to write this and ask... what is your favorite quote delimiter? I mean, what do you use to delimit quote words, or regular expressions?
I find out that most of the time I use the slash for regular expressions because with them I can not type the preceding 'm'. But, for instance, on use CGI qw.:standard.; I am liking more the dot. When substituting paths, I prefer to use the exclamation mark.
Rarely I remember that I can use balanced braces. Probably that would be the better choice on most situations, but I forget it...
This is another posting about using Hailo as a guinea pig to test some module. Previously I wrote up on how we tested MooseX::Method::Signatures (which we ended up not using) and Mouse (which we now use by default).
Hailo used to use DBIx::Perlish for its database interaction but this was removed in favor of plain DBI in version 0.02. Hailo now uses an ad-hoc DBI-based setup where each database query is kept in its own Data::Section where each section content is a Template::Toolkit template.
All our database queries are generated from these templates when the storage backend is initialized, they're then prepared and kept around in a hash. There's no runtime penalty that you wouldn't get by just using plain DBI.
This setup is fast and it works, but it's also pretty nasty. Nothing else in Hailo reinvents the wheel so it was always on the TODO to try some more mature DBIx::* module like DBIx::Class.
I am not using Perl at work. I don't know when I will next get a job that gives me the opportunity to use Perl. That's too bad, because I really enjoy working with good Perl code. Notice that I specified good Perl. Unfortunately, a lot of the legacy code that I've seen is bad - painfully bad, even. There's no point in blaming anyone. Bad code happens. We get in a hurry, we push out a quick hack. Maybe we try some clever trick in a production project before we truly understand the ramifications of that trick. Plenty of bad code has come from my own overstressed brain.
Maybe it's unfair to call it "bad code." It was a result of stress, enthusiasm, or simple ignorance. When I have an outlet for all that energy, my code improves. It shines. It doesn't piddle all over the carpet.
While still drawing the differences between programmers, language practices and behaviors, I stumbled upon another major issue. Our tendency to write modules instead of applications.
This is a touchy subject, I'm sure, and I hope not to offend anyone.
Since the majority of Perl programmers are actually sysadmins by day [and superheroes by night], we're accustomed to writing pieces of software, "modules". We have CPAN to host all these modules. Occasionally we might write a program, an App, a small cute frontend to some module that we have. CPAN supports that.
This is all fine and dandy but when making an effort to market our kickass language, we need to tackle different approaches of marketing. One of them is the impression of producing something to the general public. A concept that is strong in marketing, but illusive to understand and tackle.
I got a new Nexus One phone .
Installed ASE (android scripting environment) and perl.
Here is the hello_world.pl that is installed in the /sdcard/ase/scripts
$ cat hello_world.pl
use Android;
my $a = Android->new();
$a->makeToast("Hello, Android!");
The adb shell seems to be very restrictive , I get a permission denied for any command that I try.
opening the interpreter from the ASE app give the following
/data/data/com.google.ase/perl/perl -de 1
and opens the debugger .
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.
