The Journey of a Thousand COMMITS
One of the most challenging parts of most projects, for me at least, is taking the first step, and if there’s a procrastination quagmire it’s always in those early days.
To explain, over my career I’ve seldom done projects that implement only, or even significantly, things I already know. Instead I’m always drawn to, or into, projects that involve learning and conquering new things, doing something not (widely) done before, pushing envelopes, achieving very difficult requirements that might be perceived as impossible (and sometimes turn out to actually be impossible), etc.
This keeps it fun and challenging and rewarding (and it’s one of the reasons I’ve never been a big disciple of Test Driven Development — if I were repeating patterns and techniques in project after project, it would be of obvious value, but when I’m endlessly jumping technologies, using new techniques and libraries and protocols, with projects that are speculative and often based upon research while under way, etc…it’s less of a win). But invariably there are those stages where I have to learn significant new things (not like “learn this one thing”, but rather “learn an entire field to winnow down to the specific choices for this project”). I often avoid it for a while, often whittling time away on the trivial stuff (which recently might be configuring containers and configuration scripts, etc).
Things learned incrementally, with continuous feedback and rewards, are never a problem — and a lot of tools and technologies are built around this model — but many others demand an enormous up-front investment of time and intellectual effort before it can begin to offer any value at all.
I’ve written about this before, and I’ll include the graphic that I made then-
And that’s where a fun project I’ve started with my ten year old son sits right now. Mobile, voice communications, with real-time, low latency, high quality, bit-efficient streams of hundreds of people. But progress continues and it should make for some fun posts on here given my inability to talk about other engagements.
This post is mostly just a fun little exercise to freshen the cache while updating the site, so excuse me while I jump around a bit, as the prior section reminded me of a bit of a peeve regarding this industry, and it’s one that I constantly encounter.
I was once in a shop (a very large financial firm) where I was the “Borland Delphi” expert. I still recall a conversation where a project being conceived in C# was being discussed, and the manager on the project commented that I was probably not interested/that it would be outside of my expertise, because I’m a “Delphi guy”.
At the time this happened I had a fairly popular published open source project in C#/.NET. I had a published technical article on the .NET platform making the rounds, had been recognized nationally by Microsoft, had my MCSD and an assortment of other Microsoft certifications (hey…I never bragged about them, displayed them on my wall, etc — they were instead decent motivations for digging into the edge material that I might not have bothered with, and I’ve never regretted gaining them), etc. I had done more in .NET and C# and the Microsoft stack than the entirety of the room, and was, to my knowledge, might have been the most experienced on the platform in the entire organization.
But in this industry people want to pigeon-hole you. They want everyone to fit in a place in the technology tree. To have a camp, so to speak. Now often this is sadly true, where the developers get a hammer and then for the rest of their career try to make everything a nail. But many times it isn’t.
If you aren’t guarding against it, it’ll “typecast” one into a role that might not be interesting going forward, might not be lucrative or with long term viability, etc.
I’ve seen the same thing, to much amusement, in the database world: I’ve done an enormous amount of work and projects with relational databases, and with NoSQL databases, and with column stores, and with document and KV stores, and with graph databases, and with in-memory databases. I’ve built large projects on Microsoft SQL Server, pgsql, Vertica, Datomic, Couchbase, and on and on and on. I built a large scale solution using LVM snapshots and sqlite.
But if you do a project in any of them, you get typecast to those participants as only knowing that, and by association of being fervently against the alternatives. Do a project in SQL Server and you must be some anti-NoSQL old timer who should see what the kids are doing nowadays in their new fangled tools (I saw exactly this sort of feedback when I critiqued Digg’s hilariously poor RDBMS use years ago: People in the RDBMS camp declared me one of their champions, and the NoSQL camp declared me the enemy). Use a Couchbase Cluster and you surely have lots of angry, opinionated words ready to attack relational database.
The whole flag waving thing gets incredibly boring. I develop for Windows and Linux and Android and iOS, in C++ and Go and C and Java and C#, on the web and in services and in fat apps and in native apps.
As an aside, this same thing happens in the “blogging” and online world. After I wrote a couple of critical pieces about the rose-coloured glasses of some in the NoSQL camp, I was cheered on and referenced endlessly by the anti-NoSQL crowd (many of whom just fear change). If I criticize iOS or Apple I must be a member of the pro-Google crowd. And on and on. And then I’ll post something that goes exactly contrary to those assumptions, get some angry emails about being a turncoat, lose subscribers, etc. Eh. Whatever.
Use the best tools. Apply them well. Make great solutions. Seems pretty simple.
Accelerated Mobile Pages
I’d of course heard about AMP (most of it of the conspiratorial slant), a recent initiative of Google’s for creating a faster web, and from the context of the way people talked I presumed that it was some sort of new WAP-like protocol, completely decoupled and simplified from the web as we know it.
Interesting enough. When I finally spent the time I was a bit surprised to see how trivial the whole AMP thing really was. And via a simple plug-in this site supports AMP — just append /amp on the end and voila, a valid, cacheable AMP page.
Google announced an iOS-like beta program of Android N yesterday, adopting the early public availability and the hopefully useful feedback that provides. Enrolling compatible devices (essentially the newer Nexus devices) is a simple webpage away. This is a dramatically better model than the forced-wipe, manual-install of prior iterations, where the images often didn’t even come out until they were almost fully baked. Android N is most certainly not fully baked at this point, but it’s fun to play with.
I dropped it on my Nexus 6p and from a normal usage angle it’s mostly a graphical refresh (in this iteration going from “simplified”, with some borders removed, layouts simplified, etc. In this industry we endlessly cycle from simplified to bedazzled and back again, each time perceiving it as “more modern”). On the programmer side it gives Java 8 support, adds multi-window support (which I suspect was prioritized and given a lot of executive pressure given the criticisms of the Pixel C), ala what Samsung has done for several years, and so on.
At this stage, I would not recommend installing Android N. Aside from a number of serious malfunctions in various existing APIs (causing a number of apps to malfunction or fail entirely using various codecs, camera APIs, and so on), it has a significant number of rendering issues (many clearly related to the multi-window support), and just generally extremely poor graphical performance. It’s a very early test version, so this should be expected, but it’s just not a good daily driver. The same easy mechanism used to enroll can also be used to unenroll, which is very elegantly implemented.