readings in tech and urban design

as surfed the evening of 2013-11-29

the data city

by jack self, 2009.10.04
http://millenniumppl.blogspot.com/2009/10/data-city-jules-verne.html
a critique of http://www.thingsmagazine.net/2009/10/on-battlesuits-collage-city-seeking-and.htm

linked to...

On battlesuits, the collage city, seeking and remembering

unattributed via things magazine, 2009.10.01
http://www.thingsmagazine.net/2009/10/on-battlesuits-collage-city-seeking-and.htm
Makes the claim "The modern city is the data city."
"The data city of the future will be unnavigable without technology, granted..."
Speculates about role of changing patterns of information consumption & memory

linked to...

the city is a battlesuit for surviving the future

by matt jones, 2009.09.20
http://io9.com/5362912/the-city-is-a-battlesuit-for-surviving-the-future
Archigram, a 1960s "protoblog" architectural collective actant
"cities as systems, reflecting the contemporary vogue for cybernetics and belief in automation."
"people are walking architecture"
Adam Greenfield, Nokia design director: "a searchable, query-able city" - a read/write city
"Behaviour and information as the raw material to design cities with as much as steel, glass and concrete."
"chaotic sprawls of the industrialising world such as the "maximum cities" of Mumbai or Guangzhou. Here the infrastructures are layered, ad-hoc, adaptive and personal"
"Cities are entities that network outside of nations as their wealth often exceeds that of the rest of the nation put together - it's natural they solve transnational, global problems."

linked to...

the street as platform

