blogs.perl.org

Hi Folks
Yes, I'm moving house tomorrow, so if I don't respond to your emails, just hold you breath until normal transmission is resumed...

If you are creating a distribution using Dist::Zilla, you can install it using "dzil install". However, that will use the standard CPAN shell.

To make this work with cpanm, use:

dzil install --install-command "cpanm ."

Now if only Dist::Zilla allowed aliases like git did... I'd like to have something like this in ~/.dzil/config.ini:

[alias]
    instm = install --install-command "cpanm ."

As we began working on iCPAN, we became aware of how problematic it can be to figure just exactly what is in the CPAN. More importantly, we became aware of things we really wanted to do when interacting with CPAN. Last month, Dave Rolsky posted some comments on a next generation CPAN search . He has a fairly extensive list of things which a CPAN search could offer and I'm more than inclined to think that he's on the right track.

• be available to the wider community to clone, fork, patch, pull etc
• let you upvote/downvote modules
• have tighter integration with reviews, dependency reports etc
• allow for complex searches

There are really so many things it could be. The problem, as I see it, is that this is too big a job for just one person and that may be where projects have stalled in the past.

The Good, the Bad and The Ugly

The recent discussions about yacc made me feel a bit like Lee Van Cleef in an old spaghetti Western. Cast alongside Clint Eastwood, Van Cleef watched with great concern as one attempt after another was made on Eastwood's life. Van Cleef didn't mind Eastwood getting killed -- he just wanted to be the one to do it.

As some of you will have recognized, I am talking about a very interesting discussion started by a paper by Might and Darais entitled "Yacc is Dead". I am finding it very much worth reading as an example of clear and precise mathematical writing. With respect to the parser itself, my opinion is that Russ Cox's extremely well-informed blog post, "Yacc is not Dead", is an accurate assessment.

In our Hackerspace RaumZeitLabor in Mannheim, Germany, we have a "Network Power Manager 2000" which is a device that has 8 power sockets and is able to turn these sockets on/off when told so via network. We use it to save some power when nobody is at our space.

That sounds quite nice, but we had to reverse-engineer the protocol. Afterwards, we noticed that only one (!) connection to that device is possible. So our first approach of using a little script to communicate with it was not optimal: It had timing problems because the NPM2000 took a little bit longer to close the TCP connection.

Therefore, I decided to write a little webapp using the excellent Dancer framework which talks to the NPM2000 and provides a nice API to the user(s). It also should keep one TCP connection open all the time to save the overhead of creating a new connection and waiting for old connections to close properly on both sides.

When talking about an affordances, it turns out that there are different definitions, but I like to think of an affordance as "an element of design which suggests the correct course of action", which seems to be pretty much what Donald Norman meant when he adopted the term. It's an elegant concept which, if applied properly, makes it easy to do the right thing and harder to do the wrong thing. However, sometimes you want to do the wrong thing, so an affordance which makes this impossible isn't the most useful in my book. I just want doing the wrong thing to be jarring enough that it would give anyone pause.

And this brings me to the following issue I often see in SQL:

SELECT count(*) 
  FROM employee 
 WHERE salary < 20000;

Suggestions are welcome in which widget toolkit is the easiest to learn and use to create a GUI program in Perl. Most people suggest using Java and Swing as the easiest and the most accomplished language and widget toolkit to use. Yes, I could use Java and Swing but I would prefer to use Perl.

Until recently, while I thought currying was kind of cool, I did not really understand what the use of it was. I call a function and I am done with it. It was not until I was cleaning up some code in my football predictor project that I started to understand how currying could make your life easier.

Let us say that you have a function that takes an input and based on that input does some calculations. Now, this is normal in Perl. For instance,

What an odd thing to write... I've been developing software in one way or another for about 30 years and Perl has been my primary language since around 1993. And yet I don't have a single CPAN module to my name and haven't really been involved in the community at all other than thanking the stars that it exists and produces such fantastic things.

So, I suppose, consider this my hello.

Interestingly, I find myself being pulled more and more strongly into the vortex because of my involvement as one of the core developers of Melody. As great as Movable Type has been (and as proud as I am that it's being used here on blogs.perl.org), it's a mess of years-on-years of internally-focused development. With Melody, we're trying to unwind the mess (without unwinding the features) so that we can continue to make it even better in a far more efficient and community-driven way.

To those bloggers that may have received a similar email, I have been told that it may have seemed spammy, and I apologize if so. I'm just very excited about this project and would like to see it help as many people as possible. –Michael

My name is Michael Schade, I'm a nineteen-year-old entrepreneur, student, and frequenter of the St. Louis Perl Mongers. I have been collaborating with Dr. Kevin Scannell on the free, open-source, and Perl-based Accentuate.us, a web service that is a new method of input for over 100 languages. It allows users to type text in plain ASCII and, using statistics, it will add the diacritics, which have special meaning in many languages, automatically. Improving computer input is crucial to saving endangered languages, and we have chosen Perl to aid us with this task.

I recently extended Dancer::Plugin::Database to add a few more handy features.

Now, instead of returning a straight DBI connection handle (a DBI::db object), it returns a Dancer::Plugin::Database::Handle object, which is a subclass of DBI::db, but adding new quick_insert, quick_update and quick_delete methods, allowing you to do, for instance,:

# in your Dancer app:
database->quick_insert($tablename, \%data);

# Updating a record where id = 42:
database->quick_update($tablename, { id => 42 }, { foo => 'New value' });

So, let's say you want to handle a POST request containing a name of someone to add to your Christmas gifts list. It could be as simple as:

Padre 0.76 was uploaded to Pause on Wednesday night my time (.au), I didn't have it in me to write up the release announcement at the time, and somehow last night slipped by completely. So while I wait for my son's end of school year presentations to begin, I'll try to be a little more productive with my time.

0.76 once again sees a lot of work done by two main contributors, Ahmed Zawawi and Zeno Gantner.

It also sees a great response from the translators with a late call for translations by Zeno just prior to release.

I have so say that the most marked change I noticed when I fired up 0.76 for the first time was the changes to the Syntax Check tab done by Ahmed. This is a much needed improvement to one of my more used features of Padre. Great work Ahmed and thanks!

OK, so what's come through this development cycle:

Zeno made a number of changes, improvements and fixes:

Earlier I replied to Ovid’s post Perl101: Red to Green Gradient about how to create a gradient that is closer to being accurate. (Rafaël had pointed out that Ovid’s didn’t properly deal with hue and intensity.) The problem with the more accurate approach is that Ovid wanted one that shifted from red to yellow to green and my version did not do that.

So I give you a better (although still not 100% accurate) solution. It has not yet been optimized. It may have bugs. Your mileage may vary. Some conditions and limitations may apply. Yadda yadda yadda.

Note: the following technique is not friendly to the color-blind.

I sometimes find that I want to visual data with color. Specifically, I want to use red for "bad" and "green" for good, with a linear gradient in between. As I'm often building Web pages, that means I want:

In other words, I want a smooth, linear gradient from red to green for any number in a range. I'm always hitting a search engine for an example, so I figured other people could use this, too.

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!

http://citizenspace.us

http://sf.pm.org

Announcement posted via App::PM::Announce

RSVP at Meetup - http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/15674810/

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.

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.

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:

• home win —> 60.92%
• draw —> 23.44%
• away win —> 15.15%