Slash Boxes
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 ]

fansipans (7678)

  (email not shown publicly)

Journal of fansipans (7678)

Sunday October 05, 2008
09:55 AM

Using Data on the Web - Models, Persistence, Management

Originally posted to my blog.

I've been drowning myself in jQuery and HTML+CSS at work, which has been awesome for coming up to speed with all the recent technical developments on the web.

One thing that has piqued my interest quite severely is the integration of JavaScript with server-side environments. With a tighter binding between client and server code, we can write less code, have better test coverage, and truly refactor web applications across everywhere their business objects/rules live.

After rediscovering Joose (one of the guys on use.perl wrote it or helps write it I believe), and seeing one of their demos where Joose uses GoogleGears or HTML5's Database feature, I really wanted a simple-to-use ORM for JavaScript. Without GoogleGears or HTML5 support this could also easily be done server-side by having a url that took standard orm requests (find/search/save/delete) and returned standard JSON.

Now this sounds familiar.... oh right, that's a perfect description of CouchDB!

CouchDB is another thing I've had a lingering fascination with. It is a document-based database written in Erlang, with a JSON interface. Data manipulation inside the database is performed by snippets of code that create "views" of the data. CouchDB ships with JavaScript support, and support for Perl exists in CPAN via CouchDB::View. It's one of those things you can see has HUUUUUGE potential, but really needs those little libraries that link it to other popular frameworks/platforms to really take off, or get that foot in the door with the web programmer zeitgeist.

So according to this mailing list thread about work on Joose.Storage which mentions CouchDB and this announcement that Joose supports the cross-platform serialization library "jsonpickle", I wonder what it would take to get that perfect easy API so in a Joose class all you'd have to add to your Joose class definition is:

does: CouchDB

That and maybe adding something like (totally making this up)


to the top of your javascript, and badabingbadaboom you've got versioned object persistence backed by one of the most awesome open-source high-performance databases out there!

Edit: Looks like there's already a jQuery CouchDB plugin, written by Jerry Jalava (see announcement on his blog.) It looks like a straightforward implementation of the CouchDB API:

connection(database_name | view_name)
save(database_name, document)

I'd like to see a database-backed object persistence layer that can use that API, or a number of other APIs, such as:

1. A server resource/URL that receives the name of a database operation, and a JSON representation of the data. This is nice because it's easy to implement with whatever server database / language / runtime you have. If this were a centralized project, it would be trivial for members of the community to support new server environment/database combinations.

2. JSON-enabled Database Servers. Who wants to write the MySQL Server JSON connector? Or a generic JSON-to-Database bridge, which could support a standard JSON interface, and many different backend databases? The bridge could be configured with even more javascript to function as server-side validations or business logic.

3. SQL Dispatcher. Pretty much the same as #1, but with the SQL generated client-side. This would still provide a JSON interface, and require parameterized queries.

It seems to me that all of these ideas have been best expressed by CouchDB, but to acheive widespread adoption, I still have concerns with legacy systems, existing infrastructure, critical mass, etc.
Wednesday May 16, 2007
09:06 AM

Storing Content "Within A Package"

Had a hilarious DUH moment yesterday. I was trying to figure out the best way for my CGI::Application application to bundle in all it's html templates into it's own package so when installed there's nothing other than the perl modules, no other directories / web pages / sites to set up..., everything is in /usr/lib/perl5/5.8.4/MyApp and the Templates are in /usr/lib/perl5/5.8.4/MyApp/Templates

So I'm pondering, and pondering, thinking maybe I can tweak the low-level of Petal's code into treating filenames and perl modules interchangably, and if using a perl module, read in from the __DATA__ section or something...

Then I realize the entire problem is reduced down to one simple variable change to my cgiapp_init:

    default_type => 'Petal',
    include_paths => \@INC

So now CGI::Application looks for my templates, and finds them, as pure html, no __DATA__ jibba jabba, just easy. Huzzah!

Thursday April 19, 2007
10:01 AM

Charlotte Perl Mongers Meeting

The Charlotte Perl Mongers will be meeting tonight, for time and location see the link below.

The subject of the meeting is Perl vs. Ruby: Web Application Frameworks

I'm giving the presentation on the Ruby side. I'll be going over the embedded server that ships with Ruby, WEBrick.

We'll briefly present Perl's CGI::Application and Ruby's WEBrick, then compare and contrast between them. I think both topics will delightfully show how simple it is to put new and old code online quickly and easily, where the power of web browsers and remote agents can shine ... with rainbows ... and ponies. I like ponies.

Charlotte Perl Mongers Home Page

My Slides on WEBrick
Wednesday March 28, 2007
09:38 AM

Hello World / Perl Monks Question

Hello World! First journal entry... long time listener, first time caller...

What motivated me to finally post is this simple sienfeldian question: "What is the deal with PerlMonks?"

I'm looking at something that seems like the perfect troll ... specifically:

Highlights include:

is there a way to make tty:// really log into a system from a browser
I want to experiment with [making] a custom protocol that could be used between a system and its proper clients that avoids spinning the firewall by disabling all the usual protocols and only accepting a custom one
so that customers can get on board by downloading a protocol installation kit as soon as they have a formal relationship (e.g. a financial account) whose registration can be automated rather than needing lower level network modifications or hardware.

This post honestly made me laugh because it's got just enough technical basis to warrant "discussion", but it's so wildly silly if you actually know what you're talking about and it's received a fair amount of discussion and ideas around the pros and cons of implementation. Also, the person's nick is "Moron". And finally, what does this have to do at all with Perl? I can understand being extremely patient with new users, but threads like these really seem to lower the signal to noise ratio.