In the world of Perl programming, nothing annoys me more than opening up a module and finding a bunch of POD interleaved with code. I've heard people argue in favor of this atrocious practice, saying that it allows the documentation for a function to be next to its implementation. But if I'm reading the code at all, it's only because I've already read the documentation and it wasn't good enough. That's not meant to be an insult -- maybe I was trying something weird that the author didn't intend, or trying to track down a bug that the author was not aware of.
I work with a small team (in a large company) to maintain a widely used and system critical test automation framework developed in-house. This framework was developed when perl 5.6 was considering cutting-edge, and the archaic techniques of the C programmers who designed the system are readily apparently. As an ardent supporter of Modern Perl this frustrates me on a daily basis.
This framework, and the tests written to use it, encompass nearly 2.5 million lines of code. Because of the horrendous design of the framework, I would imagine that at least a million lines of that (and probably more) is boilerplate. The organization places on on this code and any efforts made to actually improve the sad state of affairs, are almost always rebuffed.
As the first talk in series of talks on form validation, Fred Moyer will present an overview of Data::FormValidator. Real world code examples will be presented, and you'll see how you can use Data::FormValidator to implement form validation for legacy codebases as well as new code. Data::FormValidator is a loosely coupled, highly flexible, and easy to use form validation module written by Mark Stosberg.
This meeting will take place on Tuesday, March 23rd at 7pm at Six Apart World Headquarters.
RSVP at Meetup - http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/12793946/
Fred Moyer's CPAN page:
http://search.cpan.org/~phred/
Data::FormValidator on CPAN:
http://search.cpan.org/dist/Data-FormValidator/
You might recall we made an announcement a few months ago, regarding a deadline. The deadline, 1st March 2010, was the date we had to switch from SMTP to HTTP for report submissions. Since December there has been a lot of work behind the scenes, and some public changes too. Much of the publicly visible work has been done that can be done, while the remaining backend pieces are completed. David Golden has been posting regarding his progress on the Metabase, which will stand as a core component of CPAN Testers in the future.
Sub::WrapPackages 2.0 is a fairly substantial rewrite from the previous version, and may introduce some minor incompatibilities. But what you get in exchange makes it worth it.
The code is now marginally less batshit-insane;
It uses Devel::Caller::IgnoreNamespaces, which I factored out of Hook::LexWrap, so caller() works;
It is better tested;
It protects its magic @INC subroutine from 'use lib'
In Pre-commit hooks and breaking the build, I wrote a little wrapper around 'svn' to ensure that I could locally alter how it functions. However, I hard-coded the name to the actual executable. I should actually be doing the equivalent of $self->next::method to find the next executable in my path. So I wrote the following bash function to give this a try.
The sao-paulo.pm group is releasing this month the vernal equinox calendar, with daily articles until the day and night are equally long :). The articles are in Portuguese and the idea is spread modern web development using Perl to Portuguese speakers.
A quick announcement. A couple of months ago I brought up a problem with Dist::Zilla in that it had no way to stop modules from being indexed that are included in the distribution for testing or example purposes only. Ricardo gave me a work around, but I decided it was time to actually implement a real fix. So today I've released Dist::Zilla::Plugin::MetaNoIndex.
Adding this to your dist.ini:
[MetaNoIndex]
folder = author.t
Will add a section to your META.yml file like this:
no_index:
directories:
- author.t
Which will stop PAUSE/CPAN from complaining at you about Foo.pm or whatever other classes you might have created for testing.
I just started using Search::GIN a while ago and it's a lot of fun. It's also an amazing example of how to write code correctly, using roles, abstraction and introspection. Reading the source is illuminating.
Search::GIN 0.04 has a few fixes that existed for a while in the Github repo but were not uploaded to CPAN.
There is now some docs on writing queries to help beginners. Hopefully I'll get around to documenting the extractors and write up some usage examples.
A major thanks goes to Stevan Little which helped me understand KiokuDB and Search::GIN and Yuval Kogman for writing these great tools. :)
Based on an explanation from Aristotle which has worked for me, here's one way you can make blogs.perl.org work a bit better for you. I've approved these and they seem to be OK.
As you may know, anonymous commenters are getting "Text was entered wrong" errors. This is because of a currently undiagnosed error with ReCaptcha. To work around this:
Log in
Click "POST"
On the next page, select "Comment" from the preferences menu
At the top, where it says "Immediately approve comments from", make sure that "Trusted commenters only" is selected
Further down where it says "E-mail Notification", select "On".
Near the bottom where it says "CAPTCHA Provider", select "None"
Now select "Registration" from the "Preferences" menu.
For "Authentication Methods", make sure "Anonymous Comments" is checked.
Whenever someone posts to your blog, you should be emailed notification. If they're "not trusted", you'll have to approve their posts. When you do, you'll have the option to make them a trusted commenter and not have to approve their posts again.
Open development seems to be percolating into the arts. A friend of mine, MG Lord, is on a team
commissioned by the LA Opera to write an opera about LA's 110 Freeway.
They (MG, her co-librettist Shannon Halwes, and composer Laura Karpman)
are putting 110 on the Web one aria/overture/intermezzo at a time,
as they workshop it. In effect, they're blogging the opera.
Have you ever needed to create an application server quickly? Maybe you tried SOAP? It's never a fun experience, and if you're like me you may have ended up reinventing the wheel a lot due to poor quality modules on CPAN, or confusing documentation. Today I'm announcing JSON::RPC::Dispatcher. It's a super easy way to create JSON RPC 2.0 web services. It's built on top of Plack so you can easily deploy it anywhere you need.
How easy is it to create an app server? This easy:
Yesterday and today I released to CPANCantella::Worker and Cantella::Worker::Role::Beanstalk. I am very happy with these two packages. They are the culmination of about a month of on-and-off playing around with different approaches to having distributed event-driven worker processes. As an added benefit, I can also run a pool of beanstalkd servers in case I need to bring one down for maintenance or I have some unexpected downtime.
One thing I love about git it how you have control over your local environment. Need a pre-commit hook? Just add the damned thing. Need it for Subversion and you're not the admin of the subversion server? Sucks to be you. Fortunately, having a reasonable command line lets you work around this. And I needed to because I broke the build. Twice. In a week. Buying the donuts for this would be slightly less annoying if it weren't for the fact that I get to "enjoy" low-calorie yoghurt bars instead. (Though I'm now below 82 kilos for the first time in a couple of decades).
So no more breaking the build. Right. On my previous team, if I needed a module, I could usually add it. On this team, it's a bit painful, so I just use what I need locally and then break the build when I forget and commit use Test::Most 'die';. So I wrote a little bash scrip to make svn less brain-dead.
Last week I started using github, forked a project, and read some of miyagawa's beautiful code. Later on the weekend, I imitated a particular style I found from his code to improve my own code.
And then I realized: during the course of many years as a programmer, I really really seldom read other people's code, especially real-world code. Sure, I do whenever I have to patch something. But other than that, practically never.
Other than code, I do read an awful lot: books, magazines, mailing lists, forums, blogs, web pages. I have never doubted the benefits of reading for improving knowledge and understanding, so why haven't I read more code? A couple of reasons I can think of:
1. We programmers are not paid to read code. We are paid to write programs, to churn out lines upon lines of code. Heck, we're not even paid to write good code, we're paid to get the job done.
Not thinking that any Perl books would be available for Kindle, I searched anyway. I can get at least Learning Perl and Mastering Perl from the Kindle store. I'm thinking about this because I'd like to see what I can do with an iPad Kindle app.
I'm on a trip with severe weight requirements for luggage, so I've been trying the Kindle app for the iPhone. It seemed weird at first, but after a couple chapters of the first book, I don't mind it anymore. The tech books are a bit different. If you're used to the beautiful and understated typography that is one of O'Reilly's hallmarks, you're going to think the Kindle is a bit odd. I think I have it slightly nicer on the iPhone, but it's still different.
I've been a google user ever since giving up AltaVista back in the day. I've heard good things about bing, laughed at their funny TV advertisements, and have deep-down (in a weird sort of way) wanted a search product from M$ to be a success.
I decided a few days ago that I'd give bing.com a try for a complete month - to see if it could win my heart. After 2 days I must say that I'll be going back to google.
I was reminded of the "Perl is Alive" meme last night after watching this video. I decided to search for Perl is Alive on my now default search engine to see how wide-spread this effort/search term had become.
The only thing conceivably unique? It's triply-linked, thus allowing multiple traversal orders. I'm confused. How is this different from a directed graph?
Many years ago, when I was... roughly 15 (I think), I met Theodor Ts'o (one of the first hardcore Linux Kernel hackers, since version 0.90, I believe) at a Linux event IBM organized in Israel. I should note that he is a very nice person.
After the event, we got to talk a bit. We talked about our favorite games. Mine was "avoiding segfaults". This was back when I was programming in C.
Today I wrote the following regex: qr/^([\w|\.]+)\s+(?(\d+)\s+)?(\w+)\s+(?:(\d+)\s+)?([\w|\d|\.]+)$/;
Then got a Segmentation fault
Can you spot the error?
Here's a hint: it is missing a colon (:).
This is perl, v5.10.0 built for i486-linux-gnu-thread-multi
