Thruflo d.o.o

The fundamental thing about digital fabrication is the shift to post purchase manufacture.

The moment when a product is fabricated is a moment of crystalisation. An abstract design becomes a concrete product. A world of possibilities is reduced -- irreversibly -- to a single form.

Delaying that moment of execution until after purchase allows the world of possibilities to overlap with information about the purchaser and their context. The reduction of a product to its concrete form can be informed by this information: be it ergonomic, environmental, personal, social.

Companies who design products that adapt to contextual information will have a competitive advantage. Phones that just fit your hand. Furniture that just fits your space. Gadgets that just fit your lifestyle.

To do so, practically, they need to master their designs as parameterised applications: to publish the underlying logic of their models, not just static vector exports. At this point, the consumer experience can shift from radio buttons to sliders, as we can see in the first generation interfaces of Digital Forming and Matter Machine.

Alastair Pavan from WikiHouse often quotes John Maynard Keynes as saying:

> "It is easier to ship recipes than cakes and biscuits"

I want to argue that the interpretation of these recipes (the "eval" part of the read-eval-print loop) is -- far more than the usual hype -- what's really interesting about distributed manufacturing.

New research builds directly on the Schrödinger, Stuart Kauffman canon to derive not just life but intelligence from entropy. In What is Life?, Schrödinger defines life in thermodynamic terms, i.e.: entropy (or disorder). In At Home in the Universe Kauffman shows how order spontaneously emerges to create life. Now, Alexander Wissner-Gross (aka @alexwg), "a physicist at Harvard University and the Massachusetts Institute of Technology", has published research showing how intelligence emerges from the goal of maximising entropy.

The researchers developed a software engine, called Entropica ... In one test, the researchers presented Entropica with a situation where it could ... move a cart to balance a rod standing straight up in the air. Governed by simple principles of thermodynamics, the software responded by displaying behavior similar to what people or animals might do, all without being given a specific goal for any scenario.

Entropica's intelligent behavior emerges from the "physical process of trying to capture as many future histories as possible," said Wissner-Gross. Future histories represent the complete set of possible future outcomes available to a system at any given moment.

Wissner-Gross calls the concept at the center of the research "causal entropic forces." These forces are the motivation for intelligent behavior. They encourage a system to preserve as many future histories as possible. For example, in the cart-and-rod exercise, Entropica controls the cart to keep the rod upright. Allowing the rod to fall would drastically reduce the number of remaining future histories, or, in other words, lower the entropy of the cart-and-rod system. Keeping the rod upright maximizes the entropy.

"The universe exists in the present state that it has right now. It can go off in lots of different directions. My proposal is that intelligence is a process that attempts to capture future histories," said Wissner-Gross.

If this is right, then the same force that creates life -- the intentionality of physical systems to minimise order within the body -- also leads to intelligence -- the intentionality to maximise order outside the body. Every action has an equal and opposite reaction.

Here's a powerful new way of looking at the world -- and one that's exceptionally relevant for people building communities or designing social interactions. I quote from the introduction to Wired for Culture by Mark Pavel, head of the Evolution Lab at Reading University:

I want to call these tribal groups cultural survival vehicles. ... Richard Dawkins in The Extended Phenotype coined the term vehicles to describe structures that carry replicators. ... Putting these two ideas together, we can see that replicators (think of genes) exert their effects on the external world, and thereby influence the likelihood that they will survive, through the vehicles (think of your body) they build. The distinction between replicators and vehicles is important because it reminds us that an animal's body is merely a temporary structure built by its genes to promote their survival and reproduction. ...

When I use the term cultural survival vehicles, it is to capture the idea that our species evolved to build, in the form of their societies, tribes, or cultures, a second body or vehicle to go along with the vehicle that is their physical body. Like our physical bodies, this cultural body wraps us in a protective layer, not of muscles and skin but of knowledge and technologies, and ... gives us our language, cooperation, and a shared identity. We are the actors that produce this vehicle, behaving almost like individual genes clamouring inside it to exert our effects on the outside world, and influencing our likelihood of surviving. Our nature is wrapped up in the strategies we evolved and now deploy to make the cultural survival vehicle work for us. ...

