Unpopular ideas and why they're worth protecting

I've been thinking a lot about the situation in the SW United States. You know the one, Senate Bill 1062 which was passed by the Arizona Legislature last week and most recently vetoed by Arizona Governor Jan Brewer, ironically, at the behest of at least three state senators who "made a bad decision in a rushed process." The process was pandering to the state's constituency that no longer thinks the right is far right enough. The bill, which at two pages in length is a nice contrast to the usual Federal bills that obfuscate by expanding to thousands of pages, allows for the "Exercise of religion [which] means the PRACTICE OR OBSERVANCE OF RELIGION, INCLUDING THE ability to act or refusal to act in a manner substantially motivated by a religious belief, whether or not the exercise is compulsory or central to a larger system of religious belief." Of course that is meant to be a shield against litigation and, in effect, allowing American business to discriminate. 

At first, I had the same general reaction of as a lot of the world; one of shock and dismay at the seemingly backwards step away from the tolerance and compassion that this country has worked so hard for in the last half-century. Upon further reflection, however, I can understand it. I don't support it by any measure. But I can see the value of a government that would allow such unpopular opinions to not only exist but be heard and legislated. Change only occurs if unpopular opinions are allowed to be disseminated and considered. That is how progress is defined. Benjamin Franklin stated that dissent is the highest form of patriotism. No one is forced to live in Arizona, Massachusetts, California, Texas nor any state which upholds strongly held beliefs on one side of the sociopolitical spectrum or another. In our republic democracy, we are free to live, vote, or legislate to our own values. And if Governor Brewer's veto stands, isn't that democracy, complete with checks and balances at work?


Pixar leveraged Moore's Law to create Toy Story and now Google is following their plan

Toy Story 3 trailer-002

image courtesy: Bill Toenjes

A terrific yarn from Alvy Ray Smith, one of the co-founders of Pixar about how they knew they could create Toy Story, given enough time and resources in the 1970s. They knew that Pixar would have to spend its time building and innovating hardware instead of making movies in the early years in order to help Moore's Law along the way.

An interesting sidenote is how Moore's Law actually works (computing gets an order of magnitude better every five years) and why the intervening years matter (because the thought process to imagine those gains have to be acquired). Consequently, what Pixar did for movies is what Google is trying to do with the web. That's why they are building Android and Chrome, which are noticeably heading towards convergence. Google wants to own the web and everyone who interacts on/with/through it. They are predicting a future where everyone utilizes the ubiquitous cloud to do things we aren't even currently doing at all.

In order to imagine the computing paradigm of 2020, Google has to push the evolutionary crank around one cycle at a time. That's why they marketed their new Chromebook Pixel as the device for what's next. We don't know what's next but Pixel has to be built to "gain the courage, the insight, and the engineering mastery to proceed to the next step."

Now, I really want one of these.



Flickr tries again to be relevant by offering 1TB free for all users

I've been a flickr user since 2005 though, I let my pro membership lapse about 3 years ago. I stopped paying for it because it wasn't useful or relevant anymore. Flickr once defined social media long before twitter or facebook were dreamed of. Then Yahoo! came and acquired them. I thought it was a good thing at first. However, it didn't take long until it was obvious Yahoo! had bigger problems that keeping flickr afloat. They basically let a gold mine fall through their grasp as they let user after user leave with hard feelings due to crazy administrative stuff like deleting people's uploads to simple atrophy by letting their mobile apps become stale.

They were first (or close enough) in creating communities of users to contribute and engage in meaningful ways. They were first to offer 'unlimited' storage even if you didn't pay, they kept your images around so that whenever you came back, they would be there waiting for you. They were first in building quality API to interact with other services that people use. They were even first among the vowel droppers of app naming. All of these advantages meant nothing in a few years. I have tried 500px and SmugMug as replacements and none of them felt as seamless in terms of sharing. I loathed uploading directly to facebook but I eventually pulled the Flickr-Facebook integration since the mobile app sucked so bad.

So here we are, in 2013, as Melissa Mayer attempts to buy their way back to relevance. They acquired tumblr today, which I recently began using after choosing the 'Betamax/MiniDisc/HD-DVD' option in Posterous way back when those two were competitors and before twitter acquired Posterous and let that platform wither and die. Another attempt to get back in the game, they've offered 1TB (yes that's 537,731 6.5 Mpx images as their new landing page eloquently reminds me) gratis for all users. So all my images are back and hopefully they can get the photographers and artists back and make this platform a player again. I'm in.

