Archive for Google

Three Tech Wishes for 2017

Happy 2017! As we put 2016 in the rearview mirror, we’re all taking a look at the outlook for 2017 as I did here but I wanted to take a more personal angle here and explore what I desperately want to see from the tech community. This list is by no means exhaustive and for the sake of time (and online attention spans) I’m limiting it to my top three.

Google Account Management: Dealing with multiple Google accounts is an unfortunate and annoying fact of life for me both as a regular user and as a developer. In this year alone I’ve probably written thousands of lines of code for myself and for clients to deal with this problem by basically scraping calendar events between two or Google accounts. The business case for this problem is pretty simple. Company A gets a contract to do some work but they don’t have the resources in house, so they subcontract part (or all) of the job to Company B, but Company A doesn’t want the client to figure out that Company B exists and is actually doing the work, so they give all the Company B people Company A Google accounts. My event scraping solution is sloppy and fraught with all sorts of little issues. Google should find a way to implement some sort “vanity account” system that let’s the actual email addresses be masked between multiple domains, so that the customer sees what Company A wants them to, but Company B doesn’t have the overhead of dealing with yet another GMAIL account.

Reactive Programming Hype: A lot has been made of Reactive Programming in 2016. While there is definitely some fire to the smoke, things are getting way too hyped and frankly I’m seeing Jr developers pitching reactive programming on freelance gigs as some sort of silver bullet that will solve all the problems you have have and even ones you don’t know you have yet. This is scary! Sure there has always been hype around “new” (sneer quotes because Reactive Programming is only new from a ‘certain point of view’) technologies and methodologies but this hype train around all things with the word or root ‘react’ in them has the kinetic energy of ten hydrogen bombs. I’ve gotten too many projects in this year from prospective clients that were over-engineered in one of these reactive libraries by some Jr dev who just got a little too excited on the Kool-Aide sales pitch and the story is sadly all the same – the client was happy with what he was told but what he got was a steaming pile of hard to reason about spaghetti code and ultimately a rewrite. For 2017 let’s just pull the cord a little on the hype train, OK?

Docker Direction: Despite some fairly significant pain in upgrading between Docker versions and other more minor issues, I am still a serious believer in Docker as the premier containerization solution. Coder Radio listeners will remember that even as a callow youth I was on the Docker train right from the beginning but my faith has been somewhat shaken and I’d like some clearer communications regarding where the technology is going, who they feel their ideal target users are, and where Docker the company sees its role beginning and ending — in other words where will they and where won’t they compete with vendors who are selling / implementing Docker.

Those are my three (I hope fairly doable) wishes for 2017, but before I go…. I also want to note what I didn’t mention here that I have in my end of year / new year posts for the last years – App Store monetization and more specifically a sign from Apple on where they see that going. We got our answer in 2016 – subscriptions. While that will work for a number of apps and is working fine for my Backpoints (iOS & Android), it does not satisfy all the needs of independent developers and likely will not create the high-value ecosystem of professional paid (paid defined as taking money in any non-donation way) software that the iOS App Store originally enjoyed. When I think about Apple and their answer to the monetization issues on the App Store, I am remained of that great quote from Dan Brown’s Angels and Demons: “God answers all prayers, but sometimes his answer is ‘no’.”

Google Home Review

I’ve been spending some time with a Google Home at my office. It’s. been a pretty interesting experience overall and makes me more confident in my previous assertion that of the big three in tech (Apple, Google, and Microsoft), Google is going to dominate the digital assistant / bot space. While my experience with Home was not perfect, it was a pretty impressive showing for a first generation device.

The Good: Google Home is smart as a whip! There’s just no way around that. My office mate and I spent hours trying to trip it up on trivia, calculations, and finding obscure movie and song facts and the device held up just fine. By far the most useful functionality for our office has been dictating songs to it and passing back and forth; prior to the Home, we would take turns playing (put your hate in the comments) vinyl records. Sure, we could do this with a PC or even an iPad but just being able to pick songs verbally has been an surprisingly enjoyable experience. I know this sounds a bit silly, but it reminds me of when I got my first iPad – I had mocked the iPad as just a large iPod Touch, but I changed my tune after my first few minutes using Apple’s tablet. This is just how I feel about Home, though I went in with a little more of an open mind than I did with the iPad.

The microphone seems fine but I do occasionally have to re-state requests to the device and it’s not clear if I just mumbled or my NJ accent was too hard for Home to parse on certain phrases. The speakers are pretty good and don’t have that tinny quality to the sounds that I was worried about before I got the device. For most users Home will likely be the highest quality speaker they have in their house, but I can see audiophiles wanting something a bit more.

