This release continues down the path of improvements, bug fixes and translations. The changed release process seems to have improved the translations committed to Padre prior to release, which is a big win for Padre in the multilingual stakes. The efforts of the translators are greatly appreciated by the Padre team, and I'm sure all speakers of a language other than English when they see their Perl IDE of choice in their native language.
Working on a large project, and Padre is certainly that, you appreciate the efforts of those who contribute a lot and those who contribute a little, it all makes a big difference. What we don't always see is the persistence of some of the contributors to actually make a big difference in the ultimate release that makes it to CPAN.
I've had the pleasure of exchanging several
emails with Dave Rolsky, author of a
new OO tutorial on the subject of whether to introduce treating objects as the underlying hash reference.
He says he won't include even one example because
"it really doesn't send the right message. My revisions to perlobj will explain how to implement accessors using the object as a hash reference."
I was shocked, because I find I need to visualize my
object's data structures. Also, in several cases, reading
or writing attributes directly allows me to implement some
needed functionality.
I spent a good few hours today attempting to use the MailboxGUID returned from the WMI Exchange provider to search for the associated Active Directory account, using the msExchMailboxGuid attribute.
Here's two functions I came up with in the end. One to convert MailboxGUID to something that a search on msExchMailboxGuid will like:
We've decided we're gonna start releasing Dancer under codenames that relate to people who've worked on the release.
This release (1.3020) we've seen the continued (and blessed!) involvement of a one "Michael G. Schwern". To some of you he might just be a "mike" or "michael" (or perhaps "the schwern"), but none of us in the core knew Schwern personally before his involvement with Dancer, and this came as a very welcomed and pleasant surprise.
Considering the storm of issues and pull requests done by Schwern, we decided the next version should be named after him, hence "The Schwern Cometh". :)
The latest version is only a week-or-so of development but carries the following statistics:
6 contributors
6 bug fixes
12 features and enhancements
10+ issues closed
I really do see this as exceptional work. Other than Schwern I also want to thank Naveed Massjouni and Maurice Mengel for their contributions to this release (and any previous release!).
In the near future we'll also unveil the most elaborate hooks subsystem in the micro web framework world. I already know whose names will be splashes on that release. :)
If you're an existing CPAN Tester, and have recently upgraded LWP, you may have noticed that your report submissions have been failing. The reason being that LWP::UserAgent now requires that any https protocol request, needs to verify the certificate associated with it. With the Metabase having a self-signed certificate, this doesn't provide enough verification and so fails.
In the short term if you don't need to update LWP (libwww-perl), refrain from doing so for the time being. For those that have already done so, or have recently built test machines from a clean starting point, you will either need to wait until we have put a long term solution in place, or may wish to look at a solution from Douglas Wilson. Douglas has created a "hypothetical distribution", which you can see via a gist.
Others have also blogged about the problem, and have suggests and insights as to how to overcome this for the short term:
Paul Weller once sang of "a new direction. We want a reaction. Inflate creation." All three could be attributed to why two major events in the Perl event calendar started in 1999, and now happen all around the world today. The two events, The German Perl Workshop and YAPC::NA, both were a new direction for Perl events and specifically a reaction to more commercial events. They both also brought a new creativity to the Perl community.
In 2011 we now have YAPCs, Workshops and Hackathons happening on a monthly basis somewhere in the world. They are still very much organised by members of the Perl Community, and bring together a diverse group of people to each event. They often inspire some to create Perl events themselves. However, that initial enthusiasm is often quickly followed by panic, when the organisers start to figure out what they need to do to make a great event. Which is where a book might help.
The first two posts dealt with tests at the unit and class level. At the package/module level I was able to test the output of Excel::Writer::XLSX against files generated by Excel.
The "Whatever-Star" was at first alarming to me! I first noticed it when I learned how to shuffle an entire list. The Whatever-Star can do some other stuff, too. But that's ok, we'll start with this.
my @shuffled = < alice bob carol dave erik frank >.pick(*);
Now... in the past I've tried ".pick(1)" which gets me one name at random. Then ".pick(2)" will give me two, and not repeat. If I put in too many then it'll only give me back what it can, in this case all six names. But ".pick(*)" ... that doesn't even look valid! The documentation says (though I can't recall where) that it is the same as ".pick(Inf)". When I picked more than there were, it stopped when there was nothing to pick. So this makes sense... try to pick an infinite number and we'll just get them all. Nice. Still kinda weird about the '*' though.
In the p5p discussions of Dave Rolsky's new Perl OO tutorial and OO recommendations, Johan Vromans and others have mentioned
that in good OO programming, one should not violate encapsulation by directly accessing an
objects underlying data structure.
$self->{foo} = "Look Ma! No encapsulation"; # don't do this, they say
In general that is true, but not always, We should avoid absolutist language, especially in tutorials. I'll come to an example of that.
For Nama, I generally use a setter with this syntax:
$self->set(foo => "bar");
The set method (inherited from a parent class based
on Object::Tiny) makes sure the key is a legal one.
Because it looks distinct, I'm not likely
to use it unless I want really write access to that attribute.
This simple approach allows me to manage object attributes culturally, i.e.
without specifying them as read-only or read-write.
In an app of 13k lines, the 'set' method appears just 110 times.
В следующем выпуске YAPP наших слушателей ожидает интервью с Андреем Шитовым - Perl программистом, автором perl6.ru, организатором Московской группы Perl программистов (Moscow.PM), организатором всевозможных Perl мероприятий в нашей стране и за ее пределами.
Мы поговорим с Андреем о будущем языка Perl и его шестой реинкарнация, о перспективах языка, о месте perl-программистов в обществе, о проектах Андрея, его увлечениях, обо все что покажется нам интересным. Если и у вас есть какие-то вопросы к Андрею Шитову, то отправляйте их нам и мы постараемся задать их во время нашего интервью.
Свои вопросы Вы можете писать в twitter: twitter.com/yapp_ru, по почте: yapp_ru@gmail.com, в jabber: yapp@demond.org или в комментариях к данному анонсу на blogs.perl.org по адресу: https://blogs.perl.org/users/perl_demon
The SF Perl Mongers next meeting will be on Tuesday March 22nd, at 7pm. Jonathan Swartz will be introducing Mason 2.0.
Mason is a Perl-based templating framework for generating web pages and other dynamic content. Over the past decade it has been used to generate thousands of web sites large and small, including Amazon.com, Target.com, Salon.com and del.icio.us.
Version 2.0 of Mason was released last month, twelve years after its initial incarnation. It has been rearchitected and reimplemented from the ground up, to take advantage of modern Perl techniques (Moose, Plack/PSGI) and to add long-desired features and syntax.
Jonathan Swartz, the original author of both Mason 1 and 2, will present Mason 2's new architecture and improvements and show how it fits into the modern Perl web development universe.
Having read commentary about coding practices, meditated,
contemplated, posted a blog entry about my app and begged
for constructive criticism, I found my way into a significant
refactoring.
I haven't seen much about the step-by-step
process of dividing and modularizing code.
Here how I am approching it.
The app already uses OO, but suffers from some 260 global
variables and about 6k lines of code in the main namespace.
I broke that code into about 30 different modules, testing
after creating each new module, with the help of git for
source control, and a couple scripts showing which files and
in which subs each variable appears
Most modules still occupy the same namespace,
however have access to only the minimum necessary subset of
global variables. I did this using a structure like this:
[Audio_engine_setup.pm]
package main;
our ( $sampling_frequency,.... )
sub configure_freq { say "configuring soundcard at $sampling_frequency" }
We have a non-Moose class but want to make a Moose subclass of it. In the first post, "Subclassing Tricky Non-Moose Classes: Don't Do It", we looked at a way to extend non-Moose classes without actually subclassing them. It is pretty straight-forward, and typically will cause less headaches.
Sometimes that method might not meet your needs, and you might really want to make a Moose subclass of a non-Moose class. This tutorial will get you started with a couple modules that will help you do just that: MooseX::NonMoose and MooseX::NonMoose::InsideOut.
The nitty-gritty
If you're looking to get your hands dirty and find out how this really works, your first stop should be
Recipe 11 in the Moose Cookbook. It is optional reading for our purposes, though.
It does a great job explaining how to subclass a common, blessed hash, non-Moose class "by hand," and points us to MooseX::NonMoose which handles those details for us.
I also started the traditional TravelTeams Wiki page, which you can find here. If you're planning to come, please consider adding your travel info to this page. Maybe you can meet up with some fellow Perl hacker at your departing airport, or meet somebody in Riga (and maybe share a cab to the hotel...)
Anyway, I'm very much looking forward to this years YAPC, especially since I missed the last one...
I tweeted something last night knowing full well that few people see my tweets
and most of those that do aren't programmers.
So I decided to post here in case anyone else experienced the same problem.
I installed the new LWP (v6) last night via cpan.
The next time I tried to install a module my cpan client barfed red errors (see below).
CPAN::Reporter was erroring when trying to send test results via Metabase.
I updated all SSL modules (cpan> upgrade /SSL/) and installed Mozilla::CA
as suggested in the LWP Changes
(and a tweet by miyagawa).
No luck.
I noticed something else in the LWP Changes file:
For https://... default to verified connections with require IO::Socket::SSL
and Mozilla::CA modules to be installed. Old behaviour can be requested by
setting the PERL_LWP_SSL_VERIFY_HOSTNAME environment variable to 0. The
LWP::UserAgent got new ssl_opts method to control this as well.
so I added this to my .bashrc and all is well again:
The client reported that the site sometimes took more than a minute to load.
Doesn't respond very slowly to me, and the pager is only primed to ping me if
there is a sustained downtime (hiccups are not something I want to wake up for
every night at 3:00am).
Strangely, load hovered around 7 most of the time, only spiking to 13 every
few minutes. With a 16-core processor, this was well within operating
parameters, if just a little worrisome. Nothing in the log files.
Oops, now I get a slow page load. Takes 30 seconds to load a page. Refresh
again, and the page loads just fine. Clear browser cache, and the page still
loads just fine.
Like I said in my previous blogpost, Module::Build has some serious technical problems. This causes another problem that I didn't discuss previously, but that's maybe the worst thing: no one loves it. MakeMaker also has some crazy internals, but it commands the love of a dedicated group of hackers. It's because of that more than anything else that I'm pretty sure its flame won't extinguish any time soon. Module::Build does not have such a luxury; no one seems motivated anymore to maintain it (if you are, do please take up contact with its current maintainer, David Golden). I fear Module::Build is screwed.
