Month: December 2007

Amateur thoughts and ambitions

One of the better things I’ve stumbled across this past year is Larry Lessig’s talk, How creativity is being strangled by the law.

The piece makes his usual argument that copyright law stifles innovation in the age of new media. Most striking to me, though, was the part where he uses the phrase “amateur culture.” He explains, “…I don’t mean amateurish culture, I mean culture where people produce for the love of what they’re doing and not for the money.” He uses the term to describe the activity of “kids” (?) creating their own remixes from existing media.

I can remember another amateur culture that’s now largely disappeared. Back in my teens, modem-based bulletin board systems (BBSes) fostered a rich “read-write” culture for amateur programmers. Most of us did not work in technology; after all, the commercial Internet hadn’t been born yet, so the computing industry was much smaller and more obscure. A career as a programmer seemed like a mysterious and rarefied thing to me back then. The coders you met on BBSes were often people who simply liked to do programming in their spare time.

These systems allowed us to circulate public domain source code for fun games and useful applications written in BASIC, Pascal, C, even assembler. We hacked on existing code to get it to do what we wanted, trying to figure out ways to push the limits of our little 8086 processors and 640K of RAM. We mingled regardless of our level of knowledge, beginners and experts alike. We had friendly user meetings in diners in Brooklyn and Manhattan (I lived in NY at the time), where we chatted about home-grown upgrades and discussed how to link up to the nation-wide discussion networks that existed then.

It was amateur culture at its best: lots of exchange, circulation, and cooperation happened all the time. But it was definitely not amateurish. Many were extremely capable and knowledgeable coders.

Today, there are still people who code just because they enjoy it, but the amateur culture and its community hardly exist anymore. Beginners on web forums are more interested in what they need to know in order to land a job, rather than in coding itself. Even open source projects tend to be dominated by career professionals; read any public mailing list and you’ll see how unhelpful they often are to amateurs who want to get involved. One reason I like python is that the project makes a genuine effort to connect to the sensibilities of amateurs. But even its forums are littered with snarky individuals.

All of this is largely due, I think, to the ideology of professionalism, which convinces us that having a stable career is the pinnacle of achievement. It damagingly equates amateurs with dilettantes. That’s why one of the first things we ask in this country when meeting a stranger is, “So what do you do?” By which we really mean, “Tell me what you do for a living so I can know who you are and whether you’re worth talking to.”

In 2008, I resolve to be more wary of this ideology and its negative effects. I want to embrace being an amateur in the various things that I do. I want to think less about careers and focus more on how to best spend my time doing what’s important to me. And I want to find more amateurs to hang out with as well.

Software is an Art

Today a blogger named Damon Poole wrote a short post titled, “Designing Software is the same as Predicting the Future.” It resonates with my post from a while back on whether “software engineering” is the right metaphor for writing code.

The essential problem of coding is to deal with the unknown as best you can. Software is made to solve a problem, but the more unique the problem, the more difficult it is to draw upon existing knowledge to create good solutions. Unknowns force you to make guesses. Educated guesses, hopefully, but guesses nonetheless.

This is why I’m in the camp of those who believe that creating software is an art. It’s an endeavor that wrestles with the unknown. This artistry is highest when you find yourself asking, “How do I do X?” and there don’t seem to be any pre-packaged answers you can look up in a textbook or simply google.

Paradoxically, once the software is written and refined, the unknowns are removed from the picture. Art largely disappears once the pure functionalism of operational software emerges. I think this is why many good programmers have short attention spans, get bored, and tend to jump from project to project. They crave the excitement and gratification of facing the unknown. But this is always ultimately ephemeral.

HTTP + XML do not a RESTful interface make

I’ve been stumbling across criticisms of the un-RESTful design of Amazon’s new SimpleDB service. Worth reading in particular is a piece by someone named Subbu Allamaraju, who seems both smart and accomplished. He did a quick rewrite of the API in his post, A RESTful version of Amazon’s SimpleDB. It’s a great example of how clean URLs can be when a bit of thought is put into them.

And people should also read it to clear up a popular misunderstanding about REST. I’ve already given it away in my title: HTTP + XML do not a RESTful interface make.

