Once in a while we talk about things such as GreyPAN or DarkPAN referring to open source Perl code that is not on CPAN or code that is hidden behind corporate firewalls respectively. It might be interesting to see if we can encourage more of that code to be released to CPAN.
AFAIK Bugzilla is one of the successful Perl projects in terms of user base but it does not have a huge mind share in the Perl community. I am not sure what are the reasons but I think the fact that it is not on CPAN is part of this so I looked at the project a bit.
Getting the source code
Bugzilla has a wiki page for developers where you can find information on how to contribute to the project. They just recently switched from CVS to Bazaar which is a nice distributed vcs. Instructions on how to get the source code can be found on the Bugzilla Bazaar page.
Yesterday, I was thinking about this same exact thing. I have a project where the compile-time hit of the collective libraries that make up the application is a little on the heavy side. I thought to myself that it would be good use something like Test::Aggregate, but I wondered if that could mean that some of my tests could be affected by a downstream dependency where the state could be changing at the class level. I don’t think it’s very probable, but it could happen and it would be a real pain to debug.
In Modules vs Applications, Sawyer X noted that one of the "issues" (emphasis mine) of Perl people is the tendency to write modules instead of applications. That CPAN is great but due to the lack of end user programs there is no WOW factor. He suggested that we write programs/applications that everyone can use to attract more people to Perl.
While I agree with the last suggestion, I don't agree with the preference to modularize everything as an issue. As someone who wrote a program years ago that is comprised of many separate scripts and duplicated code (even in different languages, just for the fun of it) and still have to maintain it today, I'd say that not putting as much code as possible into reusable modules is a mistake.
I'd instead suggest that we still write modules (which is what made CPAN great anyway), but try to *also* accompany each distribution with a demo app (preferably in the App:: namespace).
Most of my work with DPAN revolves around the creation of private, CPAN-like repositories that a project team can use without affecting anyone else. Setting up a DPAN process for a recent customer involved making several MiniCPANs, one for each project group. I had to add a couple of features to CPAN::Mini to make it work out. These new features show up in CPAN::Mini 1.100590.
Like most CPAN tools, CPAN::Mini assumed that there would only ever be one repository, so a person tasked with maintaining several had a problem. Consider this workflow to support several groups:
There's a master MiniCPAN that holds all of the modules anyone in the company is allowed to use. The remote is a real CPAN.
Slave MiniCPANs pull from and filter the modules in the master to contain just the modules their application needs. The remote is the master MiniCPAN.
DPAN (or CPAN::Mini::Inject) adds project specific modules to the slaves.
Monday and Tuesday there were two Israeli Perl Mongers (israel.pm) meetings, of Haifa.pm and Rehovot.pm, respectively. I gave a talk at both of them.
Haifa is way up north compared to where I stay ("middle earth", A.K.A., Tel Aviv). I took an hour-long train ride there with Shlomi Fish. Then we walked over to Qualcomm, where Shmuel greeted us and offered snacks and drinks. I had foolishly forgot that not all places necessarily have a computer designated for the projector and didn't bring mine. Shmuel brought his and we hooked things up. (Tip: always carry a copy of Portable Open Office!)
I was reading yet another post that was trying to bash Perl without actually pointing at a feature that is really bad in the language when I saw that comment about
reverse reverse "hello"
not doing what the author wanted.
This is the point when I was trying to imagine someone sitting in front his TV and double clicking on the on/off button and being surprised it "does not work".
and the logs will be displayed to screen. The default level is WARN, but if you want to debug things:
% DEBUG=1 perl -MLog::Any::App ...
or if you want to quiet things down:
% LOGLEVEL=error perl -MLog::Any::App ...
If you put 'use Log::Any::App' in your script, when run it will by default log to file too (~/prog.log or /var/log/prog.log). It can even automatically log to syslog.
It's very interesting watching people use Test::Class. Usually, it's wrong. This isn't really a fault of Test::Class, though (well, not much), but rather, it's a fault of its documentation. It needs more.
A while ago, I answered to Sawyer's blog post "On low attendance in TelAviv.pm meetings" basically saying that I challenge the idea that the event he referred to is a TelAviv.pm at all. I was being facetious and nitpicking, but my motive was, and still is, my belief that the .pm meetings are a perl-centric, social gathering of like-minded Perl, ahem, mongers, and should be treated in the same way that you treat 4-5 perl guys who meet in a pub.
This is why I was very excited about the re-emergence of Haifa.pm, which was exactly what I was thinking about, a non-formal, friendly gathering of like-minded people that wanted to share their affection for Perl. And for that I want to thank both Uri Bruck and Shmuel Fomberg for organizing this event, and for inviting me to speak, which I always love and dread to do.
"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 .