The Bad: I’ve experienced occasional service outages with Home that required it to the restarted. The error message given suggests that my wifi may have been to blame, but every other device on the network was fine. It’s impossible to dig deeper into this, but it stands to reason that the issue is a service hiccup on Google’s end. Silly as it sounds, it kills the magic of a voice interface if you have to get up (in my experience) every other day to unplug and restart the device.

The Ugly: Google account management is a mess on just about every Google product and Home is not exception. Home only allows you to have one account on the device — this is a terrible design decision as it makes the assumption that one account equals one person. The reality for my use case and many others is that on e person will have multiple accounts. My guess is the most common case would be users (like me) have one Google account personally that has their Play Music, YouTube Red, and other Google entertainment services on it and also have a Google Work account used primarily for email and (most importantly for the purposes of Home) calendar. In my case, I put my personal Gmail on Home to get the entertainment functionality but am totally cut off from my work calendar. Ideally, I’d like a system where Google understands that users have different Google accounts for different contexts and allows the user to take calendar services from a Google Work account while using their personal account for entertainment and everything else.

All in all, I like the Home. It is definitely a first generation product, but most of the issues with it are fixable via software. Currently, I don’t see any real competition for Home other than Amazon’s Alexa but Amazon is in a very different business than the big three, so I would question their commitment to building a truly expandable AI assistant – Google’s opening of Actions to third party developers is a strong step in the right direction. Apple seems unwilling or unable to make Siri more than a lame parlor trick and even if they did, they’d likely be very paternalistic in terms of user privacy, severely limiting third party developer access. Microsoft is doing some really cool stuff, but they don’t have the platform beachhead that Google has in Android and all of the Google related services and that Apple has with iOS. The most surprising aspect of using Home is how it has me strongly considering picking up the next flag ship Android device to get that Google AI functionality on the road. Do you have a Home or comments / questions on this post, sounds off in the comments or Twitter.

Swift on Android

SwiftRumor has it that Google may be considering making Apple’s Swift a first class language for Android development. Predictably, the internet has been pretty excited about this possibility. My lack of enthusiasm for Swift has been fairly well document, so I’m going to keep my comments to a minimum.  Swift on Android shares the same API problem as Swift on iOS and this likely has more to do with legal wrangling than technology.

Java and Objective-C are very object oriented languages and the Android SDK and Cocoa Touch APIs reflect that. Swift is a far more functional language than either of them. “Good Swift”, which I have been told is functional and not just “Objective-C in Swift” doesn’t really go so well with a OO designed API on Apple’s platform. Why should that problem not exist on Android as well? Maybe Google and Apple will rewrite their SDKs to be more functional, but that’s not where they are right now.

Oracle is suing Google and has been suing Google for Android’s use of the Java programming language, which Oracle acquired in its acquisition of Sun. The lawsuit is ridiculous and a destructive waste of resources, but that’s a pretty fair description of the US legal system, so it is likely to continue to be an ongoing concern for Google. If Google were to stop using Java on Android, that might put them in a better position regarding the suit and it’s pretty clear that the licensing on Swift would prevent any similar issue from cropping up between Apple and Google.

Yes, I’m admittedly bias, but it’s important to think about the practical and ulterior motives that Google might have for adopting Swift and not just blindly jump aboard the hype train. Swift is a decent programming language, but it’s not the right solution to every problem and we should only make changes when it makes sense to do so. Let me know what you think on Twitter or Google+.

Google and I: It’s Complicated

Larry Page’s Google IO keynote speech was more than a little touching. it gave the company m more more human face and reminded me of why Google and its story is so inspiring. Unlike most other major tech companies, Google is actually “doing stuff”; in fact, Google is not afraid to take on projects that have the odor of science fiction: self-driving cars and Glass come to mind. In a lot of ways, Google is actually the sort of company that I think many developers dreamed of being apart of as children, so why then do I have this weird issue with them. A lot of Coder Radio listeners seem to think that I “hate” Google — an accusation  that is more silly than true.  My real issue is what Google does with our data (what they craftily refer to as “signals”) behind the scenes — the truth is the we (the public) don’t really know to what extent and in what ways Google is monetizing our data and it is that secrecy that leaves me with cause for (albeit mild) alarm. The question becomes — do the benefits and amazing technologies that Google brings us justify the potential privacy implications?

Again, I want to reiterate that I really do like a lot of what Google does. In fact when forming my company (Fingertip Tech, INC), Google was one of the main role models I had in mind — at the time Google was one of the few non-Linux focused companies that was making a real effort to bring open-source software and values to a more mainstream market; that is a tact I’ve taken and tried to expand on by open-sourcing as much of the software that I right as is feasible. Google’s dedication to pushing the web and mobile forward is nothing short of expiring.

