Josh On DesignArt, Design, and Usability for Software EngineersMon Jul 06 2015 00:20:21 GMT+0000 (UTC)\nWhy I Will Always Use A Speck Phone Case<div class="body blocktype_body"><span style="color: inherit;">Yesterday, amidst the Independence Day Fun, I lost my phone. &nbsp;Or rather, it flew away on the rear bumper of my mother in law’s car. &nbsp;</span></div><div class="body blocktype_body">Late last night -- after cleaning up the kitchen, saying goodbye to our guests, and finally getting Jesse to sleep -- I reflexively pulled out my phone to check my email, only to discover it missing. In an instant I knew what happened. &nbsp;&nbsp;</div><div class="body blocktype_body"><span style="color: inherit;">You see, I did something foolish. To safely enjoy the fireworks I bought at Costco, I corralled the kids to a lawn blanket, put on some music, and placed my phone on the raised bumper of the car in our driveway. &nbsp;After 30 minutes of pyrotechnic fun in the street, my mother in law and husband said goodbye and drove to their house on the other side of town. Amidst the chaos I forgot my phone still playing music on the bumper.&nbsp;</span></div><div class="body blocktype_body"><span style="color: inherit;">Upon discovering this revelation, Jen suggested I use the “Find my iPhone” to see if it’s still working. Given that my mother in law lives 15 minutes away, including 5 minutes on a freeway, &nbsp;the likelihood of it being smashed to tiny pieces by a semi were high.&nbsp;</span></div><div class="body blocktype_body"><span style="color: inherit;">I didn’t expect to receive a signal but Find my iPhone did indeed find it. It was on the side of the freeway four miles away. Last ping 30 seconds ago. &nbsp;It’s still running! Or at least the GPS. But for how much longer?</span></div><div class="body blocktype_body"><span style="color: inherit;">I threw on some clothes, drove to the spot, and discovered two cars already there. &nbsp;One, a truck driven by a man with a horse trailer from the near by rodeo, had broken an axel. &nbsp;The other car had his kids who came over to help. They were waiting for a tow truck to arrive. I introduced myself, asked if they needed help, then explained how an app had led me to them. “Did you happen to see a phone lying on the ground in the darkness?”.</span></div><div class="body blocktype_body"><span style="color: inherit;">The guy looked around with a flashlight and found my phone under the axel of his truck (not the one that was broken). &nbsp;I looked at it and pressed the home button. The screen came on and was completely undamaged. &nbsp;The Speck case that I have used continuously since I bought the phone (an iPhone 5S) was banged up but still intact. &nbsp;The phone itself had a scratch but I think that came from the keys in my pocket earlier in the week.</span></div><div class="body blocktype_body"><span style="color: inherit;">I’m impressed. It flew off of a car at 50+ mph and still works perfectly. I just ordered <a href=";cgidmaster=sptyp-st030#start=19&amp;sz=12">a new case</a>. I switched to blue plaid over grey, because it seems like a nice way to celebrate the impossible.</span></div><div class="body blocktype_body">Thank you Speck!</div><div class="body blocktype_body"><img src="/images/69312_IMG_3195.JPG"></div>\nIndependence from Old Code<div class="body blocktype_body">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. &nbsp;I’ve built several open source projects over the last year and it’s time to shut some of them down. &nbsp;Out with the old to make way for the new. Let’s review, shall we?</div><div class="body blocktype_header">Electron IDE</div><div class="body"><a href="">Electron</a> is the new Arduino IDE I started last summer. While the initial progress was good, I was never able to get to a 1.0 version due to conflicts between the serial port library and Atom Shell, the native packager I was using. &nbsp;The underlying problem is that all of the webkit packagers use custom versions of NodeJS which conflict with some native modules. &nbsp;In the end I was spending far too much time on packaging and not making any progress on building a usable tool. &nbsp;</div><div class="body">Then the world caught up. &nbsp;Arduino announced their new web-based IDE as well as updating their existing Java one with new extensibility features. &nbsp;I started to think that maybe no one needed Electron anymore. The final straw was when the Atom project renamed AtomShell to Electron. &nbsp;The time has come to shut it down.</div><div class="body blocktype_header">Amino</div><div class="body blocktype_body"><a href="">Amino</a> is a graphics API in Javascript backed by OpenGL ES native code. I still find it useful for prototyping on the desktop, but all of my work lately has been web-based or with headless Raspberry Pis. &nbsp;Code not used is code that doesn’t improve, so I’m putting it on hiatus for a while. I’ll start working on it more if I find I need it again. If you were using Amino for HTML canvas then I suggest using D3 or Paper.js.</div><div class="body blocktype_header">Photon Shell</div><div class="body blocktype_body"><a href="">Photon</a> is a simple command line shell written in pure Node JS as an exercise. I basically wrote it on a dare when I was frustrated with the current state of CLIs for Windows. &nbsp;It’s useful for learning but I wouldn’t use it as your main shell. I’m not going to do any more work on Photon.</div><div class="body blocktype_header">Leonardo Sketch</div><div class="body blocktype_body"><a href="">Leo Sketch</a> is officially dead. I haven’t worked on it in three years and it was built on a custom Java UI toolkit that I haven’t maintained. No one ever used it anyway, so it’s existence will not be missed.</div><div class="body blocktype_body"><b>Now on to some new stuff.</b></div><div class="body blocktype_header">AMX</div><div class="body blocktype_body"><a href="">AMX</a> is a new Node based tool I started. Much like PM2 and Forever it manages server processes. &nbsp;The difference between AMX and the others is its focus on ease of use. &nbsp;You can create a new process with "amx make my project", then start it with "amx start my project". &nbsp;Logging, stopping, and listing are done with similar simple commands. &nbsp;AMX also supports web-hooks for github projects, all with simple and straightforward config files. Most importantly, it does all of this without any extra dependencies. As in none. You should be able to run it on anything that has Node with a simple "npm install -g amx".</div><div class="body blocktype_body">AMX will remain simple, so I don’t plan to ever include plugins, scripting, or build systems. If you want those there are other options available. AMX will stay focused on simple executing processes on demand, and keeping them up.</div><div class="body blocktype_header">RazzMaster</div><div class="body blocktype_body"><a href="">RazzMaster</a> is another new tool I’ve built for my RaspberryPI work. Based on <a href="">Adafruit’s awesome PiFinder</a>, this commandline program will scan your network for available Raspberry Pis, then let you set them up with any defaults you need over SSH. It can even blink the Pi’s green LED so you will know you are really connected to the device you think you are. &nbsp;If you need to repeatedly set up a Pi (or multiple Pis) this tool will make your life a lot easier.</div><div class="body blocktype_body">RazzMaster will soon support wifi settings and changing the default password. Then possibly some prefab configs for common Raspberry Pi setups like media servers and web kiosks. Let me know what you’d like to see.</div><div class="body blocktype_header">Useful Node Streams</div><div class="body blocktype_body">You may have noticed that almost all of my work lately has been in NodeJS. &nbsp;Since I often create custom streams for common tasks, I decided to put them in a new repo creatively called <a href="">"useful-node-streams"</a>. &nbsp;It currently has object streams for logging, writing to newline delimited JSON files, a realtime stream of a twitter #hashtag, a stream to fetch your follower count periodically, and finally a websocket server stream that repeats anything sent to it over the wire to all connected websocket clients. &nbsp; &nbsp;</div><div class="body blocktype_body">If you have any streams that you use over and over please let me know and I’ll include it.</div><div class="body blocktype_header">PureImage</div><div class="body blocktype_body"><a href="">PureImage</a> is a 100% pure Javascript in-memory implementation of HTML Canvas for Node. It is woefully incomplete with only the ability to draw simple antialiased lines, shapes, and text and images. It is also extremely slow. And buggy.&nbsp;</div><div class="body blocktype_body">So why would you want to such a horrible piece of software? Because it has no native dependencies and will run on anything. It can read and write PNGs and JPGs without any native code as well (thanks to some other amazing open source node projects). &nbsp;It can even load and render text with custom truetype fonts.&nbsp;</div><div class="body blocktype_body">PureImage is useful for command line scripts on servers that don’t have X windows or that you can’t get the native Cairo libraries compiled on (which are surprisingly hard to compile, especially on limited hardware). &nbsp;You could also use PureImage for webserver apps when you want to do server side rendering, again without messing with native dependencies. If you can take the speed hit, then PureImage might be right for you.</div>\nFor I Have Met the Super-Men and They Are Us<div class="body blocktype_body">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 <i>quite</i> yet, when the good version comes out in a few years we will all become superheroes.</div><div class="body blocktype_body">Despite the individual product differences all wearables are about the same big idea: bringing the human nervous system closer and closer to computer processing. Virtual assistants such as Google Now, Siri, Cortana and whatever Amazon’s thing is called, constantly monitor both your digital and real world environments looking for patterns. In return they provide you, <i>the human</i>, with contextually relevant information. What you need when you need it. Virtually all of this can be delivered through cloud processing so the actual interface can shrink progressively from a phone to a watch and eventually smart glasses or a discrete earbud.</div><div class="body blocktype_body">Wearable sensor features, like sleep and heart tracking, are just extra data to be funneled into the cloud brain of your choosing (well, your phone vendor’s choosing). &nbsp;Haptic feedback completes the loop, bringing the processed information back to your physical body. &nbsp;After a few cranks of Moore’s Law the cloud and wearables become an integrated information sandwich, with humans as the tasty meat in the middle. &nbsp;What will we be like when this happens? What existing examples can we look at? I think the best place to look is an unexpected place: comic books.</div><div class="body blocktype_body">With the exception of Superman, &nbsp;every super hero is just a normal person given some extraordinary ability. For the X-Men it’s a mutant power. Spiderman can sense danger and stick to walls. Ironman has his flying suit. For Bruce Wayne it’s a gigantic bank account. A decade from now some people will live with computer enhancement computer enhancement. What will we call these people? Cyborgs or perhaps superheroes?</div><div class="body blocktype_body">Let me give you a few examples.</div><div class="body blocktype_body">With progressively cheap sensors and haptic feedback, anything that a computer can measure can be turned into an additional human sense. <a href="">This TED talk</a> shows a man who can feel live information through the skin on his back. In 2004 Udo Wachter <a href="">built a belt</a> that constantly vibrated in the direction of north. The wearers developed an intuitive sense of which direction. And that was ten years ago. Today this stuff is easy to build. Recently I made <span style="color: inherit;">a smart bracelet that vibrates whenever I point my hand north. Think about that! I could be dropped off in the woods and never get lost (until my batteries ran out) with a hand built&nbsp;prototype using&nbsp;less than $100 of mail ordered components.&nbsp;I built my own superpower.</span></div><div class="body blocktype_body">Imagine this taken to the next level. What if you could feel equations or hear radar? What if you could literally see the music around you.&nbsp; Take <a href="">the Daredevil</a>, for example. He is blind but can sense motion around him. This could be done in a crude form today with Kinect sensors and haptic feedback on your torso. You could literally feel an attacker approaching you. Spideysense!</div><div class="body blocktype_body">Tony Stark's Ironman suit is mostly possible. Even jetpack flying could be done under computer control today with modern sensors. The only unrealistic part is an intense power source that lasts longer than 30 seconds. We simply don’t have the energy density to make it work. Still, I hate the idea that superheroes are impossible due to lack of batteries so i’m sure we’ll figure it out in the next 20 years or so. Super capacitors or graphene sponges will probably do the trick, assuming we don’t get an arc reactor first.</div><div class="body blocktype_body">More interesting than the wearables themselves is the effect on humanity. <a href="">Bill Gates and Stephen Hawking</a> have expressed reservations about creating Artificial General Intelligence that would supersede or even exterminate humans.</div><div class="body blocktype_body">I think this is unlikely. Not because it couldn’t happen, but because of the huge social changes that will precede the AGI. We are far closer to building cybernetic super humans than an AI that could take over the world. One human with the right tools can be as productive as 20 unassisted men at almost anything. &nbsp;Massive unemployment is far more likely than Skynet.</div><div class="body blocktype_body">This really isn’t new, though. &nbsp;Man has always made new tools. From using an axe to touch typing our malleable neurological systems can easily make use of new things as if they were natural parts of our body. In a sense, all tools are natural. &nbsp;We have the innate ability to not only <i>design</i> new tools, but <i>integrate</i> them into our sense of self.</div><div class="body blocktype_body">Humans have always been driven to improve productivity through tools. Sensors and <a href="">haptics</a> will simply take this to the next level. &nbsp;A man with a sewing machine can out produce ten men sewing by hand. The tractor made food cheap. The modern kitchen gave us time savings. Facebook took it back again. Overall these are fundamentally <i>good</i> changes, even if they have bad effects of replacing human labor with technology. The challenge is always how to deal with these effects, not to try to avoid them.</div><div class="body blocktype_body">This is why I think the risk of an Artificial General Intelligence singularity are completely overblown. Not that it won’t happen, but that <a href="">The Singularity</a> (when the the future becomes impossible to see through the technological change event horizon) will happen <i>before</i> we get AGI. Rather the Singularity will come when cyborg tools make 99% of today’s labor redundant. We will either have to deal with a world of mass unemployment or quickly invent new things for most of us puny humans to do.</div><div class="body blocktype_body">When the change comes what will happen? A new world war? World peace? A complete generation of humans face tweeting into the Matrix. I don’t know, but no matter what happens it will be a global economic and social shift that is impossible to predict, transforming humanity into something new. &nbsp;Long before the AGI gets here we may already be gone, replaced by homo-cyberneticus.</div>\nThe Holy Grail: Pure CSS Scrolling Tables with Fixed Headers<div class="body blocktype_body">For a recent project I needed a nice HTML table library to render a long table of data with fixed headers.&nbsp;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.&nbsp;</div><div class="body blocktype_body">There are indeed many ways make fixed headers but every method has flaws. Some require all columns to be the same width. Some don’t handle horizontal scrolling when you have lots of columns. Some use Javascript to reposition the rows instead of native scrolling.&nbsp;</div><div class="body blocktype_body">The W3C has really let us down here. Fixed headers on tabular data would seem to be an extremely common use case. I don’t understand why this isn’t just built into HTML 5. &nbsp;</div><div class="body blocktype_body"><span style="color: inherit;">So... after much research I decided to build my own system. I’ve come up with what I think is the best possible way using modern CSS standards like flex-box while keeping the markup as semantic as possible. It uses 100% native scrolling, with only a few compromises and one significant flaw. &nbsp;I’m hoping one of my intrepid readers can come up with a solution. &nbsp;</span></div><div class="body blocktype_header">Separating the Header from the Body</div><div class="body blocktype_body"><span style="color: inherit;">Getting an element to scroll is easy: put it inside a container with overflow:scroll. Getting part of it to stay fixed is not. &nbsp;I tried many ways to isolate the top row of a table but none of them work reliably (overflow, position:relative, and others). Browsers just don’t seem to like splitting a table into pieces. So the first compromise is using two tables, one for the headers and one for the body.</span></div><div class="body blocktype_body">Splitting the table half also means auto layout won’t work.&nbsp;Auto layout is when the width of a table column is based on the contents of each cell of the column. Since the table header is separate from the body any autosizing on the body won’t affect the header and the columns won’t line up.&nbsp;I think auto-layout is a bad idea anyway due to speed and non-determinism issues, so I’m okay not supporting it. We can still have different widths for each column but we must explicitly set the widths using CSS or Javascript.</div><div class="body blocktype_body">For my initial attempt I made just the body scroll and put the header above it. Using flexbox I could give the header it’s minimum required space and allocate the rest to the body. &nbsp;This is better than older solutions that give the body a fixed percentage like 90% since that will vary based on the page size. &nbsp;This solution will work, but only if the table isn’t too wide. &nbsp;If there are more columns than will fit on the page the header and body will scroll horizontally, but separately. You’ll scroll the body left and the header will stay put. &nbsp;Hmm. The opposite of progress.</div><div class="body blocktype_header">Nested Scrollpanes</div><div class="body">Then I hit on an idea: &nbsp;the header and body will stay together horizontally as long as they don’t overflow. If I put them inside a div exactly wide enough to fit them, then make that outer div scroll then it will do the right thing. the trick is getting one div to scroll only horizontally and the other to scroll only vertically. &nbsp;This is hard to explain verbally so let’s look at some markup.&nbsp;</div><div class="body blocktype_codeblock">&lt;div&nbsp;id="constrainer"&gt; <span style="color: inherit;">&nbsp; &nbsp; &lt;div&nbsp;class="scrolltable"&gt; </span><span style="color: inherit; background-color: rgb(255, 255, 204);"> &lt;table class'header'&gt;&lt;thead&gt;&lt;th&gt;foo&lt;/th&gt;&lt;th&gt;foo&lt;/th&gt;&lt;th&gt;foo&lt;/th&gt;&lt;/thead&gt;&lt;/table&gt; </span><span style="color: inherit;">&nbsp; &nbsp; &lt;div&nbsp;class="body"&gt; </span>&nbsp; &nbsp; &nbsp; &nbsp; &lt;table&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;tbody&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;tr&gt;&lt;td&gt;foo&lt;/td&gt;&lt;td&gt;foo&lt;/td&gt;&lt;td&gt;foo&lt;/td&gt;&lt;td&gt;foo&lt;/td&gt;&lt;/tr&gt; … close all the tags</div><div class="body">There is a container called <i>scrolltable</i> which contains a table called <i>header</i> with only a single row. <i>scrolltable</i> has a second child, a div called <i>body</i>, which contains the data table. &nbsp;It’s reasonably semantic and not too many extra divs.The whole thing is wrapped in another div called <i>constrainer</i>, which exists only to constrain this demo a fixed height and width. &nbsp;Constrainer is styled with:</div><div class="body blocktype_codeblock">#constrainer&nbsp;{ <span style="color: inherit;">&nbsp; &nbsp; height:&nbsp;200px; &nbsp; &nbsp; width:&nbsp;200px; }</span></div><div class="body">We want <i>scrolltable</i> to scroll only horizontally, so we can do that by setting the <i>height</i> to 100% and <i>overflow-x</i> to scroll.</div><div class="body blocktype_codeblock">.scrolltable&nbsp;{ <span style="color: inherit;"> overflow-x:&nbsp;scroll; height:&nbsp;100%; }</span></div><div class="body">We want the body to be exactly wide enough for it’s content and only scroll vertically. &nbsp;This requires the magic <i>-webkit-fit-content</i> width value, then setting <i>overflow-y</i> to scroll.</div><div class="body blocktype_codeblock">.scrolltable&nbsp;&gt;&nbsp;.body&nbsp;{ <span style="color: inherit;"> width:&nbsp;-webkit-fit-content; &nbsp; &nbsp; overflow-y:&nbsp;scroll; }</span></div><div class="body">I want the header to use it’s normal height and give the rest of the vertical space to the body. This sort of space allocation is perfect for flex-box.&nbsp;</div><div class="body blocktype_codeblock">.scrolltable&nbsp;{ <span style="color: inherit;"> display:&nbsp;flex; display:&nbsp;-webkit-flex; &nbsp; &nbsp;flex-direction:&nbsp;column; &nbsp; &nbsp;-webkit-flex-direction:&nbsp;column; } </span>.scrolltable&nbsp;&gt;&nbsp;.header&nbsp;{ <span style="color: inherit;">} .scrolltable&nbsp;&gt;&nbsp;.body&nbsp;{ &nbsp; flex:&nbsp;1; &nbsp; -webkit-flex:&nbsp;1; }</span></div><div class="body">We don't have to set anything on the header since the default flex value is 0.</div><div class="body">There’s only one thing left, to give the columns explicit widths.</div><div class="body blocktype_codeblock">th,&nbsp;td&nbsp;{ <span style="color: inherit;">&nbsp; min-width:&nbsp;150px; } </span></div><div class="body blocktype_body"><br></div><div class="body blocktype_header">Live Demo</div><div class="body">Here’s what it looks like. I’ve added some visual styling to make the rows and columns prettier but these extra rules don’t affect the scrolling mechanism.</div><div class="body"><img src="/images/69761_SafariScreenSnapz059.png"></div><div class="body"><a href="">click for live demo</a></div><div class="body">Overall I’m pretty happy with it. There’s only two significant flaws: the use of a magic <i>-webkit-fit-content</i> property and the vertical scrollbar is missing. Actually, the scrollbar is there but it’s inside of the outer scrollpane so you don’t see it unless you’ve scrolled all the way the right most column. &nbsp;However, given that everyone is moving to gesture based scrolling, I think it’s a reasonable tradeoff. &nbsp;This system could be adapted to have fixed headers on the left edge instead of the top, but I can’t see a way to have both edges fixed. The W3C really should solve this properly.</div><div class="body">I've put the code on <a href="">github</a>. Please fork it and play around. Suggestions and improvements would be greatly appreciated.</div><div class="body blocktype_header">Update</div><div class="body">My friend Cooper showed me a slightly different formulation that has less boilerplate: just one div around a single table and no magic webkit properties. The downside is you have to set the width on the wrapper DIV and height on the TBODY. That's not a bad tradeoff for using only standard css rules. I've added his version to the repo too.</div>\nApple is not making a TV<div class="body blocktype_body">A year ago <a href="">I speculated </a>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. &nbsp;</div><div class="body blocktype_body">Today The Wall Street Journal is <a href="">reporting (verge link)</a> that "Apple dropped plans to release a 4K TV over a year ago because it couldn't find compelling ways to differentiate the product.. Apple reportedly considered including a FaceTime video chat features that could direct cameras to the speaker at any given moment".</div><div class="body blocktype_body"><b>Nailed it!</b></div>\nApple Watch doesn’t need a killer app. It *is* the killer app.<div class="body">As smartwatches have slowly faded into existence from their sci-fi past, I have always wondered: <i>what is the killer app</i>? What is the feature (or actual app) that would do something <i>so useful</i> 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? &nbsp;After living with my Apple Watch for a few weeks I think I finally know. <b>The watch itself</b> is the killer app.</div><div class="body blocktype_header">The Killer App</div><div class="body">We expect platforms to have a killer app to launch them. A smartphone has tons of uses, but when Apple launched the iPhone they focused on email, iPod (playing music), phone calls, and a mobile Safari. &nbsp;Given that iPods and hand held devices that made phone calls already existed we could probably shorten this to say: &nbsp;the iPhone gives you the full Internet in your pocket. And it really did. From that base the world’s developers created many amazing things. Facebook wasn’t useful to me until I could upload a photo anytime, anywhere; but it all started with the internet in your pocket.</div><div class="body">It would be logical to assume the Apple Watch has a killer app. The iPod was the a thousand songs in your pocket. The iPhone was the internet in your pocket. The Mac was a computer that just works. What is the Apple Watch? &nbsp;At first I thought it would be notifications, which is the only thing the Apple Watch does really well right now (assuming you use an iPhone). But now I think I’ve got it wrong.</div><div class="body"><b>The Apple Watch isn’t a computer that sits on my wrist. The Apple Watch is a watch that also happens to be a computer. &nbsp;That’s a huge mental shift.</b></div><div class="body">The killer app isn’t any one feature or app. It’s that Watch is on my wrist. Always. Every day. It’s the proximity to my body -- and to my nervous system thanks to the haptic feedback -- that makes all the difference. &nbsp;A notification on my phone lock screen would seem to be the same as a notification on my wrist... but it’s not. The wrist is different. More immediate. More discreet (I always have mine set to mute). More personal.</div><div class="body blocktype_header">Daily life</div><div class="body">As always, the real test of a device is whether I use it. Have my daily habits changed? &nbsp;I think they have. &nbsp;I use the timer and alarms a lot more than I did before. When you have to wrangle a four year old kid timers really help. Having them on my wrist, and being able to set them with a voice command, makes a huge difference. Sure, I’ve been able to do that for years with my phone, but being on the wrist makes a contextual difference.</div><div class="body">After some tweaking I’ve found the notifications to be useful. Responding to my wife’s text while driving. General awareness of a Slack channel. I love going to the park with my son without having the feeling of missing something, but also without feeling like I’m always in my phone. Again, placement on the wrist is the important thing. &nbsp;Filtering the notifications is still a challenge. It will take a while before we can filter messages the way we can with spam, so I expect to see improvement from Apple on that front over time.</div><div class="body">I was surprised to find that none of the 3rd party apps have made much of a difference. I’ve searched and found nothing indispensable. The keepers, for me, have been Slack (company chat) and Things (todo list); but in both cases they are the same content as my phone, just closer. Proximity is once again the killer app.</div><div class="body blocktype_header">Should you buy an Apple Watch?</div><div class="body">So should you buy one? &nbsp;No. &nbsp;Not yet.&nbsp;</div><div class="body">I’ve spent the last few months testing lots of smart watches. Apple Watch is a definite one oh (1.0) product. It's slow and limited. As is the Zen Watch, LG Watch R, Microsoft Band, and basically everything else on the market. &nbsp;All smartwatches will get tremendously better in the next year or two.&nbsp;</div><div class="body">However, if you <i>really</i> feel compelled to buy something, then yes: buy an Apple Watch if you have an iPhone. Or a high-end Android Wear watch if you have an Android phone. But please, for the love of all things good and decent, <a href="">don’t buy a Samsung product</a>; especially the train wreck that is Tizen.</div><div class="body"><br></div>\nUnbuffering the Buffered<div class="body">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 <a href="">stdbuf</a> command. It solves (well, works around) one of my longstanding problems working with command line programs: buffering.</div><div class="body">How many times have you been working on some code where you need to invoke a command line program. It seems so easy. You just exec the command, back-tick or spawn or whatever exec equivalent your programming language has. The result is captured back into a string that you then parse. Easy peasy.</div><div class="body">Now suppose you need to invoke a long running command line program. Perhaps it's downloading a file or you want to monitor all the processes with 'ps'. Whatever it is, you want results back from the program before it finishes. You want the output as it's generated. This seems like it would be simple. If you run it from the command line the output is incremental, often one line at a time. Now call it from your program.&nbsp;</div><div class="body">Nothing. &nbsp;</div><div class="body">No output comes into your code. Wait a few minutes. Oh there it is. The input comes in a giant chunk instead of one line at a time. What happened? Welcome to Unix.</div><div class="body blocktype_header">Everything is a file, except when it's not.</div><div>Unix' philosophy of everything is great as far as it goes, but it's actually a lie. There are many thing in unix which appear to be files but are not. Sure, you can open them like files, but they actually produce data on their own timetable. They might queue up all data until the program ends, then spit it out at once. Or they might send data in 4k chunks. However, when you run these programs interactively everything is realtime. What gives? The answer is that the standard input / output files actually have extra features to determine if the other end is 'interactive' or not. Let's dive a bit deeper.</div><div><br></div><div>When you are on the command line or terminal you are actually running what's called a pseudo-terminal. <a href="">According to Wikipedia</a> these date back at least to the late 1960s. They process control characters which move the cursor around, setting colors, resizing the screen, and other interactive things. When you run a program it receives data on the stdin (standard input) stream. If you run the program interactively then stdin comes from the shell. If you run it as part of a pipeline, or from within another program, the stdin comes from a file or some other input source.&nbsp;</div><div><br></div><div>Given that stdin could come from anywhere, how does a program know to use these interactive control characters? It turns out there are APIs to determine if the input to a program is actually an interactive terminal or really just a stream of bytes. This is how a program like Vim can be interactive through what is supposedly a file. And this is why the same program will behave differently depending on how you call it. This is why exec'ing a program from your code gives you unexpected behavior. The program is switching from interactive to streaming mode. &nbsp;</div><div><br></div><div>In Unix terminology, the output switches from unbuffered to buffered. The buffers have a default size, often 4Kb (depending on your operating system). That's why you get no output for a while then suddenly get a bunch. The buffer is only flushed when you hit 4096 bytes of data.</div><div class="blocktype_header">So what can you do about it?</div><div>In the past I've used a couple of solutions. Some programs have explicit options to turn off the buffering. This might be called <i>interactive mode</i>. Other times I can find a different way to get the data. A last resort option is to trick the program. In Node I can use the <a href="">pty</a> module to essentially create a pretend pseudo terminal (a <i>pseudo</i>-pseudo-terminal?) which then runs the app for me. It's inefficient but it gets the job done.</div><div><br></div><div>However, I've discovered a brand new solution. Or rather, a brand old one. The <i><a href="">stdbuf</a></i> command has been a part of the standard GNU utils for decades. According to the docs it will "allow one to modify the buffering operations of the three standard I/O streams associated with a program." Perfect. Just what we want. </div><div><br></div><div>It works like this. Call <i>stdbuf</i> with options to change buffering, followed by the original command you wanted to run. To disable buffering on the input stream use <i>-i 0</i>. Use <i>-o</i> for the output stream. In my case I wanted to run bluetooth scanner with buffering disabled on all of the input, output, and error streams. Here's the code in NodeJS</div><div><br></div><div class="blocktype_codeblock"><span style="color: rgb(167, 29, 93);">var</span> scanner <span style="color: rgb(167, 29, 93);">=</span> child_process.spawn( <span style="color: rgb(24, 54, 145);"> "stdbuf"</span>, //the stdbuf command [ <span style="color: rgb(24, 54, 145);"> '-i0'</span>,<span style="color: rgb(24, 54, 145);">'-o0'</span>,<span style="color: rgb(24, 54, 145);">'-e0'</span>, //disable all buffering <span style="color: rgb(24, 54, 145);"> '/usr/bin/hcitool'</span>,<span style="color: rgb(24, 54, 145);">'lescan'</span>,<span style="color: rgb(24, 54, 145);">'--duplicates' </span>//the real program I want to run ]);</div><div><br></div><div>And that's it! How does it work? Magic probably. According to <a href="">this</a> it's a LD_PRELOAD hack, which is basically magic. So there you go. </div><div><br></div><div>How have I not heard of this magic program before?!</div><div><br></div><div><br></div><div><br></div><div><br></div>\nThe Wiring of Humanity<div class="body">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&nbsp;instead of being truly horrible. All of these devices will continue to get better and better, longer battery life, simplified UI, etc. &nbsp;Soon we won’t know how we lived without them.&nbsp;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.</div><div class="body">Try to imagine the world one hundred years from now. It’s really hard. &nbsp;Predicting even 20 years in the future is a crap shoot. &nbsp;In a hundred years we’ll have cheap space flight and cheap power. Unlimited food and objects thanks to advanced bio-farming and 3d printers. Day to day living has been&nbsp;rewired around the self driving car. We finally cleaned up the atmosphere and started bringing some extinct species back to life. The average person&nbsp;is effectively&nbsp;infinitely wealthy by today’s standards. In short, minus the warp drive, we live in Star Trek.</div><div class="body">It’s an idillic vision. While I have undoubtedly gotten details and timelines wrong (self driving cars are coming much sooner that I expected), I think the core is correct. Pretty much any physical problem has been solved or is at least solvable. That doesn’t mean we have world peace, however. &nbsp;People are&nbsp;still people&nbsp;so people&nbsp;problems will remain. &nbsp;Unless something else changes.</div><div class="body">The&nbsp;smart watch is the first computer that is on you 24/7, or at least the waking part of your life (why don’t we have&nbsp;body heat&nbsp;charging yet?). This is powerful. Eventually the devices will disappear into an earbud or an implant. Humans will be connected to the global network and each other in a far more intimate way than ever&nbsp;possible.</div><div class="body">Today I can know my wife’s location at any time, and she can know mine. &nbsp;I can instantly take photos of my son&nbsp;doing something cute&nbsp;and share them with my mother 2500 miles away. Instantly. For free (marginal cost, anyway). I can tweet my immediate thoughts to anyone who cares to know them, instantly, for free. &nbsp;Smartphones and Twitter didn’t exist a decade ago. Now imagine a hundred more years of progress.&nbsp; </div><div class="body">I know. You can’t.&nbsp;It’s fairly impossible to imagine life after being connected to the cloud brain for a century. But one thing is for sure. Anyone will be able to know what anyone else is&nbsp;doing or thinking at any time, if they simply choose to. &nbsp;This is a fundamental change in humanity. We all become wired together. &nbsp;We become, in essence, a planet of telepaths.</div><div class="body">Does this blown your mind? It certainly blows mine. &nbsp;I don’t know what the future holds but the potential&nbsp;is literally mind boggling. Will we be&nbsp;happy telepaths like the Betazeds? Will we hate&nbsp;each other and long for isolation? What social norms must we develop to protect our sanity? How will we balance physical relationships with the virtual ones? Perhaps all travel will end as we experience everyone and everything remotely&nbsp;and instantly.</div><div class="body">I only know one thing. It’s going to be a helluva a ride.</div>\nSamsung Should be Broken Up, I Have the Evidence<div class="body">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.</div><div class="body">When my Gear S arrived I immediately noticed the classy two part box, very much like the boxes my traditional watches come in (I refuse to call them <i>dumb watches</i>). My high hopes were about to be dashed. While I knew the watch would require pairing to a phone before being usable, I assumed it would work with any Android phone. After all, why restrict your market, right? I was wrong.</div><div class="body">A quick search on the web turns up that the Gear S, uses Tizen, not Android Wear. For some reason all of Samsung's Tizen watches only work with Samsung devices. The watches require a minimum OS version and also the Samsung Gear Manager app. This app is only available through Samsung's own app store, not the regular one, and it refused to install on my Moto X. </div><div class="body">Okay fine. Samsung wants you to use their watch with one of their devices. I think it's foolish to restrict your market, but I'll live with it. So I go to Costco to pick up a new Samsung tablet. In this case, the 8 inch Tab 4 (not to be called the Tab 4 8, which would make no sense). I forget if the tablet had Galaxy in the name.</div><div class="body">After charging and boot the tablet I ran all of the software updates. Hmm. No Lollipop. Why is a brand new device not receiving the latest OS? No matter, the Gear Manager app works on KitKat. I dutifully go to Samsung's ugly app store and install the manager. Turn on the watch to pair, and.... nothing. The tablet can't find it. After messing with settings, checking bluetooth, etc. I waste 30 minutes and still Samsung's own app can't see the watch. Getting a bit frustrated here.</div><div class="body">After some Googling I scan for the watch from regular Bluetooth settings. It sees the watch! Finally some progress. Select it. And... it takes me right back to the manager app that couldn't find it a second ago. Except this time it says that the watch isn't supported on my device or requires a software update. It doesn't tell me if a software update is available, or what version I would need. And of course, it didn't give me this message when I first scanned, thus wasting my time.</div><div class="body"><b>What devices actually work?</b></div><div class="body">Now it's time to answer the question. What devices are actually supported by the Samsung Gear S? Search around for it. I dare you. You won't find the answer from Samsung. Let me help you. Here's Samsung's <a href="">support page for the Gear S</a>.</div><div class="body">In their own words: <i style="color: inherit;">Samsung Gear S™ is currently compatible with Samsung devices that meet the following criteria: </i><span style="color: inherit;"><i>Android™ version 4.3 (Jelly Bean) or higher, WVGA or higher screen resolution, and 1.5GB or higher memory.</i> My Tab 4 8 certainly meets those requirements, though I have no idea why a watch manager app needs a <i><b>gig and a half</b>&nbsp;</i>of memory to run, but still, it should work. </span></div><div class="body">Further search reveals a list of Samsung phones on AT&amp;T's site which support the Gear S, but of course they only list the phones that AT&amp;T sells. The same for T-Mobile and other carriers. Why can't I just get a full list of compatible devices from Samsung?</div><div class="body">I finally get the answer from an <a href=";ASIN=B00PMABICC&amp;nodeID=2335752011&amp;store=wireless">Amazon review</a>. Apparently the Gear S only works with <i>specific</i> Samsung phones. Not any of Samsung's tablets. Not any one else's phones. Not even all Samsung phones. Just specific ones that no one has a complete list of. The bottom of the Gear S support page even says: "<i>Some Samsung Health/Fitness applications and related services available for Samsung wearable devices may not be compatible with Samsung tablet devices"</i>, which implies that the rest of the tablet experience would be fine. That is clearly not the case.</div><div class="body">Today I returned the Galaxy Tab48 to Costco and ordered a Samsung Galaxy S5 from Amazon. Not an Active or Alpha or Mega because who knows if the same phone in a different body would work. Just a plain S5. Hopefully my color choice won't affect the compatibility rating.</div><div class="body">This is a truly horrible experience for the customer. I'm literally being paid to use it and I already hate it. I would never recommend anyone get a Samsung wearable.</div><div class="body"><b>Too Many Devices</b></div><div class="body">Samsung products have become confusing. Look at their lineup. Can you tell me which one to buy? Why do they have both a 7" and 8" Tab 4? At least call it the Tab 4 + so that you don't confuse the numbers. Their phones are worse. What's the difference between an S5, Alpha, Mega, and Active? They look roughly the same but with wildly different prices and support. Is the Note a tablet sized phone or a phone sized tablet? I didn't know without looking up the specs (apparently it's a huge ass phone with a stylus).</div><div class="body">Once you get a device from them the OS updates are spotty. Why do some devices receive updates and not others? Why does a brand new device run an old OS, with no timeline for an update? Why does their manager app refuse to run on a device which meets it's own <i>documented</i> specs? &nbsp;</div><div class="body">And why can't a tablet work with a smartwatch anyway? It has bluetooth and wifi. It has the horsepower and hardware. There is no technical reason why this shouldn't work. Did they intentionally exclude tablets or were they too lazy to certify the devices from other branch of the company?</div><div class="body"><b>So how did this happen?</b></div><div class="body">It's worth stepping back to ask the question: h<span style="color: inherit;">ow did Samsung get like this? How does one of the biggest companies in the world fail so badly at making good products? This isn't just the product itself that failed, but the advertising and documentation and marketing around the product, and the massive over-abundance of product <i>choices</i>. I think I know the answer.</span></div><div class="body"><span style="color: inherit;">Samsung’s mobile division&nbsp;is a huge&nbsp;company in it’s own right.&nbsp; They make a lot of products, many in overlapping categories. Samsung wants to over-saturate every possible part of the market. They want to use all of the new components coming out of the rest of Samsung. They also have a lot of people to employ, so they have them make what are essentially duplicated products. These products don't exist because of market demand. <i>They exist because Samsung needs them to exist</i>.</span><span style="color: inherit; font-size: 26px;">&nbsp;</span></div><div class="body"><span style="color: inherit;">I suspect that Samsung, like many big tech companies, is full of silos. These are product groups who don't talk to each other. They may even compete with each other.&nbsp;The silos focus only on what’s next, never on where they are now (thank you Yoda). &nbsp;Once a device leaves the factory they don’t want to ever think about it again. They don’t wan’t to update its software. They don’t want to confirm whether it will work with anything newer. &nbsp;They don’t want to certify it with a product from another silo unless forced to by upper management. </span></div><div class="body"><span style="color: inherit;">The problem is that when you forget about the device you are also forgetting about your customer. &nbsp;I've been burned. I will never buy another Samsung device again. They simply didn't care enough to </span><i style="color: inherit;">correctly</i><span style="color: inherit;"> document basic requirements. Was it the phone group's responsibility to document the compatibility list or the watch group? How do I know my next phone won’t work with my current Gear watch? Perhaps the watch group will have moved on to the new watch and the phone group to the new phone, and I'm left without an update.&nbsp; The customer experience, which goes beyond the time of purchase, should always be first. </span>It seems that what comes first at Samsung is p<span style="color: inherit;">umping out new devices.</span></div><div class="body"><b>Nuke it from orbit. It's the only way to be sure.</b></div><div class="body"><span style="color: inherit;">The only way this can be fixed is by making Samsung smaller; by taking away the conflicts of interest and silos.&nbsp;</span></div><div class="body"><span style="color: inherit;">Samsung should spin out the mobile and gear divisions into their own companies.The Gear division would make watches that work with everyone's phones and tablets. They would finally have an incentive to do so because they could sell more watches. No longer would&nbsp;they be held back by a <a href="">strategy tax</a>.</span></div><div class="body"><span style="color: inherit;">The mobile division could then make fewer but better phones that people actually want to buy with less overlap. They would no longer have to pump out every variation just to use up components from Samsung's semi-conductor division Samsung should be broken up.&nbsp;&nbsp;</span></div><div class="body"><span style="color: inherit;">Of course they won’t do that. Instead they will amble along making a lot of revenue and very little profit, pushing out the latest specs in crappy products with unhappy customers. Customers who will abandon Samsung when given the choice.&nbsp;</span></div><div class="body"><span style="color: inherit;"><b>Samsung: too big&nbsp;to fail, too big to succeed.</b></span></div>\nPredicting the future is hard<div class="body">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.</div><div class="body">I'm doing a lot of wearables research right now for work. It got me thinking. How do successful companies like Apple make things that people didn't know they wanted? Certainly they take risks, and occasionally the risk fails (iPod HiFi, anyone), but most of the time they nail it. How do you do this?&nbsp;How do you predict what features will make someone want to use a device. How did Apple know that people wanted&nbsp;iPods before iPods were on the market. How do we know that people will want to move notifications from their phone to their watch, and that this is valuable enough to justify a multi-hundred dollar device.</div><div class="body">The first strategy is to build a feature that is obvious and simply do a really good job of it. Lots of companies are trying this. Fitness tracking and notifications are two obvious features. This is why s<span style="color: inherit;">mart watch coverage focuses on those features. They&nbsp;are known problems that we can already solve (though perhaps not solve well, yet). These features are also valuable enough that there are also standalone devices which do just one or the other of these things.&nbsp;</span></div><div class="body">But this doesn’t answer the question of what will be the other killer features. Fitness bands are fixed function devices that will only ever do one thing well. Apple Watch and Android Wear are app platforms. They are built to expand and grow over time. The only reason to build such as system is for future features that we can't predict yet? What will be the killer apps? How do we predict the future?</div><div class="body">The answer is we can’t. &nbsp;Before these things are built we simply can’t know what will be good and useful, or bad and useless. We can make some educated guesses based on what are known problems, or existing solutions that we hope to replace, but until we <i>actually</i> build&nbsp;it we never really know.&nbsp;</div><div class="body">So&nbsp;build it we must. &nbsp;I’m pretty sure this is what Apple does. They prototype things internally. Lots of things. Crazy things that will probably never ship. (Just look at some of their insane patents). Apple knows that only 1 out of 10 will be a good product idea, but they don’t know which one of the ten until they try them all. &nbsp;You’ve just got to build it.</div><div class="body">So, we have to build it. I don’t know what will be the killer apps in a few years that justify the wide spread adoption of smart watches. The only way to know is to build it.</div><div class="body">Alan Kay famously said in 1971: "<i>The best way to predict the future is to invent it.</i>" He's still right<span style="color: rgb(37, 37, 37);"><span style="font-size: 14px;">.</span></span></div><div><br></div>