The essential balancing act of human societies is that they will normally work best when everyone pulls together, but at any given moment what is best for you might differ from that which is best for your group. Our psychology is the outcome of this balancing act. It is the set of temperaments geared towards using our cultural vehicles to promote our individual survival in a world full of others like ourselves.

A simple principle for pricing risk into development projects. Whoever makes feature decisions and signs off on implementation should carry the risk of scope creep or non delivery.

As an agency or a developer, you can provide fixed cost development budgets but only when you decide what's in or out and what done looks like. (More accurately, you decide on done, done done and done done done). Where it's not appropriate for you to own the delivery decisions, it's not constructive for you to bear the risk.

jQuery is the de-facto library for the web, installed on 85% of websites. There are calls for the last few major release versions to be shipped in all major browsers. However, look what just came along. Two way data binding in the form of <angular />, Ember.js and friends. Suddenly the very thing that jQuery is so good at, DOM manipulation, is abstracted out of the picture.

The lesson, which we all know, is that change comes not from beating the incumbent at their own game but from focusing on what's going to make their strength redundant. The interesting thing I've just realised is that the Internet makes communication redundant.

So far, the main impact of the Internet has been to change the way we communicate. However, the real shift is towards a pervasive web where information is implicit. Just as <angular /> abstracts out DOM manipulation, implicit information abstracts out whole tranches of activity. Communication, for so long the core skill of successful brands, people and organisations becomes entirely irrelevant.

It may be tempting to view a future of no communication as a land of the blind where the one eyed man is king. In a world with no marketing, surely the business that buys ads will thrive? However, this misses the pivotal cultural shift. As HG Wells illustrated so well, people's behaviour is governed by the culture they operate in.

I was chatting with @h4rrydog a couple of days ago about the best tools to collaborate "internally", i.e.: between ourselves and with ad hoc teams of other people. Every man and his dog has their preferred workflow but I just setup one that's so delightful I can't help but share it.

