autarch's Journal http://use.perl.org/~autarch/journal/ autarch's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:02:57+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 autarch's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~autarch/journal/ Moose class in Minneapolis - September 23, 2009 http://use.perl.org/~autarch/journal/39626?from=rss <p>Just a heads up that I will be giving a one-day Moose class here in Minneapolis on Wednesday, September 23, 2009. The cost is a very low $120. Future classes will cost more, so take advantage of this while you can.</p><p>For more details on the class, please see <a href="http://blog.urth.org/2009/09/moose-class-in-minneapolis-september-23-2009.html">my blog</a>. You can <a href="https://www.theperlreview.com/cgi-bin/events.cgi">pay and register via the Perl Review website</a>.</p> autarch 2009-09-15T02:18:15+00:00 journal Moose class in Minneapolis - September 23, 2009 http://use.perl.org/~autarch/journal/39575?from=rss <p>Just a heads up that I will be giving a one-day Moose class here in Minneapolis on Wednesday, September 23, 2009. The cost is a very low $120. Future classes will cost more, so take advantage of this while you can.</p><p>For more details on the class, please see <a href="http://blog.urth.org/2009/09/moose-class-in-minneapolis-september-23-2009.html">my blog</a>. You can <a href="https://www.theperlreview.com/cgi-bin/events.cgi">pay and register via the Perl Review website</a>.</p> autarch 2009-09-03T20:54:30+00:00 journal No more cross-posting http://use.perl.org/~autarch/journal/38435?from=rss I'm so freaking sick of being spontaneously logged out from use Perl. The final straw was when it did this as I submitted my most recent cross-post. So, want to read my writing about programming? Check out <a href="http://blog.urth.org/">my blog</a>, which has a separate <a href="http://blog.urth.org/programming/">programming category</a>, with its own <a href="http://blog.urth.org/programming/atom.xml">category-specific Atom feed</a>. autarch 2009-02-09T17:28:04+00:00 journal Moose::Manual! http://use.perl.org/~autarch/journal/38403?from=rss <p>I'm very excited to announce the first release of the new Moose::Manual documentation as part of the Moose 0.66 release. This is part of the documentation work being funded by <a href="http://news.perlfoundation.org/2008/11/2008q4_grant_proposal_moose_do.html">the Moose docs grant from TPF</a>.</p><p>One of the complaints we often hear about Moose is that the docs are not good enough, and that it's hard to get started with it. The Manual was created to address this issue. I'm hoping that it will be a good starting point for people to understand Moose concepts and features. After reading it, you should be able to start creating Moose-based classes right away.</p><p>I also hope that people will give us feedback on the Manual. It's still new, and I'm sure there are parts that need polish, and concepts which were left out. If there's something you're confused about or wish were documented, please <a href="mailto:autarch@urth.org">email me</a> or visit the <a href="irc:ircperlorgmoose">Moose IRC channel</a> and tell us.</p><p><em>Cross-posted by hand from <a href="http://blog.urth.org/">House Absolute(ly Pointless)</a> - <a href="http://blog.urth.org/2009/02/moosemanual.html">permalink</a> </em>.</p> autarch 2009-02-03T19:35:43+00:00 journal books.perl.org - needs an owner or it goes away (mostly) http://use.perl.org/~autarch/journal/38245?from=rss <p>So I maintain (for some value of maintain) a few<nobr> <wbr></nobr>.perl.org things, including books.perl.org, on a VMWare server that the Perl NOC folks need to decomission.</p><p>Of those, apprentice.perl.org will just go away (it's long dead), and datetime.perl.org will move to my own server (it's just a very low-traffic wiki).</p><p>That leaves books.perl.org. This is a custom app, and it's a bit of a mess (actually, a horrible mess, the original died while in the midst of some major refactorings).</p><p>My take is that we don't really need a custom app for this sort of stuff, so I'm just going to extract the reviews and make them available as text, perhaps with the idea of putting them in the Perl 5 wiki or something.</p><p>However, if someone really wants to keep the site going, I can help you transition it elsewhere. The catch is that this needs to happen by the end of the month. If you're really gung-ho about this, email me at autarch @ urth.org.</p> autarch 2009-01-09T03:21:22+00:00 journal The Many Axes of Software Development http://use.perl.org/~autarch/journal/38000?from=rss <p>People want many things from software, and those desires are often contradictory. There's a constant back and forth about what people want from CPAN modules, in particular. It seems like we have the same arguments year after year. I think talking about priorities before talking about why something is good or bad is crucial.</p><p>So what are these priorities? How do they work together? Which ones are contradictory? Which ones are most important to you, and when do the priorities shift?</p><p>(Note: when I say library below, mentally substitute "module, library, distro, or framework")</p><ul> <li> <p> <strong>Well-vetted</strong> - When looking for a library, you might want something other people have already used for a while. You want to know that it does what it says on the box, and that most of the big bugs have been found.</p></li><li> <p> <strong>Cutting Edge</strong> - Some folks like to use new stuff. It's fun to experiment, and often the new stuff is the most advanced, most interesting, most time-saving. It could also be the biggest new piece of shit, the buggiest, slowest, etc.</p></li><li> <p> <strong>Dependency free</strong> - The CPAN depdendency discussion never goes away. Some people really, <em>really</em> don't like large dependency chains. When you want to use a module as part of an app, and you want non Perl gurus to install that app, this becomes a huge issue. Telling them "just install these 100 modules from CPAN" doesn't cut it.</p></li><li> <p> <strong>Small (does one thing)</strong> - Less code means less bugs. It also means less docs to read, and makes a library simpler to learn.</p></li><li> <p> <strong>Easy to integrate</strong> - Some libraries are designed to be integrated with other modules (Catalyst), some want you to embrace their world (Jifty).</p></li><li> <p> <strong>Complete</strong> - Some libraries come with a complete solution (Jifty) and some require you to put together a bunch of pieces into a whole (Catalyst).</p></li><li> <p> <strong>Fast</strong> - Sometimes speed (of compilation and/or execution) really matter.</p></li><li> <p> <strong>Memory frugal</strong> - Just like with speed, sometimes memory usage matters.</p></li><li> <p> <strong>No XS</strong> - Sometimes you're stuck using a system where you can't compile anything. Or maybe you have a compiler, but the module requires external C libraries, and you can't install them (a hosted account).</p></li><li> <p> <strong>Active development</strong> - Maybe you feel more comfortable knowing the module has a future, even if that means a higher rate of change.</p></li><li> <p> <strong>Stable</strong> - On the other hand, maybe you want something that's just done, where you know new releases will be infrequent and backwards compatible.</p></li></ul><p>I'm sure there are more priorities (feel free to mention some in the comments). It's easy to say we want all of these things, but there are many, many conflicts here. I won't go into all of them, but here's a few examples.</p><p>If you want <strong>well-vetted</strong>, you're not going to be using <strong>cutting edge</strong> code.</p><p>If you want <strong>dependency free</strong>, that code is probably not <strong>well-vetted</strong>. That dependency free code probably has some reinvented wheels, and those wheels are probably less round than the dependency they avoid.</p><p>If you want <strong>fast</strong> or <strong>memory frugal</strong>, you probably can't also insist on <strong>no XS</strong>. If you want <strong>complete</strong> solutions, than <strong>small</strong> and <strong>easy to integrate</strong> may go out the window.</p><p>Personally, my top priorities are usually <strong>small</strong>, <strong>easy to integrate</strong>, and <strong>active development</strong>. I'd rather learn several small pieces and put them together than try to digest a big framework all at once. And I'd rather have an active community, even if I have to keep up with API changes.</p><p>I don't care <em>too</em> much about <strong>fast</strong> or <strong>memory frugal</strong>. I work on a lot of webapps, which are often less demanding performance wise, at least if you can count on a dedicated server or two. Contrast this to a small "throw it in cgi-bin" app. Webapps also often have a lot of opportunities for speed improvements at the application level with caching and other strategies, so I worry less about the underlying libraries.</p><p>I'd much prefer <strong>well-vetted</strong> to <strong>dependency free</strong>. I think the latter is an entirely false economy, and what we really need are much, much better installer tools.</p><p>But these are just my priorities for the work I do most often. If I were working on an embedded data-crunching app, I'm sure my priorities would change quite a bit!</p><p>I'd like to see people state their priorities up front, and explain why it's important for the work they do. Often this gets left out of the discussion. Without this information, we often end up just talking past each other.</p><p> <em>Cross-posted from <a href="http://blog.urth.org/">House Absolute(ly Pointless)</a> - <a href="http://blog.urth.org/programming/index.html#000028">permalink</a> </em>. </p> autarch 2008-12-02T04:13:03+00:00 journal Frozen Perl 2009 Draft Schedule http://use.perl.org/~autarch/journal/37923?from=rss <p>We just published our <a href="http://www.frozen-perl.org/mpw2009/schedule">first draft schedule</a> for Frozen Perl 2009. There's a lot of great talks being given, and there's still plenty of time to register at the early bird rate. That's $20 for student/low-income individuals and $40 for everyone else.</p> autarch 2008-11-22T22:33:21+00:00 journal Frozen Perl CFS ends tonight! http://use.perl.org/~autarch/journal/37913?from=rss <p>Please <a href="http://www.frozen-perl.org/mpw2009/cfs.html">submit your talks</a> if you've been waiting to do so!</p><p>Also, check out the class that brian d foy is offering.</p> autarch 2008-11-20T19:20:58+00:00 journal Mastering Perl class at Frozen Perl http://use.perl.org/~autarch/journal/37874?from=rss <p>At <a href="http://www.frozen-perl.org/">Frozen Perl</a>, brian d foy will offer a <a href="http://www.frozen-perl.org/mpw2009/class.html">one-day Mastering Perl class</a>. The class will take place on Friday, February 6, the day before the workshop.</p><p>The class is a very affordable $100, and we have a few student spots available for just $25. This sort of class would is normally more expensive, but brian is doing this to help support the workshop and the Perl community.</p><p>I think this will be a great class. The content is well-suited for people who already know Perl but want to become more accomplished Perl hackers.</p> autarch 2008-11-14T04:45:58+00:00 journal Discoverability in REST vs Providing an API http://use.perl.org/~autarch/journal/37781?from=rss <p>I'm still stuck on the whole problem of the requirement that URIs for REST APIs be discoverable, not documented. It's not so much that making them discoverable is hard, it's that making them discoverable makes them useless for some (common) purposes.</p><p>When <a href="/2008/10/but-i-like-docs-roy.html">I last wrote about REST</a>, I got <a href="http://use.perl.org/comments.pl?sid=41350">taken to task</a> and even called a traitor (ok, I didn't take that very seriously<nobr> <wbr></nobr>;) Aristotle Pagaltzis (and Matt Trout via IRC) told me to take a look at <a href="http://tools.ietf.org/html/rfc5023">AtomPub</a>.</p><p>I took a look, and it totally makes sense. It defines a bunch of document types, which along with the original <a href="http://www.ietf.org/rfc/rfc4287">Atom Syndication Format</a>, would let you easily write a non-browser based client for publishing to and reading from an Atom(Pub)-capable site. That's cool, but this is for a very specific type of client. By specific I mean that the publishing tool is going to be interactive. The user navigates the Atom workspaces, in the client finds the collection they're looking for, POSTs to it, and they have a new document on the site.</p><p>But what about a non-interactive client? I just don't see how REST could work for this.</p><p>Let me provide a very specific example. I have this site <a href="http://www.vegguide.org/">VegGuide.org</a>. It's a database of veg-friendly restaurant, grocers, etc., organized in a tree of regions. At the root of the tree, we have "The World". The leafs of that node are things like "North America", "Europe", etc. In turn "North America" contains "Canada", "Mexico" and "USA". This continues until you find nodes which only contain entries, not other regions, like "Chicago" and "Manhattan".</p><p>(There are also other ways to navigate this space, but none of them would be helpful for the problem I'm about to outline.)</p><p>I'd like for VegGuide to have a proper REST API, and in fact its existing URIs are all designed to work both for browsers and for clients which can do "proper" REST (and don't need HTML, just "raw" data in some other form). I haven't actually gotten around to making the site produce non-HTML output yet, but I could, just by looking at the Accept header a client sends.</p><p>Let's say that Jane Random wants to get all the entries for Chicago, maybe process them a bit, and then republish them on her site. At a high level, what Jane wants is to have a cron job fetch the entries for Chicago each night and then generate some HTML pages for her site based on that data.</p><p>How could she do this with a proper REST API? Remember, Jane is not allowed to <em>know</em> that http://www.vegguide.org/region/93 is Chicago's URI. Instead, her client must go to the site root and somehow "discover" Chicago!</p><p>The site root will return a JSON document something like this:</p><p> <code> { regions: [ { name: "North America", uri: "http://www.vegguide.org/region/1" }, { name: "South America", uri: "http://www.vegguide.org/region/28" } } ] } </code> </p><p>Then her client can go to the URI for North America, which will return a similar JSON document:</p><p> <code> { regions: [ { name: "Canada", uri: "http://www.vegguide.org/region/19" }, { name: "USA", uri: "http://www.vegguide.org/region/2" } } ] } </code> </p><p>Her client can pick USA and so on until it finally gets to <a href="theURIforChicago">http://www.vegguide.org/region/93</a>, which returns:</p><p> <code> { entries: [ { name: "Soul Vegetarian East", uri: "http://www.vegguide.org/entry/46", rating: 4.3 }, { name: "Chicago Diner", uri: "http://www.vegguide.org/entry/56", rating: 3.9 }, ] } </code> </p><p>Now the client has the data it wants and can do its thing.</p><p>Here's the problem. How the hell is this automated client supposed to <strong>know</strong> how to navigate through this hierarchy?</p><p>The only (non-AI) possibility I can see is that Jane must embed some sort of knowledge that she has <em>as a human</em> into the code. This knowledge simply isn't available in the information that the REST documents provide.</p><p>Maybe Jane will browse the site and figure out that these regions exist, and hard-code the client to follow them. Her client could have a list of names to look for in order: "North America", "USA", "Illiinois", "Chicago".</p><p>If the names changed and the client couldn't find them in the REST documents, it could throw an error and Jane could tweak the client. A sufficiently flexible client could allow her to set this "name chain" in a config file. Or maybe the client could use regexes so that some possible changes ("USA" becomes "United States") are accounted for ahead of time.</p><p>Of course, if Jane is paying attention, she will quickly notice that the URIs in the JSON documents happen to match the URIs in their browser, and she'll hardcode her client to just GET <a href="http://www.vegguide.org/region/93">the URI for Chicago</a> and be done with it. And since sites should have Cool URIs, this will work for the life of the site.</p><p>Maybe the answer is that I'm trying to use REST for something inherently outside the scope of REST. Maybe REST just isn't for non-interactive clients that want to get a small part of some site's content.</p><p>That'd be sad, because non-interactive clients which interact with just part of a site are fantastically useful, and much easier to write than full-fledged interactive clients which can interact with the entire site (the latter is commonly called a web browser!).</p><p>REST's discoverability requirement is very much opposed to my personal concept of an API. An API is <em>not</em> discoverable, it's documented.</p><p>Imagine if I released a Perl module and said, "my classes use Moose, which provides a standard metaclass API (see RFC124945). Use this metaclass API to discover the methods and attributes of each class."</p><p>You, as an API consumer, could do this, but I doubt you'd consider this a "real" API.</p><p>So as I said before, I suspect I'll end up writing something that's only sort of REST-like. I <em>will</em> provide well-documented document types (as opposed to JSON blobs), and those document types <em>will</em> all include hyperlinks. However, I'm also going to document my site's URI space so that people can write non-interactive clients.</p><p> <em>Cross-posted from <a href="http://blog.urth.org/">House Absolute(ly Pointless)</a> - <a href="http://blog.urth.org/programming/index.html#000026">permalink</a> </em>. </p> autarch 2008-11-01T21:23:44+00:00 journal I'd Like to Be Dead Like Perl http://use.perl.org/~autarch/journal/37731?from=rss <p>The "Perl is Dead" meme has been going around for some time. It seems like one of those self-reinforcing things that people keep repeating, but where's the evidence? The other half of the meme is that other dynamic languages, specifically Ruby, Python, and PHP are gaining market/mind share.</p><p>That is true. I hear a lot more about Python, Ruby, and even PHP these days than I did five or ten years ago. Does that mean Perl is dead? No, it just means Python, Ruby, and PHP are doing better now than in the past. That's not bad for Perl. On the contrary, my theory is that a rising "dynamic languages" tide will lift all boats.</p><p>Tim Bunce <a href="http://blog.timbunce.org/2008/02/12/comparative-language-job-trend-graphs/">wrote about job posting trends</a> in February of 2008, and it's interesting reading. Unsurprisingly (to me), all of Perl, PHP, Ruby, and Python jobs are growing, and while Ruby and Python are growing faster than Perl, Perl is still <em>way</em> ahead of them. My guess is that eventually they'll level out around Perl's percentage and start growing slower.</p><p>Today I was thinking about Perl's reported morbidity (in the context of a relatively stupid "Perl 6 is Vaporware" article (that I don't care to link to because it was lame)).</p><p>Perl could have a lot of jobs and still be dead. After all, COBOL has a lot of jobs, but no one thinks of COBOL as a "living" language, it's just undead.</p><p>I decided to take a quick look at books instead. My theory is that if people are buying books on a topic, it must have some life, because that means someone wants to learn about said topic.</p><p>The flagship Perl book is <a href="http://www.amazon.com/Learning-Perl-5th-Randal-Schwartz/dp/0596520107">O'Reilly's Learning Perl</a>. The fifth edition was just released in June of this year.</p><p>It's currently #3,984 amongst all books, which isn't bad. Even more impressive, it's #1 in the Amazon category of "Books &gt; Computers &amp; Internet &gt; Programming &gt; Introductory &amp; Beginning". This would be more impressive if this category included Learning Python, but I don't think it does.</p><p> <a href="http://www.amazon.com/Learning-Python-3rd-Mark-Lutz/dp/0596513984">O'Reilly's Learning Python</a> is also doing well, at #3,357 among all books. In fact, this is the highest rank book of those I looked at.</p><p> <a href="http://www.amazon.com/Learning-Ruby-Michael-Fitzgerald/dp/0596529864">O'Reilly's Learning Ruby</a> is at #194,677, which I can only assume reflects the book, not Ruby itself. The best-selling intro-level Ruby book is (I think) <a href="http://www.amazon.com/Beginning-Ruby-Novice-Professional/dp/1590597664">Beginning Ruby: From Novice to Professional</a>, at #23,024.</p><p>So Perl seems to be holding its own, and for some reason the intro Ruby books aren't selling well.</p><p>On to <a href="http://www.amazon.com/Programming-Perl-3rd-Larry-Wall/dp/0596000278">O'Reilly's Programming Perl</a>, which is <strong>the</strong> Perl reference, despite being rather old (8 years). It's at #12,428.</p><p> <a href="http://www.amazon.com/Programming-Python-Mark-Lutz/dp/0596009259">O'Reilly's Programming Python</a> is at #32,658. I would've expected <a href="http://www.amazon.com/Dive-Into-Python-Mark-Pilgrim/dp/1590593561">Dive Into Python</a> to do much better than #177,394. It has very high ratings, much better than Programming Python, and I've heard good things about it on the net. Go figure.</p><p> <a href="http://www.amazon.com/Ruby-Programming-Language-David-Flanagan/dp/0596516177">O'Reilly's The Ruby Programming Language</a> is at #5,048 and <a href="http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055">Programming Ruby</a> is at #13,125. My guess is that many people skip the intro level Ruby books in favor of these two.</p><p>So what's the summary? Each of these three languages has at least one book in the top 10,000, and the best selling books for each language are all relatively close. Certainly, Perl is looking pretty good in this light.</p><p>Another interesting thing about the Perl book market is the sheer number of niche Perl books out there, <a href="http://www.masonbook.com/">one of which I co-wrote</a>. Compare <a href="http://oreilly.com/pub/topic/python">O'Reilly's Python book page</a> to <a href="http://oreilly.com/pub/topic/perl">their Perl page</a>. Of course, the Python page has more recent books, but maybe they're just catching up on topics Perl had covered years ago.</p><p>This is all quite unscientific, but I think there's some value here. My conclusion is that Perl is not quite dead yet, and is in fact doing reasonably well. While it may not have the same buzz that the new kids have, people still want to learn it.</p><p> <em>Cross-posted from <a href="http://blog.urth.org/">House Absolute(ly Pointless)</a> - <a href="http://blog.urth.org/programming/index.html#000025">permalink</a> </em>. </p> autarch 2008-10-25T01:32:39+00:00 journal But I Like Docs, Roy! http://use.perl.org/~autarch/journal/37714?from=rss <p>Roy Fielding, the inventor of REST, wrote a blog post recently titled <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven">REST APIs must be hypertext-driven</a>. It's quite hard to understand, being written in pure academese, but I think I get the gist.</p><p>The gist is that for an API to be properly RESTful it must be discoverable. Specifically, you should be able to point a client at the root URI (/) and have it find all the resources that the API exposes. This is a cool idea, in theory, but very problematic in practice.</p><p>A consequence of this restriction is that any sort of documentation that contains a list of URIs (or URI templates, more likely) and documentation on accepted parameters is verboten.</p><p>Presumably, if I had a sufficiently smart client that understood the media types used in the application, I'd point it at the root URI, it'd discover all the URIs, and I could manipulate and fetch data along the way.</p><p>That's a nice theory, but has very little with how people want to use these APIs. For a simple example, let's take Netflix. Let's assume that I want to use the Netflix API to search for a movie, get a list of results and present it back for a human to pick from, and add something from that list to my queue.</p><p>Without prior documentation on what the URIs are, how would I implement my client? How do I get those search results? Does my little client appgo to the root URI and then looks at the returned data for a URI somehow "labeled" as the search URI? How does my client <em>know</em> which URI is which without manual intervention?</p><p>If I understand correctly this would somehow all be encoded in the definition of the media types for the API. Rather than define a bunch of URI templates up front, I might have a media type of x-netflix/resource-listing, which is maybe a JSON document containing label/URI/media type triplet. One of those label/URI pairs may be "Search/http://...". Then my client POSTS that URI using the x-netflix/movie-search media type. It gets back a x-netflix/movie-listing entity, which contains a list of movies, each of which consists of a title and URI. I GET each movie URI, which returns an x-netflix/movie document, which contains a URI template for posting to a queue? Okay, I'm lost on that last bit. I can't even figure this out.</p><p>Resource creation and modification seems even worse. To create or modify resources, we would have a media type to describe each resource's parameters and type constraints, but figuring out how to create one would involve traversing the URI space (somehow) until you found the right URI to which to POST.</p><p>Of course, this all "just works" with a web browser, but the whole point of having a web API is to allow someone to build tools that can be used outside of a human-clicks-on-things-they're-interested-in interface. We want to automate tasks without requiring any human interaction. If it requires human intervention and intelligence at each step, we might as well use a web browser.</p><p>I can sort of imagine how all this would work in theory, but I have trouble imagining this not being horribly resource-intensive (gotta make 10 requests before I figure out where I can POST), and very complicated to code against.</p><p>Worse, it makes casual use of the API much harder, since the docs basically would say something like this<nobr> <wbr></nobr>...</p><p>"Here's all my media types. Here's my root URI. Build a client capable of understanding <em>all</em> of these media types, then point it at the root URI and eventually the client will find the URI of the thing you're interested in."</p><p>Compare this with the Pseudo-REST API Fielding says is wrong, which says "here is how you get information on a single Person. GET a URI like this<nobr> <wbr></nobr>..."</p><p>Fielding's REST basically rules out casual implementers and users, since you have to build a complete implementation of all the media types in advance. Compare this to the pseudo-REST API he points out. You can easily build a client which only handles a very small subset of the APIs URIs. Imagine if your client had to handle every URI properly before it could do anything!</p><p>In the comments in his blog, Fielding throws in something that <em>really</em> makes me wonder if REST is feasible. He says,</p><blockquote><div><p>A truly RESTful API looks like hypertext. Every addressable unit of information carries an address, either explicitly (e.g., link and id attributes) or implicitly (e.g., derived from the media type definition and representation structure). Query results are represented by a list of links with summary information, not by arrays of object representations (query is not a substitute for identification of resources).</p></div> </blockquote><p>Look at last sentence carefully. A "truly RESTful API", in response to a search query, responds not with the information asked for, but a list of links! So if I do a search for movies and I get a hundred movies back, what I really get is a summary (title and short description, maybe) and a bunch of links. Then if I want to learn more about each movie <strong>I have to request each of 100 different URIs separately!</strong> </p><p>It's quite possible that I've completely misunderstood Fielding's blog post, but I don't think so, especially based on what he said in the comments.</p><p>I'm not going argue that REST is something other than what Fielding says, because he's the expert, but I'm not so sure I really want to create true REST APIs any more. Maybe from now I'll be creating "APIs which share some characteristics with REST but are not quite REST".</p><p> <em>Cross-posted from <a href="http://blog.urth.org/">House Absolute(ly Pointless)</a> - <a href="http://blog.urth.org/programming/index.html#000022">permalink</a> </em>. </p> autarch 2008-10-21T22:35:29+00:00 journal You don't need to scale http://use.perl.org/~autarch/journal/37642?from=rss <p>Programmers like to talk about scaling and performance. They talk about how they made things faster, how some app somewhere is hosted on some large number of machines, how they can parallelize some task, and so on. They particularly like to talk about techniques used by monster sites like Yahoo, Twitter, Flickr, etc. Things like federation, sharding, and so on come up regularly, along with talk of MogileFS, memcached, and job queues.</p><p>This is lot like gun collectors talking about the relative penetration and stopping power of their guns. It's fun for them, and there's some dick-wagging involved, but it doesn't come into practice all that much.</p><p>Most programmers are working on projects where scaling and speed just aren't all that important. It's probably a webapp with a database backend, and they're never going to hit the point where any "standard' component becomes an insoluble bottleneck. As long as the app responds "fast enough", it's fine. You'll never need to handle thousands of request per minute.</p><p>The thing that developers usually like to finger as the scaling problem is the database, but fixing this is simple.</p><p>If the database is too slow, you throw some more hardware at it. Do some profiling and pick a combination of more CPU cores, more memory, and faster disks. Until you have to have more than 8 CPUs, 16GB RAM, and a RAID5 (6? 10?) array of 15,000 RPM disks, your only database scaling decision will be "what new system should I move my DBMS to". If you have enough money, you can just buy that thing up front.</p><p>Even before you get to the hardware limit, you can do intelligent things like profiling and caching the results of just a few queries and often get a massive win.</p><p>If your app is using too much CPU on one machine, you just throw some more app servers at it and use some sort of simple load balancing system. Only the most brain-short-sighted or clueless developers build apps that can't scale beyond a single app server (I'm looking at you, you know who).</p><p>All three of these strategies are well-known and quite simple, and thus are no fun, because they earn no bragging rights. However, most apps will never need more than this. A simple combination of hardware upgrades, simple horizontal app server scaling, and profiling and caching is enough.</p><p>This comes back to people fretting about the cost of using things like <a href="http://search.cpan.org/dist/DateTime">DateTime</a> or <a href="http://search.cpan.org/dist/Moose">Moose</a>.</p><p>I'll be the first to admit that DateTime is the slowest date module on CPAN. It's also the most useful and correct. Unless you're making thousands of objects with it in a single request, please stop telling me it's slow. If you <em>are</em> making thousands of objects, patches are welcome!</p><p>But really, outside your delusions of application grandeur, does it really matter? Are you really going to be getting millions of requests per day? Or is it more like a few thousand?</p><p>There's a whole lot of sites and webapps that only need to support a couple hundred or thousand users. You're probably working on one of them<nobr> <wbr></nobr>;)</p><p> <em>Cross-posted from <a href="http://blog.urth.org/">House Absolute(ly Pointless)</a> - <a href="http://blog.urth.org/programming/index.html#000020">permalink</a> </em>. </p> autarch 2008-10-11T16:01:00+00:00 journal Perl with debugging symbols on Win32? http://use.perl.org/~autarch/journal/37552?from=rss <p>I'm trying to figure out what's causing a <a href="http://www.nntp.perl.org/group/perl.cpan.testers/2008/09/msg2256900.html">new test failure</a> for Moose on Win32. I've reproduced it with Strawberry 5.8.8 on a Windows XP VM, and also found that it does not happen with 5.10.0.</p><p>It's a segfault in perl.exe, and without a perl.exe with debugging symbols, all I can get out of the failure is a stacktrace in assembly, which is clearly not very helpful.</p><p>Are there any Win32 experts out there who could do some investigating? Just getting a stack trace with the Perl core function names in the trace would probably be very helpful. Actually fixing the problem even more so<nobr> <wbr></nobr>;)</p> autarch 2008-09-27T00:59:29+00:00 journal Cross-posting from Movable Type to use Perl http://use.perl.org/~autarch/journal/37374?from=rss <p>If you're seeing this on use Perl then the cross-poster is working. You can <a href="https://svn.urth.org/svn/MT-Plugin-UsePerl-Journal/trunk/">get it from my svn</a>. You'll also need to install WWW::UsePerl::Journal, which I monkey patch like crazy in the plugin. I have submitted patches to barbie, though, so hopefully that'll go away in the future.</p><p>The plugin isn't too smart, so if you save the same entry it'll re-crosspost each time. Patches welcome, of course.</p><p> <em>Cross-posted from <a href="http://blog.urth.org/">House Absolute(ly Pointless)</a> - <a href="http://blog.urth.org/programming/index.html#000018">permalink</a> </em>. </p> autarch 2008-09-06T16:00:50+00:00 journal Answering "What is Moose" and "Why Moose" http://use.perl.org/~autarch/journal/37343?from=rss <p>I now have <a href="http://blog.urth.org/">my own blog elsewhere</a>. I finally got some programming content on it, <a href="http://blog.urth.org/2008/09/new-moose-docs-aim-to-answer-what-is-moose-and-why-moose.html">New Moose Docs Aim to Answer "What is Moose?" and "Why Moose?"</a>.</p><p>As an aside, anyone have a plugin for Movable Type to crosspost to a use Perl journal?</p> autarch 2008-09-03T22:43:31+00:00 journal Frozen Perl mini-documentary on Current http://use.perl.org/~autarch/journal/37204?from=rss <p>My friend Gabe Cheifetz made a mini-documentary at Frozen Perl 2008 for Current TV. You can check it out <a href="http://current.com/items/89141442_code_a_thon_decoded">at current.com</a>.</p><p>Unfortunately, current made some additional changes to Gabe's final product, apparently mostly to introduce factual errors. Doh! You'll notice them as soon as you watch it, but I left a comment on their site with corrections for non-geeks.</p><p>Nonetheless, I think it's neat.</p> autarch 2008-08-16T15:33:19+00:00 journal Looking for Co-maintainers (Log::Dispatch, maybe others) http://use.perl.org/~autarch/journal/37193?from=rss <p>I have a lot of <a href="http://search.cpan.org/~drolsky/">modules on CPAN</a>. There are way too many for me to give them all the attention they deserve, so often patches get dropped and bugs ignored.</p><p>In particular, there are a few that could use the attention of someone interested in helping maintain them. Log::Dispatch is used by a lot of people, and could definitely use some attention. There are a number of <a href="http://rt.cpan.org/Public/Dist/Display.html?Name=Log-Dispatch">open bugs</a> in RT, and I have more patches &amp; bugs in my email inbox.</p><p>Another distro that could use some love is Alzabo. I don't think it has a lot of users, but if you are a user of it and want to see it better maintained, let me know.</p><p>If there is some other distro of mine that you'd like to help maintain, especially one with open bugs, please let me know.</p><p>Write to autarch@urth.org and tell me what you'd like to help with. If I don't know you, I'll probably ask you to start by submitting a patch. All of my code is in <a href="http://svn.urth.org/">my svn repo</a>, so getting the latest version is easy (https://svn.urth.org/svn/Distro-Name/trunk).</p> autarch 2008-08-15T14:28:04+00:00 journal So you want to host a Perl workshop ... http://use.perl.org/~autarch/journal/35803?from=rss <p>Frozen Perl has come and gone, and I think it was a great success. There were no major catastrophes, nor any minor ones, really, and the feedback we've gotten has been very positive. We're already talking about doing this again next year.</p><p>This writeup is intended to help remind us what we can do better next year, and also to give people thinking of organizing a similar event some advice on how to do it. First, check out <a href="http://www.yapc.org/workshops.html">the writeup I did</a> for the yapc.org site on planning a workshop. That will tell you how TPF can help you out, and give you some ideas of the basics you need to plan for.</p><p><strong>First Things First - Venue</strong></p><p>The absolute most important thing to do, as early as possible, is to book your venue. This was a source of pain for us, though the venue we ended up at was great. If you're planning to do an event at a university, see if there's a student group who can help you book the venue. We worked with the Bioinformatics group at the University of Minnesota, and as a result saved nearly 50% on the venue. This had a huge impact on our budget, as it basically saved us about 17% of our income!</p><p>Of course, you need to double-check things like audio-visual for your venue, though nowadays any new venue should have all the AV equipment you'd want.</p><p><strong>Second Things Second - Sponsorship</strong></p><p>The other thing that you can't do early enough is start contacting sponsors. If you're planning to keep the event very cheap, then you should plan to pay for most things with sponsorship. For our event, approximately 2/3 of the total expenses were paid by sponsors. Some sponsors will be very quick to respond, and some will take some cajoling. Another thing to realize is that you'll ask many, many more places than will respond. We contacted 30+ companies, and got 8 sponsors total.</p><p>Most of those sponsors were very quick to say yes. My conclusion from this is that your time is best spent contacting as many different companies as possible, rather than focusing on repeated contacts with a few.</p><p>If you're in the US, sponsors will be able to treat their sponsorship as a tax-deductible donation, though most of our sponsors didn't seem too concerned about this. Keep in mind that sponsors are getting something of value for their sponsorship, such as free admission and advertising. That should be accounted for in any thank-you letters you write.</p><p>Other sponsors may want to treat the sponsorship as a marketing expense, and as such may want an invoice for the full amount which breaks down the items they're getting. You can probably put things in this invoice like "20 free admissions", even if the sponsor isn't going to use them. They just want to be able to break down the expense in some way. Don't be afraid to ask them exactly what they want.</p><p><strong>Budgeting</strong></p><p>One initial mistake I made was to forecast our income and expenses for 80 attendees, assuming all 80 were paying. Obviously, this isn't the case, because organizers and speakers don't pay. We ended up with approximately 95 attendees, of whom maybe 80 paid. This includes a few day of registrations (5 or so). We also had 6 or so people who paid but didn't show up, but this didn't really matter for the budget, since we had already ordered their meals and t-shirts. It did mean the day-of registrees got lunch though.</p><p>Also keep in mind that with very low ticket prices, each additional attendee ends up being a <em>net loss</em>. Our expenses per attendee were close to $60 each, but the highest ticket price was $40. This wasn't a problem, but if we'd had 150 attendees, it'd would've been a disaster. Keep this sort of dynamic in mind when doing your budget forecasts.</p><p>Here's the final budget breakdown for the curious:</p><p><em>Income</em></p><p>Registration fees: $2,190 - a few folks opted to pay more than the ticket price, though that only added a $100 or so to this amount<br>Sponsorship: $5,000<br><strong>Total: $7,190</strong></p><p><em>Expenses</em></p><p>Venue: $1,250 - this was really cheap for such a nice venue<br>Event catering: $3,290.04 - included a continental breakfast, sandwiches for lunch, and an afternoon snack<br>Wireless access for the event: $0? - we may be getting this for free, otherwise it'll probably be around $200<br>Hackathon venue: $357.15 - included a $107.15 for internet, yeesh<br>Hackathon food: $245.15 - included a surpsising 20% service charge<br>T-shirts: $871.10 - these were 4-color silkscreens on black, American made (aka no sweatshop) shirts<br>Saturday dinner: $200 - I paid for everyone's appetizers and salads, knowing that we had a decent surplus<br><strong>Total: 6213.43</strong></p><p>This leaves us with a net surplus of <strong>$976.57</strong>. We'll probably do some sort of targeted grant with this money.</p><p>One thing to keep in mind is that some expenses may not be 100% fixed until after the event. For example, we paid for some of the food at the event based on consumption. It's a good idea to make sure you expect to have at least a few hundred dollars in surplus after the event.</p><p><strong>Registration</strong></p><p>ACT's registration process is damn confusing, though hopefully this will be fixed in the future. Basically, what it calls "registration" is the act of making an account or indicating interest in the event using an existing account. It is <em>not paying</em>.</p><p>We forgot to tell sponsors that if they wanted to use their free admissions, they needed to have people register in advance. We were fortunate that we had enough no-shows on the day of the event that we had enough meals! I <em>almost</em> forgot to account for our keynote speaker too, which really would have been lame.</p><p>Make sure that all of these people have accounts in the system and are marked as attending so that you include them in meal counts.</p><p><strong>Random Notes</strong></p><p>We were awfully late to make our shirt design, which meant a scramble to get them printed, and it also meant that Stephen Perkins had to pay for them out of pocket and get reimbursed by TPF.</p><p>We may consider closing registration a bit earlier next year to ameliorate this problem. We also did a bad job of making sure people got a shirt of the size they requested, and ended up not having shirts for some folks.</p><p>The lightning talks slide dance is a bit of a time waster. This year Ken put most of the talks on his laptop, but some folks had trouble using it cause they're not familiar with Macs. A KVM might be a better solution.</p><p>I hope all this information is useful to anyone out there planning their own event.</p> autarch 2008-02-29T23:25:40+00:00 journal TPF, money, and grants http://use.perl.org/~autarch/journal/35720?from=rss <p>Something I've talked about recently with a few folks is that TPF has "too much" money. Specifically, TPF has reported an increasing balance at the end of its last couple fiscal year. Nonprofits are not supposed to consistently make a profit (no kidding), and this has a bad smell. I don't think there's anything fishy going on, mind you, it just doesn't <em>look</em> right.</p><p>Part of the problem comes from a large $35k grant paid to TPF by NLNet for Parrot. TPF got the money from NLNet back in 2005 (IIRC) and it took a while before that money started flowing out of TPF.</p><p>In discussions with a couple folks in TPF, they've said that they'd really like to spend the money, but they don't have avenues to do so. As most folks know, conferences and workshops are generally profitable for the organization (Frozen Perl netted around $1k) so that's not a way to spend money.</p><p>Then there's the grants program. I'm on the grants committee list and I've seen all the grants that've come through for the past couple years. The problem with the grants system is that there's not nearly enough grant applications coming in. Then of the applications that do come in many are simply unrealistic. Either they are too vague, too niche, or too hard, and so don't get approved.</p><p>I've been thinking about this recently and I think that this failure mode is basically built-in to the current grants system. First, TPF has a sort of unwritten rule that it won't fund travel, because there are so many Perl folks who'd like to go to so many Perl events that it would be hard to handle. I think there's definitely some truth to this, though I could see a use in funding travel specifically for project hacking (which TPF has done from time to time).</p><p>Another unwritten rule is that individual grants will not be more than $10k. This also makes sense, as $10k is a lot of money to give to one proposal. So what's the problem?</p><p>I for am unlikely to ever apply for a grant under the current scheme (ignoring the fact that I'm ineligible because I'm a grant manager), even though I could probably come up with something TPF would be willing to fund.</p><p>The problem is that I just can't see how a grant could be an incentive for me. I already put a fair bit of my time into FS/OSS projects just because I want to do so. I'd love to put in much more time, but I have things like a mortgage and family to consider. Realistically, the only way I'm going to put more time into my projects is to take a sabbatical from work, or at least work part-time for a while.</p><p>But if you look at the work/money ratio for past grants there's no way that could happen. Even if I aimed for something like %60-80 of my current FT income, a grant could not come close. It'd be more like 20-30%. So the grant provides no incentive for me. I suppose I could still apply for one anyway, but I don't feel right about that because it <em>would just be funding work I would do anyway</em>!</p><p>I'm sure many other developers have the same issue. So what is the point of the grants program, if not to make work happen that wouldn't otherwise happen? The acknowledgement of one's work is nice, but I already get that in many other ways, and if I'm looking for acknowledgement in the form of cash, I'd expect a heck of a lot more than a couple thousand dollars (Amazon and others, contact me privately for an address to which you can mail a big fat check).</p><p>Personally, I'd be perfectly happy to see TPF fund three months of full time work on any Parrot, Perl 5, or some other project likely to be of great benefit. Of course, the number of people eligible for this sort of grant are few in number, but it might achieve more in the long run.</p> autarch 2008-02-22T01:25:44+00:00 journal 5 years of DateTime http://use.perl.org/~autarch/journal/35394?from=rss <p>I guess before that there was just a formless void with no time, no past and no future. Ok, maybe not, but no DateTime.pm for sure.</p><p>I realized that the 5 year anniversary of the Perl DateTime Project passed by recently. I date it <a href="http://www.nntp.perl.org/group/perl.datetime/2003/01/msg388.html">this post to the datetime@perl.org list</a> I made on January 9, 2003. That really got the ball rolling, and I was actually working on the first version of DateTime.pm in the next day or two.</p><p>Thanks to everyone who's contributed over the years. I don't think we realized that we'd end up creating _the_ definitive set of Perl date/time libraries, to the point where a _lot_ of people say "oh, I just use DateTime for everything".</p><p>Even better, I think we still have one of the best date/time library suites of _any_ language out there. The only thing I've seen in all this time that comes close is the Chronos library for Smalltalk, myself. Of course, if someone wants to point me at one they think rocks, I'm happy to learn more.</p> autarch 2008-01-15T23:07:31+00:00 journal Frozen Perl call for lightning talks http://use.perl.org/~autarch/journal/35368?from=rss <p>Our <a href="http://www.frozen-perl.org/mpw2008/lightning.html">call for lightning talks is open</a>. Ken Williams is going to be organizing it (thanks, Ken).</p><p>Also, Saturday is the last day to get the $20 early bird rate for non-students, so now's the time to sign up if you haven't yet done so.</p> autarch 2008-01-11T20:12:42+00:00 journal Frozen Perl 2008 early bird deadline coming up http://use.perl.org/~autarch/journal/35322?from=rss <p>The Frozen Perl 2008 deadline is coming up. I wrote some text that I've been asking folks to forward to their internal work email lists. If those of you out in use Perl land who are reading this could do the same, I'd be most grateful.</p><blockquote><div><p>The early bird deadline for Frozen Perl 2008 is fast<br>approaching. After midnight Central on Saturday, January 12th,<br>the rate for non-students will double from $20 to $40.</p><p>Frozen Perl 2008 is a one-day Perl workshop happening on<br>Saturday, February 16th, with a great schedule of speakers. The<br>theme is "Perl in Practice", and there are a lot of great talks.</p><p>We have two tracks of talks. For folks new to Perl, there is a<br>strong slate of talks for beginners, including introductions to<br>OOP, testing, and more. For more experienced Perlers, there are<br>talks on Moose, Catalyst, and all sorts of interesting Perl<br>wizardry.</p><p>Registration includes breakfast and lunch, and possibly a<br>t-shirt, all for the ridiculously cheap price of $20. If you're<br>coming from out of town, there is a group rate at the nearby Days<br>Inn. There will also be an all-day hackathon on Sunday, February<br>17th for the true geeks.</p><p>For more information, check out the website at<br>http://www.frozen-perl.org/. You can sign up online, so don't<br>delay.</p><p>We hope to see you there.</p><p>Dave Rolsky<br>Frozen Perl 2008 Organizer</p></div></blockquote> autarch 2008-01-07T17:06:50+00:00 journal Thoughts on Parrot http://use.perl.org/~autarch/journal/35285?from=rss <p>I've been the Parrot Grant Manager for a little over two years now, and that gives me an interesting position to observe its progress. I'm not really involved in the code side of the project, but I do pay attention to developments at a high level.</p><p>To be honest, most of the time as the grant manager was somewhat depressing. Not a lot seemed to be getting done, and I couldn't authorize any milestone payments. That in turn made us look bad in the eyes of our major funder, NLNet.</p><p>In the past six months or so I've seen a really amazing jumpstart of the project. A lot of credit for this goes to Allison Randal. She came up with <a href="http://www.perlfoundation.org/parrot_grant_from_nlnet">a very aggressive schedule</a> (towards the bottom of the page) and has been sticking to it, and I think her energy and hard work is motivating others as well.</p><p>For the first time in a while, I actually feel like Parrot is more than just a cool idea, it's a project that's going somewhere.</p><p>I'd also like to point out that there is some money available for people who work on Parrot. If you take a look at the schedule there are lots of milestones in the future. Many of them have Allison's name next to them, but I'm sure she'd be happy to have others pitch in. Each milestone is worth $2,000 on completion.</p> autarch 2008-01-04T16:38:49+00:00 journal Frozen Perl Preliminary Schedule and Registration http://use.perl.org/~autarch/journal/34888?from=rss <p>We've published a <a href="http://www.frozen-perl.org/mpw2008/schedule">preliminary schedule</a> for the Frozen Perl workshop. I think the schedule looks great, and I'm quite excited about it.</p><p>A few days before our call for speakers ended, I was feeling a bit panicked that we wouldn't have enough talks, so I harassed everyone I could to submit talks. We ended up with way more submissions than we could schedule, which is great for us, but I feel a bit guilty now.</p><p>I've also opened up registration for the workshop. The early-bird rate is $10 for students and $20 for everyone else. That rate will double on January 12. To register for the conference, you must first <a href="http://www.frozen-perl.org/mpw2008/main">log in</a> to an existing conference account (from YAPC 2007, for example), or <a href="http://www.frozen-perl.org/mpw2008/register">create a new account</a>. Once you are logged in you can pay for the conference online.</p> autarch 2007-11-13T05:26:37+00:00 journal Frozen Perl 2008 Call for Speakers closes tomorrow night http://use.perl.org/~autarch/journal/34733?from=rss <p>There's a little more than 24 hours left in the Frozen Perl 2008 <a href="http://www.frozen-perl.org/mpw2008/cfs.html">Call for Speakers</a>. If you've been putting your submission off to the last minute, that last minute is fast approaching. Submissions close at midnight (America/Central) on Tuesday, October 23.</p><p>If you're on the fence about submitting a proposal, we really hope you do submit something. More proposals gives us more choice, and we really want to encourage new, interesting topics, and new, interesting speakers.</p> autarch 2007-10-22T22:00:57+00:00 journal Frozen Perl 2008 CFS ends in five days (10/23) http://use.perl.org/~autarch/journal/34715?from=rss <p>I know all of you out there are enjoying making us sweat by waiting til the last moment, but the last moment is approaching. If you haven't yet, check out our <a href="http://www.frozen-perl.org/mpw2008/cfs.html">Call for Speakers</a>, and <a href="http://www.frozen-perl.org/mpw2008/newtalk">submit your talk soon</a>!</p> autarch 2007-10-19T02:09:14+00:00 journal Tests? Who needs 'em? Scope creep? Bring it on! http://use.perl.org/~autarch/journal/34656?from=rss <p>I've been working on a rather huge revision to my <a href="http://www.vegguide.org/">VegGuide.Org</a> site for at least a year or so. It started as a rewrite of the UI, but ended up becoming a switch to Catalyst and a UI rewrite and a bunch of new features. Talk about scope creep!</p><p>The funny thing about this is that it has defied the common wisdom about projects in a couple ways. First of all, the scope creep isn't really a problem, because I have no deadline. In the end I'll have a better product, it'll just take longer to get there. Ok, that doesn't defy common wisdom, exactly, but it's interesting to me that there are projects where scope creep isn't a killer, and the creep hasn't been demoralizing, since it's almost entirely driven by what I want.</p><p>The other funny thing about this project its lack of tests. When I started the move to Catalyst, there were no tests, and I've written a few along the way, but I'm not sure if they even still pass. I admit this somewhat shamefacedly becase I've been a big advocate of testing at my @DAYJOBS.</p><p>This is not a tiny project. I have about 16,000 lines of code in modules with almost no docs to speak of (another "mistake"), though that doesn't exclude whitespace. There's also about 6,000 lines of Mason templates.</p><p>I've been thinking about this for a while, and I realized that what makes it work is that I have written <em>every single line of code</em> in this project, so <em>it all makes sense to me</em>. I also have a decent memory for code, and I wield a mean grep.</p><p>I'm not claiming it's bug-free, but the bug count is surprisingly low given the large amount of code churn. I've never been afraid of refactoring this code base, and this project is basically a 50% rewrite, as I'm rewriting the controller and view layers from scratch. The model has changed, but mostly in an evolutionary way when I add new features or remove dead code. The underlying architecture of the model has remained the same, intentionally, since a 100% rewrite is too overwhelming.</p><p>There's no free lunch, however. Without tests, I really can't afford to let another programmer make major changes to the code base. Not only would they be more likely than me to introduce bugs, as the code became less a product of one person, I'd be more likely to introduce bugs.</p><p>The common wisdom is right. Tests do prevent bugs, and they're incredibly crucial in multi-person projects, especially when you expect to have turnover in developers, which of course you will on any long-lived project. But it's still funny for me to realize that I've been able to get away without them for so long. I don't know if I'll ever write any serious tests for this code, though maybe that will happen if I decide to make major changes to the model layer.</p> autarch 2007-10-12T01:49:20+00:00 journal Ego mining CPAN data http://use.perl.org/~autarch/journal/34515?from=rss <p>The other day, I was wondering what percentage of CPAN I have sent patches for. I was kind of hoping for a nice impressive number like 1%.</p><p>I wrote a little script that takes a local CPAN mirror (courtesy of CPAN::Mini) and extracts the latest version of every module looking for my name or email address in files that look like changelogs. This obviously gets more than patches, since in some cases I just submitted a bug report or suggestion.</p><p>It's not quite perfect since some CPAN authors will say something like "applied patch from RT12345" without a name. I didn't want to fetch all those different tickets, since that'd take a long time.</p><p>So the list I came up with was this:</p><p>Apache::Compress, Apache::Filter, Apache::Session, App::Info, Catalyst::Action::REST, Class::Container, Class::Validating, CPAN, CPANPLUS, Data::Structure::Util, DateTime::Calendar::Chinese, DateTime::Calendar::Discordian, DateTime::Calendar::Hebrew, DateTime::Calendar::Julian, DateTime::Event::Recurrence, DateTime::Format::Duration, DateTime::Format::Natural, DateTime::Format::Strptime, DateTime::Incomplete, DateTime::Set, DateTime::Span::Birthdate, DBD::mysql, DBD::Pg, DBI, Devel::Cover, Email::Address, Exception::Class::TryCatch, ExtUtils::ModuleMaker, GD::SecurityImage, GraphViz, HTML::FillInForm, HTML::Tidy, IO::All, IPC::Shareable, Kwiki, Lingua::ZH::PinyinConvert, Log::Dispatch::Config, Log::Log4perl, mod_perl, Module::Build, Module::Signature, Net::SFTP::Foreign, Pod::Coverage, Set::Infinite, Spiffy, Spoon, Storable, SVK, SVN::Web, TAP::Parser, Test::Simple, Test::Taint, Thread::Pool, XML::Atom, XML::SAX::Expat, XML::SAX::Writer</p><p>It was fun to do this because I found a few cases where I'd totally forgotten having been involved.</p><p>This isn't quite 1%, closer to 0.5% (57 modules out of 12208). Of course, if you count the modules I've personally released, I end up with 97 modules, closer to 1% but still not quite there.</p><p>BTW, my original goal was to build a database of who patched what, but parsing out the bazillion ways someone says "patch from so-and-so" is really hard, and the RT thing is still a big problem. There's also a problem just figuring out identity, since people end up referred to in many ways, by full name, first name ("patch from Stas"), email address, and nicknames like CPAN ids or IRC nicks.</p><p>It'd be pretty cool to get that data, though, since we could see things like modules with the most patchers, most patches, most frequent patchers, etc. Maybe I'll get back to this sometime.</p> autarch 2007-09-21T19:20:27+00:00 journal PerlySense++ http://use.perl.org/~autarch/journal/34401?from=rss <p>Johan Lindstr&#246;m is attempting to bring the cool whizbang features of IDEs to Perl developers using Emacs or Vim. I've been following along with the development releases as he's been going, and it's a pretty cool tool. The big feature for me is the ability to move my cursor to a Perl class name, then hit "C-p C-g", and PerlySense figures out where the associated file is and opens it for me. This is very cool when I want to look at the source of something I've installed via CPAN, for example.</p><p>You can also use "C-p C-d" to bring up the docs for a module, which I've not quite gotten as into, but I can see it being useful. It's also got some other key strokes, as well as its own major mode to facilitate browsing Perl code, which seems interesting, though I'm not sure if I can see myself using it much.</p><p>Anyway, if you use Emacs you should <a href="http://search.cpan.org/dist/Devel-PerlySense/">check it out right now</a>. I don't think there are vim bindings, but a lot of the functionality is provided via a standalone script, so hooking that into vim probably wouldn't be too hard.</p> autarch 2007-09-10T05:07:09+00:00 journal