Trevor F. Smith: Exterior

Loosely Joined

I was asked to pick up a load of half completed code from another developer and finish it off for a piece in the new terminals at SJC. The code was reasonable enough, but now that we're doing final integration it's incredibly hard to test that everything works together because of all the moving pieces:

The piece is going to be fantastic (I'll post deets when it's complete) and it's a good reminder of the value of test driven design.

The Old Video on a Cube Trick, eh?

Peter wrote a page which reads your webcam stream and uses it to texture a WebGL cube:

Urban Screens: The Schematic City in Gaming and Architectural Representation | Serial Consign

This short essay will consider two broad themes in examining the delineation of urban space by architects and game designers. These themes are a top-down, consideration of the city as a system and the charged notion of "play" in urban space. The title of this text, Urban Screens, is itself a play on the way we describe the representation of the city. Part picture-plane and part screen-capture, this is a speculative endeavour, a superimposition of multiple "ways of seeing" the same universal subject – the blanket of urban fabric that covers much of the world.

via serialconsign.com

I'm amused by how close we are to Ogogliio City. Four years ago the idea it seemed so far away.

Cities as games? 3D in browsers? Movies like "Inception"?

Academics are calling for it, techs are building it, and Hollywood is prepping us for it.

My Spaciblō talk at WebGL Camp

In the video I don't appear as flustered as I felt which I attribute to tips I learned from Berkun's Confessions of a Public Speaker.

WebGL Camp

I'll be talking at WebGL Camp about the hows and whys of Spaciblō. The basic premise of my talk is that WebGL isn't fun yet, we really have no idea how to use it properly, and we need open stacks like Spaciblō so that a thousand little dev teams can try out weird and wonderful design and development techniques.

The rumor is that they'll be streaming video live and then recordings will follow, so you can gawk at little old me presenting between heavyweights like the Google Chrome 3D team and the guy who built WebGL for Mozilla.

I'll be the tall nervous one.

Only three years too late

Massively, a news site focused on massively multiplayer online games, reported Monday that it was hearing about big layoffs, which included the entire Second Life Enterprise team (which built a version of the virtual world for businesses) and the Singapore office. Prior to the cuts, Linden Lab employed more than 300 people, Massively said.

Linden Lab said the restructuring will help it focus on its big goals — building a version of Second Life that works entirely in the Web browser (rather than requiring users to download software) and integrating it with social networks (which is where online gaming companies like Zynga have found massive audiences).

via games.venturebeat.com

I know schadenfreude isn't pretty, but when I was running Transmutable I put up with a metric ton of SL engineers and users telling me that the web wasn't going to eat their lunch.

I wonder if they're going to make a fat client which takes over the entire browser window and acts like a native app instead of a web app.

Update: At WebGL camp I met two friendly and smart SL people who gave me hope that they're well informed and working hard to balance the momentum of their community with the ways of the web.  Good on 'em.

Falsehoods Programmers Believe About Names

So, as a public service, I’m going to list assumptions your systems probably make about names.  All of these assumptions are wrong.  Try to make less of them next time you write a system which touches names.

