Tag Archives: android

modularity is great – if you commoditize the right complements

Google bought Android and made great things with it.

They also had an interesting audacity to announce an “open, modular” phone that ‘anyone’ could design from, and make components that would play nicely together (like IBM did with their initial ISA architecture releases back in the 80s). (Microsoft then flipped the tables on IBM and non-exclusively licensed MS-DOS to them, which meant hardware manufacturers could build entire replacement “[IBM] PC compatible” machines … that ran Microsoft software. )

But this only works if you’re Google – an advertising company that wants more eyeballs on its ads.

If you’re a phone manufacturer, like Motorola, the absolute last thing you want is for “anyone” to be able to replace all of the modules in your phone – because you’re not selling the OS, you’re selling hardware. As Joel Spolsky wrote 15 years ago,

If you can run your software anywhere, that makes hardware more of a commodity. As hardware prices go down, the market expands, driving more demand for software (and leaving customers with extra money to spend on software which can now be more expensive.)

Sun’s enthusiasm for WORA is, um, strange, because Sun is a hardware company. Making hardware a commodity is the last thing they want to do.

Motorola is a hardware company. They may want add-ons to be available to their base phone, but the certainly don’t want you replacing everything – unless it’s from them.

Jean-Louis Gassée notes these issues in his latest article, “Lazy Thinking: Modularity Always Works”,

In order to succeed, “disruptive modularity” needs a stable architecture with well-defined and documented boundaries. Module innovators need to be able to slide their creations into place without playing havoc with the rest of the edifice. This is how it worked in the Wintel PC world…sort of. In PC reality, as many of us have experienced, the sliding in and out of modules wasn’t so neat and often landed us in Device Driver purgatory. In the mid-nineties, one Microsoft director told me that the Redmond company actually spent more engineering resources on drivers than on Windows’ core software. …
Most important, strongly-worded theories are less interesting than exploring their cracks, where they don’t seem to work. This is how physics keeps moving forward and this is also how our understanding of business should advance. In the case of Project Ara, the unexamined consensual acceptance of Disruption Theory led many to believe that Modularity Always Wins meant smartphones would (and should) follow the same path as PCs.

I hope JLG (and I, and Joel Spolsky, and basic economics) are wrong.

But I doubt it.

programming your home by mike riley

Mike Riley’s entry in The Pragmatic Programmers series, Programming Your Home – automating with Arduino, Android, and your computer – was a lot of fun.

While I am not really in a position to do many of the mini projects given in the book (wrong type of house plus we rent), reading some of the project ideas did give me some inspiration for other activities. One of those is a Buffer-like tool I’m now writing to queue tweets over-and-above what the free level of Buffer will allow (and on a different schedule from my Buffer-fed queue). In conjunction with python-twitter, cron, and simple email messages, I’ve got a system started to which I can email things I would like to be posted, and they will go out when the cron job runs.

The Arduino is an impressive embedded platform – one that has also rekindled another long-time interest I’ve had in robotics. Years back, I recall seeing Sally Struthers advertising for one of those learn-at-home groups, and one of the options was robotics. (By “years back”, I mean 20+ years ago – probably more like 25 years ago, at this point.) I used to own a copy of Robot Builder’s Bonanza – and read it cover-to-cover a couple times. I loved watching Battlebots on TV. I’ve always wanted to buy/use LEGO Mindstorms.

Using robots to automate daily activities (and, of course, for fun) has been a fascination since I first saw Lost In Space and myriad other scifi shows and movies.

Riley does a great job of not demanding you be an expert programmer (or even a programmer at all) with the fully-implemented code examples in the book. He also does a good job of indicating what you’ll likely have to tweak on your own – and what you can probably just leave alone in the examples. Add to this the “extra credit challenges”, and I highly recommend it to anyone interested in home automation, embedded development, robotics, or just general programming/scripting.

There are some other interesting Python snippets throughout the book – that don’t have to be used in the context of an Arduino (like using Google’s SMTP server (via authentication)).

replace the restaturant buzzer

Somebody needs to replace the ubiquitous restaurant buzzer with either an SMS- or smartphone-based tool: when you put your name on the waiting list, you give them your phone number.

When your table is ready, they can buzz your phone.

Fewer moving parts for the restaurant. Fewer chances to lose stuff. Less crap to carry if you’re a customer.

And if you don’t have a phone anywhere in your party? Well, those few folks can get a buzzer.