'Web' applications and the circle of life.

2017-01-20 • James Mason

Web technologies are a funny thing.  There's no doubt that web applications have improved far beyond what was imagined in the early days of the web... everything is more performant, more interactive, and designs are more immersive. JS engines have gotten faster, HTML specifications have embraced more resources, including local integration, and CSS has grown to allow rich, robust styling. We continue to push the envelope with technologies that will serve the web faster, like HTML 2 and websockets. Web development has become a huge field. The combination of fast moving technology, developed by a growing workforce has, inevitably, allowed "web" technologies to migrate into other areas: node.js runs many server-side applications; the gnome desktop relies heavily on CSS and JS for implementing basic UI elements; HTML documentation pervades.

It's natural, then, that user-facing applications would escape the browser frame. In multiple different iterations now, "web applications" have become just "applications" on the desktop or mobile platform. Somehow, though, they're never 'good enough' for general adoption by both the consumer and developer communities: adoption rises and falls like waves on the sea, each wave a new round of applications driven by advances in web technologies, only to be eclipsed by 'native' (C++, CLR/.net, Objective-C, GTK/Qt) applications, over and over. Why? And when will web applications truly be 'good enough'?

I noticed, as I installed yet-another Electron app, that I'm sitting at the top of another wave, while simultaneously, a prior wave of web applications is being eclipsed, and it made me reflect on just how many times we've been through this.

In 2007, Apple released the iPhone, with the expectation that developers would use mobile Safari to build apps, for which 'installation' meant, mostly, adding a shortcut on the phone. Steve Jobs has been quoted[1]:

The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.
And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.

The App Store is largely viewed as a response to early jailbreakers, and complaints from a developer community that did not want to embrace web technologies, and since, the volume of (native) apps in the App Store has been a regular measure of the success of the platform.

In 2012, Mozilla once again brought web-based applications to the forefront, launching FirefoxOS which was described as "powered completely by Web technologies and offer everything you expect from a smartphone"[2]. In 2016, Mozilla demoted the project, although this is typically associated with the lackluster sales, and continuous stream of negative reviews, as Mozilla pushed toward their ultra-low price point goal of a $25 smartphone.

Google has found much more success with ChromeOS, and the broad market of Chromebooks available with the lightweight, web-centric OS. While early announcements appeared in 2009, the first hardware didn't ship until mid 2011, the CR-48 from Google. ChromeOS may have had a slow start, but it quickly picked up steam, and hasn't slowed, despite having, basically, one native app: the Chrome web browser. Chrome apps, which run on both desktop Chrome and ChromeOS, "let you use HTML5, CSS, and JavaScript to deliver an experience comparable to a native application."[3].

Despite accelerating sales of Chromebooks[4][5], fed by their low price points, security improvements based largely on their small footprint and native image delivery systems, and their ease of administration, Google still felt pressure to bring 'native' apps to ChromeOS. This is, ironically, a complete inversion of the native application. With Chrome as the foundation, and the Android marketplace chosen as the source for a larger application pool, we've seen an evolving series of Android emulation layers be bolted onto Chrome... while this does pave the way for the larger pool of Android apps to run on Chromebooks, Chrome remains the native environment here, and Android apps will, for the near term at least, be burdened by the performance losses inherent in any emulation layer.

The newest wave of Chromebooks feature much beefier specs than their web-centric predecessors, driving up price points from the $200 range on average to the $500 range[6][7], largely in support of Android apps, but also to meet the needs of power users who like the basic design principles of an OS with a smaller attack surface, simplified maintenance, and easy access to developer tools, over increasingly expensive Macbooks[8] or Windows machines whose resources are ever-more consumed by the OS itself[9].

