For a long time now, I've been thinking how to organize my information about people, their addresses, phone numbers and birthdays, their websites and code they've contributed to, codename "Hoover". But there are some problems that always keep me from writing more than the bland user interface I've come up with so far.
The main problem is, that I'm no good with user interfaces. So I'd like to reuse somebody elses user interface and just import the data into it. Perl is good at that. But I'm not aware of a sufficiently good data store with sufficiently nice user interface. There are some proprietary solutions that have good to horrible integration with other programs:
The Windows Address Book is a pain to import and export, and it doesn't support custom properties of contacts.
Thunderbird is fair to automate (through Mozrepl). Adding custom fields is possible, and there are already some premade importers, for example for Gravatar images.
Building my own LDAP schema would be the enterprisey solution, but getting applications to talk to it seems hard. Having only Thunderbird available to read from the LDAP also makes this a solution less desireable.
Ideally, I want a storage format that (I) can synchronize with my mobile phone and automate from Perl, to keep the information synchronized with the interwebs.
Both articles are a mouthful, and try to be very thorough in the advices and ideas they present. Sadly, both miss the point completely by assuming that "contributing" means "committing code". And this is not only wrong, its part of the reason people hesitate to contribute
For starters, "Open Source" projects tend to be seen as a hard-core programmers-only club, where you have to know how to program (mainly in C/C++), or you have no reason to be there. Seeing that the high profile projects are such complex systems, I can understand how did this image.
There has been a bit of discussion recently on the #distzilla IRC channel about how people are integrating their CPAN distribution development with Git, and in particular some of the Dist::ZillaGit plugin(s). I thought it might contribute to a useful discussion if I show how I have things set up.
Like many, I want to host my code on GitHub and then periodically publish to CPAN. Dist::Zilla helps in both these by providing plugins to automatically push releases to GitHub, and then also upload to CPAN.
What bothers some is the stage at which these things happen, and also how the branches and tags are represented on GitHub. In particular, folks might want:
a "clean" git branch which tracks CPAN releases
another branch which is the "trunk" of development
a user browsing the GitHub website to see the CPAN branch (with the README, etc)
I've just released Dancer::Plugin::Database 1.00 to CPAN. This includes Alan Haggai's patch to supply runtime configuration info to the database keyword as a hashref (thanks, Alan!) which was already released as a developer release, 0.91_01.
I've bumped the version to 1.00 to indicate that I consider it stable and ready for use in production, for those users who mistrust any module with a 0.xx version number.
Over the years it has become abundantly clear to me that people who object to OO fall into two categories:
A handful of people who really understand object-oriented programming.
Wankers with blogs.
Though I don't object to OO, it's still unclear which of the above categories I fall into. I suspect it's not the first.
This brings me to a lovely quote from H. L Mencken, "for every complex problem, there is a solution that is simple, neat, and wrong" (annoyingly, there are tons of subtle variations on that quote. I need to find the original). A "solution" I had in Role::Basic was was simple, neat, and wrong. I'm kicking myself, but my problem was my failure to apply what I thought I had "learned" from the original traits papers.
All:
The group I manage is severely understaffed and one of my most competent employees has just tendered their resignation.
This blog entry is not an official job announcement. The official announcement will be made available online once it is finalized. I would just like to touch base with anyone who might be interested.
I want to be clear that, though we use perl every day, this is not a "software developer" position. My group works in a technical support capacity doing everything from providing recommendations on architecture and design reviews to writing utilities to extract data from logs. The primary skills that I need are scripting (perl/shell), SQL/stored procedures, trouble shooting/problem solving/critical thinking, Unix (AIX/Solaris) and security concepts/best practices.
The position is in the Baltimore/Washington D.C. area and relocation expenses are not included.
Please contact me if you are interested so that we might touch base.
Ok, I must admit that we havn't posted something for quite some time. We actually held our meetings and everything, but there was nothing of interest so far. But recently at Christmas time we had our special christmas meeting.
Lots of Perl mongers become busy at christmas time. Buying gifts and stuff, you know, the usual pre-Christmas stress. Other mongers are allready traveling throughout the country visiting relatives for christmas. Though not everyone is able to attend to the last meeting of the year. Our last meeting dates were late in December and therefore very close to Christmas eve.
Thats why it has become a habbit to give relatives and friends of our the ability to check what we "weird" guys are doing when we are out for the "Programmers-Meeting".
So we had some attendies at our meeting who are not into programming. Of course talking about Perl and stuff need to set back a bit that evening, we didn't want to scare non-programmers away with techno-babble. But on the other hand someone brought tiny chocolade Santa Clauses to the meeting. And it is quite interessenting getting to know the social surroundings of our fellow members. You know, we are not just programmers trying to help each other, we are also some kind of friends here.
Perl test output (the so-called "Test Anything Protocol" or "TAP") is simple: "1..N" declaring that N tests are planned, then either comments starting with "#", or lines starting with "ok X" or "not ok X" saying whether or not test number X succeeded. Generating it should be simple. Parsing it should be almost as simple.
However, the code to generate and parse test output is a byzantine nightmare: Test::Simple and its dependencies are at least 1345 SLOC, and the various TAP-parsing modules are at least 3918 SLOC (including an IteratorFactory!).
Both generating and parsing the subset of "TAP" used by most programs can take around 50 SLOC. This seems like a perfect opportunity for a ::Tiny module.
Every now and then, I can't remember the exact semantic of a function or module, and every now and then the documentation is not quite clearstraight about it. Then I gotta see the code running to make sure. Eventually my own personal memory stack will overflow and I will need to revisit some of this information. Here it's where:
Perl has so many useful builtins that most people who use the language probably only use a fraction of what's available. Every year or so I like to peruse perlfunc and perlsyn as a refresher. Yet in years and years of hacking Perl code, there are a few in there that I will never use. I surprised myself the other day by reaching for the loop control command redo. It occurred to me that while I use other loop controlling things like next and last constantly, I couldn't remember a single time before when I have ever had to redo an iteration. For the curious, here's the astonishingly simple scenario where it came up.
It's frustrating to me that I have limited bandwidth right now. A new job, a new country, a (soon to be) new baby, and a new blogging venture have all conspired to ensure that I don't have as much time for writing software outside of work. However, I've been working hard on Role::Basic and following a suggestion from Stevan Little, I've started [a branch with Moose::Role tests](
https://github.com/Ovid/Role-Basic/tree/moose_tests) and have started working through them. Some are clearly inapplicable (for example, Role::Basic has no notion of attributes), but a few have given me pause. I wasn't sure if they were supporting original traits behavior or if they were extensions for Moose. Since I've already ready the original traits paper (pdf) several times, I decided to move on to Traits: The Formal Model (pdf) to make sure I hadn't missed anything. There are some interesting bits there.
After half a day of yak-shaving that started with having to port yet another Makefile.PL to the dist.ini format, I am now finally able to post this small snippet of elisp code to blogs.perl.org from within emacs (more on that later):
I don't think this is documented anywhere, so let me blog about it before I forget it. Install the module CPANDB. See if it works by running one sample program, maybe:
use CPANDB;
use YAML::Syck;
print Dump [CPANDB::Distribution->select
("order by volatility desc limit 1")];
It may take a while but you will get something like this:
SslAuth uses the recently added TLS certificate authentication support in Mojolicious 1.01.
The first argument passed to the callback sub is the IO handle, giving you access to whatever IO::Socket::SSL provides. (get_cipher, for example).
ParamsAuth is very basic, its purpose being to keep your params-based authentication uniform with other auth-types.
The arguments passed to the callback are the values from the named form or query parameters.
BasicAuth has been around for a while, and uses a similar interface:
If you're looking to be hip with the latest oauth goodness, Marcus Ramberg recently released Mojolicious::Plugin::OAuth2.
...
On a side note, Вячеслав Тихановский (vti) updated MojoX::Validator only days ago. It is, to date, the only form validation helper that doesn't make me think Amway would have been a better career choice. It can be integrated into Mojolicious or used separately. And, like Mojolicious, the code is easy to understand and contribute to. Join up!
Once in a while I have something to tell about Perl and me. I used my very own server for years and sometimes I even used use.perl. Since the shutdown of the blogging interface at use.perl it seems that most bloggers moved to blogs.perl.
A friend, Ido (ik_5) put up a post (in Hebrew) about the last TA.pm meeting, and although he misspelled my moniker twice, he raises two interesting points.
First of all, he complains about being mocked when everyone introduced themselves and he said he works with Pascal. Secondly, he asks why don't people program in Pascal? What's so bad about it?
So, apologies have to go to people you've offended. Even if you didn't mean to, even if they didn't get a joke you thought you were sharing. When feelings are hurt, it's time to pause and apologize. So, hopefully Ido is reading this and might be less upset now.
Right now, if you get yourself a copy of CPAN (or check out a mirror) you won't find a lot of information about CPAN authors. You'll find name, email, PAUSEID and, in some cases, an URL. It's good, but it's not really comprehensive. It doesn't tell you how to find an author on Twitter, Github, Stackoverflow etc. Sure, you can find that stuff out with some research, but how hard should you really have to work for this information?
An important consequence of the choice of parsing algorithm
is the
handling of parse-time errors.
It's often overlooked.
Perl's use of LALR based parsing puts severe limits on its
ability to locate errors,
limits which the Perl interpreter is sometimes able to overcome.
Consider the following erroneous piece of code.
my $lyric =
'Sloopy wears a red dress, yeah
As old as the hills
but when sloopy wears that red dress, yeah
you know it gives me the chills
Sloopy when I see you walking,
walking down the street
I say don't worry sloopy, girl
You belong to me';
print "$lyric\n";
Some of you may have spotted this as the lost third verse of the
October 1965 US #1 hit, "Hang on Sloopy".
Others may notice that the single quote in "don't"
is going to make things come out pear-shaped.
On this latter point,
the Perl interpreter's performance is uncanny, if a bit noisy:
