Zotero is in my opinion the best solution to citation management available. It's a firefox/xulrunner based solution for collecting and maintaining bibliographic data and it's associated full text. Zotero has a cloud based API but also an internal (largely undocumented) Javascript API. I find the JS API much more interesting than the cloud API due to having total control over my data (and works offline etc etc...).
Two frustrations I've had with a lack of good alternative to the msword integration code, and problems with interacting with the internals of a running firefox/xulrunner. I finally cracked open mozrepl, and the cpan module MozRepl and prototyped a bidirectional bridge between Zotero and perl.
The code is here, and should be a useful start for anyone who wants to do any bibliographic data mangling in perl. I'm not going to publish it to CPAN until I work out how to test it properly.
Today I'm working on some code. That's not surprising. It's also not surprising that the person I'm working on the code with is on holiday until the new year starts. Before he left, he made some significant changes to optimize our code, but for one subsystem he didn't have the time to apply his changes. This means that we have 7 tests failing out of 397. In a quick check we found there were plenty of conflicts between his code and mine and my work was generating even more conflicts. This meant we had two choices for how to deal with this while he was gone:
I could continue my work with passing tests and deal with even more conflicts when he returns
I could merge his code, deal with some failing tests. get rid of the conflicts and have a much faster code base
Previous end-of-year report for 2011. Previous quarterly report: Apr-Jul 2012.
2012 is my most productive year yet in my "CPAN career": 943 releases (compared to 495 in 2011). That's about 2.5 releases per day! So far I have about 215 distributions under my account, almost half of them (96) are new modules in 2012. The reasons the number of distributions is high include: Perinci modules family being split into many distributions (and then some, to avoid recursive dependencies problems that I seem to keep bumping into), the various Task distributions, and also the fact that releasing CPAN modules is so darn fun! A little too much fun, I'm afraid.
Almost all the BackPAN distributions have also been analyzed.
Personal Feed
You can subscribe your kwalitee report feed of your distributions (http://cpants.cpanauthors.org/author/PAUSEID/feed).
Metrics
Finally Moose and friends are correctly considered as "use strict" equivalents, and new valid_signature metric is introduced (both have been implemented in Module::CPANTS::Analyse 0.86 months ago, but have not been introduced on the previous site for various reasons). On the other hand, some of the experimental metrics about debian packages are disabled because the data source has not been updated for a while.
Issues?
If you find anything, tell me via github's issue tracker:
Dear YAPC::Europe attendees and those who would like to come to Kiev in August 2013,
We are very happy to announce the launch of the conference site: yapc.eu/2013.
Together with that, I am correcting the week countdown counter: there's no week minus 34, and the week -35 is followed by the week -33. The dates of the conference are 12-14 August 2013. There's a negligible small change that the dates will be changed, so we will make additional announcement when we are ready. It's Christmas and New Year time, that's why we have to wait a little bit more to be 100% sure. Vyacheslav vti and Anatoly sharifulin have just returned from Saint Petersburg where they attended the celebration of the 25th birthday of Perl, which is a good excuse :-)
A few days ago, I announced the release of Mojolicious::Plugin::ModuleBuild. After some thinking I realized that without much (any?) changes it would work more generally, even with the ExtUtils::MakeMaker toolchain. Therefore I am now announcing the availability of Mojolicious::Plugin::InstallablePaths.
The general concept is that Mojolicious applications assume a certain directory structure for use locally. To make a CPAN-installable distribution out of that application one must move some directories. Further, if packaging using Module::Build, even more changes had to be applied.
Mojolicious::Plugin::InstallablePaths allows a consistent usage in all phases of development and with either build tool (EUMM or Module::Build). Hopefully this helps encourage people to think of their Mojolicious apps as candidates for CPAN and makes it easier for them to share them with the world that way!
The old module will be marked for deletion and the old blog entry will be removed as well, so don’t try to use it, its going away.
GitHub now holds a pmtools Git repository. Since I have some time right now to attend to pmtools (and other personal programming), I thought it would make my life easier to move my pmtools development into Git while making pmtools development more collaborative.
(Yes, I will accept pull requests, but I reserve the right to review all changes before making a formal release.)
I generally have no problem understanding what's in a CPAN distribution and why, but lately (for years, now), it seems that tools are building files that I don't know about. Is there a canonical place to find information about what absolutely, definitely needs to be in a CPAN distribution? I generally rely on my tools to do this stuff for me, but honestly, what's META.json, MYMETA.json, META.yml,MYMETEA.yaml? And then I wind up with files like MANIFEST.bak and MANIFEST.SKIP.bak and I honestly don't know the format of many of these files, why they're duplicated or where to look up this information. Which of these files should I commit to source control and which of these files should git ignore?
It's an embarrassment because honestly, I should know this stuff, but I don't. Surely there's a place where I can find all of this explained at once, perhaps in conjunction with a description of the files in my .cpan, .cpanm directories?
Most of you love programming and shut ears when its only starts to buzzing anywhere but please hold on, its for a good cause and maybe even you might benefit from it.
Assuming someone would like to help with Windows, how could he generate a list of modules that are especially problematic on Windows?
Is there a way to fetch all the distributions that have no successful test reports on Windows?
Is there a way to create the ratio of (failed test reports)/(all test reports) on MSWin32 for each distribution, and then show the top 100 of that list?
Tomorrow is the 25th birthday of Perl. The Perl programming language.
When I've first heard about it, it was named PERL, the spelling that now is a nice indicator of awareness in the row with Perl and perl. Honestly, I never thought of Perl as of a practical extracting and reporting language, I simply had no clue about which reports and which extractions were mentioned in that definition.
I have first seen the name of the language on the book covers in a book shop in my home town years ago. I cannot tell you when exactly, but it was definitely before 1998. At that time it was only something related to web and programming for me.
Perl is not my first programming language. The first one was C++ (with ++ from the start), and I still find it one of the best languages and tend to use it as soon as there's a small need.
OK, so I decided to hack in support for submitting CPAN testers reports into cpanminus. I've uploaded the result to CPAN in case anybody else wants to use it. After CPANPLUS and cpanminus, the logical name for it was cpantimes.
As a Perl programmer on Windows, I've often had moments of supreme frustration. I can't use SSH or SFTP from Perl, and I can't use some of the mail handling modules. When I got started back in the early years of the century, I couldn't even use CPAN; I had to compile my own Perl and accept the fact that tests just mostly had no chance of working. Over the past year or two, however, especially as I've come to rely on CPANtesters for my own modules, I've started to realize that one reason for this is the lack of dense testing of modules on Windows. (Yeah, Paul Evans had something to do with that realization, too.)
But then Gábor Szabó posted on Google+ that he hoped to make it to #20 on the Windows smoke tester leaderboard. (As of today, he's at #19 - congrats!)