Shells, Terminals, and tmux, oh my!

I've been working in a lot of non-microsoft development lately, namely the xAMP stack. Trying to find a suitable development environment has been a challenge. I've tried Eclipse, Netbeans, MAMP, MacVim and found all of them wanting in some fashion or another. It's either too bloated or slow or just feels wrong. Finally this weekend, I was determined to get back to the root and use Terminal (see what I did there?)

Learning to go CLI after a career in IDE is somewhat intimidating. Luckily, I started learning this stuff in the *nix heyday of the early nineties (I remember reading on USENET that some Finnish guy name Linus was going to port unix to the x86 platform). So I was at least comfortable in vi and bash, if not proficient. Started with plain ole Terminal and quickly moved to iTerm2 and quickly built tmux and I was off. I could do most things on the CLI, from creating directories to vim to executing the occasional sudo make install to get stuff running. 

Ironically, the most taxing thing to learn how to do was to copy a directory and all its contents to a new directory. I tried copydir and cpdir without any success. With a little help from my favorite search engine, I found a nice unix command line primer on ibm's site of all places. If you ever need to copy the contents of a directory from one to another, here it is:

tar cf - /path/to/original |  \
  (mkdir -p /path/to/copy; cd /path/to/copy; tar xvf -)

I'm sure there will be more. Now tomorrow I have to switch back to Windows and MS development. I hope I remember how to start Visual Studio.

Key stuck in ignition (or how did we get by before the Internet)

Tonight, I came home and pulled into the driveway as usual and put the tranny in park and turned off the ignition. I've done this a thousand times in my 2005 POS Ford Focus. Pull in, put it in park, turn off, take key, leave. However, tonight, the key did not come out. It felt like I could not turn it all the way to the 0 off position. Turn the ignition back on; start the car; put the transmission in various gears. No luck, the key would not come out.

My first clue to trouble was that I could shift the transmission out of Park without stepping on the brake first to release the Shift/Lock interlock that prevents folks from shifting the car into a moving gear without realizing the consequences and having your foot on the brake pedal. There's a spot next to the shift lever to unlock the interlock device if it's stuck but I had the opposite problem. It was stuck off.

Pull out the smartphone, a quick google search brings me to this page. I push the collar under the shifter back up after it's been placed in Park and et voila, key comes out. Seriously, what did folks do before the Internet. Some folks may ask their preferred supreme consciousness for answers when they do not know the answer. I ask Google. QED

The cracks are starting to form...

via bgr.com

via bgr.com

For all the bravado behind the idyllic synergy behind the Steve Job's Reality Distortion Field, the cracks are beginning to form after his death. These aren't the first signs. I think the message has changed significantly around their core products. Under Steve's rule, we never would have seen an iPad that was thicker, even marginally, than its predecessor. There would be no discussion of A5, A6, O69 processors; Steve preferred to keep those details away from the consumer.

But now, there's political chaos reminiscent of actual corporations rather than the (Walt) Disney-like transcendance that typifies a company with more cash than Amazon, Microsoft, and the US government put together. The SVP of iOS, Scott Forstall, and SVP of retail, John Browett, have been canned and the SVPs of Design, Jonny Ive, and Technology, Bob Mansfield have taken on additional responsibilities. (Even un-retiring in Mansfield's case.

Why Holbrook missed the spirit if not the letter of the infield fly rule

When a rule is barely understood, that’s a problem. When a rule is applied in seemingly counter-intuitive fashion, that’s a problem. When a rule causes fans to flip out, littering the field with debris and causing an 18-minute delay, that’s a problem.

Too bad for MLB that this happened on a one-game wildcard play-in format. Too bad for the Braves for not winning their division and making this point moot. Too bad for the Cards a tainted victory when it may not have made a difference. Too bad for the umps that this happened less than a month after the NFL interception-touchdown.

Backbone.js Is Not An MVC Framework

There Are No Controllers In Backbone

There simply aren’t. In spite of the documentation saying that routers or view may be sort of maybe almost kind of close to some of what a controller might do, there are no controllers. It’s not a construct that exists in the backbone namespace, and there’s no implementation that represents what a controller does, architecturally.

