Exactly. Some of us are already programming applications with this in mind. I've normalized my virtual servers at... 256mb disk size; the websites are reactive layouts that adjust from 320x480 pixel cellphone sized displays to 3 megapixel thunderbolt displays and more; navigation is tied to keyboard shortcuts that can be mapped to haptics... be it mouse clicks, taps, swipes, or sign language.

Now days, my travel kit includes my iPad, a wireless bluetooth keyboard (solar), and an HDMI adapter. I go to friends houses, and simply connect to their HDMI hi-res television. If I want to do mobile development on the go, I grab my Mac Mini and do the same thing. HDMI is the best connector *ever*, and anybody who doesn't have an HDMI connector and wireless keyboard for their tablet is simply not groking the ergonomics of tablet portability.

Recently went through this myself. Despite having used a kanban board, used version control, commented code, written unit tests, etc, some junior devs thought the code sucked. My takeaway was that there were still too many barriers to entry. Too many passwords, not enough installation instructions, etc.

Somewhere in the process of learning to write production ready code, it occurred to me that it was necessary to work the process backwards. Begin a project by setting up your hosting or distribution environment before starting to code. Write unit tests before starting to code. And so forth.

Getting other people to contribute to your project requires the same kind of thinking. Set up a project page before you start to code. Write a vision statement before you start to code. Write installation instructions, coding style guidelines, and operations support instructions before you start to code. That way, as you proceed in the project, you have clearly build up the documentation that other people are going to need to join your project. These things shouldn't be started after the fact.

If you can't point a new dev to a website and say 'download the source and instructions' here, it's probably too complicated and will meet resistance.

What does the flow into and out of science have to do with anything? Migration is one of the four basic mechanisms of evolutionary change, along with natural selection, mutation, and genetic drift. Ideas flowing into and out of science is perfectly consistent with migration and Cultural Evolution models.

As for memes, I kindly recommend memegenerator.net, in all it's lowest-common-denominator glory, and the iPhone and Android app stores. Memes, like genes, are ubiquitous. The reason they don't seem to exist is because they're everywhere.

Wrote my senior thesis on Kuhn, positivism, etc nearly 10 years ago. My take away was that scientific and theoretical advances get disseminated throughout society. Ergo, a population undergoes memetic evolution. Drawing on biology, the obvious model is one of punctuated equilibrium. Once one reconciles the ideas of paradigm shifts with punctuated equilibrium, it becomes pretty evident how technology evolves, science is disseminated, differing rates of change in different fields, etc. All one has to do is look at the iPhone, iPad, and Leap to see modern paradigm changes in action. (Protip: The language we use to describe the punctuated equilibrium changes of the human species is that of stock markets, marketing, and market analysis.)

As Gibson put it, "The future is already here — it's just not very evenly distributed." I also highly recommend Hulls "Science as a Process".
http://www.amazon.com/Science-Process-Evolutionary-Development-Foundations/dp/0226360512

I don't buy it. The package is addressed to 1101 East 58th Street. That's the UChicago Administration and Admissions office address. No way. It's obviously a College application. And a good one too! Somebody has a sense of aesthetics. Probably someone wanting to go into Art Preservation or Museum Curratorship. Maybe Egyptology or Paleontology.

Performance art? It's obviously an application to the College (received in December, duh). Among some alumni, bets on the declared major range from Art Restoration & Museum/Library Curation to Archeology, Egyptology, & Paleontology. I almost went into Paleontology. One of my best friends has a B.A. in Egyptology. I have a half-dozen acquaintances I know who focused in various Museum/Library curator positions. It could be any.

As a UChicago grad, I think the answer is obvious. It was delivered to the Admissions office during the month of December. It's an application to the college. The Admissions office would just like to know who it's from! :)

It's daring, if somewhat obvious. But to my knowledge, it hasn't actually been done before. It was bound to happen eventually, however. I'm just kind of surprised it took this long, in fact. Whoever sent it will obviously get in if they have a modicum of academic ability or talent. It's exactly the kind of nerdy stunt, with an appreciation for aesthetics, that UChicago appreciates.

