Jun 302013

Two_women_operating_ENIACI didn’t set out to become a programmer. Believe it or not, I didn’t even own a computer until I was 30–it was a beat-up E-machine that a college room-mate sold me for a hundred bucks. At the time, I was an English major, after having gone through a brief period in which I had the hilarious idea to become a public school teacher.

My intention with regards to becoming a teacher were never wholly pure. Yes, I wanted to make a difference–having grown up in an impoverished community, and having attended some fairly recognizably shitty public schools, I did indeed have dreams of reaching that kid in the back of the class who was keeping herself distinct from the rest of her fellow pupils. But I never really thought I had the personality to teach. It looked to me that teaching well required a zeal and a patience that I knew deep-down I lacked. And it wasn’t what I really wanted to do.

I wanted to write. Had been writing for a long time, since before I was a teen-ager. I had grown up surrounded by books–my parents had a nearly full set of the Harvard Classics, volumes of which I would pull out and flip through with awe. In the same set of bookshelves, on the bottom shelf, was a full set of World Encyclopedias. When I was nine or ten I attempted to read the entire set, A-Z…but, being nine or ten, my attention wandered.

By the time the Internet was first really seeping into public consciousness I was lucky enough to have been immersed in it for a some years. My first encounter with HTML was in Geocities–I had just discovered that on this world wide network of machines I could read not only the literature of the past but also contemporary, bleeding edge work by people who, like myself, were all hunched over little keyboards, all over the world.

There were, indeed, literary schools and movements being born on the network, and while everyone else I knew was just discovering the possibilities of this instant distributed global media web, I had already become an avid admirer and self-styled participant in all the turmoil. Net art was showing me some of the possibilities of using the computer and the network itself as art. Like many of that era, I learned Flash. But I wasn’t content to simply animate and link–I was ambitious. I taught myself ActionScript, and set about flailingly experimenting with what could be done with the network, automation, algorithms, and the data on the network itself.

I wasn’t very good. In the end, aesthetics took a back-seat to my new-found power. I had learned how to program, and I had learned to respect application architecture. I built things in a way that were easy for me to change–because I had gone through the pain of learning how scope worked, learned that multiple copies of a function were damned hard to maintain.

A fellow net artist suggested I learn PHP. I taught myself PHP and, slowly, by extension, I learned about web servers. I taught myself basic Linux System Administration, because I hosted my own work, and I wanted to know as much about the frame my stuff was in as I wanted to present my stuff. There was language to be explored there, too.

Lately, I’ve engaged a lot with HTML5, and a lot of JQuery. JavaScript was something I learned along with HTML and CSS, but when JQuery was first introduced I thought was beautiful. Selectors! Chaining! AJAX! By the time HTML5 was commonly supported by the major browsers I had long left Flash behind, and I was ready for a new web.

 Posted by at 4:17 am
Jul 182009

For the past year or so I’ve been working on a new media poem called Black River Ghosts.  While the work is nowhere near ready to be presented to the public, I’ve been using some of its functionality on the social networks, and in a few spots these test cases/previews have been actually garnering praise.

Anyone familiar with my work in networked literature knows I have an ongoing fascination with poetry generators–applications that write poems based on datasets and randomizing algorithms. The motivations behind this obsession are very simple, if problematic on the theory tip: a good poetry generator allows the “author” to relinquish control; other than providing a dataset and some compositional templates, the generative poet does not compose the generative poem. The poem is instead composed by a combination of the underlying code and the reader’s initializing of the application.

I have more than a thimbleful of thoughts as to why this is a worthwhile paradigm for new media poetry, and why I often feel new media poets who don’t at least dabble in the margins of this paradigm might be missing some of the point of a networked literature, but those will be saved for a future post. Instead, I’d like to introduce you to a PHP framework that I’ve been using to create the piece, and offer some thoughts on how working in this way requires a different conception of poem composition.

CakePHP is rapid application development framework for creating web apps with PHP, and, though I’m very much a n00b as far as its use goes, so far it seems the best choice for building complex applications quickly and with as little code as possible. CakePHP leverages the Model-View-Controller design pattern to modularize the various components of a software project. This means that the application is coceptualized as having 3 layers: a model, which represents a data source; a controller, which encompasses the logic involved in working with the data from the data source; and a view, which is comprised of all the presentational or visual display functionality. MVC applications separate these layers into seperate files, thus promoting reusability and easy refactoring.