And yet, simultaneously, web applications are rising again. Github's Electron[10] project paves the way for desktop applications based on chromium (the open source upstream of Google Chrome) and Node.js, with tooling and instructions around packaging for Windows, MacOS, and Linux (!!!). Electron grew out of the Atom project[11], an effort to provide an open-source, extensible code editor based on web technologies. (Full disclosure... Atom is my IDE of choice... for now.) Electron, serendipitously, released in the midst of a wave of next-generation communication tools, and has found it's killer app in providing an easy way for Slack[12], rocket.chat[13], Riot[14], Wire[15] and Discord[16] to easily move their web-based applications to the desktop. Today, I installed yet-another Electron app just recently: Simplenote[17], an open-source tool for jotting quick notes and syncing them _everywhere_. I stepped back and realized that nearly all the new apps I'm trying, and most of the apps I'm using, are web-based. Either packaged Electron apps like Atom and rocket.chat, or Chrome apps/frames like Trello[18], Signal[19], and Autodesk's TinkerCAD[20]. And the native apps on my desktop? Web browsers mostly (both Chrome and Firefox), along with a couple of 'legacy' apps: Pidgin for old-school chat, and Evolution, for connection to my work mail.

So, where are you in the lifecycle of web applications? Riding the crest of Electron apps, or waiting for that shiny new Chromebook that lets you run emulated Android apps? Or, do you live in iOS or Android, and just can't even tell (or care) what technologies are underneath the hood of your apps? Are you surprised to find more web technology on your desktop than you expected? I'd love to hear!


[1] https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-iphone-no-third-party-native-apps/
[2] https://blog.mozilla.org/blog/2013/07/01/mozilla-and-partners-prepare-to-launch-first-firefox-os-smartphones/

Pumpkin Art

2016-11-02 • James Mason

One of the oddities of holidays is how language changes context. Aside from the week before Halloween, imagine the rarity of the question "what are you carving on your pumpkin?"

Having heard this question a fair number of times last week, I reflected on some of my own pumpkin art, and wanted to share.
 

Impossible problems, simple solutions

2016-11-01 • James Mason

Everyday we confront problems with no viable solution. Sometimes we simply accept them; sometimes we struggle against them for years. Some are critical, but most are simple annoyances; to the careful negative observer: subtle, regular signs of failure.

For example, let me share a ridiculous lifelong struggle: microwaving a frozen burrito. This, it turns out, is an impossible problem. Sure, any idiot can throw a burrito in the microwave for a couple minutes, and have something edible, but it won't be good. The center might still be cold, or the tortilla may be hard as a rock. The filling may boil out, and most likely, the wrap will be soggy on at least one side. In short, there is nothing you can do to make a frozen burrito come out of a microwave well cooked. I should know; I've tried every possible thing. I've cooked it fast, and slow, and slow then fast. I've cooked it on a wet towel, under plastic wrap, on a special microwave cooking plate. It's impossible.

If this were code, the solution would be clear: deconstruct the problem. Break it up into smaller problems, and with enough iterations and subdivisions, eventually you're not even solving smaller problems, but just following the obvious, simple course from problem to solution. On the rare occasion that doesn't work, change the scope: go back to the original premise... you're likely to find you've made an incorrect assumption. Even for software developers trained in this mindset though, applying this technique to everyday problems isn't obvious. If it was, there wouldn't be frozen burritos.

I'm writing this for a couple reasons: aside from the obvious advice, reminding developers that the tools we have for coding apply in real life as well, I'm also marking a turning point for this blog... which has long been an impossible problem for me. As much as I've wanted to fill it with good content centered around open-source technologies, I'm rarely able to find a subject that isn't better covered elsewhere. I want to blog more. I've been asked to blog more, but always the subjects elude me. It turns out the simple solution was a problem of scope: like this post, the things I want to share, that aren't said enough, simply aren't related to open-source. So, starting with this post, I'm solving the problem... by changing the scope. From here on in, I'm writing about whatever I want, whatever I feel needs to be said, shared, repeated. Stick around, and see if we can have some interesting conversations.

P.S. Here's the solution to frozen burritos:

• Microwave it whole, at high power, just long enough to defrost the tortilla completely.
  Usually 45 - 75 seconds.
• Open it up and scrape the filling out into a bowl.
• Microwave the filling at medium heat until it's at a safe temp - I look for boiling.
  Usually 3 - 4 minutes at 60%.
• Spoon the filling back into the tortilla, wrap it back up, and cook the whole thing for 30 seconds to get the tortilla warmed up nicely.
• Enjoy!