As Roy Fielding’s dissertation chapter lays it out, a REST architecture should follow the abstraction of “resources” from the “connectors” that perform operations on them. The HTTP protocol happens to be able to do this nicely: URLs refer to resources and the GET/POST/PUT/DELETE methods manipulate them. However, this isn’t inherent or automatic: you have to use its vocabulary properly. SimpleDB is a perfect example: it violates the principle that resource identification and operations should be separate. The API embeds operations in URLs.

So yes, it uses HTTP and XML. But no, those things alone don’t make it truly RESTful.

REST is certainly a huge step forward in enforcing cleaner abstractions, though in Amazon’s defense, it’s obvious why they choose to design their API the way they did. The URLs for SimpleDB have the same structure as those in ECS; consistency was probably the goal. So yes, it’s a conservative move that forward-thinking coders are turning their noses up at, but it’s also one for which existing developers will probably be grateful. Rant all you want about the evils of non-idempotent GET requests… for Amazon’s customers, the old API style feels familiar, and means one less new thing to get used to, or to learn.

Figuring out the mystery of T-Zones(tm)

I’m convinced that cellular phone companies keep dark basement cubicles full of evil marketing gnomes whose sole job is dreaming up ways to confuse and frustrate customers.

I thought it’d be cool to use my phone for browsing those new fangled web pages designed for mobile, and to be able to check my email. Having no idea how to go about this, I dug into the incredibly twisted world of marketing lingo, misdirection, and bad technological practices of T-Mobile.

Part 1: T-Zones(tm) Means Fun!

First, I went to the T-Mobile website and looked at their Services & Accessories page. Something called T-Zones(tm) is featured in a large box. What is it?

“The place to buy services—on your phone or on the Web. Check out all the fun and useful things available at t-zones.”

Okay. It has an icon that says “Web & Apps,” which sounds promising. Except… in a smaller box separate from T-Zones(tm), there’s also a list of “Other Services” that includes “Internet & E-mail Services.” What’s the difference? Well, obviously, T-Zones(tm) is “fun and useful” (trademarks will do that sometimes) whereas the other service isn’t.

Fine, I’ll bite. What does T-Zones(tm) Web & Apps give me?

E-mail on the go
Keep in touch while you’re out of the house. E-mail service lets you use your phone or other T-Mobile device to access personal e-mail from a variety of common providers so you’re never out of the loop.
[…]
Choose when and where you Web
Just $5.99 per month gives you unlimited access to mobile Web destinations and great capabilities—like reading, editing, and sending e-mail directly from your phone.

Sounds good, aside from the minor fact that web is not a verb. But how is it different from Internet & E-Mail Services? Well, the latter seems to be only for BlackBerry, Sidekick, and Smartphones. I consider my phone to be pretty snazzy, but I don’t know if it’s a Smartphone. How can I tell?

Luckily, there’s an FAQ on the side that tries to help out with this. Sort of.

Do I need a special phone to get Internet access?
Most phones can display text-only Internet by using T-MobileWeb service. To find a phone with a full Web browser, go to the Phones page and check the T-Mobile Internet check box.

Holy crap, that’s confusing. Checking off the T-Mobile Internet box doesn’t really show me Internet-capable phones, it shows phones with a FULL Web browser. “Most” phones are already capable of text-only Internet. Thanks for making that crystal clear!

Part 2: Wrestling with the phone

It would appear, then, that T-Zones(tm) is the right choice for my Nokia 6086. Which, incidentally, is NOT a Smartphone, after all. I do want “unlimited access to mobile Web destinations.” And if T-Zones(tm) makes it fun and useful, so much the better.

Frankly, the T-Zones(tm) menu item has always scared me. I didn’t know what it did, and it terrified me to think that I might click something by accident and discover a $1000 charge on my next bill. But this time, I clicked it. It brought up a little screen that sort of resembled a web page. I could navigate, just like using a regular web browser on a PC, to a screen that let me turn on T-Zones(tm) service for $5.99/month.

I suddenly understood. The T-Zones(tm) item is a simple mostly-text web browser. That’s all.

Which suits me fine. I can get the basic information I want, and I don’t really need the bells and whistles of a fancier phone with better browsing capabilities. On the other hand, I want to make the most of what the device can do. Googling around, I found that there’s a better browser, Opera Mini, that’s available for this phone. Why not try it out?

I transferred it successfully, but when I ran it, it showed the message: “Application access set to not allowed.”

It reminds me of that old passive voice trick, “War has been declared.” By whom, damnit?! Just who is it exactly who won’t allow this application to run? I want some answers.