by dan hill, 2008.02.11
http://www.cityofsound.com/blog/2008/02/the-street-as-p.html
"The way the street feels may soon be defined by what cannot be seen with the naked eye."
"Each element of data causes waves of responses in other connected databases, sometimes interacting with each other physically through proximity, other times through semantic connections across complex databases, sometimes in real-time, sometimes causing ripples months later. Some data is proprietary, enclosed and privately managed, some is open, collaborative and public."
Quoth Archigram: '“When it’s raining on Oxford Street, the buildings are no more important than the rain”'
Data ephemeral like the weather (like Archigram's rain)
"So the more relevant question is how do the buildings and the rain of data interrelate?"
"Considering the non-visual senses might be a better analogy when it comes to perceiving the way data affects i.e. looking at the way the street sounds, feels or smells."
"Holes in data, public and private, may become more relevant than the pothole in the pavement - until you trip over it, at least."
re availablility of services, "a sense of fragility in the network, perceived but not comprehended by users"
Two possible future streets: "Locked down street", "Open source street"
Generativity: " Proprietary systems, while ideally suited to high-security purposefully-closed networks, are intrinsically unlikely to enable a form of creative aggregation and connection unintended by the owners and makers."
Localization of data:
"Intrinsic local detail will tend to require collaborative updates from local users themselves."
"An open approach to descriptive data can enable a far richer local dataset to emerge, more accurately conveying the sense of what the street is. It may also be patchy, however."
Commercial efforts are likely to be poorly adapted for local needs.
"This commercial development is a given, and often not related to those whose job it is to shape streets."
"The various information modelling systems - the building information modelling system; those conveying the state of local services; those broadcasting the presence of a bus - could be built with openness in mind. Why do this? In order to enable maximum coverage and to stimulate engagement and innovation, with occasional possibility for unintended creative use. And often, it's public data and therefore part of a civic relationship."
"Just as good street planning might leave a space open to possibility, and not over-prescribe its program, so informational systems can leave themselves open to possibility."
Re open analytics:
"The patterns of use in their data become as self-evident as that shortcut worn through the grass in front of the library."
"actually showing the seams of an object is far more likely to engender trust, engagement and appropriation."

=== thoughts:
we are architects, historians, geographers. sociographers, demographers, planners. social workers, teachers, counselors.
"As Reyner Banham said, when you’re running with technology, you’re in fast company - and you may have “discard the professional garments by which you are recognised”."

=== further reading list:

Adam Greenfield, Everywhere - on ubiquitous computing

Transmetropolitan - graphic novel, prototypal dystopian megacity future

I want to help build products which maximize freedom, agency, enlightenment, and well-being. Top-down approaches fail because the universe is made of atoms. Products which pander to passé procurement models are willfully negligent and ought to constitute developer malpractice.

Thinking in Promises

This morning I had an epiphany: of course some people find promises to be "easy" and "intuitive" at the same time while others find them "hard" and "unwieldy":

Programming in promises requires thinking about type signatures.

Depending on your perspective, this is either a great thing or The Worst Thing Ever^TM

People who have programmed in statically typed languages before are used to thinking about parameter types and return value types. For these people, it is easier to reason about a function from a URL to a Response object in terms of (URL) => Response rather than (URL, (Error, Response) => void) => void (using jsig notation). The former clearly expresses the expected input and output of the function, while the later only has input which is presumably being evaluated for its side effects.

People who are used to programming in dynamic languages primarily aren't used to having to think in terms of types and signatures, so this additional overhead contributes to their perception of promises as being too hard, too mysterious, or too much to think about. Programmers used to thinking about types are already thinking about this, so this mental overhead is negligible, and the abstraction of promises makes code easier to reason about simply because it let's them reuse the abstractions, patterns, and mental models they're already used to.

My relativistic assertion is that neither approach is correct, just as neither The British colour nor the American color is correct. This assertion is not without controversy, but neither are Promises. I appreciate the clarity that having type signatures gives me in communicating about code to fellow programmers (including my future self).

Finally, I want to clear the air. There is an unfortunate amount of FUD on the side of some promise proponents, whom I've heard say things like "callbacks aren't composable". It is possible to do metaprogramming on callbacks, including things like control flow manipulation (parallelization), map/reduce, decorator pipelining, etc. It's just that this needs to be done either in an ad hoc way or using some purpose-built library like async (or any one of the dozens of other control flow libraries in npm). These are not always clear to reason about. I won't make any claims as to which is easier, but with promises, since they're just values, one can use the same value programming techniques like map and reduce that is typical in synchronous code.

building F# compiler on Mac OS X 10.8 Mountain Lion

F# is a lovely mixed paradigm functional language targeting the Common Language Runtime, which works great cross-platform on Mono.

I had some trouble getting it installed on my machine, so this documents the exact steps I followed at the end of February, 2013, to get everything up and running. Initially I was following F# 3.0 in the Mac and Mono World. Dave's blog has a bunch of other great content which I recommend you check out.


- Download and run the installer for mono 3.x: http://www.go-mono.com/mono-downloads/download.html

In the console:

# Check installed mono version:
$ mono -V

# I get 3.0.4.

# add mono to pkgconfig path
# in your .bash_profile:
export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Versions/Current/Lib/pkgconfig/


# Git clone fsharpc:
$ git clone git://github.com/fsharp/fsharp.git

# Make sure brew packages are installed and up to date:

$ brew update
$ brew install pkg-config
$ brew install autoconf

# cd to fsharpc directory and comment out mono version check in ./configure:

$ cd ~/dev/fsharpc

# For me, lines 1764 - 1766

# #if ! pkg-config --atleast-version=$MONO_REQUIRED_VERSION mono; then
# # as_fn_error $? "\"You need mono $MONO_REQUIRED_VERSION\"" "$LINENO" 5
# #fi

# Run config script with correct paths:

$ ./autogen.sh --prefix=/Library/Frameworks/Mono.framework/Versions/Current/ --with-gacdir=/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/gac

$ make

$ sudo make install

# verify the install:
$ fsharpc
F# Compiler for F# 3.0 (Open Source Edition)
Freely distributed under the Apache 2.0 Open Source License

error FS0207: No inputs specified

Now you're ready to go.

call to network citizenship

Aaron wasn't a victim of a cruel Department of Justice, unless we all are. His death is tragic, and this country (both our culture and our society) is terrible at dealing with mental illness. And the grossly disproportionate charges sought by his prosecution, and the prospect of facing more than 30 years in prison for his alleged and victimless crime no doubt caused great stress for a sensitive, idealistic, brilliant 26-year-old.

But we should remember his work, and his message of openness, and take from it a renewed urgency to educate ourselves as citizens of a networked space.

He was an activist, fighting at the vanguard of liberalism and freedom in our bold new networked age. He understood what was at stake in an interconnected world, how easy it is for individuals to be subsumed and left powerless by faceless, distributed, protocol-based power structures.

As network citizens, we must treat ignorance and willful idiocy of networked power structures as no more acceptable than not knowing that there are 50 states, or that the Constitution was not signed in 1776, or that there are three branches of the American federal system.

The network is the dominant power structure of our lifetimes, and it is incumbent upon us to be conversant in this new territory, to understand the stakes, the parties involved, the competing powered and monied interests, and to recognize that we still have legitimate popular sovereignty over these several corporate and special interests. Citizenship is a duty for any individual caught living in an advanced society. Be a citizen.

Requiescat in pace, Aaron Swartz.

Aaron Swartz speaking at a PIPA/SOPA opposition rally in New York.
(Photo (c) selfagency under a Creative Commons BY-SA 2.0 license)

I reproduce here Aaron's Guerrilla Open Access Manifesto:

Information is power. But like all power, there are those who want to keep it for themselves. The world’s entire scientific and cultural heritage, published over centuries in books and journals, is increasingly being digitized and locked up by a handful of private corporations. Want to read the papers featuring the most famous results of the sciences? You’ll need to send enormous amounts to publishers like Reed Elsevier.

There are those struggling to change this. The Open Access Movement has fought valiantly to ensure that scientists do not sign their copyrights away but instead ensure their work is published on the Internet, under terms that allow anyone to access it. But even under the best scenarios, their work will only apply to things published in the future. Everything up until now will have been lost.

That is too high a price to pay. Forcing academics to pay money to read the work of their colleagues? Scanning entire libraries but only allowing the folks at Google to read them? Providing scientific articles to those at elite universities in the First World, but not to children in the Global South? It’s outrageous and unacceptable.
“I agree,” many say, “but what can we do? The companies hold the copyrights, they make enormous amounts of money by charging for access, and it’s perfectly legal — there’s nothing we can do to stop them.” But there is something we can, something that’s already being done: we can fight back.

Those with access to these resources — students, librarians, scientists — you have been given a privilege. You get to feed at this banquet of knowledge while the rest of the world is locked out. But you need not — indeed, morally, you cannot — keep this privilege for yourselves. You have a duty to share it with the world. And you have: trading passwords with colleagues, filling download requests for friends.
Meanwhile, those who have been locked out are not standing idly by. You have been sneaking through holes and climbing over fences, liberating the information locked up by the publishers and sharing them with your friends.

But all of this action goes on in the dark, hidden underground. It’s called stealing or piracy, as if sharing a wealth of knowledge were the moral equivalent of plundering a ship and murdering its crew. But sharing isn’t immoral — it’s a moral imperative. Only those blinded by greed would refuse to let a friend make a copy.
Large corporations, of course, are blinded by greed. The laws under which they operate require it — their shareholders would revolt at anything less. And the politicians they have bought off back them, passing laws giving them the exclusive power to decide who can make copies.

There is no justice in following unjust laws. It’s time to come into the light and, in the grand tradition of civil disobedience, declare our opposition to this private theft of public culture.

We need to take information, wherever it is stored, make our copies and share them with the world. We need to take stuff that's out of copyright and add it to the archive. We need to buy secret databases and put them on the Web. We need to download scientific journals and upload them to file sharing networks. We need to fight for Guerilla Open Access.

With enough of us, around the world, we’ll not just send a strong message opposing the privatization of knowledge — we’ll make it a thing of the past. Will you join us?

Aaron Swartz


July 2008, Eremo, Italy

Allow me to recapitulate a few of the things I believe and care about

- om. connectedness
- the great opposition to entropy
- work on stuff that matters
- symphony
- excelsior
- be humble yet ambitious
- no ownership, no secrets
- start often
- when in doubt, work harder
- keep moving, moving is living
- you know less the more you go on
- explore
- honor awe
- keep a healthy disregard for the impossible
- be intentional
- play. play nice.
- waste time, money & resources
- break laws, policies, norms and taboos
- hack the world around you
- hack everything. be constructive.
- consume less, create more
- test limits
- challenge metaphors
- build models
- improvise
- travel light
- embrace ambiguity
- avoid pretension
- be better
- be stylish
- be selective & critical
- make truth & beauty
- leave a paper trail
- challenge perspectives
- be incorrigible
- be called a damn fool
- be arbitrary and capricious
- experiment more
- mad science, mad hacking, mad making.
- drink, eat, smoke to excess
- throw stones at cathedrals
- help people in need
- travel abroad. travel off planet.
- document everything
- embellish liberally
- win by your own rules

Thoughts on JavaScript from 38,000 feet.

Note: what follows is some stream-of-consciousness writing from the plane on my way back from EmpireJS in New York this past Monday. It's a reflection of some of my current thoughts on JavaScript as a platform.

Let's say I wanted to build a robot to do something really awesome, like make toast or drive in space or fly a rocket crane or something. And I wanted to be able to do that in an expressive, high-level language.
Here's the thing. JavaScript won on the web, because it is everywhere. But with new platforms, do we want to be doing it in JavaScript just because it's familiar?

What, actually, are the good parts about JavaScript? Not just Crockford's favorite language features - I mean in terms of the ecosystem.

Npm is obviously a good part. We've done a great job of finding a good level of granularity to promote incredibly productive code reuse, and at the same time built a community to build thousands of these modules. This is good, and we should keep it. Now, bear with me:

I like programming because, as Fred Brooks so brilliantly put it, it makes me feel like a wizard. You sit at a terminal, type a few arcane and idiosyncratic incantations, and suddenly this machine does things. That's cool. But I want to be able to build things faster. Here's the thing - and I know I'm something of an anomoly here - I don't actually like programming. I like making things. I like being able to see the result, sharing things with people, and doing zany or useful or silly or amazing or trivial things. But i dont like typing things. One of the things I love about code is the ability to change things.

I have very little tolerance for idle bitching. Unfortunately, I also tend to complain a lot. Maybe not complain, but criticize, in the sense of identifying things that could (and should) be better. I'm not always a very happy person, because I see so much badnesss around me. But then I give myself the power to change some of it.

In his talk at EmpireJS, @domenic characterized a lot of what we as JavaScript developers do as Stockholm syndrome - we repeat things to ourselves to convince ourselves that we like and enjoy some of the dumb things in JavaScript which no person in their right mind would actually enjoy. Life is too short, the list of problems to be solved too long.

I submit we should be embracing this prolific explosion of compile-to-JavaScript languages. People are making things which solve their on problems. You dont have to use it. Write in whatever you like. But dont feel obligated to write in things you don't like. Don't tolerate badness. Do you like coffeescript? Maybe, maybe not. Now, do you use modules written in coffeescript in your projects? If not, why not? It better not be for some silly reason. Here's the thing - it shouldn't matter what language the code is written in. JavaScript is our vm. Whatever tools we use to arrive at that JavaScript should be wholly immaterial. We need to stop caring so much about imolementations, and start caring more about interfaces.

I heard a crazy and seditious idea last night - to start publishing tons of C modules to npm. At first that sounded crazy: native modules are evil, etc, etc. But why not? There's an argument to be made that having a common implementation language is better for encouraging community contributions. But most modules, I would contend, are written in whole or in large part by a single author. We shouldd acknowledge and embrace this, and realize that the really interesting things we should care about are tiny piece of functionality - especially domain-specific things. We don't need another damn templating language - we need fun things like math and science modules. It shouldn't matter if someone wants to write in R or Fortran. The biggest platform advantage we can have is fostering the incredible environment of code reuse and productivity, built on top of the right abstractions and interoperability.

Rather than promoting some perverse and conformist orthodoxy, I want to be a crowded bazaar at the intersection of exotic trade routes going to every far flung corner of the internet. I want to encourage mad hacking for its own sake - just to see what we can make. I want us to adopt creative and generative constraints, and discard traditional ones. Color outside the lines. Mostly, I want to look out at the world around me and see everything as mutable, as hackable, and continuously improveable. I want to be able to see the world like Neo from the Matrix - and I want to help others see the world this way, too.