Since I live here on planet earth where biology by in large restarts with every spring, which happens in this part of the world in march, I'm bit reluctant to join the gregorian calender, which is named after a roman katholic pope and a calendar which prior to that changed its start to january by another roman dictator, which makes it further unatractive to me. don't get me wrong, I dont want to act here any more special then necesary, but its good to review and to make plans.
This is a short narrative of how I 'discovered' Perl and why I have stuck with it for the last three years.
Back in October 2007, I had recently joined a financial services firm as a fresh graduate. During a meeting of the corporate charity committee it was suggested that a website should be created to set up a charity auction. In an impulsive moment I went ahead and raised my hand. The key motivation was the sense of satisfaction that always accompanies voluntary work. The fact that the chairperson of the charity committee was a very pretty lady whom I was keen to impress may or may not have something to do with my decision.
A little about my background. At that time I had dabbled a bit with different programming languages. I had modified a perl script here and there but had not written a complete application from scratch, let alone a website.
Some years ago I created the Net::Appliance::Session Perl module. It allows the user to automate interactions with CLI-based networked devices (think routers, switches) - a sort of Expect but with some helpful domain knowledge. The module has turned out to be quite popular (which is important to my story), in use by many organisations.
There is a shopping-list of problems with the code, though, which makes both bug-fixing and feature development really hard. I've been planning a rewrite for over a year, and finally completed most of that in the past few days.
The new version is completely different internally, but that shouldn't matter much. The problem comes in that I've engineered a new "phrasebook" system for the scripted CLI interactions, and also the programmers' API has changed. [Edit: I should add that lots of long-asked-for features are included, so the rewrite did bring benefits for the user.]
For the annual winter gift-giving season [0], I usually prepare a printout
of nice pictures I took during the past year for the grandparents of my
kids and other relatives. This involves going through 2839 photos [1]
and filtering out the 10 to 30 pictures a given relative might care most
about (there is some overlap, eg. the birthday of one of my kids, but
not that much).
So the task is:
go through a lot of photos quickly
select/tag some with different criteria
export the selected photos.
I once wrote a thing called
fotagger, but currently my
SDL is broken and I wasn't in the mood to fix it. So I took a closer
look at the tool I'm usually using to view pictures: qiv.
Here it is, only a few hours into the new year, and I'm already breaking a resolution of sorts. It wasn't a proper resolution, but given that I have plenty of things on my plate — not the least of which is a baby on the way — I had decided that I wasn't going to hack on Role::Basic for a bit until I saw the dust settling.
First, a simple question: if you're interested in Role::Basic, is it as a stepping stone to Moose, or because you just want roles and nothing else? The answer to this question could have a huge bearing on a fundamental problem that I face. This post is going to be rather long, so if all you do is answer that question, that's fine. I need to know. The reason this post is going to be long is because making things hard is easy. Making things easy is hard. Thus, in trying to solve a problem in an "easy" way, I have to think about a hard problem.
And what is most amazing about it? That 186 or 46% are either resolved
or patched. That's a wonderful success rate.
If you have a login on rt.cpan.org you can issue this query to see the
actual 401 tickets.
Very nice graphics and ad-hoc statistics are then provided by RT when
you look at the bottom of the page. I've never noticed that RT footer
under the result of a query before.
For example I can create a bar chart by CreatedMonthly that shows me
when the rally started: 65% of the tickets were created from August
to December. That's because on the first days of August was the relaunch
of http://analysis.cpantesters.org/ after a few months break due to the
cpantesters 2.0 launch. Analysis is the real work horse that drives me
in this game. It's kind of playing solitaire with bugs. Analysis
provides the deck: cards of many different shapes and colors, my job is
to read them and find the ones that can be resolved quickly.
5 bazillion functions imported by default in top level Namespace
The lanugage comunity is esentialy the VB6/JavaScript community --
Well at least JavaScript has clean semantics.
In other words php is not the market we want to go after.
I'm just saying that php is not a good model to base a language off of, except for ease of configuration.
It's been some time since I last blogged. My next post will be looking forward to what I'm planning to write next year, but first I should blog about what stuff I've come up with in the past couple of months.
Shared memory
I had already written POSIX::RT::SharedMem before, but even though POSIX IPC is a great idea (for being remarkably sane to use) it isn't widely implemented (Linux, Solaris and recent versions of OS X support it out of the box, FreeBSD does too but you have to enable it explicitly). Therefor I ended up writing SysV::SharedMem, which does pretty much the same thing, accessing shared memory as a string, but implemented using a different backend. It's largely derived from File::Map, unlike POSIX::RT::SharedMem that delegates most of the work to File::Map. Writing it has made my conviction that SysV IPC is an incredably crappy API even stronger, but fortunately that's largely hidden from the end-user.
James Clark in XML vs. The Web has finally said what needed to be said -- that XML is a singularly bad format for data transmission. Here is the crux of what Mr. Clark had to say:
It's "Yay", because for important use cases JSON is dramatically better than XML. In particular, JSON shines as a programming language-independent representation of typical programming language data structures. This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this. The fundamental problem is the mismatch between programming language data structures and the XML element/attribute data model of elements.
Tradition tells us to look back and forward when a year turns. And this year I choose to be a traditionalist.
The Past
It's been a remarkable year for me, Work- and Perl Wise. I had the opportunity to work with two great companies with both skilled and devoted coworkers.
And I dived head first into great distributions like
Dist::Zilla
Moose
PSGI
Mojo
Catalyst
DBIx::Class
XML::Compile
... and many more
Not all are from this year, or even new, but they are all great examples of the code quality of CPAN.
I had a short look at Perl 6. Alas there weren't enough time in a year to do share between the exciting stuff in Perl 5 and 6. But next year...
Connectivity
Restful applications are nice and easy to integrate functionality, even internally in a company.
I wrote Catalyst::Model::REST to make it even easier to access other applications through the model layer of Catalyst.
Yesterday we had our first revived Tel Aviv Perl Mongers meeting. You probably came across the announcement once or twice in your RSS feeds, mailing lists or even through a personal message from me.
Apparently this worked quite well. The last Perl Mongers meeting included 5 to 6 times as many people as previous meetings. It was pretty awesome. We also scored pretty high on the variety of people.
I got to meet a lot of new people, hear interesting talks and mainly have a lot of laughs.
After the talks, the top-posters went out to dinner and had a great time. The discussion of how to represent a salad in pure OO form ensued and all hell broke loose from then on! :)
Next meeting we're hoping to get even more people to attend. My plans include shorter talks and a lot more fun (such as lightening talks) and getting more people to step up (help organize and give presentations on various issues).
Thanks to everyone who came, everyone who gave talks, helped with the website (DNS, hosting), graphics, flyers, advertising and so on.
Over the summer I had the privilege of attending a week-long workshop on CUDA hosted by the Virtual School of Computational Science and Engineering. It was was free for students from the University of Illinois (and other partner institutions, I presume) and it was excellent. If you want to learn CUDA quickly and you want to learn it well, I highly recommend attending such a workshop.
Over the fall I started writing and using CUDA kernels in my research. This meant writing code in C. C is a great language, but it is not known for its whipuptitude. Almost immediately, I noticed that my main() function did little more than manage memory and coordinate kernel launches. This, I thought to myself, is exactly what scripting languages are for, and wished there was something out there to let me manage CUDA memory and invoke CUDA kernels from Perl.
This is how I started down the path of writing perl_nvcc.
As predicted in the October Summary, the latest milestone for CPAN Testers came just before Christmas. On 22nd December to be exact, as can be seen on the Interesting Stats page of the CPAN Testers Statistics site. Once again, many thanks to all the testers who have help to contribute to the milestone.
Congratulations to Chris Williams for posting the 10 millionth report. It was a PASS for App-cpanminus-1.1005.
YES! I am extolling the greatness of Dist::Zilla! It really has a lot of greatness. I think it's finally reduced the friction enough that I'm going to start making dists for all my internal projects. A big thanks to all involved in building up such lovely infrastructure.
A long time ago I posted about Roles without Moose and while I still feel that for most cases Moose is the way to go, there can still be a bit of resistance to the idea. Matt Trout responded to my post with how one could have just roles (read his entire post to understand the context):
package Foo::Manual;
use Moose;
extends 'UNIVERSAL'; # get rid of Moose::Object
with 'Foo::Manual::Bar';
sub new { bless {} => shift }
This still involves putting Moose on your servers and when you're faced with a large dev team that is very conservative in their approach, this might be an uphill battle. So what are my alternatives?
