1801 - Joseph Marie Jacquard uses punch cards to instruct a loom to weave “hello, world” into a tapestry. Redditers of the time are not impressed due to the lack of tail call recursion, concurrency, or proper capitalization.

It’s a prototype demo, but some gestures are really nice. I’m not really sure what will be the right gesture to turn multiple pages, but I kindof like the very simple one where you slide with 2, 3 or four fingers to turn 2,3 or 4 pages respectively.

• Every meeting must have one clear decision maker. If there’s no decision maker — or no decision to be made — the meeting shouldn’t happen.

• No more than 10 people should attend.

• Every person should give input, otherwise they shouldn’t be there.

• No decision should ever wait for a meeting. If a meeting absolutely has to happen before a decision should be made, then the meeting should be scheduled immediately.

Whoever picks up their phone is footing the bill.

With an entire body at your command, do you seriously think the Future Of Interaction should be a single finger?

This breaks a lot of assumptions I had about magnets.

Please check our Frequently Asked Questions.

PATENT PENDING. Contact page.

To be presented as the Emerging Technologies demonstration ‘Throwable Panoramic Ball Camera’ at the SIGGRAPH Asia 2011: Jonas Pfeil, Kristian Hildebrand, Carsten Gremzow, Bernd Bickel, Marc Alexa. Computer Graphics Group, TU Berlin.

Diploma thesis ‘Throwable Camera Array for Capturing Spherical Panoramas’: Jonas Pfeil. 2010. Advisors: Marc Alexa, Carsten Gremzow.

High resolution images: Ball Camera (JPEG, TIF), Panorama (JPEG, TIF). These two high resolution images and the following text are available under the Creative Commons Attribution 3.0 Unported (CC BY 3.0) license. You can use them freely but you have to include a reference to “Jonas Pfeil” and this webpage (http://jonaspfeil.de/ballcamera). The video is licensed under CC BY-NC 3.0. Please contact me if you need a higher quality version.

Panoramic photography creates fascinating images. Very wide angle images are closer to the human field of view than conventional pictures. If seen through a panoramic viewer they let us experience a location as if we were there. Panoramic image stitching can create panoramas from pictures taken one after another. Unfortunately, acquiring the images takes a lot of time and moving objects may cause ghosting. It is also difficult to obtain a full spherical panorama, because the downward picture cannot be captured while the camera is mounted on the tripod.

In this work, we present a throwable panoramic camera that solves these problems. The camera is thrown into the air and captures an image at the highest point of flight - when it is hardly moving. The camera takes full spherical panoramas, requires no preparation and images are taken instantaneously. It can capture scenes with many moving objects without producing ghosting artifacts and creates unique images.

Our camera uses 36 fixed-focus 2 megapixel mobile phone camera modules. The camera modules are mounted in a robust, 3D-printed, ball-shaped enclosure that is padded with foam and handles just like a ball. Our camera contains an accelerometer which we use to measure launch acceleration. Integration lets us predict rise time to the highest point, where we trigger the exposure. After catching the ball camera, pictures are downloaded in seconds using USB and automatically shown in our spherical panoramic viewer. This lets users interactively explore a full representation of the captured environment.

We used the camera to capture full spherical panoramas at scenic spots, in a crowded city square and in the middle of a group of people taking turns in throwing the camera. Above all we found that it is a very enjoyable, playful way to take pictures.

- pager escalation gets way harder, because a ticket might bounce through 20 service calls before the real owner is identified. If each bounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build a lot of scaffolding and metrics and reporting.

- every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service.

- monitoring and QA are the same thing. You’d never think so until you try doing a big SOA. But when your service says “oh yes, I’m fine”, it may well be the case that the only thing still functioning in the server is the little component that knows how to say “I’m fine, roger roger, over and out” in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it’s indistinguishable from automated QA. So they’re a continuum.

- if you have hundreds of services, and your code MUST communicate with other groups’ code via these services, then you won’t be able to find any of them without a service-discovery mechanism. And you can’t have that without a service registration mechanism, which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where.

- debugging problems with someone else’s code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox.