Month: August 2013

I’d been extremely resistant to adopting third-party tools in my development efforts for a very long time. I liked owning my tools end-to-end and I liked writing my own code just for the sake of knowing exactly how it worked. I didn’t even have a Gmail account because I was running my own mail server and didn’t see the need to support someone else’s service.

Eventually I learned my lesson about how good specialization can be. Now I say it’s a stupid lesson to have had to learn but I think you can say that about a lot of lessons.

Now my adoption of third-party tools has brought on a new problem.

I’m a big fan of Trello, as can probably be inferred by my earlier post on working with its API. I’m less of a fan of GitHub but respect that it’s a massively powerful tool, especially for sharing code across a distributed group. Both are tools that I use on personal projects and that my office has adopted internally. And that’s led to some interesting issues with the line between personal and professional in these systems.

It started simple enough. I was subscribed to a GitHub repository by a member of another team in the office so I could provide some commentary on a particular piece of code. I log in with my single GitHub account. Suddenly I’m getting email notifications to my personal email address telling me that, by virtue of being part of the office organization, I’ve been subscribed to repositories for teams I don’t interact with.

Okay, that’s something I can deal with. Attach my work email to the account, route everything from the organization through that, it’s all good.

A few weeks later I get a new email. Apparently someone in the organization decided that we need to have a rule that you must use your real name in your profile and must use an identifiable photo, and my account does only one of those. A few weeks ago this was my personal account, now I have coworkers telling me how I have to use it.

Switch over to Trello and it’s a similar story. I’d used it for project tracking for awhile before my team decided to use it. We had an organization set up and everything was great, as I kept my personal boards in the “My Boards” area and my work stuff was tucked away in its own organization below it. Yeah, it was annoying to get a notification to my phone if one of my teammates decided to do some off-hours work and start moving cards I was on but it was really no big deal.

Eventually the company decided that enough people were using Trello that we’d upgrade to Business Class. All of our boards were moved over to this new business account and one of our team managers pulls up the account to show how everything is grouped nicely under the new business. I pull up my account and find a jumble of work-related boards mixed in with my personal ones. I ask the manager about it, he can’t explain it so he brings over an IT guy. As the IT guy goes to look up whether or not my account was properly added to the business, I know what he’s going to say. “Oh, you’re not using your corporate email? Yeah, you’ll need to create a new account.”

And therein lies my new problem with adopting third-party tools. It seems to be defeating part of the purpose of having all these cloud-based, accessible-anywhere solutions if you have to have multiple accounts for them. Isn’t one of the selling points having everything in one place?

I know a lot of my coworkers have no problem setting up multiple accounts. Clearly that’s the expected behavior. I honestly can’t think of a better way to do it outside of modifying the tools we’re using to allow for accounts to have a split personality of sorts. It just bothers me and I wish there was a better way.

Over the last couple weeks I’ve spent some time playing around with Chrome development and Google Hangout extensions. Nothing revolutionary by any means but there were a couple interesting things I came across that I figured I’d share out.

One thing I found slightly funny is that both Chrome extensions and Hangout extensions are JavaScript based but how they’re packaged is completely different. For a Chrome extension you only need a manifest file, which you can combine with your actual extension files to create a installation package within Chrome. For a hangout extension, your JavaScript is wrapped inside an XML file which you host on a server somewhere, then you need to have your extension listed inside their developer center and pointed at that XML file.

Because a Hangout extension has to be listed in Google’s systems, there’s no such thing as a private extension, something you share out only to certain people. For example, I was making an internal-only tool for my office’s telepresence setup. In development I could share that out to specific users that would be running it, but that forces the developer tool sidebar to be open in the Hangout. The only way to get rid of that bar is to make the extension public, which I don’t want to do.

On the Chrome side of things, I found some interesting stuff in the manifest validation. I was alternating on whether what I was building should be an extension or a packaged app for Chromebook. The two of those have differences in how the JSON manifest looks and there’s no block comment in JSON, so I couldn’t have both versions side-by-side and just switch back and forth. I decided to try a variation on the old “1 == 2” trick for block comments in VB Script, where you wrap your code in a bit of logic that always returns false. In this case, I renamed my “app” block to “_comment_app” and ran it through the compiler. It was allowed but I got an error saying that “_comment_app” was unknown. Okay, so the compiler does some validation, good to know. I then spent some time fighting with getting an AJAX call working in a different extension, and it turns out it’s because I had copied and pasted a “permissions” block in the wrong spot, which the validator didn’t catch. Some validation, yes, but not complete validation.