Drinking the Kool-Aid


Let’s say you were to take a new job on the other side of the country, specifically to work on some cool iPhone/iPad products under a great brand name. Say you’ve also fell in love with everything and anything metallic brushed looking with light up fruit inscribed on the cover. Now let’s say your employer get’s purchased by the one company who’s technology/products you’ve avoided for half of your career. Hi, I’m Cliff! You’re here because you have a thirst for water with red powered flavoring and pure granulated sugar applied. I’m here because I recently discovered a similar urge and have begun quenching myself with the proverbial powdered water delivered by the happy smiling pitcher that crashes through brick walls but never spills a single drop. (You’d think by the second or third wall he would have at least formed a crack or sprung a leak!)

I was just inspired by another Apple Fan swallowing grape flavored drink in a blog post where he describes many of the unknown miracles you get with software from Redmond these days. I have to admit I am intrigued as I was unaware of what’s been cooking in Microsoft until most recently. I’ve switched one of my iPads to Bing a couple of months ago because I really wanted to give it a chance but I never really do much searching on the iPad so it was a really poor way of experimenting. This time around I plan to do something bigger, much like my original jump from Windows XP to Linux trial-by-fire. I plan to force a new Microsoft product on myself and write a short blog post about my experience. I’d like to do this on a weekly basis but since my plate is already so full I don’t know if I can keep up that pace. Today I’m starting with Bing everywhere. The above blog post has me excited enough about the bing app on iPhone so I’ll start there while also switching my defaults in Safari, Firefox and Chrome. I will live the Bing lifestyle and report back here next week.
Appropriate imagery connecting my early childhood gaming habits with the urge I feel now...

Cross Platform Mobile Development


Just when I thought I reached my peak for number of programming languages I could fit in my skull I get bitten by the Lua bug! Not exactly sure what to make of it at first, I rolled up my sleeves and dug deep to see what the big deal was. Why Lua? Was it yet another language, or could there be something I was missing. Hi, I’m Cliff. You’re here because you thought Lua was one of those ornaments you hang on your neck when going on vacation. I’m here for quite the same reason, only I figured out something more.

I found a product called, Gideros Studio, which is based on Lua technology. It facilitates powerful cross platform mobile development for iOS and Android, allowing you to prototype apps in a mobile agnostic emulator while offering instant deployment to device. Development with Gideros is fast! Apps are pushed to device and launched instantly, much quicker than Xcode, IntelliJ, or Eclipse. What’s more, apps are pushed without wires! So now that I found something extremely useful that could be done with the new programming language I am psyched to push the limits. I’ve been mostly quiet on my blog but more active these days on Stackoverflow with questions and answers as I explore.

Side note
If you are getting an error “attempt to call method ‘getContentWidth'” while trying to follow one of the various tutorials or examples out there note that version 2012 of the studio has recently been released and you should upgrade. Some of the examples were built against a beta of the newer SDK and you will no doubt hit the issue unless you’ve upgraded within the last couple of weeks. Also note that you should rebuild and redeploy the player on your device using the newer SDK to avoid the error.

Watching the text scroll in…


…then I watch it scroll away again! Have you ever wanted to do something with your software product that in all practicality was quite trivial? Have you later found out that to accomplish your task you had to entertain the entirety of a software ecosystem, most of which you didn’t create or have no control over? Hi, I’m Cliff. You’re here because you’re trapped behind a monitor watching cryptic text scroll up the screen at lightning speed. I’m here to remind you that you are not alone. Maybe you just wanted to patch a label on an app so that it aligned better with some other on-screen components. Maybe you merely wanted to borrow an algorithm that groups a bunch of stuff by individual days and labels them accordingly. Maybe you just wanted to run a code generator that promises to recreate a programming interface in a given language. Whatever the case you feel trapped because as the text scrolls by, you can smell your hard drive capacity nearing zero. You feel frustrated because you’re certain that the files currently downloading to your computer are identical to files in another location on the same machine but because of some cruel curse placed on you by the overlords of IT you are constrained to using them only with another product and not with the thing you are currently working on.

