For me, it goes something like this.
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 email@example.com)
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
We're offering c. £45K plus bonus.
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.
use LWP::Simple 'get';
my $uri = "http://buzzword.org.uk/2012/schema-org.html";
my $microdata = HTML::HTML5::Microdata::Parser->new(
my $query = RDF::Query->new(<<'SPARQL');
PREFIX schema: <http://schema.org/>SPARQL
SELECT ?name ?page
a schema:Person ;
schema:name ?name ;
schema:url ?page .
my $people = $query->execute($microdata->graph);
while (my $person = $people->next)
"Found person: %s %s\n",
the latest version of
has some significant speedups.
Enough so, that it seems appropriate to revisit an
(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.