Ivan Bessarabov brought to my attention that Pod::Readme 0.10 dies when it sees an =encoding directive.
I've just released Pod::Readme 0.11 which recognises =encoding directives, and remembers the encoding specified; however, currently, it doesn't actually make use of that encoding when outputting the README file. I need to think more on what, if anything, I need to do with it.
Come one, come all to the San Francisco Perl Mongers December Social at Citizen Space on Tuesday December 21st at 7pm. Bring your laptop, some holiday libations, yummy appetizers, and any other holiday treats to share with the group.
If you can bring something specific like a potluck item, or soda, or wine, please post it on the Meetup board or the SF.pm mail list so we can be loosely coordinated. There may be impromptu lightning talks, or karaoke, but that really depends on who motivates. Have a wii or guitar hero game? Bring it!
In case you're wondering why I've been rather quiet (for me) lately, it's due to my expat blog. I'll post here again, but I'm trying to get a lot of content up there for wanna-be expats.
Ever since I've promised to write about my "generic streams" framework on #moose IRC channel (it happened several weeks ago), my conscience wouldn't leave me alone.
I'm still not ready to talk about streams with enough details, so I'll talk about the bigger picture instead.
So, I'm working at Yandex company on a quite large-scale project (it's a blogsearch if you really want to know). Our codebase is separated into something like 400 separate distributions, mostly perl. Every distribution is packaged into debian package and all these packages are cross-dependent in the complicated ways. We've got several hundreds of production hosts, separate test hosts and the separate test cluster. Our group is just a small part of the whole company (less than 1 percent in fact) and so some of our modules are used outside of our blogsearch project.
Last month saw a number of changes, both major and minor, to the workings of CPAN Testers behind the scenes. As mentioned in the last post, some of these have had a striking effect on the ability to process more reports at a time. Last weekend actually saw us less than 24 hours behind a report being posted and appearing on the site. However, there is a caveat to that which I will come to in a moment. Having done so well to close the gap between reports being submitted and appearing, last weekend I took the opportunity to perform a major reindexing, which prepares the data storage for the next round of changes. Hence the spike you might have seen on the status page.
I had an interesting talk with a friend over the weekend about the math behind the prediction. The outcome of which is that to come up with win, lose, draw predictions, all you need to do is add up the predictions for all point differences. Let me give you an example, if the point difference for the home team is 1 then they have one by one goal (1-0, 2-1, 3-2, …). If you take the draw then all draws are equal thus the goal difference of 0 is the chance of all draws (0-0,1-1, 2-2,…). If you take the lose position then the goal difference for the home time is -1 which covers (0-1, 1-2, 2-3,….). So, you do this up to a goal difference of 5. This makes it much easier to make a match prediction.
Let me leave you with a prediction. Today Liverpool is playing versus Aston Villa. Here is how it breaks down: Liverpool has a goals per game at home average of 1.71 and Aston Villa has a goals per game away average of 0.71 according to Soccer Stats. You can probably already predict the outcome just from that but here is the percentage breakdown:
Recently, a co-worker chided me about there being no apparent quick & easy utilities for Perl that served a directory listing over HTTP; specifically, something that matched the functionality of:
python -m SimpleHTTPServer
I perused CPAN, but found only modules that could be used to create a utility.
A couple of vim-strokes later...now there is App::dirserve. Suggestions for a better name are welcome.
It uses Mojolicious' development daemon for the work, and as such has one pre-requisite. It has a bit more functionality that the python solution, and more importantly, css gradients make it much prettier.
usage: dirserve [OPTIONS]
These options are available:
--directory Directory to serve. Defaults to current directory.
--index-page Page to show by default. Defaults to directory listing.
--port Port to serve on. Defaults to 3000.
--no-dots No navigating to parent directories via '..'.
--help This message.
Thanks to cpantesters I'm doing something that amazes me --
as I write C, it is taken and tested for me on all sorts
of different systems.
This is a stern test of my ability to write
portable C code,
and, in general I'm quite pleased with how I've done.
So far only one mistake
can clearly be laid
at my door.
That mistake doesn't put me in a good light --
mistakes seldom do.
But we learn more from mistakes than from successes.
In this case, the mistake exposes a habit of mine that
programmers of the modern school will find a bit lunatic.
And perhaps it will give me a good way to point out how
that lunacy shaped your training as well,
no matter how recent it was.
I often read the “Daily WTF” because there’s something satisfying about seeing other people’s bad code. “See? Our code isn’t as bad as all this!” It’s not as fun when you find “Daily WTF” moments in your codebase.
Today, one of my coworkers asked about a piece of code that wasn’t giving the expected results. It’s a part of some really old code that would be done differently given the time to rewrite it. Any way, there are a series of if/elsif/else clauses that check various things. One of those things is to validate some data against a known constraint. This particular section is supposed to validate that the given data falls within the range of a valid UINT (UINT8, UINT16, etc).
After the previous steps, the git repository has an accurate history of what was done to the SVN repository. It is a direct translation though, and shows more the process and tools that were used, rather than developer intent. I proceeded to simplify how the merges were recorded to eliminate the convoluted mess that existed and make the history usable.
Two main classes of these problems existed. There were branches were merged one commit at a time, as that was one way of preserving the history in SVN. The other case was trunk being merged into a branch, and immediately merging that back into trunk. Some other issues match up with those two merge styles and the same cleanup will apply to them.
Here is a section of the history of the 'DBIx-Class-resultset' branch being merged, one commit at a time. Obviously not ideal, but you can mostly tell what is happening.
"You can get fired for not knowing Perl" I'm still sad that I had to miss the Nordic Perl Workshop in Reykjavík, but I'm going through talks that they've linked on their @nordicperl2010 Twitter feed. I like Tryggvi Björgvinsson's mutation testing talk, especially since he tells how he got a lecturer fired for not knowing Perl. I wish I was there to see if, but I only get to see the slides.
He points out an important but often ignored part of Perl's testing culture: we let the foxes guard the henhouse. That is, the code author and test author are often the same person. Not only that, but CPAN Testers runs the tests that the author provides. Tryggvi asks "Who watches the watchers" (with plenty of appropriate artwork).
How can we suss out problems with tests? One idea is to mutate the source code to see if the tests fail. For instance, we might change a comparison operator. The original code might test for greater than:
One of my client's schemas contains a table which contains a column named 'can'. In his context this is a convenient abbreviation for 'Client Access Number'. In Perl however, ->can() is already spoken for. Since DBIx::Class::Schema::Loader creates an accessor method for each column of each table in your database, things went sideways on me today when I tried to auto-generate classes for all tables in that database.
Luckily irc.perl.org #dbix-class came to the rescue again, and Caelum was quick to patch the bug. So if you have clients like mine, rest assured the next push to CPAN will cure what ails ya. :)
One of my little obsessions is attempting to figure out a way to create a money-spinner (also known as a cash cow) by predicting the outcome of football matches (also known as soccer matches to those in North America). I did some research and I found that there is a frequentist (I don’t want to get into the argument of Bayesian vs Frequentist approaches to Statistics) method for doing this. Most of the research is from econometrics and has to do with predicting crowd sizes rather than actual outcomes of matches.
I’ve been thinking, why is it that Character strings, and Binary strings are mostly the same in Perl. If you read in a binary file, why would you want it to behave as if it were a Character file?
The main difference currently, is that Unicode Character strings have the utf8 bit set. There isn’t really any difference between ASCII Character strings, and Data strings. It also presents a challenge if you want to read in Data strings that have Character strings in them, especially if the encoding of the Character strings is anything other than UTF8.
There are some historical reasons for this conflagration, Perl was originally designed to work with ASCII Character strings. Since there was almost no difference between the 8 bit ASCII, and 8 bit data; there wasn’t any real need to separate the two. Unfortunately the world (of programming) is no longer this simple, Perl needed to change to handle Character data that wouldn’t fit in a single 8-bit byte.
We will cover a range of topics from understanding Dancer, writing your own Dancer applications (tutorials included!) and writing a plugin or engine backend to Dancer.
The work on the articles already benefited applications and modules. If you follow the articles, you'll be able to understand how they were all written, in complete detail.
You don't write Perl 6 documentation like a story. Not only i can't make it up freely but its also almost impossible to know all details in that time. So you write about the bits you are shure you know. Thatswhy i also layed out the structure for the tablets 4-6, even if there is almost no content. This way I sort the thought in my head and can link to proper spots now. The magnitude of links is a serious part of the work but it will make it much more usefull.
You know, when I look at Russian Cyrillic, or Greek letters, it looks like squiggles. I've never studied it, so I have no means to relate it to sounds, let alone meanings.
So, when people say, "I can't read Perl", it only tells me they haven't studied it.
And if people choose to be vocal about their own ignorance, saying "Perl is unreadable!", that's saying a lot more about them than it does about Perl.
As far as I can tell, millions of people speak Greek and Russian. I'm not one of them, and that's ok. I don't keep saying "Russian is impossible", simply because I personally don't know it.
If it matters, I've seen some pretty impenetrable Python, Ruby, and Java code. And I even pretend to know those languages at least in passing.
I presented OOP approach for solving workflow tasks in my previous post.
Now I'd like to show you, how to deal with workflows in a slight different manner.
I'm gonna write about Workflow lbrary from CPAN. And I'm going to present you some kind of a tutorial on how to use this lib, and what features does it have.
The main idea of Workflow lib is configuration over coding. Flow is described in XML files, of course 'some' coding is still required.
So let's implement our request management using workflow lib.
First of all, we'll create application, with all that simplifications, that we had in previous post, and than enhance it to real world web application and add some complex and interesting features that workflow lib can offer.