NAVIGATING THE WEB DEVELOPMENT CLUSTERFLUX: PART ONE

There are a lot of bad ways to go about learning to make web applications properly. I think that I took a particularly bad route, and continue to have to maintain code I wrote and am not particularly proud of. I was, and continue to be, extremely cavalier about web development. It is fairly obvious that I would rather be writing games or thinking about graphs (not the kind with x and y axes, pleb.) Nevertheless, I still have a reasonable sense of shame when it comes to my own code. I also think that making stuff for the web is a pretty good job as far as jobs go. As such, I would like to write something to help others figure out what to learn and in which order to become mildly proficient web application programmers.

I will also cover some design, but it should be taken with a grain of salt. I am not a proficient designer, but I often find myself doing design work. I will focus mostly on the technical aspects of design, an area where I have made a lot of mistakes in the past.

I'm not going to talk all that much about how to use specific technologies. Instead I'm going to talk about why and where to use specific technologies, and discuss concepts. There are heaps of articles available that explain in excruciatingly pointless detail how to use specific tech.

I'm aiming these posts at a very specific set. These people are at where I was before I got started building for web. They:

1. Already know how to program and understand object-oriented programming.
2. Are familiar with Python.
3. Are familiar with HTML and CSS.
4. Have not built a web application before, but have set up / worked on sites in the past.

As far as I can tell, Rails gives Ruby developers a unified way to get into web tech, so they are less likely to find something like this useful. I am not the most devout web developer. Indeed, my writing this is borne of my frustrations with the activity. Those more entrenched in the job may provide better overviews.

HTTP

The first bad move I made was not bothering to understand HTTP. It's not something that web developers can take for granted. HTTP is not only a technical detail, it informs the so-called architecture of programs that use it. You don't have to know what I'm about to summarise to make a web application, but your life will be easier and your code will be less stupid if you do.

The unavoidable detail is that HTTP splits communication into requests and responses to those requests. The client sends requests to the server, and the server processes those requests and responds. Server-side programming consists largely of processing requests and rendering responses to be sent. Reading RFC2616, the HTTP 1.1 spec, would probably be overkill. Some people recommend it, but I haven't found the need.

An HTTP request consists of three parts:

• A request line, which in turn consists of:
• The URI (address) of a "resource", e.g. a page, a file, a blog post, a tweet.
• The "method" - what to do to the resource. Create, update, delete, etc.
• The HTTP version (the browser or lower-level server-side software takes care of this for you - it's going to be version 1.1.)
• Some headers specifying additional information about the nature of the request, rules, etc. I haven't been able to find a clear explanation of what the intent of headers is in the RFC. In practice, setting them often allows additional control over requests, which may fix problems or make your life easier. They are used by lower-level software to indicate how things are encoded and the such.
• A body. This part is optional, but is used to contain things like form data.

The most common request methods are:

• GET - get whatever information is identified by the URI.
• POST - add the entity represented in the request body as a new "subordinate" of the resource at the URI. e.g. create a new product in a catalogue.
• PUT - store the entity represented in the request body at the URI. If there's already something at the URI, update it.
• DELETE - delete the thing at the URI.
• HEAD - same as GET but the server must not return a body. Basically returns the headers without transferring the whole entity.

A HTTP response is similar to a HTTP request except that instead of a request line, it has a status line. A status line consists of the HTTP version, a status code summarising how the request went, and a reason phrase explaining the status code.

Status codes (with their default reason phrases) you have probably seen before are:

• 404 Not Found
• 500 Internal Server Error
• 403 Forbidden
• 200 OK
• 201 Created
• 301 Moved Permanently
• 503 Service Unavailable

The body of the response will often (but not always) contain a web page in HTML. The Content-Type header tells the client (probably your browser) what sort of data is in the response body.

The most common way to send a request is using a HTML form. Here is a form that requests the greatest common divisor of two integer numbers:

<form id="gcd-form" method="get" action="/gcd/">

    <label>A</label>

    <input type="text" name="first_int"/>

    <label>B</label>

    <input type="text" name="second_int"/>

    <input type="submit" value="Calculate GCD">

</form>

This will print out a form that looks like this:

A B

In theory, we could use it to send a request to a program that will calculate the GCD of the two integers. Based on what I've talked about at so far, we can guess that the integers would appear in the body of the request, the "action" parameter will tell us the URI of the request, and the method parameter (surprisingly) tells us the method of the request.

Congratulations, you now know things about HTTP that most beginning web developers don't bother to find out. Hopefully it makes your life easier in future. Next time I will go over the application of what we learned to the simple GCD example, as well as looking at REST, an "architectural" idea that builds on HTTP.

If you want to fact-check or clarify my ramblings on HTTP basics, the RFC can be found at http://tools.ietf.org/html/rfc2616.

THE THING ABOUT CHEESECLOTH FOR PEOPLE WHO DON'T KNOW

Cheesecloth is fantastic, not only can you use it to make cheese, but also tofu and soymilk. Unfortunately, some people do not understand how to get the best out of this boon to the economy. They squander the blessing of cheesemaking cloth and use only ONE LAYER at a given time. This (in general) is a terrible idea, as the cheesecloth will easily develop holes and generally become nasty and unusable. Did you ever wonder why it comes in a kind of tube shape sometimes. NOW YOU KNOW. Have a great day, don't fuck up your cheesecloth.

GAME CONTENTISM: A CURSE AND A DISEASE

Video game analysts - bloggers and scholars - are prone to a number of deplorable mistakes, but the two most frustrating are the assumed primacy of the immediate moment, and the assumed primacy of content. In a medium set apart by its access to mechanisation, process, automation, and convention, analysts chose to talk about the static content, the plot details, the immediate moment, and the cinekinematics. The contours of the state space are reduced to the visual, the plot, the text. The source code is invisible. Despite some scholars' best efforts, the computing machine and the software are still invisible. In a medium that fundamentally depends on software.

This is reinforced by the construction of games as a generic coathanger for fashionable items of content - a film in more than one dimension but nevertheless a film which can be traversed, reduced to a kind of phenomenological poetry, and thus transcended.

But if one looks at the experiences of others, a much different picture may emerge.   The source code, itself a social product, produces (in some specific cases) a social space. It does this through players, even the ones that just watch. It may also produce an object, just as other software constitutes objects of utility. The features of these electrical entities can only be found in their social context. No amount of phenomenological navel-gazing will put a scratch in the surface of the thing. Both the social and internal dynamics of software must be understood (at least in the abstract) to come to general conclusions. Specific conclusions are much easier to come by, but few seem to be willing to make them. In doing so, they create a feeble and constrained vision for the future of the medium. They place poetry above sport, composition above improvisation, the work above the practice.

I am not interested in video games, really. I am interested in software art and software culture. Where the word art is used in the most mundane and everyday sense of the word, the kind of art that one needs not aspire to because it's just there. Where culture is used in the broadest sense of the term - encompassing the entire gamut of related symbolic meaning. Video games are a significant part of this, but their customary name is hugely misleading - video certainly does not come first.