The Room

The Room http://chris.prather.org/rss.xml Brewing Up a Storm http://chris.prather.org/brewing-up-a-storm.md.html <h1 id="brewingupastorm">Brewing Up a Storm</h1> Because I recently had the opportunity to do a fresh re-install of my world<a href="#fn:1" id="fnref:1" class="footnote">1</a>, I've spent the last few days playing with <a href="http://search.cpan.org/dist/App-perlbrew"><code>App::perlbrew</code></a>. <code>App::perlbrew</code> is the invention of Kang-min Liu aka gugod, and the basic idea is that it's a perl manager. It will install and track several different installations of Perl for you, allowing you to switch between them at will. <pre><code>$perlbrew installed perl-5.10.1 perl-5.8.9 perl-5.6.2 $perlbrew switch perl-5.10.1 $perl -v This is perl, v5.10.1 (*) built for darwin-2level </code></pre> I'd like to state now that what gugod had was very nice. It was very simple, very straight forward and did exactly what it said on the package. I have not spoke with him about this application, and anything I say here is my opinion and has no reflection upon him or anybody else that might have been involved. Having seen what power some simple scripting can do in the form of Miyagawa's <code>App::cpanminus</code>, I started tinkering with <code>perlbrew</code>. It started with perl 5.10.1 not installing properly on Snow Leopard<a href="#fn:2" id="fnref:2" class="footnote">2</a>, so the first thing I added was a way to force install. <pre><code>perlbrew install -f perl-5.10.1 </code></pre> Then I decided it and <code>local::lib</code> both sharing $HOME/perl5 wasn't going to be pretty. So I taught it to use an environment variable <code>PERLBREW_ROOT</code> to relocate the default install. In my setup I have it set to <code>$HOME/.perlbrew</code>. <pre><code>$export PERLBREW_ROOT=$HOME/.perlbrew $perlbrew init Attempting to create directory /Users/perigrin/.perlbrew/perls/current Perlbrew environmet Initiated. Required directories are created under /Users/perigrin/.perlbrew. Please add this to the end of your ~/.bashrc: source /Users/perigrin/.perlbrew/etc/bashrc </code></pre> Then I got annoyed with the pages of verbose output, so I stole a page from <code>cpanminus</code> and implemented a <code>quiet</code> switch that is enabled by default. Output now goes to <code>$PERLBREW_ROOT/build.log</code>. Today I integrated it with <code>local::lib</code> so that if you have <code>local::lib</code> installed it will drop the proper configuration in the <code>perlbrew</code> configuration scripts so that when you install new modules they get installed into your <code>perlbrew</code> managed directories<a href="#fn:3" id="fnref:3" class="footnote">3</a>. Finally just now I finished getting <code>--as=</code> working. This means that if you build a custom perl you can have it installed under a special name and then easily switch to and from it. I'm planning on using this to build a <code>--as-workperl</code> that contains all the modules I need for work. <pre><code>$perlbrew install perl-5.10.1 --as=debugging-perl -D=debugging </code></pre> I would like to integrate a plugin system<a href="#fn:4" id="fnref:4" class="footnote">4</a>, but all in all I'm very happy with it. Much thanks to gugod for making it to start with, and to Miyagawa for getting me itching for small lightweight tools in my toolchain. If you're interested in my changes, you can check them out on my <a href="http://github.com/perigrin/App-perlbrew">github</a> By: Chris Prather on 2010-03-07T00:00:00 Tags: <div class="footnotes"> <hr /> <ol> <li id="fn:1">Last week I upgraded my trusty Macbook Pro from OSX 10.5 (Leopard) to OSX 10.6 (Snow Leopard), using a "complete wipe". The old system had been around for ~3 years and was showing the cruft so it was time.<a href="#fnref:1" class="reversefootnote"> ↩</a></li> <li id="fn:2">Apparently there is an issue with Snow Leopard's locales, and a single test fails.<a href="#fnref:2" class="reversefootnote"> ↩</a></li> <li id="fn:3">Full disclosure, I got this to the proof of concept stage but not really much further. It currently expects <code>local::lib</code> to be installed to <code>$HOME/perl5</code> (which is the default). If you have it installed somewhere else, you'll need to manually set up the environment.<a href="#fnref:3" class="reversefootnote"> ↩</a></li> <li id="fn:4">Having recently played with plugins in <code>cpanminus</code> I have to say they're incredibly nifty. The <code>github</code> plugin is especially nice. I especially would like a plugin to allow swapping Git in for several parts of the system.<a href="#fnref:4" class="reversefootnote"> ↩</a></li> </ol> </div> 2010-03-07T00:00:00Z Why I should (apparently) be shot on sight http://chris.prather.org/shot-on-sight.md.html <h1 id="whyishouldapparentlybeshotonsight">Why I should (apparently) be shot on sight</h1> Recently <code>chromatic</code> posted: <blockquote> [12:52] chromatic: More and more I think Module::Install hurts CPAN's installation experience. Ia! Ia! EUMM fhtagn! </blockquote> Which I found curious. I suspect it is because it resorts to driving ExtUtils::MakeMaker which <code>chromatic</code> has been vocal about hating in the past. It was however Elliot Shank's comments in response that I found really off putting. <blockquote> [12:58] clonezone: .@chromatic_x I want to throttle all CPAN authors that use Module::Install. M::I may be great for the author, but it sucks as a user. [12:59] clonezone: Any CPAN author that uses Module::AutoInstall should be shot on sight. </blockquote> Needless to say I use both <a href="http://search.cpan.org/dist/Module-Install/lib/Module/Install.pm">Module::Install</a> and <a href="http://search.cpan.org/dist/Module-Install/lib/Module/AutoInstall.pm">Module::AutoInstall</a>, and before the firing squad shows up to execute my unrepentant self I figured I should explain for posterity's sake. First some history. In 2003 I became interested in the <a href="http://openguides.org">OpenGuides</a> project. OpenGuides is a Perl based wiki to build guidebook style websites for Cities. I maintained a guide or two for a while before losing the time and resources to host them. OpenGuides uses Module::Build. Early on when I was starting to work with OpenGuides as a Guide Admin, a troublesome build of Module::Build had gotten into CPAN. I don't recall the details and to be honest they're not important. Things happen, not every release can be perfect. This build basically caused a ton of pain for anything that used Module::Build for installation. Obviously Module::Build has fixed these problems since then. I have not had a problem in over five years with Module::Build. Most of the time I don't recognize that it is even being used<a href="#fn:1" id="fnref:1" class="footnote">1</a>. This story isn't about Module::Build, it's about why I deserve to be shot on sight. The experience left a bad taste in my mouth. One bad module could break my entire toolchain. A module that the maintainers of OpenGuides didn't control and couldn't fix for me the user. That was a horrible experience, and it came right as I was starting to release my first Perl modules onto CPAN. I am lazy, and at the time I was using Module::Starter to build my distributions. Module::Starter would build my Makefile.PL to use EUMM and everything generally "just worked", but I still didn't like the fact that I had to rely upon the user having the right toolchain installed. When someone, I suspect <code>mst</code> suggested I take a look at Module::Install because it auto bundled itself into <code>inc/</code>. I was curious enough to take a look. The declarative sugar was nice, but the bundling was the important part. Now there has been an ages old debate about bundling. Adam Kennedy explained it well enough <blockquote> In the Module::Install model, all authors need to do incremental releases of the modules affected by the problem, but users need to do nothing. In the Module::Build model, all users affected by the problem need to upgrade their version of Module::Build, but authors need to do nothing. At present, both of these don't solve this problem correctly. Module::Install doesn't have a method for ensuring authors upgrade, and Module::Build doesn't have a method for ensuring users upgrade. </blockquote> I quite obviously lean strongly on the "make the author responsible" side of the fence. The number of Authors of CPAN modules is smaller than the number of Users of CPAN modules. Make the pain point as small as possible is my argument. Module::Build even supports bundling itself now as well. So this story isn't really about bundling either, this story is about why I deserve to be shot on sight. When one starts using Module::Install one quickly finds Module::AutoInstall, the one that has the firing squad after me. Module::AutoInstall will spawn a CPAN/CPANPLUS instance to chase down dependencies<a href="#fn:2" id="fnref:2" class="footnote">2</a>. We use this at one of my jobs to maintain our dependencies for the very large application we're maintaining, but it's a feature that CPAN and CPANPLUS both have managed to do for quite some time now. The other feature that Module::AutoInstall performs, the one I'm willing to be shot for, is Features. Features are what make utilities like <a href="http://search.cpan.org/dist/Task-Kensho"><code>Task::Kensho</code></a>, <a href="http://search.cpan.org/dist/Task-Catalyst">Task::Catalyst</a>, and <a href="http://search.cpan.org/dist/Task-Moose">Task::Moose</a> useful. They allow you to gather, possibly optional, dependencies together into smaller groups and present that as a choice to the user. Features do not exist in ExtUtils::MakeMaker, and in Module::Build the closest I could find was a "reccomends" dependency which lacks the grouping (as far as I could tell from the documentation). I have three modules that require Features to properly work. <code>Task::Kensho</code> and <code>JSON::Any</code> are the best known of them. Without Module::AutoInstall these two modules would be a much bigger hassle for my users. <code>JSON::Any</code> for example would require me to define a specific default JSON package and make the others "reccomended", this rather defeats the entire purpose of <code>JSON::Any</code>. As for <code>Task::Kensho</code>, one of the things I like most about it is that beyond a certain set of core modules relating to the tool chain and testing, everything else is optional. This means if you don't want or need <a href="http://search.cpan.org/dist/POE">POE</a> on your machine (perhaps because you enjoy AnyEvent), <code>Task::Kensho</code> doesn't force you to take it. But it does so at a large enough level that if you opt into POE, you get a good set of recommended modules picked by default. I am also lazy, I mentioned this. I have several Modules that need to be updated to no longer include <code>auto_install</code> because they don't need or use Features. But despite at least one of these modules being popular enough to make a Top 100 list, I have never had a complaint about not being able to install it. I cannot repent for thinking about my users<a href="#fn:3" id="fnref:3" class="footnote">3</a>. So I will clean up the modules I have that don't require Module::AutoInstall while I wait for the firing squad for the few modules that must have it so that the user experience is the nicest I can provide. By: Chris Prather on 2010-02-18T03:42:00 Tags: <div class="footnotes"> <hr /> <ol> <li id="fn:1">I give much thanks to Ken Williams, Michael Schwern, Eric Wilhelm, and David Golden for the work they've done over the years to make sure I don't notice Module::Build anymore. They are awesome people who are making the world better.<a href="#fnref:1" class="reversefootnote"> ↩</a></li> <li id="fn:2">It used to do this regardless of the environment it was in, but now has checks to bail if it's under a CPAN/CPANPLUS install. They're not perfect checks, but they should work on any CPAN releaed in the last two to three years.<a href="#fnref:2" class="reversefootnote"> ↩</a></li> <li id="fn:3">If I truly were going to make life easier on myself I would have moved to <a href="http://search.cpan.org/dist/Dist-Zilla">Dist::Zilla</a> and stopped even writing a Makefile.PL.<a href="#fnref:3" class="reversefootnote"> ↩</a></li> </ol> </div> 2010-02-18T03:42:00Z Perl Oasis 2010 Thank You http://chris.prather.org/perl-oasis-2010-thankyou.md.html <h1 id="perloasis2010thankyou">Perl Oasis 2010 Thank You</h1> So Perl Oasis 2010 is now done, I'm currently sitting in the Hackathon room watching people quietly mingle and work on their projects. All told we had 33 people from 15 PMs across 4 countries. This is a larger attendance than last year, but still small enough I felt I got to sit and talk with people and really hang out. To forestall questions, yes video was shot of all of the sessions. I'm unsure of how long the editing process will take, but expect an announcement when the video will be ready. The quality of all of the talks was excellent and overall The general comments I got were very favorable, things like "excellent workshop", "well organized". So I'm pleased with the results. On to the Thank You notes. I want to thank the people who came, these conferences simply wouldn't work if nobody wanted to attend. I also want to thank the speakers<a href="#fn:1" id="fnref:1" class="footnote">1</a>, nobody would want to attend if we didn't have such an excellent selection of talks. They were the show. I want to thank <a href="http://martian.org/marty/">Marty</a> and <a href="http://martian.org/karen/">Karen</a> Pauly who traveled the furthest to be there. They are 2/3rds of the reason why Shibuya.pm was tied for the largest attending PM group. Karen also let Jamie and I talk her ear off with our organizing nattering and worries about the TPF. I want to thank Mark Keating (mdk) for his excellent keynote on "The awful things we all must do and the most disgusting word you'll hear". He encourages all of us to step out and talk about Perl not in divisive terms (Perl5 vs. Perl6; Perl vs. Python, Ruby, PHP; Perl5 Version 10 vs. Perl 5.10) but rather to use inclusive terms (Rakudo and Moose and possibly Perl "Vincent"). Mark also presented me with our new mascot for Perl Oasis, Aurelia the Camel. <img src="http://farm5.static.flickr.com/4037/4282005529_f8bd070a6f.jpg" alt="Aurelia" id="aurelia" /> I want to thank <a href="">DataRocket Data Services</a>, who provided our A/V equipment. They are an excellent bunch of guys who do insane things with MySQL and very large data sets. I want to specifically thank Cory Watson (gphat) and <a href="http://magazines.com">Magazines.com</a> for stepping up and sponsoring the entire event. Without them we would be sitting in a parking lot somewhere, probably in the rain. Finally I would like to thank my wife, Jamie, who the attendees all know worked her ass off organizing. I am an incredibly disorganized person and without her nothing would ever have gotten done. We have already started talking with the venue about next year's conference which will be the 15th of January, 2011. I hope to see you then! By: Chris Prather on 2010-01-17T14:22:00 Tags: <div class="footnotes"> <hr /> <ol> <li id="fn:1">Specifically I should mention that Miyagawa says that we should help Plack become the top google hit for <a href="http://plackperl.org">Perl Web Server</a>. So let's help do that.<a href="#fnref:1" class="reversefootnote"> ↩</a></li> </ol> </div> 2010-01-17T14:22:00Z Starting out with OOD http://chris.prather.org/starting_out_with_ood.md.html <h1 id="startingoutwithood">Starting Out with OOD</h1> The <a href="http://stackoverflow.com/questions/1078838/oop-choosing-objects">basic question</a><a href="#fn:1" id="fnref:1" class="footnote">1</a> for Object Oriented Design is <blockquote> For a given domain, how do you break the model up into Objects and Classes?" </blockquote> Let's say we're going to build an application to model the life cycle of a Book. The naive approach is to start asking "What different things are involved with Books, and how are they related?" The domain can be literally infinite when you start breaking it out and exploring it in detail. This ability to break things up is part of the power of Object Oriented Design, because it seems like it should operate the way people have thought about the world for centuries. For the most part it does operate that way. Without constraint, however, you end up lost trying to achieve some platonic ideal (like the questioner on Stack Overflow) or you end up with what people have come to call <a href="http://en.wikipedia.org/wiki/Ravioli_code#Ravioli_code">Ravioli Code</a>. The platonic ideal trap is trying to figure out if a Book has an Author or a Author has a Book, and what to properly name the parent class of Books, Graphic Novels, and Magazines. It's involved with questions of should a Magazine have a "Table of Contents", Index, or Appendices? Should a Graphic Novel? Trying to sort these things out is a fool's errand of fiddling details that may have no reflection on the needs of the system you're building. If the <code>cover_style</code> attribute is never called, does it matter that it might possibly return <code>'hardback'</code> for a Magazine? The other end of the spectrum is Ravioli Code. Ravioli Code is what you get when you no-longer model discrete components in your logic, but rather model sub-components. It's like talking about a Book not as a collection of pages, words and phrases but rather as a sequence of glyphs and wood pulp recipes. The resolution of the focus of your model is too tight, not only can you not see the forrest for the trees, you can't see the tree for the wood grain. The Power of object oriented modeling needs to be constrained by the needs of the application you're building. Say for example you're building a system for tracking a single book that is being written without considering it's publishing or distribution. In this system you won't need to model Sales, Stores, Advertising or any number of things dealing with the distribution chain, nor would you need to know about paper bond, binding type, covers, type faces, line height or the minutia of building the artifact that is a Book. You will however need to model things like Pages, Chapters, Paragraphs. To bring this back around to the point, in any application of Object Oriented Design the goal is to have a Class or Object hierarchy that matches exactly as much of "reality" as you need to accurately describe and solve the problems you're writing a program to solve, and nothing more. There is a quote by Antoine de Saint-Exupery<a href="#fn:2" id="fnref:2" class="footnote">2</a>: <blockquote> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. </blockquote> Instead of starting with "What different things are involved with Books, and how are they related?" we with really should start with "what features of a Book do I need to enable my application to deal with?" By: Chris Prather on 2009-12-31T19:21:00 Tags: <div class="footnotes"> <hr /> <ol> <li id="fn:1">The accepted answer for this question on Stack Overflow is excellent.<a href="#fnref:1" class="reversefootnote"> ↩</a></li> <li id="fn:2"><a href="http://stevan-little.blogspot.com/">Stevan</a> uses this quote all the time<a href="#fnref:2" class="reversefootnote"> ↩</a></li> </ol> </div> 2009-12-31T19:21:00Z A Little Bit of History http://chris.prather.org/a-little-bit-of-history.md.html <h1 id="alittlebitofhistory">A Little Bit of History</h1> I recently did some digging for what may be some future writings, as well as possibly something larger. Part of those diggings involved research into Object Oriented programming's history. I found this example on wikipedia of Simula 67, the first Object Oriented programming language. <pre><code>Begin Class Glyph; Virtual: Procedure print Is Procedure print;; Begin End; Glyph Class Char (c); Character c; Begin Procedure print; OutChar(c); End; Glyph Class Line (elements); Ref (Glyph) Array elements; Begin Procedure print; Begin Integer i; For i:= 1 Step 1 Until UpperBound (elements, 1) Do elements (i).print; OutImage; End; End; Ref (Glyph) rg; Ref (Glyph) Array rgs (1 : 4); ! Main program; rgs (1):- New Char ('A'); rgs (2):- New Char ('b'); rgs (3):- New Char ('b'); rgs (4):- New Char ('a'); rg:- New Line (rgs); rg.print; End; </code></pre> Here is a translation of the Simula 67 Example using <a href="http://search.cpan.org/dist/MooseX-Declare">MooseX::Declare</a> <pre><code>{ use MooseX::Declare; class Glyph { sub print { confess â€œVirtualâ€ } } class Char extends Glyph { has char => ( isa => â€˜Charecterâ€™, is => â€˜roâ€™ ); method print { CORE::print $self->char } } class Line extends Glyph { has elements => ( isa => â€˜ArrayRef[Glyph]â€™, is => â€˜roâ€™ ); method print { $_->print for @{ $self->elements } } } # Main program my @rgs = map { Char->new(char=>$_) } qw(A b b a); my $rg = Line->new(elements => \@rgs); $rg->print; } </code></pre> There really isn't a point to this post, but I thought it was neat to see how nicely clean Object Oriented programming translates from it's earliest days to something very recent. By: Chris Prather on 2009-12-24T01:38:00 Tags: 2009-12-24T01:38:00Z Lies, Damn Lies, and Statistics http://chris.prather.org/lies-damn-liest-and-statistics.md.html <h1 id="liesdamnliesandstatistics">Lies, Damn Lies, and Statistics</h1> UPDATE: Aldo Cortesi contacted me privately via email with a response to this post. With his permission I've updated this post with the substance of his response and my own rebuttal. The updated sections are marked with UPDATE/END blocks. END So after chromatic <a href="http://identi.ca/notice/16739116">linked</a> to Aldo Cortesi's post <a href="http://corte.si/posts/code/devsurvey/index.html">The impact of language choice on github projects</a> I was curious. After reading the post, I was shocked and dismayed at some of the analysis Mr. Cortesi attempts to derive from his data. I brought it up on IRC and decided at first that <code>rjbs</code>'s advice is best, "just ignore it." Obviously that didn't stand, because I saw Flavio Poletti and osfameron <a href="http://www.polettix.it/perlettix/id_perl-5-parsing">both</a> <a href="http://greenokapi.net/blog/2009/12/15/github-language-statistics/">comment</a> about Cortesi's post. Upon second reflection I realized that perhaps there was some nice value to be taken out of the data he presents. At the time Cortesi extracted his data from github, Perl was the 6th most popular language.<a href="#fn:1" id="fnref:1" class="footnote">1</a> Cortesi's first two illustrations look particularly nice for Perl. First he pulled out the median number of contributors (emphasis is his). <blockquote> Most projects have around 3 contributors, with Perl and Java projects having about 5, and Javascript and Objective C around 2. </blockquote> This means in general that Perl projects have more developers than the other languages measured except for C++. This is a good sign. Next he pulled out the median number of commits (again emphasis his). <blockquote> Most projects have around 75 commits. </blockquote> Perl however in his data (again like C++) has a much higher media, nearly 200 commits median. His explanation for this was (to me) very unsatisfying. <blockquote> The Perl and C++ data, however, seems significant - projects in these languages on average have a much longer commit history. I suspect that this is due to a decline in popularity in these languages. Recall that I collected data only for projects that had recent commits. If fewer new projects are created in C++ and Perl, we would expect projects in these languages to be older, on average. </blockquote> I think that the sheer fact that Perl (and C++) are both much older languages is enough to explain the discrepancy. Perl has many projects that have converted from one or more version control systems (Moose for example has a revision history that is only a year younger than Git itself, and is considered a young project in the Perl world). The Perl community also tends to get behind a few good projects. This isn't really obvious unless you're active in the Perl community, there are many many things that aren't obvious unless you're in the Perl community, it actually is a problem but one for a later blog post. So to extrapolate further, the Perl community tries to engender people rather than create a new project, to use one of the 21 thousand existing projects to solve their problem. This explains why we have a higher median number of contributors to our projects as well as why our projects are on a whole older. UPDATE: Cortesi pointed out the following. <blockquote> The first point where you strongly disagree with me is my conjecture that the higher median commit count for Perl and C++ is due to a decline in popluarity in the languages, which means that my sample is skewed towards "older" projects. You counter that it might just be that Perl and C++ are older, and that this is reflected in the project data. This doesn't sound right to me - for one thing, Perl was first releaed in 1987, and Python in 1990. I just don't think that a 3 year difference over a 20+ year history can explain the size of the effect. One way to approach this might be to look at the rate of project creation over the last few years, which would be easy enough to do. </blockquote> He's right, I'm simply parroting the stereotype that Perl is older than Python (or even Ruby which came into existence in the mid 90s) when I rightly know better. The stereotype however does have some merit. It's generally accepted that Perl had it's second wind during the dot-com era and that was when Python had it's first wind. I'm honestly not sure that the data can be conclusive argued one way or the other without perhaps correlating the age of the data (time since first commit) in there as well. END Next Cortesi measured number of files touched per commit (emphasis his). <blockquote> Most commits touch about 4 files, with C++ touching somewhat more, and Perl, Python and Ruby somewhat less. </blockquote> This is most easily explained by the nature of the dynamic languages that more is done in smaller modules, blah blah blah. Neither Cortesi nor I really found anything interesting in this because it upholds the standard stereotypes. Next Cortesi talks about Contributors (emphasis his). <blockquote> The average contributor contributes about 5 commits to a project. C, Objective C and Ruby developers contribute somewhat less, PHP, C#, Java and Javascript developers somewhat more. I suspect the results for C and Ruby are due to projects in these languages receiving more one-off contributions. </blockquote> Here Perl clocks in at exactly the median. If I were to guess I think the meaning here is that on average Perl projects have on average a larger core group of contributers with smaller one off commits, and that these two facts offset each other. This story reflects the information above (higher median contributer count, older more established projects), as well as the next point Cortesi makes (emphasis his). <blockquote> For all languages, a small fraction of the committers do the vast majority of the work. This won't be news to anyone in the Open Source community. More interesting, though, is the fact that C, C++ and Perl projects are significantly more "top-heavy" than those in other languages, with a smaller core of contributors doing more of the work. </blockquote> This really just reinforces the previous point that Perl's projects are older and more established, with a stronger commitment from it's core contributors. This could be read as Perl being a dying language, just like C and C++. This could also be read as these three languages not being fad languages, where people swoop in, commit a whole bunch and then drift off. Really there isn't enough information here to tease out which is true. Finally Cortesi tries to make a correlation between the number of committers for projects and something. I think however there may be a problem with his analysis. First he measures commits vs committer as a measure of how well languages recruit and retain contributors. Perl here shows up fairly well actually, third only to Python and Ruby. I strongly suspect that the significant discrepancy in data between these languages (there are more than twice as many Python projects included as Perl, and Ruby is four times again as much as Python) may come into play, but I've no evidence to back that up. UPDATE: Cortesi noted the following, which is a fair point I overlooked. <blockquote> Here, I'd like to point out that the graph shows the total commits vs the total committers per project. As such, it doesn't tell us anything about the retention of committers - a committer who makes a single commit and leaves the project is still counted. I've been thinking about how to measure committer retention - perhaps looking at the timespan bracketed by the first and last commits of a committer, as a percentage of the lifespan of the project. </blockquote> END The next set of graphs shows the number of commits per day over the first 300 days of a project. Perl here shows a strong decline, the strongest actually. Coming in second is C, then Ruby being the last obviously show a decline (Python and C++ could arguably show a decline, but they just as arguably are flat). The other languages are all flat, or show a slight increase. A suggestion came up in the comments to Cortesi's that Perl projects tend to be "complete" and move into maintenance mode. Cortesi actively rejects this idea. While I disagree with his analysis<a href="#fn:2" id="fnref:2" class="footnote">2</a> I think he's correct in refuting this. I suspect that instead Perl projects quickly move to a point where they are obviously inferior to another project and are abandoned. This story would play out with the earlier arguments regarding the commit count, and the age of Perl projects. The story behind <code>DBIx::Class</code> is a good example (even though it works counter to my argument). Originally Matt Trout used and actively contributed to <code>Class::DBI</code>, <code>DBIx::Class</code> was intended to research ideas for moving <code>Class::DBI</code>'s codebase forward. It wasn't until fundamental design differences between <code>Class::DBI</code> and <code>DBIx::Class</code> were discovered that the fork of the community really occured, and even then for the longest time <code>DBIx::Class</code> maintained a CDBI compatible API. This story plays out more often in the small, and in many of those the research project is found to be fundamentally flawed, or folded back into the parent project, or abandoned due to lack of community interest. The fact that this story plays out again and again in the Perl community is in some ways very ironic considering the Perl motto of TIMTOWDI, but this is the basis of the new motto TIMTOWDI BSCINABTE (pronounced Timtoady Bicarbonate and meaning There Is More Than One Way To Do It, But Sometimes Consistence Is Not A Bad Thing Either). Finally, it's obvious in the analysis and comments that Cortesi dislikes Perl. He is allowed to have his opinion, obviously to anyone who reads more than one post on this blog I don't share it. I found it particularly dismaying<a href="#fn:3" id="fnref:3" class="footnote">3</a> however he let his opinion of Perl ruin his analysis, and lead to what he calls "the venomousness of some of the Perl commentators". I can only assume that the venomousness he is talking about was removed or particularly bad in email, because the comments that stand now appear relatively rational and inline with the tone set in the body. I can't pretend that the Perl community isn't full of loudmouth assholes, I'm one of them, however if people find themselves feeling venomous, they should take it to their own blog. Better yet, take a deep breath and start that new project that is really cool and will change the world, and upload it to github so that the world beyond Perl can see it. UPDATE: This is pure conjecture on my part, any opinion expressed here is entirely my own and has not been approved or vetted by Mr. Cortesi. Aldo seems genuinely surprised at the strength of reaction he had, and in speaking with him his comments weren't intended to be as inflammatory as they came off. I've expressed that the Perl of the past isn't the Modern Enlightened Perl we all know and love (YOU DO LOVE IT RIGHT?!?), and tried to show how things really are in the Perl universe I see rather than the one he's obviously experienced in the past. END By: Chris Prather on 2009-12-15T18:40:00 Tags: <div class="footnotes"> <hr /> <ol> <li id="fn:1">Today it is the second most popular language on github. The increase in "popularity" is entirely based upon the <a href="http://github.com/gitpan/"><code>gitpan</code></a> project which uploaded the entire <a href="http://backpan.perl.org/">Backpan</a> repository as git repos. However the 21,766 repositories in <code>gitpan</code> are not followed by at least 3 people each, so thankfully wouldn't affect the outcome of the experiment.<a href="#fnref:1" class="reversefootnote"> ↩</a></li> <li id="fn:2">The conclusion that Cortesi makes is that Perl is that Perl is somehow much more difficult a language to contribute to after 300 days, but this is contrary to the other evidence he presents that perl projects are in general older with a larger median contributor size, and a larger core of contributors over time.<a href="#fnref:2" class="reversefootnote"> ↩</a></li> <li id="fn:3">I for one found the "offhand speculation" didn't even follow the data presented accurately enough to justify its existence without a qualifier (simply stating "my opinion is that ... "). A stronger distinction between the analysis of the data, and the sterotypical opinions he thought it backed up might have helped tone down the venom.<a href="#fnref:3" class="reversefootnote"> ↩</a></li> </ol> </div> 2009-12-15T18:40:00Z If You Give a Mouse A Christmas http://chris.prather.org/if-you-give-a-mouse-a-christmas.md.html <h1 id="ifyougiveamouseachristmas">If You Give a Mouse A Christmas</h1> Jerrad Pierce wrote a <a href="http://www.perladvent.org/2009/1/">Perl Advent Calendar entry</a> that has sparked some discussion in the Moose community. He has revised it two or three times, and the final version is disappointing but not blatantly wrong. As a Moose contributor who has deployed Mouse into production I wanted to give some perspective on the issues that came up. Jerrad suggests strongly in the tone of his article that Mouse is everything you want in Moose but faster. There are some strong issues with this implication, the first being that there is no way to really know if that is true. Jerrad quotes the Mouse documentation by saying <blockquote> Mouse is "Moose without the antlers" i.e; lacking the thorny dependencies and added heft giving you a pain in the neck. </blockquote> But the truth is that the antlers the Mouse documentation is talking about isn't the dependencies (which I've <a href="http://chris.prather.org/moose-dependencies--a-lurid-tale.html">blogged about previously</a>), it is the Meta Object Protocol (the MOP). To quote Jerrad again (from one of his re-writes) <blockquote> [Mouse] can be a nicer, gentler introduction to the world of Moose. Like the cervine form, the rodent provides a simple means of providing accessors which are more explicit than a generalized AUTOLOAD mechanism, while still eliminating redundant code. Plenty of other fancy OO features come along for the ride, but no "metaprotocol stuff," which some would argue is the raison d'Ãªtre of Moose. </blockquote> Mouse implements much of the sugar from Moose, but implements the bare-minimum of an Object System to back up that sugar. <blockquote> You may be willing to make such a trade-off, but what if you're not writing the code, and instead run into some other module that foists Moose upon you? That author may or may not need all of Moose, but chances are good they don't. </blockquote> Here is where my problem with the solution provided in this calendar entry comes. Chances are that the developer who chose to use Moose has no clue which pieces of the MOP they rely upon. The MOP in Moose is a kind of an iceberg, everything in Moose is build around it. The thin sugar layer that most people interact with is only the surface of what is going on inside. This is the power of Moose. You don't need to know what is going on for 90% of the things you do, you just need to know that Moose works, and <a href="http://search.cpan.org/dist/MooseX-Aliases">MooseX::Aliases</a>, or <a href="http://search.cpan.org/dist/MooseX-Getopt">MooseX::Getopt</a>, or <a href="http://search.cpan.org/dist/MooseX-Storage">MooseX::Storage</a> can hook into the proper places in the MOP and get things done. Jerrad mentions this almost as an aside though in his calendar entry. <blockquote> Note that even if other code will compile correctly with Mouse, it's possible the code could be doing some deep introspection and you may end up with Chet rather than Comet. it is therefore recommended that you run the code's test suite against Mouse whether you force it through Package::Alias or substituting Any::Moose. </blockquote> How confident are you that your test suite includes the proper coverage for your application that you can detect subtle bugs in the MOP? I have a few applications that have high 90%+ test coverage, and I'm not sure they would deal well with having their object system replaced underneath them. The fact of the matter is that unless the upstream module author designed their application with possible Mouse usage in mind, it simply cannot be a safe guaranteed drop in replacement for Moose. This is why the Mouse documentation say to use Moose instead. This leads to my last, and sadly personal, issue with this calendar post. I'm an active member in the Moose community. I have been for about three years now. I am one of the people who will have to support the kinds of failure that this well intentioned but reckless advice will cause. If Jerrad had simply talked to us when writing this calendar post, we wouldn't have reacted so strongly. We could have pointed out the issues in the advice he was giving, and helped him to write a better article that focused on the important part of advocating Mouse as a reasonable replacement for Moose in some circumstances, and the interesting hack he performed with Package::Alias, or Alias.pm, or even the <code>import</code> hack someone in the Moose community suggested. By: Chris Prather on 2009-12-02T18:14:00 Tags: 2009-12-02T18:14:00Z Blawd: Now With Plack Control http://chris.prather.org/blawd-now-with-plack-control.md.html <h1 id="blawd:nowwithplackcontrol">Blawd: Now With Plack Control</h1> miyagawa, the esteemed ring-leader behind the <a href="http://plackperl.org/">PSGI/Plack</a> tonight in response to an idle comment about wanting to move Blawd's simple <code>server</code> command over to the PSGI standard supplied me with a quick patch to do just that. So as of the most recent commit <code>blawd server --repo myblog.git</code> should "just work" with any environment that speaks PSGI. The code itself was exceptionally elegant and I thought it deserved to be shown off. <pre><code>has host => ( isa => 'Str', is => 'ro', default => 'localhost' ); has port => ( isa => 'Int', is => 'ro', default => 1978 ); sub _build__http_engine { my ($self) = @_; HTTP::Engine->new( interface => { module => 'PSGI', request_handler => sub { $self->handle_request(@_) }, }, ); } sub execute { my $self = shift; my $app = sub { $self->_http_engine->run(@_) }; Plack::Loader->auto( host => $self->host, port => $self->port )->run($app); } </code></pre> The old version was based on <a href="http://search.cpan.org/dist/HTTP-Engine">HTTP::Engine</a> the new version takes advantage of the HTTP::Engine plack support. By: Chris Prather on 2009-12-02T00:00:00 Tags: 2009-12-02T00:00:00Z Software Delivery! http://chris.prather.org/software-delivery.md.html <h1 id="softwaredelivery">Software Delivery!</h1> I was just reading Matt Asay's <a href="http://news.cnet.com/8301-13505_3-10404406-16.html">piece</a> about Domino's using open source to build out their multi-million dollar order fulfillment system. His take away quote got me thinking. <blockquote> There will still be a need for companies like SAP, of course, as there are broad industry needs that a company or open-source foundation can satisfy. But for strategic IT projects, we're likely to see more open source plus internal development, and less packaged software purchases. </blockquote> The gist of this is that these companies like Domino's will be building up their internal IT departments to largely take on the kinds of projects that they would previously buy enterprise grade software from Microsoft or SAP. I disagree. I think (or perhaps hope) that this is the first step in a further evolution. There is no long term economic reason why Domino's should be in the the software development business. That's not their core business. Saying that the future of open source jobs is working for the Domino's internal software development group is like saying 20 years ago that the future of open source is the Operating System. I suspect in 20 years time that there will be (or recently have been) a shift from large in-house IT teams, to outsourced teams of consulting companies and independent contractors. Teams of people already surround open source projects. Some of these people are in-house developers at large corporations like Asay's article talks about (the Moose community for example has people from Walmart, the BBC, and Omni Hotels). Some of these developers work at smaller consultancies (again Moose has people from <a href="http://iinteractive.com">Infinity Interactive</a>, <a href="http://bestpractical.com">Best Practical</a>, and my own <a href="http://tamarou.com">Tamarou</a><a href="#fn:1" id="fnref:1" class="footnote">1</a>). Some of these people are even independent contractors. It seems like a very short step for these organizations do the heavy lifting for an enterprise level IT Project. The Corporate Sponsor could then choose to either hire a skeleton maintenance staff, or keep one or more of the project's organizations on retainer. In his book The Four Hour Work Week, Tim Ferris coined a term 'geo-arbitrage'. Arbitrage is the practice of taking advantage of a difference in prices between two or more markets. Geo-arbitrage is taking advantage of physically distinct markets (say India vs Europe). Geo and temporal arbitrage are what cause the radical lowering of cost for open source<a href="#fn:2" id="fnref:2" class="footnote">2</a>. Developers who are emotionally committed to a project somehow find non-monetary ways to value their time. Currently large corporations leverage geo arbitrage with a few very large strokes. They'll off-shore their internal developments staff (setting up a development office in Mumbai or Beijing for example), or they'll hire an external company to perform a large project. I don't think this will change, but I think that this will become much more sophisticated as time goes on. Large consultancies will themselves outsource development rather than hire more developers and maintain a large staff, or perhaps smaller consultancies will band together to tackle projects normally handled by the larger consultancies. The benefits for companies like Domino's are enormous. For starters smaller focused software shops are already experts in their specific tool chain and domain. Teaching a programmer who has already built six order fulfillment applications enough about the Pizza industry to drive an application story is easier than doing the reverse with an executive in the Pizza industry, or even a talented programmer who has no relevant experience. Second finding and retaining good developers is hard. Finding committed developers with a passion for an Open Source stack is even harder. Scott Adams (yes Dilbert's creator) recently <a href="http://www.dilbert.com/blog/entry/the_bad_management_stimulus/">noticed a trend</a>. <blockquote> Imagine a world where managers always recognized and rewarded their most capable people. It would be hard for a rational employee to leave a great job for a ten percent chance of creating something even greater. But leaving a boss who is Satan's learning-challenged little brother is relatively easy. And if the general economy isn't serving up wonderful job opportunities at other companies (thanks in part to bad management) then you can see why people gravitate toward starting their own companies. </blockquote> The best developers are already thinking of striking out on their own. These are already the people who are clued in. Why not let them step out on their own, and hire them back with a few of their talented friends in the community as a consultant? That IT manager may have been incompetent as an IT manager, but he or she might make an excellent liaison to the new consultants. Sometimes it is easier to work with someone than for someone. Also, some corporations are limited by law or economic reasons to their local market they are and they may have to make decisions based not on what is best but rather on what is available. A consultancy or contractor may have a lot more flexibility in the options they can bring to the table. Perhaps they have experience handing telecommuter teams, while your company doesn't. They might be able to hire a developer from Israel, who lives part times in France, and can finish that project in a week and a half. I'm not trying to gloss over the downsides of out sourcing. It is by no means always a rosy magical world of happiness. I am simply trying to illimunate the current efforts at outsourcing as the clumsy beginnings of what will become a much more sophisticated market. Some may claim that this will inevitably lead to the same situation we have today where the consultancies of tomorrow have a single product that they schlep from project to project. They may be correct, time will have to tell. I suspect that the truth in 20 years will be even stranger than we know. Update: Apparently the Perl Ironman blogging contest wants me to mention CPAN as well for it to show up. By: Chris Prather on 2009-11-27T15:36:00 Tags: <div class="footnotes"> <hr /> <ol> <li id="fn:1">Actually there are far more consulting companies than these three active in teh community, and I've been told it was remiss to not point out <a href="http://shadowcat.co.uk">ShadowCat</a> as well as <a href="http://cloudtone.ca">CloudTone</a><a href="#fnref:1" class="reversefootnote"> ↩</a></li> <li id="fn:2">Temporal-arbitrage being the concept that even in the same place, all other things being equal, prices change depending on the time. <a href="#fnref:2" class="reversefootnote"> ↩</a></li> </ol> </div> 2009-11-27T15:36:00Z Perl Oasis 2010: Discount Hotel Rates End http://chris.prather.org/perl-oasis-2010-hotel-rates-end.md.html <h1 id="perloasis2010:discounthotelratesend">Perl Oasis 2010: Discount Hotel Rates End</h1> November 25th is the last day for the Perl Oasis special Group Rate. The rate is $75 USD / night for what according to other sources is a $135-$150 / night hotel room. <a href="http://perloasis.org/opw2010/">Perl Oasis</a> is a one day workshop in Orlando Florida focusing on Modern Enlightened Perl. This year we have speakers from three continents, and the entire Perl spectrum speaking. The Call for Speakers is still open so you can <a href="http://perloasis.org/opw2010/newtalk">submit your talk</a> as well! By: Chris Prather on 2009-11-24T20:45:00 Tags: 2009-11-24T20:45:00Z What Stops Me From Using Perl6 Today http://chris.prather.org/what-stops-me-from-using-perl-6-today.md.html <h1 id="whatstopsmefromusingperl6today">What Stops Me From Using Perl6 Today</h1> I have to confess <code>mst</code> asked me to step forward and make a comment about the <a href="http://www.shadowcat.co.uk/blog/matt-s-trout/f_ck-perl-6/">Perl5</a> & <a href="http://use.perl.org/~masak/journal/39912">Perl6</a>. I suspect because I'm a prime example of a person who's deeply involved in what <code>masak</code> calls the Perl5 story. This is because I've been bound up tightly with the Moose community for a while, and I've recently founded a <a href="http://tamarou.com">company</a> that is doing Modern Enlightened Perl development. My bread is buttered by Perl5. Recently because of <code>mst</code> and <code>masak</code> sparking a conversation I have started taking a really close look at Perl6. One of the things that struck me was how polished and complete the core Perl6 language was, and the Rakudo implementation. This post started out as a much more whiney response to <code>bakkushan</code>'s <a href="http://howcaniexplainthis.blogspot.com/2009/11/what-stops-me-from-using-perl-6-today.html">post</a> of the same name. For that version of this post I set out to compare Perl6, specifically Rakudo, to my own cherished Moose. The Example object I came up with is a stripped down version of <a href="http://github.com/perigrin/blawd/blob/master/lib/Blawd/Entry/MultiMarkdown.pm"><code>Blawd::Entry::MultiMarkdown</code></a>. <pre><code>use 5.10.0; use MooseX::Declare; class Blawd::Entry { use MooseX::Types::DateTimeX qw(DateTime); has [qw(title author content filename)] => ( isa => 'Str', is => 'ro', required => 1, ); has date => ( isa => DateTime, is => 'ro', coerce => 1, required => 1, ); has headers => ( isa => 'Str', is => 'ro', default => '' ); has commit => ( is => 'ro', required => 1 ); } </code></pre> The Perl6 version is pretty straight forward. <pre><code>use v6; class Blawd::Entry { use Temporal; has Str $.title = die "Str title Required"; has Str $.author = die "Str author Required"; has Str $.content = die "Str content Required"; has Str $.filename = die "Str filename Required"; has DateTime $.date = die "DateTime date required"; has Object $.commit = die "Object commit required"; has Str $.headers = ''; } </code></pre> The Perl6 version is shorter, and arguably more elegant. <code>TimToady</code> helped me figure out the Perl6 equivalent to Moose's <code>required => 1</code>. You just set a default that will throw an exception when evaluated. But I've lost the type coercion on DateTime. In the Moose version it is provided in the MooseX::Types::DateTimeX library and enabled by the <code>isa => DateTime, coerce => 1</code> parameters passed into the <code>date</code> attribute constructor. I know this can be done in Perl6 and after several furtive attempts to find it in the documentation as well as a question that <code>TimToady</code> answered on <code>#perl6</code> I finally found a solution. <pre><code>class Int is also { method Time { Time.gmtime(self) } }; </code></pre> Trying to shoe horn that in after a second beer at 1:30am simply wasn't producing the desired results<a href="#fn:" id="fnref:" class="footnote">1</a>. Think about that for a second, my complaint was I couldn't get the Type Coercions to work as elegantly as I wanted. That's a far cry from "half finished vaporware". So while I have reservations about some of the current design regarding the metaobject protocol (I have offered and am still in dialog with the Perl6 people about helping them steal from Moose), Perl6 is a much more complete picture than the general grousing in the Perl5 community would give you. Does that mean I've jumped ship and will start hacking in Perl6? Probably not. While Perl6 may have more polish than I expected, and is a project that is well on it's way to being complete, it lacks some fundamental things I love about Perl5. The biggest of which is CPAN. Going back to my Blawd app as an example. Blawd is only 814 lines of code because I leverage CPAN. If you look at the dependencies from the <code>Makefile.PL</code> you'll see a tight list. <pre><code>requires 'aliased'; requires 'Bread::Board'; requires 'DateTime'; requires 'DBI'; requires 'Git::PurePerl'; requires 'HTTP::Engine'; requires 'Moose' => '0.92'; requires 'MooseX::Aliases'; requires 'MooseX::Types::DateTime'; requires 'MooseX::Types::DateTimeX'; requires 'MooseX::Types::Path::Class'; requires 'namespace::autoclean'; requires 'Path::Class'; requires 'Text::MultiMarkdown' => '1.0.30'; requires 'Try::Tiny'; requires 'XML::RSS'; </code></pre> Some of these are hard requirements, <code>Git::PurePerl</code> for example. Some of these are soft requirements, <code>DBI</code> for example I only use in the MoveableType exporter, and <code>HTTP::Engine</code> is only there for the experimental <code>server</code> back-end. The point however is that I have 15 dependencies for code I didn't have to write. If I wanted to start hacking up a Blawd in Perl6 I'd have to port <code>Git::PurePerl</code>, which itself turn requires 11 modules. <pre><code>'Archive::Extract' => '0', 'Compress::Raw::Zlib' => '0', 'Compress::Zlib' => '0', 'Data::Stream::Bulk' => '0', 'DateTime' => '0', 'Digest::SHA1' => '0', 'File::Find::Rule' => '0', 'IO::Digest', => '0', 'Moose' => '0', 'MooseX::StrictConstructor' => '0', 'MooseX::Types::Path::Class' => '0', </code></pre> Now Perl6 doesn't require some of these. Moose will hopefully not be required in Perl6 in the not too distant future. But what about <code>Digest::SHA1</code>? A quick google didn't find anything suitable as a replacement, so I'd have to re-write that as well. What it boils down to is there are far more Yaks than I want to shave in the Perl6 ecosystem. Just to replace my little 814 line hack, I'd have to write a Git implementation, a MultiMarkdown renderer, and an RSS feed generator. I've added <code>#perl6</code> to my IRC client. I'm keeping a closer eye on it, but for now I say long live Perl5, further up and further in. By: Chris Prather on 2009-11-16T14:12:00 Tags: <div class="footnotes"> <hr /> <ol> <li id="fn:">I was testing the results of this article with the following simple test. bin/perl6 -e' class Int is also { method Time { Time.gmtime(self) } }; class A { use Temporal; has Time $.foo = die "Not Declared" }; say A.new(foo => 1) ' Assignment type check failed; expected Time, but got Int<a href="#fnref:" class="reversefootnote"> ↩</a></li> </ol> </div> 2009-11-16T14:12:00Z