I've written a couple articles on encapsulation
issues in perl OO, especially with regards to
home-grown versus full-framework OO.
I am told that finding my own solutions to
get the behavior I want may lead to poor
(dirty, unreliable) code when a better solution
could come through a framework such as Moose.
I rolled my own perl OO for Nama, a multitrack audio recording app I've written. However,
I'm ready to consider introducing an OO framework for the
sake of learning, code quality, testing and maintenance.
Provided that I can find satisfactory ways to solve my problems.
Here's a laundry list of (just two) OO features that I'd
need or want to implement in a Mooselike framework.
One is short and simple to describe, the other will
take several paragraphs.
By far my most popular module on CPAN has to be Facebook::Graph, and this is an interesting week for Facebook::Graph, so I thought I'd post a little blog about it.
For anyone who may have been affacted by the upgrade to LWP, the situation should now be resolved. David has put in place a 3rd party verified SSL certificate on the Metabase server, so all submissions should now be able to resolve certificate authenticity.
If you have implemented any short term fixes, you may need to remove them, before accepting the new certificate.
We now return you to your scheduled programming :)
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...
