Nick Patch will be giving a talk at YAPC::NA 2012 described as:
UTF-8 is the most popular character encoding on the web and has been for 5 years. Modern applications have to be developed with an understanding of Unicode, and this raises a lot of important questions since the good old days of ASCII. What is a character? … a code point? … a grapheme? This talk will bring you up to speed on character codes, Unicode, and UTF-8.
[From the YAPC::NA Blog.]
I love Log::Dispatchouli. I really do. I does a lot of work so you don't have to, and that's usually the type of stuff rjbs does.
After using Log::Dispatchouli for two projects, I decided to refactor it. No point in having code duplicity, right? So I refactored it into a role and called that role MooseX::Role::Loggable. That code is obviously on CPAN and has been for quite a while.
Once you add MooseX::Role::Loggable to your app you can suddenly have logging, the way Log::Dispatchouli does it. How? You suddenly have a debug attribute, for example. You suddenly have a logger_ident and a logger_facility attributes that you can override (though they have default values, one is of your package name automatically). You can now call the log method, and the log_debug method that will log only if the debug flag is on.
It's so simple I've set up all applications at $work to use it.
Why you should use? Well...
MooseX::Role::Loggable - try it!
united-domains AG joins this year's YAPC::EU as a Gold Sponsor. Thank you!
united-domains AG is the specialist for fast and simple registration of domain names with over 270 top-level domains.
Our core product is the unique "Domain Portfolio", a web-based software tool for managing domain names. This Domain-Portfolio is used for management and configuration of all domain name of a company or a private person, regardless of which provider the domains has been registered with. The "Domain Portfolio" becomes the personal control center of the client. In our domain portfolio, we manage over 1.5 million domain names of more than 250,000 customers.
Since 2011 united-domains serves clients in the North American market with its own subsidiary located in Boston (USA).
The PDL community has been buzzing with activity as they prepare for the 2.4.10 release.
For those of you who are unaware, PDL is the Perl Data Language, which gives Perl numerical array processing power. Implemented in C these computations are very fast, and with its sublanguage PDL::PP you can easily write your own C implementations of numerical algorithms too.
One of the things coming in this release will be the companion PDL::Book. Its been entirely written by the developers specifically for this release. The source is all in POD of course.
Chris Prather will be giving a talk at YAPC::NA 2012 described as:
Most Perl developers are employed by large corporations, but many dream of what it would be like to strike out on their own. Tamarou is a company that has done just that, and we’re here to tell the tale of what it’s like.
It’s been a wild ride so far, and we’ll discuss the illicit details of what we’ve learned over the last two years, and what we probably should have learned.
[From the YAPC::NA Blog.]
Happy new year, Gong Hei Fat Choi ( seems there's more than one way to type that! ). I only added that in so we can claim we got a new Padre release out just after the new year... not saying which new year though...
It has been a while since Padre, the Perl IDE version 0.92 was released. The last release was november last year!
It became clear that Padre would not be ready for a pre-Christmas release, Adam Kennedy wanted more time to work on the bits of Padre that needed work. Looking at the Changes file, there was plenty.
This release should really be dedicated to Adam, the Changes file is testamony to this.
I asked Adam in IRC what the main items for this release were:
The march towards 1.0 continues for Padre, and the latest release represents a big step towards that goal.
Over the last couple of months there has been a huge focus on the core editor GUI features, and making sure they are all as glitch free as possible and high usable for day to day operation.
This focus on polish is particularly evident for me in the Find and Replace related code, which is smoother and more functional than it has ever been.
I find myself routinely leaving syntax checking and version control markers on now, where before their various glitches would make them too annoying for me to use.
The other exciting improvement for me in this release is that all the parts of Padre needed by the Padre::Plugin::FormBuilder plugin now work properly.
This means that I can finally do a long-awaited "proper" production release of the Form Builder plugin, and finally bring cross platform GUI generation to the masses.
Finally we've received the contract signed by both parties. We are really happy to now be able to publicly announce the date and venue of the YAPC::Europe 2012.
The YAPC::Europe 2012 will take place from Monday, the 20th of August to Wednesday, the 22nd of August at the Johann Wolfgang von Goethe Universität, on the Bockenheim Campus in Frankfurt am Main.
We will post further information about the venue soon on this blog.
We’d like to thank our sponsors for stepping up to support us. We really couldn’t do this without their support.
You too could sponsor YAPC.
[From the YAPC::NA Blog.]
Out of the box, Lucene does not provide exact field matches, like matching "Acer Negundo Ab" and only "Acer Negundo Ab" (not also "Acer Negundo Ab IgG" ). Neither does Lucene provide "Starts With" or "Ends With" functionality. Fortunately, there are workarounds.
The trick is in the indexing. When indexing a field in Lucene, you can enclose a field's value with known delimiters, for example "lucenematch Acer Negundo Ab lucenematch" (where "lucenematch" is the delimiter string). As long as the delimiter appears only as a delimiter, you can safely assume that a search using "lucenematch Acer Negundo Ab lucenematch" on a field will return only documents whose default Lucene field exactly matches "lucenematch Acer Negundo Ab lucenematch" and not those matching "lucenematch Acer Negundo Ab IgG lucenematch".
Both publicly and privately I hear from folks who tell me that Marpa is an OO superclass waiting to happen. I can see their point. If there ever was a case for code reuse, the Marpa algorithm is one. On the other hand, any non-trivial use of Marpa requires additional semantics, so that the Marpa classes walk, swim and quack very much like abstract type classes.
Furthermore, the additional semantics that Marpa needs comes in pieces -- semantic actions. And even though these pieces often share little code with each other, they interact heavily as part of a specific structure. This means that their semantics are tightly coupled, both to each other and to Marpa. In short, Marpa's semantic actions look a lot like the methods of a subclass.
While I'm rambling about AnyEvent (which I'll probably do more often), here's a note I'd like to give myself.
I'm using AnyEvent in a big app with objects (objects are, generally, good!) and I have a lazy attribute (lazy attributes are good!) of an AnyEvent timer. This is so the timer doesn't lose scope and will be closed.
At first the constraint was a EV::Timer object. On one machine this failed the type constraint while on another it worked. Some of you already know why. Then I changed it to a generic Object. This failed one as well. Why?
Because AnyEvent is basically like a hub for many event loops (ANY event loop, get it?) and apparently on one machine it used EV (a high-performance kickass event loop written by Marc Lehmann) while on another it hadn't. This meant that one AnyEvent->timer() returned an EV::Timer object while another returned an Array Reference. I removed the type constraint complete. It's now good. :)
You're wrong! How does it feel to be wrong? I've never been and you look like someone who would know!
uh yes I have a running grant and want to close it in 2012 even it will take much more effort than just written down in the proposal. I was a bit shy with that to don't get rejected. I don't want to open any new projects til I get this done.
Recently I updated Index A, which is still the most usable part, because its a quick overview of all builtins and operators. There were tons of details I did: setting new links, cleaning up things I didn't understood myself exactly, making better examples, more "see also" for similar commands. There were even some Perl 6 commands new to me, which I added and we are currently approaching the entry number 650. But the most important bit was: I understand the strange socialtext wiki syntax a bit better, so I could insert a lots of anchors inside of lines. So not only similar terms are now interlinked. Even better, many (and soon every) commands can be linked from outside which is good for automatically generated links if you need some quick explanation to a perl 6 term which is linked to an even more detailed explanation and to tables where it is summarized with similar things.
Thats the link-syntax for the builtin "if":
http://www.perlfoundation.org/perl6/index.cgi?perl_6_index_tablet#if
I came along this crazy code.
But first some short explanation. The perl compiler B::C saves the state of any program at CHECK time, and runs it later. That means every action in BEGIN blocks is frozen and then thawed on a potential another machine in later time. Not all action can be frozen/thawed as we know from the common modules Data::Dumper or Storable
The compiler is better than those. It can restore regular expressions which Storable cannot. It can save the state of some IO object, which Data::Dumper can not. It can save the whole dependency tree of code. Data::Dumper or Storable can only save data, not code along with it.
But some actions are really a bad a idea to be restored at run-time.
1st sample:
my $f;open($f,">&STDOUT");print $f "ok"
This is trivial. The fileno 2 is dup'ed to $f. All at run-time. Nevertheless you will not be able to freeze/thaw $f. The compiler can.
Recently an article was published that claimed Perl usage in websites had dropped below 1%. For a Perl developer this seems ridiculous on the face of it. As it turned out, it was ridiculous, since the error margin was 17.6%. Meaning that for 17.6% of the sites they surveyed they could not even detect that they were using Perl. And they only survey the top 1 million, out of the 175 million active sites Netcraft reported. So the validity of these numbers is highly suspect.
So, all is fine? Catastrophe averted? Heh, not really.
Here's the issue: To a Perl developer this might seem ridiculous. Most of us are aware of how many websites use it under the hood. But to the average person it seems perfectly reasonable. The suffixes ".php" and ".asp" are ubiquitous and lets everyone know what the website is running on. Ruby and Python operations are proud of using their languages and flaunt it. To an average person it might even seem like there are more Ruby and Python websites.
Yet Perl is practically invisible. It drives a lot of sites, businesses and livelihoods worldwide, neither of which make any indication of the tools they're using. Let's take a look at a random sampling:
| Site | Alexa Rank |
|---|---|
| imdb.com | 37 |
| booking.com | 245 |
| cpanel.net | 1,710 |
| blogs.suntimes.com | 2,171 |
| net-a-porter.com | 2,195 |
| lovefilm.com | 3,149 |
| liquidweb.com | 7,776 |
| slando.com | 25,266 |
| socialtext.net | 145,896 |
| bestpractical.com | 161,366 |
| metacpan.org | 172,291 |
| hiveminder.com | 295,127 |
These are sites that run on Perl, but to look at them you'd never even know it. Perl has advanced route dispatching mechanisms and its great modularity makes it possible to write an entire website as a single application. In fact, for most modern Perl web frameworks it has become customary to run web applications as self-hosting services to which a web server connects via a network port. Perl has made it very easy to design one's url structure exclusively around the data one serves, which has made it entirely impossible to tell for most Perl-driven sites that they actually are Perl.
Now, all of these sites have reasons to be proud of the tools they use. Some of them indeed are very proud, booking.com for example has donated 150.000 USD last year to Perl development and others on the list have donated smaller amounts as well or are supporting Perl conferences and spend a lot of money to have a presence on Perl conferences. Those on the list who are hiring, are also hiring Perl developers, some of them quite prominently. Even others on the list are websites created for the express purpose of serving the Perl community.
Yet none of them even mention Perl on their frontpage or even link to perl.org. I know Perl doesn't have nice and easy promotion buttons like Python or PHP do. But a simple text link does the job just as well. Just a simple "Built with Perl" in the footer or a sidebar would show that you care about Perl, would make it easier for job seekers to notice that you're looking for Perl devs and would raise the visibility of Perl and make it a more appealing choice for students looking to learn a dynamic language.
I do not believe this is done out of any maliciousness and that it's rather just a simple oversight, something that was never considered. As such i've sent a small email to each of those sites, asking them to consider this issue and to please add a link to perl.org or to weigh in on why they would not do it. Maybe they are issues that the Perl community can fix.
Similarly, if you own a site yourself that runs on Perl and does not link to perl.org:
Why does your site not link to perl.org?!
Jacinta Richardson will be giving a free workshop at YAPC::NA 2012 described as:
When people hear I learned POE much faster than AnyEvent, they're usually surprised. I don't know why, but POE always made a whole lot of sense to me than AnyEvent. I've used POE in several projects (some pretty big) and it was always easy to work with, always had every component I wanted (except the SSH I wanted, though that exists too now) and the community was totally supportive and helpful. This is not unlike AnyEvent, though. I just haven't used it much.
Recently I started using AnyEvent. Not because I don't like POE anymore but because I wanted to be familiar with both. I have to say I felt quite at home with AnyEvent and started to write more and more elaborate stuff with it. I'm also trying to find more stuff to do with it, though it feels suited for more hardcore people than I. I have no idea where to start if I wanted to write an AnyEvent SSH client based on Net::OpenSSH, for instance.
If you've ever used AnyEvent, I recommend getting familiar with POE. Rocco Caputo and the community have done amazing work on it.
If you've ever used POE, I recommend getting familiar with AnyEvent. Marc Lehmann and the community have done amazing work on it.
I don't want this blog to be political, so all I will post here is this: I have posted some views on SOPA on my non-Perl blog. If you would like to read them, click here. To paraphrase Wikipedia, although this blog is neutral, its existence is not. Thank you.
Lately I've been choosing Indonesian names for my software projects/codenames, beginning with Sah, and then Rinci/Perinci, Riap, Serabi. Others will certainly follow. These names are words straight from the dictionary, but I plan to extend to proper nouns like island names (we have 17k+ of those!), characters from traditional stories, words from dialects (why, we have hundreds of living dialects too!), famous people, and so on.
The first reason for this is running out of good, distinct English names. Since we have already come to the point of picking household names like "cucumber" and "tasty pie", why not use these household names from a different language altogether.
The second reason is to catch up. Why should non-Indonesians have all the fun picking Indonesian names? :-) This blog post will also lists software projects/products with Indonesian names. I will separate the list as two, those started by Indonesians and those which are not. I will add to the list when I spot new ones.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
