Not sure how likely I am to actually succeed in giving regular updates, but I'm going to give it a go... Here is a synopsis of perlish things I’ve been working on in the past week.
The Perl Foundation (Treasurer)
Trying to track down some old contractual agreements to straighten out some payment details.
We’ve got some unfinished infrastructure refinement that needs to get done. (more details later)
Trying to close out all the details from YAPC this year. At this point, I’m comfortable saying it certainly ended in the black, though I don’t have the final number yet.
All checks that I received at YAPC were mailed to the bank weeks ago (I swear!). But I got a report just yesterday that some of them possibly didn’t get processed. I’m investigating that.
Up to date on all payment requests.
Working on a Q1, Q2 financial statement for the board. Have to get some issues worked out with our bookkeeper.
Nearly finished with the 2010 tax return.
Pittsburgh Perl Workshop (Organizer)
We’re starting to announce talks for PPW. But we still need more proposals. Please send in more talks!
MJD is coming to PPW!
No word on Damian yet.
The Perl Ops track is going to be a really big deal. Trying to get the word out any way we can.
Went to ship a new module today but Google Chrome wouldn't let me visit PAUSE
Firefox indicates that the cert is from an untrusted issuer, but allows me through after adding an exception. 'Error code: sec_error_untrusted_issuer'. This is disappointing that the Chrome developers could not match Firefox in this regard. I'm hoping that it is just a missing use case rather than a planned feature.
But alas, the PAUSE ssl certificate is still self signed signed by CACert. PAUSE admins, if you are reading this, I will buy you a signed ssl cert for pause.cpan.org. Comment on this blog post to get a hold of me, or email me on my PHRED cpan page email address. I know you guys have lot of stuff going on, but hit me up and I'll cover this part of it.
Edward Tufte's "Slopegraphs" look like an interesting addition to the chart-maker's toolkit (and we all have had to create charts at one time or another).
For some reason Dancer was able to attract a few trolls (though we only suspect it's 2-3 people overall). Those 2-3 people have been trying to destroy Dancer and its community by flooding our IRC channel, writing plenty of disgusting remarks on Reddit, HackerNews, Twitter and recently by flooding our CPANRatings page.
Unfortunately none of this worked and the community had only flourished thanks to both hardcore Perl devs and beginner users who came out of the woodwork of dark Perl web programming into the funhouse that is Dancer and its community.
We've had a lot of awesome contributors, a lot of great feedback (some was "you're just awesome", some "you're missing this or that" - which were both very helpful!) and we've seen more and more users coming out, talking to us about how much they enjoy Dancer and how we could improve it and even lending a hand in everything from code, documentation to even helping other community members. It is really really inspiring.
The Portuguese Perl Workshop is back. This year's event will be held in the 22nd and 23rd of September in sunny Lisbon, where the grass is green and the girls are pretty.
Recently I put up some apps for YAPC::Asia 2011 online. <plug>Yes, YAPC::Asia Tokyo 2011 is happening, and it's on Oct 13-15. Tickets will go on sale sometime mid-August. Call for papers is now open, please submit your talks!</plug>
Then I got this following conversation with @rblackwe:
rblackwe: @lestrrat are you running Act on dotcloud?
lestrrat: @rblackwe nope. bunch of small custom psgi apps.
rblackwe: @lestrrat you hade me excited and hopeful.
... which is, well, understandable. By coincidence, I'd just had a conversation on IRC #act about this very fact on irc with Maddingue. I was being asked if we were using Act or not, and if not, why.
The short answer was: No, we haven't been using act since YAPC::Asia 2010, and the reason for that was 1) latency, and 2) admin burden.
I just released the Acme::CPANAuthors::India today, Its based on the Acme::CPANAuthors. There are similar pre-existing modules for other countries and especially extensive ones for most of europe in the Acme::CPANAuthors::* namespace but surprising India was missing in the list despite the large group or perlers here.
This also gave me the chance to use Dist::Zilla or dzil for the first time to do my module packaging. I like all the additional features that the plugins add to your distribution. especially the auto versioning, auto Generation of Module's README, MakeFile, Pod tests, METAs from your pod documentation is very cool. I do miss the more filling module template that ModuleMaker generates for the module itself however. I am sure there must be a way to generate a more comprehensive module template here. I am still looking and will update this thread with more soon.
Acme::CPANAuthors::India seeks to get all the CPAN Authors in India together into a single list for reference and link ups.
If you are supposed to be on this list and aren't then you can raise a bug at RT for this module at http://rt.cpan.org/NoAuth/Bugs.html?Dist=Acme-CPANAuthors-India with your Full Name and CPAN ID/HANDLE.
Today I'm signing up an account at Dangdang, a large Chinese e-commerce site (previously I've ordered Chinese books from Amazon.cn/Joyo, thought I'd try other sites). Their URLs have ".aspx" in them, but when I get a registration confirmation email, it says:
It's been several weeks since the first mojocast, and the response has been quite positive.
What started out as an excuse to use iMovie has turned into something useful and galvanizing. Especially encouraging are the comments from folks currently learning Perl; presenting n00b information in an easily consumable and pleasant manner solidifies new users' decisions that Perl is an excellent choice.
The second mojocast is forthcoming, delayed only by the process of moving; sleeping on couches en route has a negative effect on finding quiet locations with decent acoustics, and girls always want attention when you're in their house. Go figure.
Never fear, though, the second mojocast is nearly complete.
Anyone who wants to contribute to its launch and the marketing of Perl through mojocasts, please contact me directly - via comments, email, or in the #mojo irc channel. The comments for the first episode indicate that even the Ruby folk are surprised and impressed with a taste of Modern Perl, so the more people that are onboard, the better; there's every reason to work together to make an impact on Perl's impression in the open source community as a whole.
How should we figure out what should be in core? Florian floated some ideas for removing some crufty modules from Perl 5.16. Some of these I don't care about, some of these I never knew about, and at least one I'd like to see in the standard distribution:
Text::Soundex
File::CheckTree
Text::Abbrev
Dumpvalue
autouse
NEXT
There are several camps in this little battle, and people tend to stay in their camp. I think all of them have at least threads of validity.
We're stuck with everything already in there because we don't know who depends on it
Make everything an additional installation, like Task::Kensho
Have the minimum you need to install modules from CPAN. (This is getting much leaner).
Include a superset of the Standard Library distribution, like Strawberry Perl or ActivePerl does.
pragmas (like autouse) are part of the language, different from a module (such as Text::Soundex).
Yesterday I decided to stay with MySQL, but today I face something a little more creative: What should the data model look like?
So far today I've collected a list of all the information I would like to store, and marked out all the information that is currently stored. It doesn't look like I have to add a lot of information, but I'm certainly changing how it's stored.
In the current version of the application a whole lot of the information is stored in static configuration files.
For example, the concept of a "Morph Rule" is a configuration variable.
So a case type is changed in accordance with a "Morph rule".
When this was designed it was not clear how often these things would change or need tuning, so it was hard coded in a way that would make it very fast to load at start-up, and very easy to access while running, but very impractical for the application to change.
Changes are currently done by manually editing .pm files.
Now that you can log in to MetaCPAN via Twitter, Github and Facebook it's trivial to update your author profile. For example, if you look at my author page, you'll see some pretty icons with links to various other sites I care about. All of this takes just minutes to set up and it does two things:
1) It makes your author page sexier
2) It makes you easier to find, follow, pester etc
One aim of MetaCPAN is to make it easier to contact authors in the Perl community. The author info is available via the API. For example, if you want a list of every author to date who has logged in to update her info (91 at the time of writing):
For a long time now I've been saying to anyone that would listen that the only thing preventing Perl from being a good language for desktop development was a lack of decent library support, and a lack of decent tools to make development relatively efficient.
With Padre, we've certainly gone a long way towards demonstrating that building large desktop applications in Perl is possible, and the stresses caused by Padre on it's underlying libraries has driven the improvement of Perl support for the dominant cross-platform GUI toolkit wxWidgets.
With library support relatively mature, and a number of people working on improving installers for Padre and Perl desktop applications, the next outstanding problem is the complexity of the Wx.pm API and the fairly steep learning curve when it comes to producing Wx.pm GUI and dialog code.
So it with great pride that I present the first working production release of Padre Form Builder, the first native cross platform GUI design solution for Perl.
Before I let my enthusiasm overpower me and jump into this rewrite with all it's worth, I have to take a long and hard look at what technologies are being used, and what I want to replace them with.
Swapping out Class::DBI with DBIx::Class is an easy choice, and I'll get back to that in a later post, but what of the engine behind it?
Currently, the whole thing is built on MySQL, but during the lifespan of this fairly complex CRM application I have seen some of the limitations of MySQL up close.
A lot of my contacts and friends also insist that while MySQL is fine for a website or any simple CRUD operations, it will let you down when it comes to more complex queries.
A colleague @$WORK found this: The Development of a Perl-based Password Complexity Filter. I was going to comment in the site about the presented Perl code looking rather like it was a straight shell script port (though the "use strict" pragma and lexicals indicate some safety, but I'm sure the more experienced Perl hackers here can smell worse.) Too bad it needs approved registration.
But that's not what I'm really wondering; are there more password checkers out there in the CPAN? I've seen Data::Password and its ::Simple variant, but a casual search doesn't bring much. I guess those two modules would be ok, if not for the former's use of global scalars such as $DICTIONARY and $GROUPS to configure the checker (I guess I could submit a patch fixing that... what do you think, lazyweb?)
When you upload module to CPAN, PAUSE checks that archive does not contain world writable files, because if
you install files with such permissions, files may be changed by any user.
If files are found, PAUSE creates modified archive, with correct permissions and uploads it with the same name,
only "-withoutworldwriteables" is added. Usually such archives are created by tar on Windows, but they can
be created on Linux too - it depends on permissions of files on authors hard drive.
Solution of this problem depends on which module framework you are using.
Module::Build version 0.31 creates archives itself and does not suffer from this problem.
Users of ExtUtils::Makemaker can:
1. migrate to Module::Build using my App::EUMM::Migrate
2. use ptar from Archive::Tar with "-C" (CPAN) option that I've added. Just upgrade to version 1.66 and add
dist => {
TAR => 'ptar',
TARFLAGS => '-c -C -f',
},
to WriteMakefile call.
For Module::Install you can use Module::Install::PerlTar 1.001, it also uses Archive::Tar 1.66.
Add following code to your Makefile.PL:
use_ptar() if author_context; #from Module::Install::PerlTar
Comments about errors in English can be sent to alexchorny@gmail.com
After just two weeks from the closing of YAPC::NA 2011, the conference survey site has been busy. We have 60 responses so far to the main conference survey, and 312 responses for the talk evaluations. Many thanks to everyone who has submitted their responses.
However, with 75% of attendees yet to submit their survey responses, it would be great to get some more submissions, both for the main conference survey and the talk evaluations. The results are extremely useful to organisers and the speakers, to help improve the conferences and the talks respectively.
If you haven't responded as yet, please check for your unique email with your personal keycode login, and click the link provided. If you cannot find the mail, please check your spam filters first and failing that please let me know and I can resend you your keycode.
For further details please see the Wiki page on the YAPC::NA 2011 site. Results of the Conference Survey will be posted on the YAPC Surveys site at the beginning of August.
The surveys close on Friday 29th July, so you still have just under 2 weeks to submit your responses. Please try and take some time to complete and submit your responses, as they really do help to improve the event for everyone.
Not Perl, mind you, I'm not in that area (yet?). But some key terms I keep hear buzzing around, and, in the tradition of starting the Christmas season in late July, I'll begin my Festivus preparation with some minor Airing of Grievances.