(As a rubyist) Python sucks.

2016-02-02 • James Mason

I've been writing Ruby for almost 9 years now, and I love it. Ruby, for those who don't know it, is an extremely expressive, natural coding language with roots in Perl and Smalltalk. I comment less in Ruby than any other language I've ever used, because the code tends to be clear and self-documenting. The community has a great ethos, driven by concepts like TDD/BDD (test or behavior driven development), DRY (don't repeat yourself), YAGNI (you ain't gonna need it), and convention-over-configuration.

I've been writing Python for about 18 months now, and it's an amazingly powerful language, with a huge wealth of libraries and resources. I don't love it. In fact, the more I use it, the less I like it. Doing a project in Django has really spiked that feeling. It's not that Python sucks, per se, I just feel like a lot of the lessons I've learned in the last 35 years of coding, and many of the concepts I've gotten used to as a Rubyist just don't apply, and that makes me grumpy.

This Thursday, February 4th, I'll be presenting for the Bellingham Linux Users Group, where I'll expound further, hopefully amusingly and enlighteningly, on this topic.

Thursday, Feb 4, at 7pm in BTC room CC201.

Why I have a Moto G.

2016-01-12 • James Mason

My Moto X (1st gen) is dying. The camera can no longer focus on anything more than about a foot away. The radio reports 'no service' on a regular basis, requiring a reboot in order to find the LTE signal again (mind you, I can see the tower from my home). Bluetooth has gone from flaky to downright frustrating, making my Moto 360 less useful, and listening to podcasts in the car is nearly impossible. None of these are what I would call "design flaws" or reasons for you not to buy a Moto X; mine is just a few years old, with a few too many drops, splashes and slides in its history. In short - it was time for a new phone.

The 'shapely' Nokia N900

I didn't want a new phone. Especially not right now: every phone manufacturer seems to think bigger is better, and I'd rather have something with the form factor of a deck of cards than that of a notepad. I'd hoped my 4"ish X would last long enough for trends to change. Alas, it didn't.

So, since I couldn't get what I wanted, a small-screened powerhouse, I decided to revisit what I really wanted in a phone, and I decided to be a bit more pragmatic this time around, and not just get the most awesome phone I could find. To that end, I made a new list of priorities:

1. Durability is important. Elegance is not.

My phone lives in my pants pocket. My pants pocket, it turns out, is a relatively dangerous place. It gets mashed against my thigh. My kids sit on it. It gets laundered. Sometimes it's unceremoniously dropped in a pile on the floor and kicked approximately towards the laundry hamper. In short, not at all the kind of place to be keeping something fragile, or elegant, or svelte even. If the first adjectives a device evokes are about its style, it most likely doesn't belong in my pocket. If it can be described using similar words as an NFL Linebacker, than it might stand a chance.

2. Cheaper is better.

As I mentioned, anything that's going to be living in my pants pocket needs to be replaceable. I don't see any reason to keep nearly a $1000 computer in my pants pocket; that would be insane. (I'm looking at you iPhone owners.) I'm not going to put my phone in a $90 case, either, no matter how "life proof" it is.

3. Unlocked is important.

I don't want to borrow, or lease, or rent my phone from my carrier. I don't want a contract, and I don't want a monthly payment for anything but the services I'm provided. My carrier knows I can leave at the drop of a hat, and they provide me a satisfactory service experience, every month, to keep me around. I may have stayed with the same carrier for most of the last 12 years, but that's not to say I'll stay next month. I ask, when I pay every bill "what have you done for me lately?" I can't do that if I'm beholden for 2 years of payments, or if my phone won't take another provider's SIM.

4. Stock Android is the best Android.

Want to make a bunch of techies groan? Start naming phone manufacturer's Android skins: HTC Sense UI. "Argh." Samsung Touchwiz. "Ugh." Moto Blur. "Eww." You get the picture. Stock Android is cleaner, faster, more usable, and the individual parts are easier to replace should you choose to, than any of the vendor skins. Don't like the home screen? Install Nova Launcher. Not enough keys on the keyboard? Try Hacker's Keyboard. Crappy light sensor? Use Lux. If your vendor has mixed and mangled services, you won't be able to do one of those. For example, don't bother installing a custom keyboard if you have an Asus Transformer tablet - unless you like having an on-screen keyboard using up half your screen while the physical keyboard is attached.

Updates are seriously affected by this as well, which makes perfect sense. What's going to take longer - validating and shipping stock Android, or reworking a skin on top of a new version? This is the #1 reason most phones don't get updates.

5. Phones make great cameras.

No one thought to bring a 'camera' to the beach that day.

Having a decent point-and-shoot camera in my pocket has changed the way I live my life, especially how naturally I can share photos with distant loved ones. Click. Share. Send. All of my best photos are impromptu, taken at a moment's notice, without staging or posing, with my phone. Having lived without this capability for the last few months, I've missed a lot, and therefore the whole family has missed a  lot. Cameras are the best part of smartphones, and having one that's both high quality and convenient is critical.

Time to choose.

So... where do I look? Well, the "stock android" limitation really thins the herd. Basically, you've got the Nexus line, Moto, and some random Asian vendors who just don't do much business in the US, yet. And while it's not the most important thing in the world, I may need service from the vendor, and Chinese phone vendors are notorious for bad service. Moto, on the other hand, offers 'Moto Care', no-questions-asked accidental damage protection, and I've exercised that on the Moto X (before the warranty ran out) - their service is flawless. I don't know what to say about Google's Nexus devices, as I've never needed service on any of them during warranty period... so that's both awesome and questionable at the same time.


Looking to purposely avoid high-end phones, I eliminated the current-gen Moto X and Moto X Pure, as well as Google's Nexus 6 (also Moto) and 6P. While the Moto E's price tag is really appealing, the 5MP rear camera (and no front camera) is too much of a step backwards. The last-gen Moto G seems like a great value too, but my provider has awesome LTE service, so buying a device with a 3G radio seemed like a waste. This left me deciding between the Nexus 5, and the current-gen Moto G.

The Nexus 5 had a lot going for it. They've packed a lot of cool new tech into a device that's still reasonably priced: support for Google Fi; an ergonomic fingerprint scanner, USB-C charging, etc.  But, $349 felt pretty steep. I felt like the Nexus 5 was defying the direction I wanted to go; giving me cool tech instead of a reliable tool. Also, the "upside-down" photo sensor really turns me off.

Eat your heart out, rose gold.

The Moto G, on the other hand, was just the opposite - I'd have to give up some tech toys I was used to with my Moto X: NFC, hands-free interaction ("OK Moto X"), the pure black of an OLED screen. In exchange, I get the durability I'm looking for: Corning Gorilla glass; cheap, replaceable shells that maintain a waterproof (!!!) seal over the solid metal frame. For fun, those shells are available in a rainbow of colors, and even with a flip-back magnetic screen cover. Not to mention that the G starts at about half the price of the Nexus 5: $179 for an 8GB with 1GB RAM.

I also get to keep using some of Moto's pioneering improvements, which I've gotten really used to - like their awesome camera app. Two flicks of my wrist, and I'm taking photos: no other phone offers more convenient access to the camera. Their 'click anywhere on the screen' (or on my watch) approach continues to make my life easy. The 1080p video, or 720p slo-mo video, with live snapshotting during video recording, rivals any other devices camera tools. The pictures coming out of its 13MP camera look great both in printed snapshots, or when shared online. The 5MP front camera is more than adequate for videoconferencing as well.

32GB of that is a class-10 SD card.

I liked the Moto G's scaling factor as well - $40 more doesn't just bump up the storage to 16GB, but the RAM as well to 2GB. With an SD slot, and Marshmallow's ability to integrate SD storage seamlessly into the system, I ended up with plenty of storage, and plenty of RAM.


In short, I got everything I wanted: A durable, relatively inexpensive, unlocked phone running stock Android with a camera that makes my whole family smile. For fun, the shell I chose is reasonably close to SUSE green. Do I miss NFC? Sure. Do I regret my choice? Not even a little. This phone is going to last me a few years, and who knows what will be out by the time it dies...

My next phone will project the Death Star in lieu of a ringtone.