The benefits of using MVC are obvious; you can very quickly set up the bones of your app, and very easily extend and revise it. CakePHP provides a framework for doing this by favoring “convention over configuration”; by applying conventions to file names, database table names, and other assets, CakePHP provides a structure that makes simply creating and writng methods for certain classes build a rich structure for your web application.

I started writing Black River Ghosts with CakePHP initially just to get my head around how to use the framework. I already had the beginnings of a dataset; a file of distinct lines of text i’d started for the project. It became obvious very quickly that I could better make use of CakePHP and the poetry if I broke the lines down into records keyed by grammar. I tagged the poetry with parts of speech: nouns, verbs, prepositions. And then I started adding to the dataset, building a table of lines of poetry that represented (very subjectively) parts of speech to me.

As I worked, I became aware of how composing poetry like this, directly into a database, with the thought that each line, each unit, would go toward composing a sentence, is a fundamentally different way of composing poems linearly, as the popular conception of poetry has taught us. The form imposes some limitations; if you’re relying on “states of consciousness,” you must rely on them in targeted bursts, and you must keep in mind that what you’re writing will be combined and recombined with all of the other elements in the set.

The resultant text, though, definitely has a rush to it. Because I’m working with phrases instead of bare words, the sentences flood with a certain lyricism I’m enjoying. As algorithmically-generated text, these early tests of my code are yielding results I like.

 Posted by at 2:11 pm
Jun 242009

Aptana StduioAs a developer, I’m pretty picky about my tools. The old debate about whether ’tis better to use a plain text editor or a full-fledged Integrated Desktop Environment was settled for me long ago; quite simply, I spend too much time with my head in code to do everything manually, as a plain text editor would require.  No, I have very specific requirements of my editing environment, which is where I spend the greater portion of my day: I need code-folding, brace-matching, an outline of properties/methods…

Early on I was a huge fan of the Eclipse development environment. Eclipse, it seemed, sought to be the swiss army knife of dev tools; though it was primarily intended for Java, it’s plugin architecture allowed it to be extended to develop in any language a plugin was provided for. This allowed me to use one application to write in multiple languages and idioms, which was just fine by me. Since the majority of my work is LAMP-related (Linux, Apache, MySQL and PHP/Perl), I found that Eclipse coupled with the PHPEclipse plugin was perfectly suited to the way I write code.

But the PHPEclipse plugin had issues, as I was soon to find out. The version of Eclipse in the Debian and Ubuntu repositories is old, and the PHPEclipse plugin has some issues working on these platforms. This was fine when I used WindowsXP as my primary Desktop OS, but when I started using Linux on the desktop this stopped me in my tracks. And while there are some fine environments out there for the Linux platform, I missed the ease and familiarity of my Eclipse interface.

Luckily, Aptana stepped in to fill the gap. Aptana can be downloaded as either a standalone application or an Eclipse plugin, and was built on the Eclipse platform. And Aptana is geared toward web development, offering a rich set of tools for working with HTML, CSS and Javascript. It’s very AJAX (Asynchronous Javascript and XML) aware; in fact, when creating a default web project in Aptana, you’re given the option of downloading and making part of your project many of the most popular and innovative Javascript libraries, such as JQuery and Prototype. And it fits my workflow snugly; not only do I have all of the functionality and extensibility of Eclipse at my disposal, but Aptana has it’s own set of plugins to aid in the development of PHP and Adobe AIR applications, and also features a very rich interface and code snippet library (featuring, thankfully, a whole range of snippets for editing .htaccess files).

Aptana, installed as an Eclipse plugin, works on both Windows and Ubuntu-another selling point for me. I run a dual boot system, and any opportunity to use the same software on both sides of my box is welcome.

Apr 222009

Over the last two years, I, along with many another developer, have developed a bit of a man-crush on John Resig, the primary creator of the jQuery Javascript Library. jQuery has taken a lot of the pain out of writing cross-browser javascript, and replaced it with a much more intuitive syntax and a compressed idiom of expression that, to me, makes the chore of writing scripts that reliably work on all browser platforms much less debilitating.

This is an enlightening presentation by John on the challenges of scripting for the Document Object Model, or DOM, the conceptual framework that allows developers to work with documents in a dynamic way. This is particularly relevant to anyone who develops work presented in the browser. It’s interesting to note that many of John’s points have little to do with the DOM itself, as an abstract entity; it’s the implementation of the DOM by the different browser manufacturers that causes issues. While the Browser Wars are often declared over by many writers on the subject, it’s shocking to see some of the current inconsistencies dug up here. As the Web gains more and more primacy as information repository and communications medium, should the people’s access really be so shaped by market concerns?