Tag: programming

Mobile Rules

Crash-Only An Android app doesn’t need exit code. Loose Address/Type-Driven Coupling The way you hand off from one screen to another in Android is with an Intent. An Intent has a Target, an Action, a URI, and a data type (as in Internet media-type, MIME type), along with some ancillary stuff. You can specify a target, essentially a class name, and control passes to that class. Or you can specify an action (make a phone call, view something, delete something) and its URI and or media-type, and let the system pick the right software to deal with it. Remove Decoration We advise people that, since mobile-device screens are small, that they have to focus on data not decoration; get rid of all the headers and trailers and sidebars and toolbars that you can, so that the user gets the maximum-possible amount of payload.

android is based on loose coupling (intents) for interactions between apps. that seems to have worked ok for the web.

Forking is a Feature

THE ONE TRUE VERSION
Most importantly, the new culture of ubiquitous forking can have profound impacts on lots of other categories of software. There have been recent rumblings that participation in Wikipedia editing has plateaued, or even begun to decline. Aside from the (frankly, absurd) idea that “everything’s already been documented!” one of the best ways for Wikipedia to reinvigorate itself, and to break away from the stultifying and arcane editing discussions that are its worst feature, could be to embrace the idea that there’s not One True Version of every Wikipedia article.

A new-generation Wikipedia based on Git-style technologies could allow there to be not just one Ocelot article per language, but an infinite number of them, each of which could be easily mixed and merged into your own preferred version. Wikipedia already technically has similar abilities on the back end, of course, but the software’s cultural bias is still towards producing a definitive consensus version instead of seeing multiple variations as beneficial.

There are plenty of other cultural predecessors for the idea of forking, all demonstrating that moving away from the need for a forced consensus can be great for innovation, while also reducing social tensions. Our work on ThinkUp at Expert Labs has seen a tremendous increase in programmers participating, without any of the usual flame wars or antagonism that frequently pop up on open source mailing lists. Some part of that is attributable to the cultural infrastructure GitHub provides for participation.

Moving forward, there are a lot more lessons we can learn if we build our social tools with the assumption that no one version of any document, app, or narrative needs to be the definitive one. We might even make our software, and our communities, more inclusive if we embrace the forking ourselves.

or more accurately, easy forking and easy merging is. the author goes off the rails towards the end saying that forking wikipedia would be good.

Programming History

LOL

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

1940s – Various “computers” are “programmed” using direct wiring and switches. Engineers do this in order to avoid the tabs vs spaces debate.

1957 – John Backus and IBM create FORTRAN. There’s nothing funny about IBM or FORTRAN. It is a syntax error to write FORTRAN while not wearing a blue tie.

1986 – Brad Cox and Tom Love create Objective-C, announcing “this language has all the memory safety of C combined with all the blazing speed of Smalltalk.” Modern historians suspect the 2 were dyslexic.