1. People have exactly one canonical full name.
2. People have exactly one full name which they go by.
3. People have, at this point in time, exactly one canonical full name.
4. People have, at this point in time, one full name which they go by.
5. People have exactly N names, for any value of N.
6. People’s names fit within a certain defined amount of space.
7. People’s names do not change.
8. People’s names change, but only at a certain enumerated set of events.
9. People’s names are written in ASCII.
10. People’s names are written in any single character set.
11. People’s names are all mapped in Unicode code points.
12. People’s names are case sensitive.
13. People’s names are case insensitive.
14. People’s names sometimes have prefixes or suffixes, but you can safely ignore those.
15. People’s names do not contain numbers.
16. People’s names are not written in ALL CAPS.
17. People’s names are not written in all lower case letters.
18. People’s names have an order to them.  Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.
19. People’s first names and last names are, by necessity, different.
20. People have last names, family names, or anything else which is shared by folks recognized as their relatives.
21. People’s names are globally unique.
22. People’s names are almost globally unique.
23. Alright alright but surely people’s names are diverse enough such that no million people share the same name.
24. My system will never have to deal with names from China.
25. Or Japan.
26. Or Korea.
27. Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have “weird” naming schemes in common use.
28. That Klingon Empire thing was a joke, right?
29. Confound your cultural relativism!  People in my society, at least, agree on one commonly accepted standard for names.
30. There exists an algorithm which transforms names and can be reversed losslessly.  (Yes, yes, you can do it if your algorithm returns the input.  You get a gold star.)
31. I can safely assume that this dictionary of bad words contains no people’s names in it.
32. People’s names are assigned at birth.
33. OK, maybe not at birth, but at least pretty close to birth.
34. Alright, alright, within a year or so of birth.
35. Five years?
36. You’re kidding me, right?
37. Two different systems containing data about the same person will use the same name for that person.
38. Two different data entry operators, given a person’s name, will by necessity enter bitwise equivalent strings on any single system, if the system is well-designed.
39. People whose names break my system are weird outliers.  They should have had solid, acceptable names, like 田中太郎.
40. People have names.

via www.kalzumeus.com

Notes on Philip Zimbardo's "The Secret Powers of Time"

Past:
positive: the good old times
negative: regrets & failures

Present:
hedonistic: seek pleasure, avoid pain. seek knowledge and sensation
fated: it doesn't pay to plan because of religion, conditions, poverty, ...

Future oriented:
work rather than play, avoid temptation
life begins after the death of the mortal body

Reference: Geography of Time, by Robert Levine

Boys become men having spent 10k hours playing video games.
- not social
- in control of their experience

They're being "digitally rewired" but education is analogue.
Back to basics curricula are doomed.

Addictions are of present hedonism.
Waiting is a waste of time, to Americans, even for things like booting the computer.

I am a very large number.

At some point while working at PARC I was having a conversation with Mark Newman (of machine language fame) when we came up with the idea that if this is a simulation of a universe then some people are more difficult to simulate than others. If you do what everyone else is doing then your actions can be compressed down (assuming Lempel/Ziv sort of repetition referencing characteristics) along with them, but if you're way out there alone in possibility space then the simulator would need a larger number to represent you.

So, part of my life goal is to earn the right to wear a t-shirt which reads "I am a very large number."

View Source for the Back End

One of my background thoughts is how to bring the culture of "view source" to server side work in a similar process to how you can see HTML code which is used to render a web page.

Currently, interested parties can often figure out which technologies are being used on the front end in the hopes that it will tell us what toolkits are being used on the back end. So, if someone's URL ends in .php and there are lots of classes or JS objects with the word "smarty" in them then we might assume that the pages are rendered using the smarty template engine.

But what if we added some metadata to pages which gave interested readers the ability to see the guts? We add link elements for alternate views like RSS, but perhaps we could add them for a resource listing the various technologies and data which went into the page.

Here are a couple of strawman examples:

<link rev="technology" href="http://djangoproject.org/" />

<link rev="data" href="http://www.census.gov/geo/www/tiger/" />

So, what if we also want to provide information about how a specific page is rendered?

There are existing tools which are used during development to inspect the specific templates, queries, and context variables used during the production of a page. The django-debug-toolbar is an excellent example. But those are for the developers of the site and (for very good reasons) are not used on production servers.

What if, as part of rendering the page, we provided links to public versions of these resources? They could be resources on the local site or they could be in a public source repository.

Here's a strawman example for a hypothetical site running code which is hosted on github:

<link rev="source" href="http://github.com/example/project/app/views.py#method_name" />

<link rev="source" href="http://github.com/example/project/app/templates/page.html" />

With this metadata it would be relatively simple to write a browser plugin or favelet which gave developers the ability to "view source" on server side code.

For sites which are open about their development, this seems like a clear value for very little effort. For stacks like Django, the information already exists in the request and response objects so a little context middleware and a few {% includes %} in the base.html could go a long way.

If the LazyWeb doesn't provide than I may have to put this together.