With Exporter, and most exporter tools we have failed to separate concerns.
Exporting fundamentally involves 2 parties: exporter and importer. Historically
however we have only ever concerned ourselves with the exporter. The "standard"
way of dealing with this in perl has been to have a module that provides
exports use it's import() method to inject symbols into the importer's
namespace.
What if we did this with other similar concepts? What if instead of:
use base 'foo';
we had:
package My::Base;
# Gives us an import() method that sets @{caller::ISA} = __PACKAGE__
use base;
...
package My::Subclass;
use Base::Class; #Automatically sets @ISA
In the past I sometimes used XML::Tiny and I found it perfect for the job. Agreed, I had to struggle only with very little and under-control XML, so I knew I could do without a full-fledged XML Parser.
For one client, I was told that our devs didn't have client access to a database with a problem, but they could connect via DBI. Thus, I whipped up the following to help them out.
It has command line history and mostly handles multi-line queries. It's not overly robust, but it's the sort of handy code you might just need in a pinch.
No, there weren't drugs involved, I merely sent a patch for Rakudo for a bug I reported a few weeks back. But the patch is... interesting.
First, about the "bug." Newest JSON spec lets you have anything as the top level thing. I spotted a few modules in the Perl 6 ecosystem that still expected an object or an array only, and the vendor-specific (possibly to be made hidden in the future) to-json subroutine provided by core Rakudo behaved the same as well.
One of the modules got fixed right away and today, seeing as there were no takers, I went in to fix the bug in Rakudo myself. Since I'm a lazy bum, I merely went in to that one fixed module and just copied the fix over!
But wait a second... ain't the Perl 6 module written in Perl 6? How did I manage to "just copy it over"? What sorcery is this! Surely you lie, good sir!
At the time, I was busy evangelizing the use of Dancer2 in professional work, and that meant exposing other developers at various levels of Perl familiarity how to accomplish tasks in the Dancer2 framework. While I waited for the new DSL parameter keywords be released by the Dancer2 core team, I decided to extend the Dancer2 DSL with keywords for parameter access of my own and added that to company broilerplate rather than have to worry about making sure every developer on every Dancer2 project was fully educated (or remembered) the aforementioned pitfalls when doing their work.
Haven't posted anything for a while, but I'm not dead, just busy. Here's a quick recap of things that I think people might find of interest.
Send In The Clones (click for larger version)
First and foremost, I'm going to be in Brussels, Belgium, next weekend for FOSDEM. If you can make it, check out the Perl track. I'll be speaking about why people are finding Perl 6 so exciting. In particular, ever since the Christmas release, there's been a fair amount of chatter about Perl 6 and I've been paying a lot of attention to people who are looking at it for the first time, without a lot of preconceived notions. The reactions often range from "wow, that's cool", to "oh my goodness, I want that!" What's even more interesting is that they're not focusing on a particular feature (which would be scary as it would pigeonhole Perl 6 as a "niche" language). Instead, plenty of people getting excited about different things which scratch their particular programming fetishes: grammars, gradual typing, concurrency, and so on. It's fun to watch.
With the gracious collaboration with Cosimo,Text::Hunspell made the switch from ExtUtils::PkgConfig to Alien::Hunspell late late year. Despite the somewhat complicated dependency requirements, this immediately made the spell checker more reliable as reported by cpantesters, as many machines do not have pkg-config or hunspell installed.
The one major platform that didn’t work on the initial switch was of course Strawberry Perl, but after some debugging and patches I got Alien::Hunspell and Text::Hunspell to work there as well. I even submitted patches to upstream to the hunspell project, which were accepted, so that in the future less patching will be required. This is what is great about Open Source when it works.
The results as recorded in the cpantesters matrix are stark:
I'm still trying to get my head around how the concurrency stuff works. I had an idea for a simple script: sometimes I run a program that dumps a lot of output, so I'd like a script that would take that as input and just hold onto the most recent X lines of it, so that they could be read at any point through a named pipe.
So I figured I'd need one thread to read lines from STDIN ($*IN in Perl 6) and keep an array loaded with a certain number of the most recent ones, and another thread to open the fifo for writing and dump the current contents of the array to it whenever someone reads it. In Perl 5, I'd probably do it by forking off a child process for half of the work, or maybe use a single loop that does both things but has quite a few no-ops. I figure in Perl 6 I can do it with threads.
As a Perl 5 programmer of about a decade, I'm well aware of how it was referred to at some point or another as the "write-only" and "linenoise" language. With the newest addition of the baby Perl 6 language to the Perl family, I fear that I must declare (wildly speculate) based on my extensive research (a boring ride on a bus, while staring at my phone) that Python steals that title now!!
Why Python? Blame whoever made the Stackoverflow Python Report scroll through my Twitter feed. I merely picked two problems from that list and asked myself what would the Perl 6 solutions to them look like.
Exploring Perl 6: Numeric Types covers the built-in number types in Perl 6, including the fantastically useful native support for rationals, and even complex numbers!
This year, I begin my nineteenth year of professional programming with Perl. It seems that I just can quit you, Perl.
Not that there is a compelling reason to do so. Sure, there are a lot of "hot" newish language/frameworks out there, like node.js, ruby on rails and python/django. And those tools are worth getting to know, not the least of which reason to do so is in the pursuit of paying gig.
Popularity of a technology is mostly important when you start a project and when all technologies are equally alien to you. In my case, Perl is home. It is the tool I can use nearly in my sleep. I know where the pitfalls are and where it shines.
The crack about Perl being write-only line noise has always annoyed me. Every language can be have hard to follow programs written in them. At least Perl often makes it easy to untangle them (thanks, perl debugger).
A person's experience with a programming language involves many aspects: how
a user first learns that a language exists, their first steps in that language,
their process of learning more about it, developing in it, contributing
to it, and spreading the word about it are all part of that experience.
In short, it's a huge swath of elements, which is why it's important to
have a means to efficiently identify any issues in that experience, so that it can be
improved.
I'd like to announce the creation of The Perl 6 User Experience
Repository. Its main page
enumerates various aspects of the Perl 6 User Experience and the
sub-pages will outline plans to overcome any of the identified problems,
or perhaps serve as a documentation repository for protocols, lists
of contacts, or other additional files.
I am not going to explain here what chef and test kitchen is. I believe most of us heard about this configuration management system and testing framework for it.
But in few words test kitchen provides some capabilities for chef cookbook developers rapidly test their recipes under various platforms and environments.
Recently a good idea came into my mind. Swat could be a good companion for all this eco system. As far as:
swat provides DSL for rapid web tests development
sparrow is a small swat infrastructure tool acting like cpan client for swat modules get installed from SparrowHub - central repository for shareable swat test suites
So I went ahead and created some useful test suites could be run as simple integration tests for 2 popular chef cookbooks:
I'm a fussy person I guess. I haven't really like the way I can filter or search for events that might interest me for the two gaming conventions I've attended the last few years, GenCon and Gary Con.
GenCon provides an excel file of events that gets updated before event registration starts. Gary Con hasn't had this yet so I scrape it. For both of them I munged that data into a sqlite db.
Now, being the sharing guy that I am I was wondering how I could share this data, other than just throwing the sqlite file somewhere. RapidApp to the rescue. I tinkered with it a bit for last year's GenCon, I didn't get it sorted out well enough to show off to the public.
Let’s say I opened a restaurant and people liked it.
Then I add an item to the menu called “Fish and Chips”. My restaurant’s version would serve a smoked salmon with a light butter/caper topping and fresh potato chips (crisps for those of you across the pond). I could certainly do it … but people would be confused.
No amount of explaining to each patron would prevent the next patron from being confused by the name. Even if I explained on several pieces of my printed materials and told customers if they asked, people would still certainly miss it, because they know what “Fish and Chips” means.
If I then claimed that the name wasn’t confusing because I had explained the differences several times, I would be wrong. It still is confusing. Claiming it isn’t doesn’t make it so.