Part 3: The mystery of T-Zones(tm) solved

Under the Option menu for the Opera Mini application, there’s an item called “App. access.” It’s what you’d use to grant permission to use the network. That’s a pretty good idea, since you don’t want applications secretly doing undesirable things on your phone. They’re written in Java, using a mobile API that has a strong security model built-in.

But on my phone, “App. access” is greyed out, disabled.

More Googling revealed that so-called unbranded Nokia 6086 phones let you adjust this setting, and Opera Mini works on them. But T-Mobile’s phones have that option deliberately disabled. Other users have reported this same problem with other applications that use the network as well.

So I can’t give Opera Mini permission to use the network, because the phone’s software has been crippled (a sadly un-P.C. word choice that’s stuck). By who? T-Mobile, that’s who.

What does this tell us about T-Zones(tm)? From what I can tell, and I might be wrong, both T-Zones(tm) and the more expensive Total Internet plan give you unlimited web access. The phones make the difference: lower-end consumers are forced to use the stock browser on crippled phones, while the more expensive service and application options are offered to users with high-end phones. This, in spite of the fact that your humble little phone might very well be capable of running applications that access the web. Definitely not very fun or useful.

It’d be like selling 2 models of Ferrari with the exact same engine, but one is capped at 50mph in the systems software. It’s capable of going faster, but it’s limited for no reason other than to encourage you to buy the faster, more expensive one. Which also happens to have a sunroof.

It’s fair to pay for a service, like network usage. It’s fair to pay for a device. But it’s bad business and bad technology to artificially disable goods simply to differentiate a product line. I don’t know how other T-Mobile customers feel, or if most of them even know about this aspect of their business, but to me, it’s downright insulting.

Pimping Python’s property()

A basic tenet of object oriented coding is encapsulation: expose the interface but hide the implementation.

Seductress that it is, Python makes it very tempting to violate this principle. Since all members of an object are public, it’s easy to access and modify them from outside. For example:

class Person:
    def __init__(self):
        self.age = None
jeff = Person()
jeff.age = 5 # maturity

Compare this with Java, where you can make a member private, and use “getters” and “setters”:

class Person {
    private int age;
    public int getAge() {
        return this.age;
    }
    public void setAge(int age) {
        this.age = age;
    }
    public static void main(String[] args) {
        Person jeff = new Person();
        jeff.setAge(5);
    }
}

The Java version has better encapsulation. If you decide later to change “age” to, say, a float, a string(!), or if you move it into another internally linked object, it’s no big deal. Just change the body of the getAge() and setAge() methods to do the typecasting or make the extra call, and you won’t need to change any other code. The implementation changes; the interface stays the same.

Of course, you could write getters and setters in Python, too, but you can’t enforce their use (data members are public, remember?). A better way is to do some magic using __getattr__ and __setattr__, although that could get messy, especially if you have a lot of names to intercept.

This has been bothering me for a while. Then I recently discovered the built-in function property(), which lets you rewrite the example above as follows:

class Person(object):
    def __init__(self):
        self._age = None
    def get_age(self):
        return self._age
    def set_age(self, value):
        self._age = value
    def del_age(self):
        del self._age
    age = property(get_age, set_age, del_age)
jeff = Person()
jeff.age = 5

Sweeeet. From the outside, nothing seems different: it still appears that you’re getting and setting age directly, just as before. But property() calls get_age and set_age transparently, giving you a layer that effectively provides encapsulation, even though you can’t tell from the outside. After all, that’s the whole point of encapsulation: you shouldn’t be able to tell from the outside.

In fact, this is actually better than how Java does it. A first version of Person might very well have age as a member which its users directly modify: this is intuitive and effortless, both conceptually and syntactically. Only later might you need to bring property() into the picture, as the object’s internals change or grow more complex. And that’s how it should be: more lines of code and more complexity only when you need it.

(Of course, you still can’t hide data members, but this still goes a long way towards better, though not complete, encapsulation.)

I can’t remember ever seeing property() mentioned anywhere in tutorials or introductory docs (it’s in the reference for built-in functions) That’s especially odd considering that one of Python’s strengths is its powerful object features. It would make sense to talk about this in the context of encapsulation. Plus I wonder how widespread the use of property() is in real world code.

Stuff like this is why I love Python.

Update: Some good comments over at reddit.