The correct use of software
I’d like to begin today’s topic by discussing use and reuse of software. As a developer, many of us are accustom to thinking in terms of source code. It is the primary means by which we communicate with the machines around us. I’d like to first highlight the one most overlooked principle of software design on the planet. Source code has only 2 uses. It’s primary use is to feed into the compiler and produce the thing we actually do use. It’s secondary use is a means of communicating with other like-minded developers what the overall flow and intent of a piece of software really is. I present this as overlooked and undervalued because the majority of us still believe software has other uses! Many believe that by placing source code on or scraping source code off of the clip board that they have somehow “used” it. While most will agree that copied code creates a problem some will argue that moving code solves the problem. In other words the argument goes, “you shouldn’t copy/paste, instead you should cut/paste!”

Whether you copy or cut source code you are not using or reusing a damned thing. Remembering what I started to explain above, using source code involves one of two actions, feeding a compiler or conveying the flow of logic. What gets often confused is the thing that comes from the source code is the thing we are really interested in. This is the thing that we really intend to use. When you copy or move text around in you’re editor you are merely altering the way in which you interact with your compiler. I’ll draw a line of abstraction here as well as you are actually changing the way you interact with your build toolchain. Think, for a moment, of a toolchain or better yet a tool. A screwdriver doesn’t care if you interact with it using your bare hands, some gloves, or a pair of pliers. Likewise your build toolchain doesn’t care if you’ve moved a snippet of source code from one file to another. The output will vary but you have not “used” that output.

Behavior independent
If you can understand that cut/copy/paste relates to using your editor rather than your software then we can entertain the other thing that is often tied up in our misunderstanding of software use. Inserting or removing source code (by either cut/copy/paste) affects the “behavior” of the thing that your toll chain produces. Confusion comes from the thinking that application behavior is somehow tied to or the same as the source code it was created from. That idea is further reinforced by the use of debuggers that allow us to step through and execute lines of source code as if they were actual executables! To really understand the blur try the following exercise. The next time you feel as if you’ve successfully re-used an algorithm via the clipboard, take those same clipboard contents and place them into an empty text file. Save the text file using whatever extension and file system you like. start your stop watch (and ideally a video camera recording session). Execute the algorithm from the source file. Stop the stopwatch (and video recorder). Now measure the time (and effort if you video recorded yourself) between start and finish. The inverse of your measurement represents the total percentage of use you get out of that source code. The most prominent thing that would come from such an exercise is what is involved in replicating the behavior you hoped to achieve through the use of source code. The exercise is meant to illustrate behavior independent of and established software product. In even the most optimal cases where your source code is a scripting language you will see a disproportionate measurement of time and effort to recreate the behavior because of the other very overlooked and heavily misunderstood concept in software design…

Dependencies
Because many developers see the world through source code much is overlooked and underestimated in the way of dependencies. In all but the most obscure cases source code has dependencies. Unless you obsess over dependencies constantly you will not see them until they come crashing down on you. An exercise in agile software engineering is to reduce/remove as many of the dependencies as possible while still maintaining a true software component that illustrates the behavior you are after. The software component is not represented by source code (ignoring scripting languages for now). The software component is where the true use and reuse begins. The massive dependencies that unnecessarily sneak their way next to the behavior that you are after. I would go into a whole dissertation of dependency management, isolating components by exposing independent behaviors, and rapid feature based delivery but I feel the above exercise is enough to illustrate my current frustrations while proving a subtle point. When you go to exercise a piece of code or better, trigger a given behavior there exists a certain amount of dependencies. These dependencies are often mis-represented as more and more code is added to a given project. Time causes dependencies for other behaviors to obscure the dependencies of the behavior you are after. It is also these same dependencies that have me watching the text scroll in…