Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

autarch
  (email not shown publicly)
http://www.vegguide.org/

Journal of autarch (914)

Monday September 14, 2009
09:18 PM

Moose class in Minneapolis - September 23, 2009

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.

For more details on the class, please see my blog. You can pay and register via the Perl Review website.

Thursday September 03, 2009
03:54 PM

Moose class in Minneapolis - September 23, 2009

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.

For more details on the class, please see my blog. You can pay and register via the Perl Review website.

Monday February 09, 2009
12:28 PM

No more cross-posting

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 my blog, which has a separate programming category, with its own category-specific Atom feed.
Tuesday February 03, 2009
02:35 PM

Moose::Manual!

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 the Moose docs grant from TPF.

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.

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 email me or visit the Moose IRC channel and tell us.

Cross-posted by hand from House Absolute(ly Pointless) - permalink .

Thursday January 08, 2009
10:21 PM

books.perl.org - needs an owner or it goes away (mostly)

So I maintain (for some value of maintain) a few .perl.org things, including books.perl.org, on a VMWare server that the Perl NOC folks need to decomission.

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).

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).

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.

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.

Monday December 01, 2008
11:13 PM

The Many Axes of Software Development

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.

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?

(Note: when I say library below, mentally substitute "module, library, distro, or framework")

  • Well-vetted - 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.

  • Cutting Edge - 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.

  • Dependency free - The CPAN depdendency discussion never goes away. Some people really, really 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.

  • Small (does one thing) - Less code means less bugs. It also means less docs to read, and makes a library simpler to learn.

  • Easy to integrate - Some libraries are designed to be integrated with other modules (Catalyst), some want you to embrace their world (Jifty).

  • Complete - Some libraries come with a complete solution (Jifty) and some require you to put together a bunch of pieces into a whole (Catalyst).

  • Fast - Sometimes speed (of compilation and/or execution) really matter.

  • Memory frugal - Just like with speed, sometimes memory usage matters.

  • No XS - 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).

  • Active development - Maybe you feel more comfortable knowing the module has a future, even if that means a higher rate of change.

  • Stable - On the other hand, maybe you want something that's just done, where you know new releases will be infrequent and backwards compatible.

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.

If you want well-vetted, you're not going to be using cutting edge code.

If you want dependency free, that code is probably not well-vetted. That dependency free code probably has some reinvented wheels, and those wheels are probably less round than the dependency they avoid.

If you want fast or memory frugal, you probably can't also insist on no XS. If you want complete solutions, than small and easy to integrate may go out the window.

Personally, my top priorities are usually small, easy to integrate, and active development. 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.

I don't care too much about fast or memory frugal. 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.

I'd much prefer well-vetted to dependency free. I think the latter is an entirely false economy, and what we really need are much, much better installer tools.

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!

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.

Cross-posted from House Absolute(ly Pointless) - permalink .

Saturday November 22, 2008
05:33 PM

Frozen Perl 2009 Draft Schedule

We just published our first draft schedule 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.

Thursday November 20, 2008
02:20 PM

Frozen Perl CFS ends tonight!

Please submit your talks if you've been waiting to do so!

Also, check out the class that brian d foy is offering.

Thursday November 13, 2008
11:45 PM

Mastering Perl class at Frozen Perl

At Frozen Perl, brian d foy will offer a one-day Mastering Perl class. The class will take place on Friday, February 6, the day before the workshop.

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.

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.

Saturday November 01, 2008
04:23 PM

Discoverability in REST vs Providing an API

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.

When I last wrote about REST, I got taken to task and even called a traitor (ok, I didn't take that very seriously ;) Aristotle Pagaltzis (and Matt Trout via IRC) told me to take a look at AtomPub.

I took a look, and it totally makes sense. It defines a bunch of document types, which along with the original Atom Syndication Format, 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.

But what about a non-interactive client? I just don't see how REST could work for this.

Let me provide a very specific example. I have this site VegGuide.org. 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".

(There are also other ways to navigate this space, but none of them would be helpful for the problem I'm about to outline.)

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.

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.

How could she do this with a proper REST API? Remember, Jane is not allowed to know that http://www.vegguide.org/region/93 is Chicago's URI. Instead, her client must go to the site root and somehow "discover" Chicago!

The site root will return a JSON document something like this:

{ regions: [ { name: "North America", uri: "http://www.vegguide.org/region/1" }, { name: "South America", uri: "http://www.vegguide.org/region/28" } } ] }

Then her client can go to the URI for North America, which will return a similar JSON document:

{ regions: [ { name: "Canada", uri: "http://www.vegguide.org/region/19" }, { name: "USA", uri: "http://www.vegguide.org/region/2" } } ] }

Her client can pick USA and so on until it finally gets to http://www.vegguide.org/region/93, which returns:

{ 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 }, ] }

Now the client has the data it wants and can do its thing.

Here's the problem. How the hell is this automated client supposed to know how to navigate through this hierarchy?

The only (non-AI) possibility I can see is that Jane must embed some sort of knowledge that she has as a human into the code. This knowledge simply isn't available in the information that the REST documents provide.

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".

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.

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 the URI for Chicago and be done with it. And since sites should have Cool URIs, this will work for the life of the site.

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.

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!).

REST's discoverability requirement is very much opposed to my personal concept of an API. An API is not discoverable, it's documented.

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."

You, as an API consumer, could do this, but I doubt you'd consider this a "real" API.

So as I said before, I suspect I'll end up writing something that's only sort of REST-like. I will provide well-documented document types (as opposed to JSON blobs), and those document types will all include hyperlinks. However, I'm also going to document my site's URI space so that people can write non-interactive clients.

Cross-posted from House Absolute(ly Pointless) - permalink .