The setup is to use a Google Apps email address (n.b.: #) with Do.com. The workflow is to use the little gadget Do.com installs into your gmail interface to turn emails into tasks. The task title is autocompleted with the email subject. There's a small link to populate the task description with the email body and autocomplete widgets to assign the task to a person, a project and a due date.

I've released a Python package called pyramid_assetgen that helps integrate Tav's Assetgen static build tool with the Pyramid web application development framework. As the docs say:

Back this morning after a break in Croatia and Prague. While I deliberately left my computer at home, my information addiction was strong enough to have me peeking regularly at my phone.

The best post I read was Everything is a Service, on the shift to a service oriented economy. I also enjoyed this clearly written reminder on the different ways to go viral.

Cory Doctorow's keynote on The Coming War on General Computation, in tandem with the whole SOPA drama, seems to have re-energised the fight for freedom on the Internet. I don't know about you but I did enjoy witnessing GoDaddy's karmic reward for the appalling UX they've inflicted on us for all these years.

Now we're officially in the year of the Dropbox clone, Insync landed with Google Docs integration. Gitdocs kicked off the open source alternative beauty parade. Sit back and enjoy.

Other open source projects I liked the look of were TouchDB and this Node.js JavaScript sandbox. Schedulables seemed like a good idea and Quicksand looked like a company worth keeping an eye on.

This post is about a user interface pattern, a common use case for it and an example implementation. The pattern is adding an extra dimension to a timeline. The use case is showing results that are both recent and nearby. The example implementation uses a slider widget and an adequate-result-volume algorithm.

When you have 1000 messages and you want to prioritise the best 50 to display, sort is the most common pattern. If the user is interested in the latest messages, sort by most recent. If they want to see the messages other users found interesting, sort by a metric like views or rating. However, the web is increasingly about real time data. Developers are processing streams and modelling tubes instead of tables. It rarely makes sense to display real time data in any order apart from most recent. So, what do you do when you want to prioritise by another dimension, like proximity or rating?

You apply a filter. In the case of a discrete filter like a keyword or tag, this is relatively simple. The user types #architecture into the search input and Twitter obliges. However, in the case of a range filter like rating or proximity it's not quite so simple. The user types near:london and Twitter, once again obliges. The subtle difference is that, in this case, Twitter makes an assumption for the user. It applies a default radius (aka default range). "Near" actually means "within 15 miles".

Compare the result volume of near:london with the result volume of near:abergavenny. In the first case (London) the result volume is so high, I may well prefer "near" to be more focused; perhaps meaning a radius of 5 miles. In the second, the result volume is so low I may prefer to widen the search to yield more recent results. Had I chosen somewhere really remote, would there have been any recent tweets at all?

Guessing a default radius introduces the risk of a bad user experience, whether through noisy results or a dead end. This can be avoided with an algorithm that prescribes the desired result volume and varies the radius or range. Let's walk through a concrete example, written in Python and CoffeeScript using SQLAlchemy and a spatially enabled SQL database.

(Before I do, let me note that this implementation was inspired by Tav's work on the original Placestation website, where he designed, implemented and introduced me to the algorithm. I am just the messenger.)

The following gist provides example code showing how to store and query geolocated Messages. Note that the location is stored as a Geography Type. This allows us to use a latlng projection (SRID 4326) whilst still accurately querying for results within a distance provided in metres. (If you're not familiar with map projections, it's worth getting your head around them before you bite off any geolocated data modelling).

If you have the dependencies installed (easy_install sqlalchemy and geoalchemy) and a spatially enabled SQL database running, you can download the script, edit the DB_SETTINGS on line 20 and run using:

python test_geography.py

With that under our belt, let's look at how we query our Messages. To work out the radius that will yield the desired result volume we can follow this pattern:

* start with a default radius (one we just make up, e.g.: 15km) * perform a query with that radius as a filter * evaluate the number of results: - if we got too many, repeat with a tighter radius - else if we got too few, repeat with a wider radius - else we have an adequate result volume =D

This next gist abstracts out the relevant parts of the previous test_geography.py script into a LocationMixin class that can be mixed into any SQLModel class. The get_distance class method on line 113 implements the pattern above using a left-node-right algorithm.

This allows us to write query code that looks like this:

With this code exposed in a request handler, all we need now is a user interface. I've collated a few files into a small example app on GitHub here. You can clone the repo, edit the db config as before and bootstrap and then run the example using:

python model.py python app.py

If you goto localhost:8080 you should see something like this:

As the page has loaded, we've initialised a LocationBar widget and an IndexPage view which both share access to a distance object.

When the page loads, the IndexPage view makes a request to /query, with the user's current geolocation. The request is handled with our query code from before. Because no distance parameter has been provided, the app uses our get_distance method to calculate a filter radius that will return a good volume of results.

When you bootstrapped the app, you generated 500 messages with random locations. If you now play with the location slider, you'll see the message numbers change as your query now supplies a specific distance parameter. The more you increase the distance, the more recent messages you will get, as more messages are within the filter radius. At lower distances, we start getting all the messages within that radius (down to no messages at all), rather than just the most recent.

Togethr is an app platform and social marketplace with aspirations to become a social economy. Why, you might ask, do we need a new social economy? Because to treat an illness you go to the cause.

Ever since Keynes, governments have borrowed money to stimulate growth in order to protect jobs. The cause of the economic crisis is not debt but instead the need for job security. Job changes are like earthquakes, they can shatter a life. If job losses were not so shattering, we would not need to borrow to ensure they don't happen. (Nor would we need to be so nervous about the day of reckoning when the credit runs out).

I've been part of the team behind WikiHouse. It's a fascinating project that points to a future where the Internet disrupts manufacturing.

WikiHouse is an open source construction set. A standard for designing houses that can be made using CNC milling technology. On one level you can download, print and assemble ready-designed houses. On the other you can tweak, share and combine componentised designs.

Micro-processing technology moved computing from the university to the pocket. CNC milling and 3D printing are digital fabrication technologies moving manufacturing from the factory to the garage.

As access to the hardware opens up, the number of people experimenting will increase. We've seen in software that, with the right infrastructure, open source will rapidly outstrip proprietary design. Architecture and product design is currently done in silos, without the serendipity of the pull request.

Those sectors will inevitably be disrupted. As The Guardian said about WikiHouse:

> "Such open platforms, using the creative commons, are one of the major forces that will change our conception of design in the near future."

Absolutely knocked for six at the view from the Hub Westminster boardroom.