The problem is that I can’t really know what I am paying for the amazing software that Google offers, since I am not paying with currency that I can track but rather my personal information. In a perfect world, I’d be able to purchase Google services ala carte and opt out of all of the “signal generation” aspect of Google. This, however, is not likely, since the data is probably more valuable than any fee that they could effectively extract from any meaningful percentage of the population. I’ve been beating the “pay for software — don’t be the product” drum for some time now, but it seems that the market would just rather not pay for certain percentage of software. Is it time to stop fighting the tide?

Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.


Wither Webkit?

As you are probably aware Google has forked Webkit and will be calling their fork Blink. Google does not intend to re-merge with the main project at any point in the future and is signaling that they will be adding new features to their rendering engine. As a developer who often has to work on the web or mobile web this is very interesting but also a little concerning.


Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.


The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

Chrome > Android

chrome-iconAndy Rubin is no longer working on the Android project at Google but, at least for now, is still part of the organization — see his parting email here courtesy of the Wall Street Journal. The good news is that Sundar Pichai is going to be in charge of Android, but the bad news is that he is the head of Chrome / Chrome OS (referring to Chrome and Chrome OS by simply Chrome going forward) and the departments seem to be doing something of a merge; or at the very least the distinct positions of Android head and Chrome head have been merged into one. The question is what does this mean for Android and, more importantly, what does this mean for Android developers and Chrome developers?

First off, let’s face the hard truth about Android it. It is quickly spinning out of Google’s control; one one end Samsung basically has a monopoly on the high end Android device market and on the other there are tons of Asian manufacturers taking Android and slapping it on sub-par devices, further diluting the brand. Chrome, however, is 100% Google. Sure, there is the Chromium open-source project, but guess who sponsors and, for all intents and purposes, controls that? That’s right, Google. Open might be a great marketing term, but let’s be real, it’s a lot easier to monetize an operating system that you control.

Many of you may not necessary agree that Google would be interested in maintaining control of Android, but it is hard to argue that Chrome isn’t  more in line with Google’s goal of a web based world built in HTML and related technologies. It’s called synergy, baby! You don’t need an MBA to see that Android (aka glorified Java) is not exactly in line with an HTML future. If only Google had a web based operating system it could focus on…. As web development technologies continue to evolve and become more capable for developing full featured applications with rich experiences, Android will become increasingly less important to Google.


My guess is that the conversion will start slow. Perhaps Google will start to push Chrome apps for the Android version of Chrome. Maybe in a year, when those rumored Google stores start to show, we’ll see a Chrome for Mobile “developer phone.” Regardless of the conversion starts, my bet is that within the next five years Google will start publically pushing Chrome  as its next generation  operating system. In fact, I think it would move faster, and probably had plans to, but is being thwarted but regions with little or poor connectivity — this is a particular issue in large portions of the United States.

The good news is that, overall, developers stand to do well in this scenario. Android developers have little to fear from Google, since Android is largely beyond Google’s control at this point; if Google ever stopped supporting it, hardware manufacturers, chiefly Samsung, have enough riding on the OS to keep some sort maintenance and development effort going. Google’s focus on Chrome will be a boon for web developers. Sure there was WebOS, a good and severely underrated web focused mobile OS from HP, and there will be FireFox OS, but it’s going to take a bit of muscle that HP and Mozilla didn’t have, in the case of HP, and will never have, in the case of Mozilla.

Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

My Android Christmas Wish

Android developers will know that there are some serious issues of fragmentation on the platform. These issue have been well recorded and, at times, greatly exaggerated. The truth is that in the last year Google has taken great steps toward making the Android development experience more on par with iOS and it could be argued that developing for Android is now as enjoyable as developing for iOS. However, there is still one larger of weakness is the blessed Android development tool chain: a good GUI designer.

Let’s face it — there really aren’t any good GUI designers for relative layouts. Certainly, the one Android developers are provided in Eclipse is a far cry for Apple’s Interface Builder. To be fair, Interface Builder traditionally has not had to deal with relative layouts and there is an element of added complexity in dealing with them. Still, that doesn’t excuse Google’s lackluster tool.

Like many Android developers, I’ve taken to working almost exclusively with layouts by editing the actual XML code. There’s nothing wrong with this, but it can be somewhat tedious when developing a complicated layout, since you have to keep rebuilding your application as you make changes to the layout.

If Google could improve or replace the Android layout tooling, I am confident that we would see more complex and attractive user experience in our Android apps. So, what do you say, Google? Questions? Comments? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