A router is not a controller. It’s a router. A view is not a controller. It’s a view. Yes, both routers and controllers share some of what a traditional MVC framework would call a controller. No, neither of these is a controller.

More MVP Than MVC

I’ve spent 5 years building MV* family applications in thick-client / GUI systems (Windows / WinForms / WinMobile) and on the web (Rails, ASP.NET, ASP.NET MVC, etc). Backbone clearly fits in to this family, but it’s also clearly not MVC. My opinion says that it’s closer to MVP, where the backbone view is closer to a P (presenter) and the HTML/DOM is the V (view).

Consider this picture of an MVC process flow (from Wikipedia):

NewImage

Here, the models contain data which is used to populate views. Actions that a user initiates are handled by the controller which processes the request and updates the models. The models are then fed back to the views and the cycle starts over. It’s cyclical in nature.

And now consider this picture of an MVP process flow (from LessThanDot.com):

NewImage

Notice the difference? Right – it’s not circular. That’s the big difference between MVC and plain-jane MVP (a.k.a. “passive view“). MVP does not work in a circular fashion the way MVC does. Instead, it relies on a presenter (the “P” in MVP) to be the coordinating brains of the operation. The presenter in an MVP app is responsible for taking the data from the models and stuffing it in to the views. Then when an action is taken on the view, the presenter intercepts it and coordinates the work with the other services, resulting in changes to models. The presenter then takes those model changes and pushes them back out to the view, and the elevator of moving data up and down the architectural stack begins again.

Does the idea and responsibility of a presenter sound familiar when thinking about Backbone? It should… it fits almost concept for concept with Backbone’s views, in my mind. But that doesn’t mean Backbone is an MVP implementation, either. It only means that views should be thought of as presenters, not controllers.

A great reminder on why backbone.js is not a MVC (nor MVVM, MVP) framework. If anything, it's best described as a MOVE framework. Models that represent the data or nouns of your application. Operations that represent the verbs of your operations. Views that combine the nouns and verbs and present them to the the user. Finally, there are events that bind all the other pieces together and allows for a common communication channel between them.

Flip your JavaScript Switch

No one likes code conditionals, right? They're difficult to read, extend, and maintain; primarily because they intermingle data with logic. They're why we put up with bloated IOC containers, just to be able to avoid using switch and nested if statements. In JavaScript, we have a better way. Here's a typical switch statement in JS:


var label = switch (dataTypeId) {
case 'revenue' : 'Thousands of USD';
break;
case 'census' : 'Number of Customers';
break;
case 'inventory' : 'Hundreds of Units';
break;
default: '';
}

So we have to deal with ubiquitous break token, the extra case structure, and lengthy code bloat to make a simple decision. Got code smell? Here's the alternative, use object prototypal extension and JSON interpretation to create a hash instead.


var labelOptions = {
'revenue' : 'Thousands of USD',
'census' : 'Number of Customers',
'inventory' : 'Hundred of Units'
}
var label = labelOptions[dataTypeId] || '';

Et voila! We have separation of concerns, data and logic. We have easy extension by adding another property to our labelOptions object. We have more streamlined code without intermingled execution tokens and is easier to grok. Thanks to JavaScript's treatment of functions as data type, you could even return functions instead of simple expressions. So before you reach for that switch construct again, think about hashing instead.

25 years of HyperCard—the missing link to the Web

I grew up in a box-centric culture at Apple. If I'd grown up in a network-centric culture, like Sun, HyperCard might have been the first Web browser. My blind spot at Apple prevented me from making HyperCard the first Web browser.

As the 25th anniversary of HyperCard approaches, ars technica takes a look back at the cool little program that could. I remember being a college freshman with my first Macintosh (Classic) in 1990 trying to figure out this desktop and GUI. HyperCard was instrumental in helping me understand this computing paradigm. Being able to put media and content on each Card and linking them into stacks.

Of course, as a comic book geek at the time, my first task was to catalog my collection. After some two months of effort, in between lectures, parties, and sleep, I finally had my first HyperCard array of my collection of New Mutants, Batman, and Grendel. I had fields for issue number, date, condition. How I longed for a way to capture an image of the actual book!

So on August 11, 2012, please join me in pouring one out for HyperCard which died in 2004 and its creator Bill Atkinson lamented the above-referenced quote to what it could have been.