Mike Levin SEO

Future-proof your technology-skills with Linux, Python, vim & git... and me!

Meant to do OAuth 2 yesterday… better dev env instead.

by Mike Levin SEO & Datamaster, 10/04/2013

Note: Many days turn out to be a “nested sub-problem”. This is life. The trick is to choose the right top-level problems so you don’t get excessively trapped in the roots. But some roots are necessary for all trees. Will it be Google App Engine or Levinux? Both!

Today is all about OAuth 2. Several years ago I started repositioning myself from SEO to a more API-driven custom programming field. But because SEO is all about tricks that you can keep re-using to great and profitable effect, I “canned” my API tricks in an accessible-by-everyone via Google Spreadsheets fusion product, called 360iTiger. This repositioning was in tandem with leaving the Microsoft (mostly VBScript on ASP & WSH) platform and onto Linux, Apache, Python. It was exactly enough to run off the edge of the cliff and learn to fly. Moments before I hit the ground, I got all the disperse pieces jury rigged together and slapped on a makeshift sort of Icarus wings sufficient to pull myself out of career BASE jump maneuver, and go gliding back up on an updraft.

I am prone to take risks like this in my career. And I really do think about it in these dramatic story-telling terms, for the very purpose of helping me navigate through ambiguous and sometimes frustrating times. It helps me see the situation better, put it maybe some historical and during-my-lifetime context, perchance to see some aspects or critical insights about the situation that others may have missed. This has allowed me to make the agile framework at Scala, Inc. during the late 90’s, which is still running part of their company today. It let me make HitTail, a remarkable product that just keeps chugging ahead over the years. And it made me make 360iTiger, which connected some wildly disparate dots into a unified and unlikely product. I am right now at another such juncture. I have already ran off the side of the cliff again.

Well, appropriately a pair of Google Glasses (Google Glass) were dropped into my lap, and I was told to program these. Now, as a multi-platform guy going back to the Radio Shack TRS-80, raised on the Coleco Adam and Commodore Amiga and dragged kicking and screaming onto the Mac (for Drexel University) and onto the PC (when the writing was on the wall). I also had the Palm Pilot on day one, and was a fan of Symbian OS with UIQ on the Sony Ericsson P910a and was in line on day-1 for the iPhone. So, I’m no stranger to new platforms, and a good number of these, I actually programmed on. I never quite made the move to native C-code, learning the idiosyncrasies and nuances of each piece of hardware. Instead, I’ve gravitated towards more generic systems programming approaches (process automation, etc.) and away from graphics and games.

This is idea for Google Glass today, because the only official way you can program this thing is through application program interface (API) calls. You never actually even touch the hardware. You program something that talks with something that talks with something. That’s the Google Mirror API for Glass. It’s quite strange, but is an understandable and very conservative approach to allowing apps out into whatever glass ecosystem and marketplace can exist on an experimental unreleased product, without tarnishing its reputation. All that side-loading stuff that’s being done with the Android SDK reeks of hack-ish-ness and wouldn’t give the Google Glass platform a good reputation.

It’s like the early days of iPhone when Steve Job was encouraging everyone to do Web apps, while Apple held a private software development kit (SDK) in reserve for their own use. Google isn’t holding the SDK back because they feel they can endure a bit of hacking more than Apple could in those early days of the iPhone and the first jailbreaking. But the SDK is the one that exists for the Android smartphone and tablet platforms. Glass is a radically different platform with radically different presumptions and rules. Using the Android SDK to develop for it is gutsy, and frankly is where most interesting things are going to be done like the blink-camera, and the last-10-seconds video recorder. But it’s not the best place to invest time right now, unless you’re ALREADY a seasoned Android developer.

Instead, it’s really best to just go through the formal Mirror API put forth by Google, which is like rails on rails. You can do anything, so long as it’s inserting, deleting, and editing cards in the timeline. These cards don’t have camera access and can’t take a picture themselves, but they can represent a Glassware APP and be SENT a picture from the built-in default camera app, and THAT’S what I’m trying to do… today, if not by early next week.

But first, we have a very new situation to deal with. It’s a conundrum. It’s a catch-22. It’s something that MUST be part of the new programming reality, but which makes everything a bit more complex. And it’s something that’s hidden and obfuscated by the copy-and-paste examples put forth by Google on the Google App Engine (GAE) as the Google Glass Quickstart Example. Well, it will get you started quick enough running EXACTLY THE SAME app as the Quickstart Example itself, but on your instance of the GAE rather than the community Quickstart Example that everyone can immediately play with. You basically do a git pull, follow a step-by-step instruction to get some OAuth 2 requirements in place, then you can visit yourappname..appspot.com. And that’s more-or-less where I am at right now.

The problem with being here is having to peel away the layers of the Google App Engine to understand what’s going on enough to modify it to my own designs.

Okay, a few things are becoming clear. I am going to want to switch to webapp2 instead of bottle.py, to keep things on Levinux much more similar to web apps on Google App Engine. That’s a fairly big breakthrough right there alone. But ALSO, I’m going to implement Python virtualenv to keep things organized - particularly the trick of keeping so many things persistent that have been installed with pip. This will be A BIG upgrade of Levinux, and very worthy of going from Beta 1.9 to 2.0.

Hmmmm, as I research virtualenv more, I’m turned off towards it… at least for right now. It is a distraction, and only really brings things to the picture that are not excessively necessary on a platform like Levinux. Levinux works like an embedded system, only having what you need for what you’re trying to do right now. As such, you don’t keep a lot of stuff installed, and as such, you are less likely to encounter library version incompatibilities. Why figure out a more complicated scheme when simply adding stuff to /opt/.filetool.lst from /usr/local/lib/python2.7/site-packages/ is enough to make things persistent.

Okay, I’m going to do one more revision of Levinux to Beta 2.0. I have a better reason than virtualenv (now abandoned) to make a 2.0 revision. It’s the fact that I’m now clued into the fact of how the /usr/local/lib/python2.7/site-packages location works. Also, I know how to get a file size count of recursively of a directory with:

du -sc /usr/local/lib/python2.7/site-packages

…which reports 4.5M total. And that’s not bad for a quick backup of pretty much EVERYTHING you install with pip. This is potentially a breakthrough, because it makes everything persistent that you install with pip, so long as you trigger off filetools.sh -b at least once after you do the pip install. And all the scripts become much, much easier! None of that piping through sed stuff to make sure you have the right version!

Okay, it’s actually looking quite a bit better. If this latest test goes well, I’ll start incrementing the version to Beta 2.0. After Python is installed, what things should I check? I should look at the /opt/.filetool.lst file, and then reboot, and look at it again and check for the presence of pip and the expected contents of /usr/local/lib/python2.7/site-packages

Okay, if I were to switch from bottle.py to webapp2, what precisely would I do? Well, there’s hardly any damage to leaving that one webapp directory in location so that my videos are still applicable. It’s just one file in a folder, not even made global. I will simply have to put in the pip commands in the right place, which always has a single filetool.sh -b command and the end of the pip commands. Things get increasingly easier.