Whenever I start on a new team, there's one thing I want and never get. I'm not a betting man, but I've even bet that this thing I want won't happen. I've never lost that bet.
When I started writing the new Test::Harness, I had a .perltidyrc file which, while not perfect, allowed me to easily format my code with the following vim mappings:
nnoremap ,pt :%!perltidy -q<cr> " only work in 'normal' mode
vnoremap ,pt :!perltidy -q<cr> " only work in 'visual' mode
Do you find Perl 6 interesting, but maybe not very accessible? Would you like to contribute half an hour of your time, if it doesn't involve learning a few new languages and weird parrot assembler langauges?
Then participate in the Perl 6 contribution challenge. No sign-up required, and there will be one task per week with which you can actually help the Perl 6 users and developers without needing to dive too deep into compiler guts.
The first challenge can be done all in Perl 5.
Any questions? Then ask. And fire away.
I've just released Marpa, a general BNF parser generator, to CPAN. (A general BNF parser generator is a parser generator which works for any grammar you can express in BNF.) Previously, CPAN did not have a general BNF parser generator suitable for practical use. Then again, neither did much of anybody else.
What was the issue? General BNF parsers have been around since the 60's. But the first ones were slow, and the reputation stuck. It's time to take a new look. As Wikipedia says, Earley's takes "linear time for almost all LR(k) grammars. It performs particularly well when the rules are written left-recursively."
LR(k) grammars include all those parseable by Bison, YACC, recursive descent, or regular expressions. Chances are that Marpa runs in linear time on your grammar, or can easily be made to do so. If Marpa doesn't run your grammar in linear time, chances are that the alternatives you are considering do not run your grammar at all.
Sebastian Wernicke gives a wonderful TED talk on constructing TED talks. He looked at all available TED talks with their popularity, and he was able to extract certain elements that made each talk either popular or unpopular. These factors might be the particular words used, the color of the slides, or what the speaker wore.
From his analysis, he was able to create a formula for the perfect (or worst) TED talk. Although he's doing it as a bit of a goof, he actually makes some good points that people might consider about making their talks.
There's still time before the summer conference season to use his suggestions for your own talks.
Forum software is frequently awful. In trying to write a minimal version on my own, I've discovered that mine is just as awful, so I'd rather use someone else's awful forum software. I'm sure it will be less awful than mine. Naturally, I'd prefer it to be Perl as I can hack on it if need be.
Unfortunately, this is to be integrated into an existing Catalyst application. Integrating multiple Catalyst applications into a single application isn't an easy task. There's CatalystX::Features, but I've not yet looked at it terribly closely. I think a better solution would be to find an existing, solid forum application and use Apache URL rewriting to make the two apps appear to be integrated.
Regardless of what approach I take, I really don't want to keep trying to write my own forum software. That's a waste of my time. What would you recommend?
... are now uploaded to flickr
First, the meeting:
I arrived a bit late but hadn't missed much. Gabor was in the middle of explaining the benefits of getting Perl on Android. He went over a lot of API examples, showing code and explaining and doing a damn goo job at it!
After that, I tried to explain how to install the Android emulator on a Linux machine, configure it and run it. My slides weren't displaying properly on the projector so it was annoying to explain and probably harder to understand.
Then Shmuel went over perl512delta and explained to us the bigger differences and their implications. He said "... because someone had to do it" - and I'm happy someone did.
Regarding more Perl on Android:
Some of the Chicago Perl Mongers got together for drinks last week. We started at one place, decided it was too crowded, went to another, and finally ended up at the Billy Goat Tavern, along the way talking about all sorts of different things, some of them Perl.
That's the best sort of Perl mongers meeting, and was always my intent with the idea. Put a bunch of smart people together in an unstructured environment and let the conversation go where it will, often in unexpected directions. Although some people might call this "networking", I prefer the no-label version. It's not something that you get out of a group of people watching someone go through a slide deck.
I had just watched Cal Henderson's "Why I hate Django" talk, and it makes for a lot of interesting conversation. The hook is the normal geek bonding over hating something (anything), but despite the comedy Cal has a lot of interesting things to say about web application architecture. Indeed, most web frameworks have these same problems (including all the Perl ones I think).
The talk mostly speaks for itself.
Lately I've been tempted to use croak() instead of die(). Somehow it seems more considerate to users. But finally in the end I'm sticking with die(). In fact, I think the Carp module should be, well, croaked.
The reasons:
1. Even though Carp has been included in Perl 5 since forever (Module::CoreList tells me: "5"), carp(), croak(), cluck(), and confess() are still not builtins, which means I still need an extra "use Carp".
2. Too many keywords! Most other languages only have "throw" or "raise".
3. Names are too weird! I understand the difficulty of coming up with a concise set of names that are similar but slightly different. But requiring these weird names might also indicate that there is something fishy about the concept itself.
4. The choice of showing a stack trace or not should not be in the individual functions. That burdens the programmer with too much thinking.
5. Even with Carp qw(verbose), what's to be done with codes that still die() and warn()? (But luckily there's Carp::Always.)
Too lazy to copy&paste, read more here!
Often times I find myself wondering how Open Source is even possible. How does something so amazing as CPAN get built and maintained and perfected?
I think I figured it out, at least one part of it.
It is possible because there are a lot of smart people out there being employed by employers who have no real idea of what is required in any given project. Therefore, programmers who have
can contribute amazing feats of collective heroism day in and day out, without having to worry about how they are going to pay for new shoes.
And then of course there is boredom. And the sheer enjoyment of coding. And altruism.
A few days ago Shmuel Fomberg (who organizes Haifa.pm) wrote in the Israel.pm mailing list: "Sawyer is doing so many interesting things currently, that it is ridicules. Sawyer, please take a long vacation to let us all catch up!".
While this truly flatters me, I reckon that's how I think of a lot of other developers (and I'll refrain from the usual name-dropping I'm accustomed to). Whatever I play with is always minimal in comparison to the stuff I see in the Perl community. This includes both Devel::Declare and the amazing Perl Onion Pillow.
When you're thinking of packaging every piece of code as a CPAN module.
A couple of days ago I need a subroutine that takes a nested data structure (e.g. {vol1 => {a=>{b=>{c=>10}}}, vol2 => {a2=>{b2=>{c2=>20}}}}), a Unix-like path string (e.g. "vol1:/a/b/c") and return the branch/leaf node of the data structure according to the specified path (in this example, 10).
After browsing CPAN and a few minutes of reading the POD of some modules and not finding exactly what I wanted [*], that subroutine idea quickly transformed into an idea of a full-fledged CPAN module. The next day I uploaded Data::Filesystem to CPAN, which is actually yet another Data::Walker- / Data::Path- / Data::DPath-like module.
Watch out for [Help Vampires](http://slash7.com/2006/12/22/vampires/).
Its a magazine most of you here would not read, bacause it explaines most of the time basic perl stuff. But many of you, I guess, care that there is a beginnerfriendly Perl publication. So do I. Thatswhy i wrote 2 articles for this isssue. About Perl 5 references and one about Perl 6. Also Perl beginner have a right to have a broad overview what is perl 6 about and how it is going. I think I never summarized it in such simple terms before. Maybe that spark your interest? :) But its written in German, as the name suggest.
Many people have been seeing the cryptic error message "Text Entered Was Wrong" when trying to use this site. It was caused by MT expecting to see the response from a CAPTCHA which wasn't being displayed.
It's taken us a while to get to the bottom of this problem, but we think that we have fixed it now. We think that the CAPTCHA will now be displayed in all of the circumstances when MT thinks it has been displayed.
Sorry for the inconvenience this has caused. Hopefully this will allow a larger selection of people to use the site successfully.
As always, please let us know if you are having any problems with the site.
I'm only a year late with this post; I wrote it in the airport in Moscow on the way home, then it never made it onto the blog. I need to published it before the next YAPC Russia, which is June 12-14 in Kiev this year.
This might be the only YAPC::Russia 2009 report you read, if only because I was the only presenter in english and maybe the only one writing about it in english. While everyone else's english got better over the conference, I think my Russian got worse.
The best reason to go to a conference is to meet new people, to see new places, and, oh, sometimes to see new code. The more interactions that we can get between the different parts of the physical world the better. If you always go to the same conference, you might be limiting the people you can meet.
**Realmente existen muchas formas de hacer esta misma tarea con Perl,
ilustrare las mas rapida usando el modulo Template::Toolkit que segun mis estadisticas viene instalado por defecto en todos los hosting CPANEL..
Si quieres ver si el modulo, entra a tu Cpanel y en servicios entra a modulos de Perl, luego ver modulos instalados en el sistema **
.
Every time I set up a DBIx::Class schema for a project, I find myself re-implementing the same pattern. While DBIC is one of the great things about modern Perl, it requires a lot of typing. Whenever I want to grab some stuff from a table, it's
my @records = $schema->resultset( 'CamelCasedClassName' )->search( ... );
Today, I used DBIx::Class::Schema::Loader to auto-generate a schema for a fun little 182-table database. I ended up with modules with names like MyApp::DBIC::Result::XStreamQueryParentArticle and MyApp::DBIC::Result::ArticleElementContent and so forth. Very useful, but what painful nomenclature.
So I ended up doing the same little hack that I always do, but improved upon it a bit this time, and have finally arrived at a solution that I really like.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