Balsamiq GDrive Edition

I have been more than a little critical of Google Drive, because of its poor support for source control (Git), however, I still use it for a number of document editing tasks. At the same time I have been looking for a wireframe editor that supports designing mobile, web, and desktop applications; I am a big fan of designing the UI first and iterating on that initial design over the lifetime of the app, so that type of tool is an important part of my toolchain.

Balsamiq, the cross platform (Adobe Air, Linux, Mac, and Windows) wireframe tool has been on my radar for some time and I even tried a demo version of the Mac app a few months Overall, I liked it but wanted to something more. It was hard to explain what was missing but something seemed lackingl, then they released the web app for Google Chrome.

This is the tool that I’ve been looking for. It is pretty much as responsive as the desktop app and saves your wireframes right in your GDrive. I found this to be a one two punch of power and convenience that was too hard to resist. Better still, the tool integrates with a number of services including Jira (more on that later) and Fog Creek.

There is a also a number of community developed templates that you can add to the app by uploading them to you GDrive, for example there is a template specifically designed for working on apps for Amazon’s Kindle Fire and Android 3.0 tablets.

I know this sounds a lot like a commercial, but balsamiq for GDrive is a great tool and given how hard it was for me to find a wireframe editor that I like, I assume there are others with the same problem. As a pro level tool, the app is not free. It costs $50 for a year or $5 a month; there is also a free seven day trial. Let me know what think. I can be found on Twitter and Google+.

Warning: Google Drive and Git Don’t Play Nice

When Google’s GDrive was finally made available to the public, I was thrilled to see that the pricing structure would allow me to get double the space for the same amount of money I was paying Dropbox. Reading the description, it seemed that GDrive had all of the features that I liked from Dropbox and even offered an equivalent to Dropbox’s add on packrat service.

In short, it seemed like a great deal. So I did a trial run. I moved (copied would be the more accurate term) some of my personal repos from my Dropbox folder to my shiny new Google Drive. The initial sync took a long time (a little over a day) but that is to be expected with any of those types of services.

My initial impressions were mostly positive. However, I did notice that GDrive’s Mac OS X app uses four times as much RAM as Dropbox’s. Still, things were going pretty well and RAM is cheap, so for the money I was saving on storage it was worth the extra memory.

My main use for Dropbox is hosting Git and Mercurial repos along with one or two SVN ones that I haven’t had time to switch over to Git. Things worked just like they did with Dropbox. Until my secondary machine synced with the GDrive. on that machine a git status showed that all the files had been removed from the repo. I readded them and things were fine until I moved back to the main machine where I saw the same issue.

I have done Googling and can’t seem to find a reason for this. The only discussion I have found of people using the GDrive in this manner seems to have ended with another user warning the Google groups asker that there could be potential issues.

Sorry to say that I don’t have a fix, but I am migrated back to Dropbox. It does seem that you get what you pay for. That might seem harsh to some of you, but if you do software development for a living that is the kind of issue that should not be tolerated at all. Let me know if you have had the same experience or not on Twitter or Google+.

GDrive Mac Performance Issues.

I am always looking for ways to minimize costs and maximize the effectiveness that I get out of my tools, so it should be no surprise that when Google’s GDrive was announced I jumped all over it. The reasons were clear: I was a heavy Dropbox user and Google offers double the storage for half the price. Overall, I am pretty happy with the service, though there are some quality of life changes Google could make: for instance, it would be nice if I could control how much bandwidth the GDrive client uses at certain times of day; this is something that I have come to love in CrashPlan.

Still, it is likely that Google will add that functionality to the Mac client at some point in the future. There is one thing that they should fix now: Performance.

GDrive takes approximately four to five times as much RAM as Dropbox when idle or syncing. In my limited testing on both a 2012 Mac Mini and 2011 Macbook Pro have Dropbox using around 40MB GDrive uses 200+MB. While syncing Dropbox jumps to the high 50’s and low 60’s on my machines. while GDrive gets pretty close to 250.

I did some poking around and it seems that at least part of the GDrive client is written in Python, rather than C++ or Objective-C. This makes a lot of sense from Google’s perspective, since Python can run on Mac OS X, Linux, and Windows. Also, if you know anything about Google’s love for Python you’d know that most Googlers would write a Python script to make a cup coffee. I a am not suggesting that Python is a bad language, so keep the hate mail to yourself. However, this does feel a bit like a case of write once, suck everywhere.

To be clear, this issue is not enough to get me to quit the GDrive just yet, but it does seem like a little more effort could have been put in here.