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)?

How about it being biological in nature? The bias comes about in the way that we perceive and identify patterns through shape, color, repetition, etc. The bias is located in the rods, cones, optic nerve, and visual cortex. And it's inherently and axiomatically in all people who have eyes and ears, in the same way that it's axiomatic that all people breath and metabolize energy. The entire field of cognitive neurobiology provides a compelling reason to treat bias as axiomatic.

One consideration to think about is that the people who are recommending you release as open source may, in reality, simply be advocating for the ability to make customizations and build on top of the framework you're developing. An open API made actually serve their needs; and may be something they haven't considered, or don't know to ask about. So, open API, proprietary framework is one possibility.

Second, consider a subscription model to a proprietary database. It's a classic business model, and can be added to most any project relatively easily. Even open source ones. On the support side, the proprietary database may be a) premium support forum, b) bleeding edge features not incorporated into the base build, c) recent bug fixes and security patches not incorporated into the base build. On the feature side, there are countless opportunities, but they'll be dependent upon your framework and what it does. For example, if you have a service that is geolocation aware, your propietary database might be a list of locations of interest.

I disagree. Outsourcing is driven by a high demand for programming talent, and a supply of cheap programming labor from developing countries. But here's the thing: we're quickly exhausting the availability of untapped labor forces. India, Russia, Brazil, China... they've all been brought online and the candidates for IT and programming position have been incorporated into the global workforce. As that happens, they're stop being cheap programming labor. But the demand continues. When globalization finishes running its course, and we effectively get global internet coverage, things are going to get better in North America with regards to programming work. There's *still* going to be a demand for programming talents; but there won't be a trade imbalance which encourages outsourcing. No, this next decade is going to be marked by quit a bit of insourcing.

Here's the thing: you *can* start practicing medicine, prescribing drugs, charging for advice on the law, auditing financials, etc. Without a degree. Or without a license. But it becomes a matter of risks and rewards and liability. Without the proper education, credentials, licensures, and professional memberships; you can't expect the state, employers, or other individuals to protect you from liability in the case something goes wrong. If you're willing to accept the liability yourself, or have some method of limiting your liability, then do what you will. If you're working with a group of individuals you know aren't going to claim damages or press charges, then the matter of licensing, credentials, etc doesn't matter.

As some examples:
- providing financial auditing to crooks and thieves (the crooks and thieves are motivated not to use the legal system);
- charging money as a consultant to provide (law) advice on a particular topic one may be an expert in (supply/demand economics may allow him to operate in that particular capacity without fear of damages being brought against him; for instance, political pundits, economists, etc );
- going over case history and drug interactions of family members (the person going over drug interactions knows the family member isn't going to sue them); - starting a business and writing software which prescribes drugs and/or evaluates drug interactions, etc (the entrepreneur/programmer has a limited liability corp and software audits protecting her);
The point being that in each of these cases, liability is contained in some way.

You'll find that entrepreneurs and PhD level professionals regularly are involved in practicing medicine/psychiatry/law/accounting/etc without official licensure and certification, etc. They're simply willing to accept liability or have the necessary protections in place (such as ownership of an LLC).

Now, with regards to IT and software professionals. It's a dumping ground for many of the same underlying reasons. 1) no professional licensure or certification bodies. 2) liability is difficult to track and account for because most IT workers are employees and aren't contracting fee-for-service. But even if you had those things in place, people could still come along without a CS degree or board certification in C++ programming, by way of simply starting their own business and assuming liability and risks themselves.

Agreed. People don't have the time or necessary context to parse text and lots of numbers during presentations. Graphs, diagrams, and photos are what really works for presentations.

Also, the transition effect is 100% spot on. Specifically, simple fade effects between graphs to give a before/after. If you create a series of diagrams or graphs, all with the same width, height, margins, padding, etc; and so they're all positioned exactly the same; you can use the fade effect in PowerPoint to achieve smooth transitions from slide to slide; and it appears that you've animated the graphs or diagrams. I can't recommend this technique enough. From the observers perspective, there's no context change when this happens; no need for the eye to rescan the image; no need for the user to jump to a new context. All the viewer knows is that an element was either added or removed from the image. This allows you to walk the user through a complex concepts.

For instance, when adding a new industrial plant machine to a shop floor (MRI scanner, 3D printer, robotic welder; whaterver); you might start with a network diagram with everything installed. Then, working backwards, selectively hide one element at a time, and save out a PNG or JPEG image. Keep saving out copies of the network diagram with one fewer piece of supporting equipment or change to the network layout, until you get to the current network state. You should wind up with a half-dozen or dozen network diagrams; all the same shape/size etc, each differing from the next by the addition of one new piece of equipment to the network. When you take this series of images and put them into PowerPoint and add a fade transition, you can walk people through the complex process of installing a modern piece of equipment on the shop floor or in the server room. Or restructuring a department. Or refactoring code. Or whatever other complex process you're doing.

Mod parent up. d3.js is becoming one of the slickest libraries around.
Add jquery.mobile.js in the mix for CSS optimized page transitions and single-page web designs.
And maybe a dash of webgl.js.


I second the notion that I'm *really* starting to like Javascript. At this point, I'm consider 100% javascript applications; since things like node.js and mongodb are now available.