I see it differently. I see it as an issue of encapsulation. The issue is whether one is going to encapsulate the parallelism inside of a thread, or inside a machine, or inside a network. From an operations perspective, a thread is usually an opaque black-box, with few controls for the operations team to manage whether they want to scale a process up or down, add extra resources, migrate to different hardware, do disaster recovery fail over testing, etc. And having been in operations for many years, I like to expose controls in my application designs that allow operations to manage those parallelism features. And so, when it comes to encapsulation, I tend towards encapsulating parallelism with a hypervisor, rather than with a thread.

The idea isn't to just scale *hardware* (although that's one way of doing things). Rather, scale the virtual nodes within a hypervisor environment. Then, if you're using a 32 core server, run 31 virtual node servers, with each node server running on one core, and with one optimized dedicated thread per CPU. The last core gets used by the hypervisor itself to manage inter-node infrastructure. The end result is a virtual network running on a multi-core server, and is essentially just this generation's version of a mainframe architecture.

There are, of course, pros-and-cons to this approach. Some things you gain, while others you loose. But as far as scaling goes, one doesn't need to scale hardware to use parallelism. Just need to have a hypervisor with some micro-sized virtual machines. I like to keep my virtual machines running node.js at about 256mb of disk space. But when the time comes to go parallel with hardware, everything is already set up to.

It's actually a really huge advantage, if done correctly. A trivial example: I'm working on an app that has a file import functionality, so I wrote a half dozen helper functions to parse a spreadsheet into JSON. Later wound up using those same functions on the server to implement an XML interface. Business logic is the same in both instances, and having a single language for both server and client allows that business logic to be stored in a single place, maintaining the Don't Repeat Yourself (DRY) rule of thumb. Having a single language on both server and client is a godsend for keeping your app DRY.

Mmmm, maybe if you have only a single node. But a cluster of node servers can scale as well as you're ever going to hope for. And for real time applications, I'd much rather have a cluster of well-behaved optimized node.js threads than hoping a black-boxed apache thread won't decided to randomly fork and/or block.

Well stated. The sharing of language client and server side is the biggest practical benefit, in my experience. And yes, it's important to have a clear understanding of how Javascript is related to Lisp, what lambda calculus is good for, and what that entails by the way of anonymous methods, closures, and the like. That being said, if you understand those things, programming with node.js and associated frameworks (like derby, meteor, etc) is like surfing in Hawaii..

Teachers don't seem to have a problem with whiteboards and chalkboards. Painters who use easels don't seem to have problem working on vertical surfaces. The problem isn't with the vertical surface. The problem is entirely related to manufacturing and design of the technology. Like requiring pens, for example. Or not having multi-touch capabilities (major ergonomic feature there - being able to use gestures - that wasn't present in earlier touchscreen form factors, due to manufacturing and programming challenges).

Here's the problem with your argument: Chalkboards. And whiteboards.

As I recall, chalkboards and whiteboards have been used everywhere for the last 30 years. The problem hasn't been vertical surfaces, gorilla arm, fatigue, and what not. Teachers and other professions deal with those issues all the time. The issue has been processing power, form factor, and ergonomics. But not ergonomics in the gorilla arm sense. Ergonomics in the sense of requiring specialized pens that can't be easily replaced, and requires exotic device drivers and software.

Can anyone say 'exocortex'? The only thing missing are the right apps and software stack.

accelerando
http://manybooks.net/titles/strosscother05accelerando-txt.html

A pair of prescription eyeglasses with designer frames can easily cost upwards of $1000 dollars or more. Project Glass is going disrupt the current eyeglass industry, as a whole new augmented eyeglasses market is going to open up. It's going to be very interesting times for LensCrafters, Cohen Fashion Optical, Pearle Vision... (and I'd be selling their stock right now if I owned any). Will they go the way of the recording industry and resist the change? Or will they be more like Barnes and Noble and try to adapt with a not-quite-successful proprietary solution? Will Google acquire LensCrafters and will we be able to buy a pair of Ray-Bans running Android? Will Pearle Vision try to avoid a buy-out by building their own Ubuntu powered glasses (sans dedicated hardware like accelerometers and microphones) and wind up being the eyeglass version of the Nook (versus the iPad)?