Josh On Design

It’s the Fourth of July again, which is America’s independence day for my non-US friends, and it’s time for some code cleaning.  I’ve built several open source projects over the last year and it’s time to shut some of them down.  Out with the old to make way for the new. Let’s review, shall we?

I’ve been wearing an Android or Apple Watch for a few months now and I’ve come to one conclusion. While you don’t want to buy these quite yet, when the good version comes out in a few years we will all become superheroes.

For a recent project I needed a nice HTML table library to render a long table of data with fixed headers. Figuring there must be a million of such libraries, I started searching around. This would seem to be a simple thing, yet after a day of searching I still couldn’t find a good solution.

A year ago I speculated that Apple would never make a TV. If they ever did, I said they'd integrate a FaceTime camera with complex image processing, but I didn't think they would make a TV at all. There's just not enough opportunity in that market to make it worth Apple's while. It's low margin and no room to differentiate the product.  

As smartwatches have slowly faded into existence from their sci-fi past, I have always wondered: what is the killer app? What is the feature (or actual app) that would do something so useful I’d wear it on my wrist, put up with a mostly-off screen and laggy voice control, learn a new interface, and charge it daily. What would it do that makes me want to actually buy one despite the limitations?  After living with my Apple Watch for a few weeks I think I finally know. The watch itself is the killer app.

I've been writing unix-ish code for more than two decades (crap, I'm old!) but last week I discovered something I'd never used before, the stdbuf command. It solves (well, works around) one of my longstanding problems working with command line programs: buffering.

Today I received my Apple Watch. Compared to the three Android Wear watches and a few fitness sensors, I can safely say it’s the first smart watch that merely sucks instead of being truly horrible. All of these devices will continue to get better and better, longer battery life, simplified UI, etc.  Soon we won’t know how we lived without them. But that’s not important right now. What’s important is when we look back in history we will say 2015 is the day we started to wire up humanity.

As part of my research at Nokia I often test and analyze products from other companies. This gives us an awareness of the state of the industry, and helps us to focus our efforts. This week my target was the Samsung Gear S smartwatch. As of yet I have been unable to actually test it. This is my story. And the story of why Samsung should be broken up into smaller companies that can actually make good products.

Smartwatches are coming. By Christmas they will be everywhere. And we won't know how we ever lived without them. Or so we are told to believe. But if you were a company making a smartwatch, how would you know what features to build? How would you know which features will fit the "something people didn't know they wanted" category? You have to predict the future. Turns out, that's hard.

Note: The first half of this post was written before the Apple Watch event and the second half after. I wanted to capture my thoughts before they were polluted by endless "reviewers" proclaiming the genius/delusion of Tim Cook. I almost didn’t want to write this because I knew my conclusion would be that you can’t review any technology this personal without using it for a while, and here I am reviewing a device I haven’t personally used. That said, I think this represents more of my thoughts on the category rather than Apple Watch in particular, a category that is going to bigger than we expect. So... here goes.

Among the too many things I’ve done recently, I was a tech reviewer for a new WebGL book from Packt author Jos Dirksen called the Three.js Cookbook.

I've done a major refactoring which will make Amino easier to install, easier to maintain and, eventually, better performance and portability. Part of this work involved moving the platform specific parts to their own node modules. This means you should no longer install aminogfx directly. Instead, install the appropriate platform specific module. Currently there is one for GL and one for Canvas. I've also added stage transparency support to Raspberry Pi!

In what was by far my most popular post of 2013, Why You Can’t Build A Smartphone, I explained why building a new smartphone platform was futile. Today, like any good author, I’m going completely contradict myself. Yes, it is possible to create a new smartphone platform. You just have to follow a few constraints.

In the first two (1, 2 ) installments of this essay I covered overall system design, the window manager, and applications. I talked about how the user will communicate with the system, but I haven’t discussed much about how the system communicates back to the user. This brings us to the next big problem of today’s operating systems: notifications and concentration.

In the future touch interfaces will take over most computing tasks but 10% of people will still need ‘full general purpose computers’. We can’t let the interface stagnate. This white paper represents a decade of my thinking on what is wrong with desktop style operating systems (WIMP) style and proposed solutions. PCs are not obsolete. They just need improvements to become ‘workstations’ again.

Note: Parts II and III are up now.

I’ve used a lot of cross platform desktop toolkits over the years. I’ve even built some when I worked on Swing and JavaFX at Sun, and I continue development of Amino, an OpenGL toolkit for JavaScript. I know far more about toolkits than I wish. You would think the hardest part of making a good toolkit is the graphics or the widgets or the API. Nope. It’s deployment. Client side Java failed because of deployment. How to actually get the code running on the end user’s computer 100% reliably, no matter what system they have. Deployment on desktop is hard. Perhaps some web technology can help.

The follow up to last year’s Beautiful Lego, Mike Doyle brings us back for more of the best Lego models from around the world. This time the theme is Dark. As the book explains it: “destructive objects, like warships and mecha, and dangerous and creepy animals… dark fantasies of dragons and zombies and spooks” I like the concept of a theme as it helps focus the book. The theme of Dark was stretched a bit to include banks and cigarettes, and vocaloids (mechanical japanese pop-stars), but it’s still 300+ gorgeous pages of the world’s best Lego art. Beautiful Lego 2 is filled to the brim with Zerg like insect hordes, a lot of Krakens, and some of the cutest mechs you’ve ever seen.

My hatred of C and C++ is world renown, or at least it should be. It's not that I hate the languages themselves, but the ancient build chain. A hack of compilers and #defines that have to be modified for every platform. Oh, and segfaults and memory leaks. The usual. Unfortunately, if you want to write fast graphics code you're pretty much going to be stuck with C or C++, and that's where Amino comes in.

A post about Arthur Whitney and kOS made the rounds a few days ago. It concerns a text editor Arthur made with four lines of K code, and a complete operating system he’s working on. These were all built in K, a vector oriented programming language derived from APL. This reminded me that I really need to look at APL after all of the language ranting I’ve done recently.