On the evening of the first day of the conference, we will hold the Social Event
at the Depot 1899 in the lovely Sachsenhausen part of Frankfurt.
Here you will be able to wind down from a day of talks with a buffet.
We arranged a bus transfer from the University to Sachsenhausen. As Sachsenhausen is
close to the city centre, you may want to finish the day by taking a walk
through Sachsenhausen back to your hotel or by taking the bus transfer
or a tram back to the university.
First, I edit Changes and dist.ini. Some people automate filling their Changes entry from 'git log', I find this inappropriate since Changes are meant for users, not developers. I also still bump version number manually (though only in one place, dist.ini). Perhaps someday I'll automate it; my version numbering scheme is mostly a boring 0.01-increments anyway.
This modification to two files will be in the commit message that marks the release.
Then I "push the one-click release process button", by running a simple Perl script, without any arguments, in the dist's top-level directory. Thanks to Dist::Zilla, the script is fairly simple. It just needs to:
(cross-posted from jobs@london.pm.org)
------------------------------------------------------------
Hi guys and girls,
We're looking for a Perl developer with 2+ years of experience programming
professionally to join our engineering team in central London, primarily to
work on the Nestoria property search engine (http://www.nestoria.com)
Nestoria is a great product to work on. As a vertical search engine we work
hard to solve many of the same problems as a larger search company:
Reliably and quickly processing millions of listings
Even more quickly searching those listings at query time
Tracking user behaviour and always improving the user experience
Internationalization - we work in eight countries with six languages
Geocoding, Natural Language Processing, Image Processing, Historical, House Price Aggregation, Mobile Web...
We are looking for somebody who has:
2+ years' experience as a professional Perl programmer
Strong knowledge of Perl best practices and modern Perl development practices
Excellent technical communication skills
A desire to coach, mentor and share your experience with junior team members
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles
Spoiler alert: the answer is 1 or true
Before delving back in the next planned blog post of another important nuts-and-bolts Devel::Trepan topic — position and status information — I'd like to take a step back and talk a little bit philosophical like I did in the first blog.
In that blog, I wrote something a bit contradictory. I wrote that I wrote Devel::Trepan to follow gdb. But at the end of the blog I wrote that I wanted it to be more of a platform for (cough, cough) research.
Someone on IRC asked me for an example of how to parse schema.org markup using my HTML::HTML5::Microdata::Parser module. So here one is. It pulls the microdata from the page, and queries it using SPARQL.
Marpa::R2,
the latest version of
Marpa,
has some significant speedups.
Enough so, that it seems appropriate to revisit an
old benchmark.
(For those new to this blog
Marpa is a new parser with a decades-long heritage.
Marpa 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.)
The benchmark I'll revisit
compared Marpa to Perl regexes,
testing the speed with which each could find balanced sets
of parentheses in a string of parentheses,
on a first longest match basis.
It's an interesting test, because it has easy cases
and hard cases,
and because the dividing line between good applications
for Marpa and good applications for regexes is
somewhere between the two sets of cases.
In the "hard cases",
the matches come toward the end.
On these, Perl regexes go quadratic (O(n2)),
while Marpa stays linear.
When Perl regexes become unuseable depends on your hardware
and your patience, but there does come such a point.
I've always been fond of origami, and in some periods I also had time to fold some as a hobby. Alas, this is not the case any more... most of the times.
I'm also proud to produce my greeting cards for birthdays and occasions, when I remember to actually make one (which happens seldom... but happens). Some time ago I stumbled upon a neat design for an origami envelope - although I don't remember where I saw it, I've found a couple of web sites that include it (e.g. here). So... two of "my" things coming together...
Then I'm fond of Perl, of course. So why not kicking it in and use it to add an image to the back of the envelope... automatically?
The story repeats again and again, and there's a single conclusion I can make out of that: never do large data aggregation in SQL and Perl.
This time I had a Perl script which builds a standard business report: lots of items show their performance by week, month, quarter etc. Thus you've got a few big two-dimensional tables where one axis is time and another one contains data item names. Say, from the beginning of the year there are about 30 weeks past today, eight months, two quarters. These are three tables with weeks, months and quarters on their time axis.
Basically, all you need is sum(field), count(field) where date between date1 and date2, applied to every type of data you've got in the system. In my case it was about a few million records with 10-20 parameters in each.
I've been doing some research into how different companies operate and I was curious if people would be kind enough to give me examples of companies they would consider "agile" in overall company organization, project management, or some other aspect. For example, I've heard some companies update their live site when devs push their changes to the main branch. That would be far more agile than than the typical change management process most companies require. Other companies avoid project managers under the premise that projects requiring managers have grown too complex.
If you can think of any examples, I would love to see them. Links would be helpful as I'd like to be able to do some more digging.
On a completely related note: I'm finding most studies on how successful companies are run are full of crap.
I've been playing with JS a bit recently, and have released a client-side library for extracting postal addresses and geocoords from webpages - it's intended for use in bookmarklets and browser extensions:
I've also made it work with node.js - which means it's installable via npm. For what it's worth, it's considerably easier to create a new user account for node packages (no human intervention step), and there's a built-in publish tool...
Many thanks to the 165 respondents, who made up 37% of the attendees. Although the responses only feature a third of the attendees, they do appear to cover a complete mix of experience, and present a good cross-section of attendees. As has been observed in previous years the average age of the attendees is getting older. That's not to say we aren't bringing new people into the community and the conference circuit, but it seems that Perl is a language people are getting into enough to attend events like this from their late twenties. In 2012, YAPC::NA had it's biggest attendance so far, so Perl is definitely growing its community. Hopefully events like YAPC are encouraging more and more people to learn more about Perl and the community. Looking at the demographics of the respondents, it's not too surprising to see the popular job roles and industries listed. However, it is encouraging to see Perl is being used in many different industries.
I’ve been a busy little bee lately, and have published a handful of new CPAN modules— I’ll be posting about all of them, but to start things off, I bring you: AnyEvent::Capture
It adds a little command to make calling async APIs in a synchronous, but non-blocking manner easy. Let’s start with an example of how you might do this without my shiny new module:
use AnyEvent::Socket qw( inet_aton );
my $cv = AE::cv;
inet_aton( 'localhost', sub { $cv->send(@_) });
my @ips = $cv->recv;
say join ".", unpack("C*") for @ips;
The above is not an uncommon pattern when using AnyEvent, especially in libraries, where your code should block, but you don’t want to block other event listeners. AnyEvent::Capture makes this pattern a lot cleaner:
I've updated five of my CPAN reviews, adding new modules and updating where new versions of modules have been released.
I've added the ability to comment at the end of each review, using disqus. Following a suggestion from Ben Bullock, module names in the summary table now link to the review section for the module, and there's a separate link for the module's doc.
In the last blog, I started describing features that are new in Devel::Trepan that aren't in perl5db. Here I will continue with one more: the evaluation aspects of the debugger REPL (read, eval, and print loop).
By default, when you type something that isn't a debugger command the debugger just tries to evaluate the string you gave it. If what you typed was really a mistyped debugger command you might get a weird error message. For example:
(trepanpl):stp
Unquoted string "stp" may clash with future reserved word ...
If you don't want this behavior, you can turn off "auto eval". And here is what happens then:
The original plan made at the end of March of working on the Sah data validation framework and form processing framework didn't happen. In April and May I released fewer CPAN distributions due to vacation.
In May and June a majority of my Perl hacking time is spent around the transaction specification in Rinci and Riap, plus a framework/generator for creating functions that support undo/transaction, because writing such functions directly has become too complex and error prone. I have completed the specification, and converted a few Setup modules to using it (the rest will follow). A demo script has also been created and blogged about.
Bitcard is an open single-sign-on web-authentication service. It’s free for both users and web sites. It is used by most perl.org services.
Ideally I would like to use one account for all perl services. If I click “login” on blogs.perl.org, cpan, … a small disclaimer that bitcard is used in the background would suffice.
PS: after proofreading this post I’d like to make sure no one feels offended. So don’t!
Some of you witnessed me last August standing in front of the great Perl congregation at YAPC::EU and talking a lot of steamy hot air out of my mouth. More precisely how nice it would be to have a DSL for GUI creation like Rebol has it. I just turned hulky green (but without the muscles) of envy when I saw how much less syntax they need to define GUI. Especially if you use the super verbose Wx. (But it looks just better :) ). As I currently do a lot for the rewrite of Kephra, make him most modern, super mighty, tight and duper I found myself currently writing some helper modules that might serve as a basis of that DSL I call GCL - GUI Creation Language.
I will speak again about it, but since there will be no other track beside it, I can give now away some of the wow points. What I created just the last days (last commit) is a sizer class that has several advantages.
Specifically, I want to look at every instance of META_MERGE in Makefile.PL in every distribution in BackPAN. I can easily program this task with my DPAN stuff since I already have a way to crawl CPAN and look in every distribution. That would take a couple of days to go through 250,000 files (although maybe I should try this with Archive::Extract::Libarchive, which speeds up the main bottleneck in this technique.
I thought about GitPAN for a few seconds, but I want to search things that are not in HEAD, too.
In my first blog I described why I wrote a new debugger for Perl and how the rewrite helps me add cool features more easily. Here I'll start to describe the cool features of this debugger. To my knowledge, all of the features described below are not in perl5db.
As mentioned in the last blog, this debugger follows gdb conventions. One implication then is that commands follow the gdb names and thus are no longer limited to one (or two) characters. But you may think well won't it be cumbersome typing in those extra characters? No, and for several reasons. First, the debugger has command aliases, which is a way to give a debugger command name an alias. And many of the aliases given by default are single letters. For example T is an alias for the gdb command backtrace. Of course, you are free to change or remove aliases. To see a list of aliases in effect type alias
Today I'm changing a bunch of code which uses ref() (specifically, code which checks whether something is a coderef: ref($foo) eq 'CODE') to use reftype() instead. reftype() works with blessed coderefs. And I will be encountering blessed coderefs quite a bit since my function wrapper (Perinci::Sub::Wrapper) marks its generated wrapper code by blessing them. I'm not even sure how that would be useful, but I'd still like to know if some function has been wrapped.
I have been putting off this for months (more than a year?) simply because I'm lazy. Personal technical debt, you may say.
Come to think of it: Having to use Scalar::Util, List::Util, List::MoreUtils, etc for seemingly basic functions is a sign of Perl's age, but also a sign of how serious Perl is when it comes to backwards compatibility. We aren't that bad too, remember that poor Python users need to be this verbose when it comes to basic stuffs, like from os import getenv; home = getenv('HOME').
I’ve been a busy little bee lately, and have published a handful of new CPAN modules— I’ll be posting about all of them, but to start things off, I bring you: 