Salve J Nilsen will give a talk at YAPC::Europe 2012 described as
Whatever you call a technical community (mongers, masons, monks, mongrels or misfits), there's some work behind organizing one. The speaker has been involved in one of these groups - Oslo.pm - for almost 10 years, and in this time gathered a few impressions on what works and what doesn't.
In this talk we'll explore some of the events Oslo.pm has organized, share how they turned out and try to figure out why they went well - or didn't. We'll touch upon topics like money, volunteering, burn-out and the importance of fun.
But this isn't an Oslo.pm talk only! We'll also make room to for other .pm group members that have something to share! Bring your experiences, or if you haven't any - bring your questions and curiosity.
If all goes well, we'll end up with some ideas for an even better community! :D
The last update on the news feed for
The Perl Beginners's site was almost a
year ago. While the site continued to improve, I neglected writing a new
entry until now, so I hope this one will compensate for that.
So without further ado, here is what is new:
We now have a page about Perl
Humour, which was restored from a page in the now offline perl.net.au
wiki.
One person asked what the sponsors use Perl for. Here you can find the first answers...
Webfusion
Here at Webfusion, Perl is at the core of our business. It delivers web pages, communicates with internal and external APIs, builds servers, registers domains, configures products and services, and even makes the tea! (That last bit might not be true ... yet!). Our systems are developed in-house, using the best of CPAN, including Catalyst, Moose, DBIx::Class, Plack among many others. Our websites are delivered via Catalyst and mod perl applications, and most of our underlying system and networking tools are written in Perl.
All our customer's domains are registered and managed using Perl. All our server hosting is implemented using Perl from building the basic servers, to managing the applications installed as part of our shared web hosting packages. We make use of many 3rd-party products to help you design, develop and protect your website, create and use online mailboxes, all of which are configured and managed using Perl.
I happen to be a TDD proponent. Now, right there I’ve probably lost about half of you, and the rest are probably going, “okay, yeah, get on with it.” TDD is one of those things that people either love or hate. For a full meditation on the ins and outs of technical hype, I’ll refer you to my other blog. In the meantime, if you’re one of those people whose sneer at the thought of TDD is still stuck to your face, I’ll ask you to indulge me for a few more paragraphs (two of which are only one sentence long). After that, if you still feel like TDD is the stinkiest thing to come along since Pepé Le Pew, you can either jump over to the link above, or just continue on, mentally subsituting “TDD” with some technical process you actually like. Or, you know, find something else to do entirely.
At the French Perl Workshop (and probably elsewhere before), Matt Trout talked about why and how some ideas could succeed and most other fail. An interesting talk. The last part was a rant against the numerous modules on the CPAN to parse command-line options. His proposal was to do the same thing to command-line programs (CLI) than PSGI did to web applications: formulate a generic specification, that developers can use to build applications and not depend on a specific implementation.
A very interesting idea. We were a few (BooK, cmaussan, niels and myself) to begin thinking about what this PCLI specification could look like. I wrote down on paper what I've been doing in the numerous CLI programs (for a broad value of the terms) I wrote over the past years.
"You get to create your own world,
and the only thing that limits what you can do
are the capabilities of the machine --
and, more and more often they days,
your own abiliites"
Linus Torvalds, Just For Fun, p. 74
As of
Marpa::R2 2.010000,
Marpa has two new, documented, interfaces.
(For those new to this blog,
Marpa is something new in parsing --
it parses anything you can write in BNF and,
if your grammar is in one of the classes currently in practical use,
parses it in linear time.
Marpa's parse engine is written in optimized C,
so that Marpa's speed is competitive with parsers of far less power.
Marpa's stable version is
Marpa::XS.)
Announcing Marpa's C library: Libmarpa
The first new interface is Libmarpa, a C language library.
Previously, Marpa's only documented interfaces required the
programmer to use it
through Perl. Using Marpa through Perl had major advantages --
it gave the programmer convenient access not just to Perl's capabiliites,
but to all of CPAN as well.
Shawn Moore will give a talk at YAPC::Europe 2012 described as
Roles are one of the most exciting and powerful features provided by Moose, but also one of the most misunderstood. This talk will explore, in depth, some common usage patterns (and antipatterns) for roles and how best to use them in the design of your classes. I will also talk about the philosophy of roles and how they fit in with the larger OO toolset.
While I was browsing the CPAN the other day, I came across Coro::LocalScalar and I said to myself, oh, what a useful idea… it lets you localize globals to a thread. An important feature if you do anything in your thread with those pesky globals from perlvar, for instance.
But, said I, its calling convention is the rather gross Coro::LocalScalar->new->localize($scalar); and it’s implemented using tie and only for scalar values. It would be nice to have a new keyword and support for arrays and hashes as well. As it happens, I’d also recently run across Begin::Declare, which is a Devel::Declare based module that provides custom variable declarations.
A few hours later, with the example of Begin::Declare to work from, I bring you Coro::Localize (now on a CPAN mirror near you). It’s localization is achieved through a combination of Coro’s on_enter /on_leave blocks and Data::Alias.
If a distribution contains multiple modules, how should VERSION be set in each module?
There are a number of options:
Every module has the same version number, and it's the version number of the dist.
Each module has its own version number. The version number of the dist might be different from all of them, or it might be take from the lead module, if there's an obvious one.
The lead module has a version number defined, but none of the other modules have a version defined.
The first option makes most sense to me, and until recently I thought it was the approach most people follow. Sure, it's a pain updating version number in every module for every release, but Dist::Zilla (and other tools?) can handle this for you automatically.
This question came up recently on the comments of a blog post. I can’t really answer that question. What I can try and answer is how to get more recognition as a Perl programmer and how to create a public portfolio, making it easier for you to find a job.
This is mostly a clean up of what I originally wrote in the comment, and I would thank you to add your own comments. John Napiorkowski has proposed a recruiters resource page on Perl.org and is working on how such a page would look. This information might be useful for a counterpart to it, completing both questions of how recruiters could reach programmers and how programmers can be more visible to recruiters and other viable employers. John has written a first post on his website. That’s a good place to start.
David Leadbeater will give a talk at YAPC::Europe 2012 described as
The RE2 regular expression engine uses a data structure called a trie to match regexps. However perl itself can use this data structure under certain circumstances. We'll investigate Perl's behaviour, apply some insane optimisations and compare with RE2 (via re::engine::RE2).
Due to server issues last night, a number of people were unable to submit their surveys. As such I have now reset the deadline to midnight on Saturday, so you have an extra day to complete your surveys and evaluations.
Unfortunately, the backup process ran last night and filled up the disk, as I hadn't gotten around to archiving the backups from past few weeks on to the main backup server. Many apologies for any inconvenience caused.
Rest assured, the automatic backup update has now moved higher up my priority list :)
Last month I was lucky enough to attend YAPC::NA in Madison, WI. Among the many spectacular talks, impressive people, and events there was a raffle that took place for conference attendees. With all proceeds going to the Perl Foundation, I contributed $100 and threw my raffle tickets in to two buckets: lunch with Larry Wall and some ThinkGeek swag.
Unfortunately, I didn't get to dine with the great one, but at one of the evening events I did win the ThinkGeek grand prize: a remote controlled outdoor helicopter (picture at right).
Now, at the time, I was slightly underwhelmed. My first thought was, "Wow! I won! Wait .. I won? How am I going to get this thing home?" My second thought was, "What the heck am I going to do with a remote controlled helicopter!?"
Windows are the main element in any Prima application. Windows belong to the Prima hierarchy, but at this time we are interested on windows simply being windows.
Prima offers two basic types of windows: the MainWindow and the Window. The main difference is that destroying a MainWindow will destroy the application, causing the closing of any related windows, dialogs, while closing a Window does not destroy the application.
The creation of both types of window requires some minimal setting. Many others can be used to get the look and feel and the behavior intended.
The settings are of two types:
Parameters indicate properties of the new window, as size, the text to be shown on top, the menu to be shown, color of the canvas, status of windows as e.g. maximized or minimized, border colors, and so on
Events indicate the way the window would react on events. The one almost always present is the paint event, which shows the operations that are performed when the window is created and then painted
The Lacuna Expanse is a massively multiplayer empire builder game written in Perl. Long ago we open sourced the iPhone and web clients for the game, today I'm pleased to announce that we're open sourcing the server as well.
Some of you may be asking, "Why would you do that?" and "Does this mean you're shutting down the server?"
No we're not shutting down our server! As long as it's at least paying for itself, we'll continue to host the server and all related infrastructure forever.
