First, by reflection... @firstbyreflection - Tumblr Blog

(via Guy In The Way Of Proposal Photo Becomes "In The Way Guy" Internet Meme | Happy Place) A meme is born!

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](https://en.wikipedia.org/wiki/Moore%27s_law) along the way. An interesting sidenote is how Moore's Law actually works (computing gets an [order of magnitude](https://en.wikipedia.org/wiki/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 insght, and the engineering mastery to proceed to the next step." Now, I really want one of [these](https://play.google.com/store/devices/details?id=chromebook_pixel_lte).

#Google #Pixar #Chromebook #Moore's Law

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

#JustMigrated

The cracks are starting to form...

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.

#JustMigrated

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.

via msn.foxsports.com

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.

#JustMigrated

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):

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):

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.

via lostechies.com

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.

#JustMigrated

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.

#JustMigrated #Dev Tips #JavaScript

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.

via arstechnica.com

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.

#JustMigrated #AAPL #HyperCard #memories #RIP

Are you a brogrammer and is that a bad thing?

"I think what has changed," agrees my Anonymous Female Tech Authority, "is that engineers are thought of as awkward tech nerds with glasses. And now they are beer-slugging dudes who stare at sales ladies' boobs."

via gizmodo.com

The recent run on brogrammers and their taking over of the tech space is greatly exaggerated. Just like most media-spawned stories during an election year, the truth is sometimes lost in search of good headline. The enterprise software space has been rife with so-called brogrammers for years. But now that they've reached the start-up world that's the darling of the media, people have noticed. Bottom line, a brogrammer is not a bro and a bro would never survive the pace of the start-up lifestyle.

#JustMigrated

An awesome talk on Dissonance Theory

via youtube.com

Why people retreat to their original opinions when provided evidence that contradicts that position. This lesson is crucial on how to effectively influence others and reconcile our morality and judgement. We have to live with dissonance. "When a friend makes a mistake, the friend remains a friend and the mistake is still a mistake."

#JustMigrated

Apple Reports Second Quarter Results

Gross margin was 47.4 percent compared to 41.4 percent in the year-ago quarter

via businesswire.com

That's all you need to know. Nearly half of all AAPL's revenue is profit. Net Profit is increased 94% Year-over-year. Wow!

#JustMigrated

Real life grown-up August Gloop

via buzzfeed.com

Joey Chestnut has nothing on Alexander Valov, pictured, the winner of Moscow's caviar eating contest. Held on April 20, 2012, the contest challenges eaters to consume 500 grams (a little over 1 pound) of the pricey preserved sturgeon eggs in the shortest time period. That's roughly a CLS550 Coupe Sasha is shoveling down his gullet there. Capitalism is alive and well in Russia, my friends.

#JustMigrated

This is how every software company should be run

At a lot companies, this is where you’d see me writing something like, “so I’ve decided to leave $COMPANY, take a sabbatical, and then join $OTHER_COMPANY to find new challenges.” At Fog Creek, that’s not how it works. Joel and Michael have a strong attitude that good developers should be rewarded as developers. When I went to them and told them that I wanted to get new experiences and get back into the writing part of writing software, they were really happy to make that happen.

via bitquabit.com

There's a lot that Joel Sposky has done for the software industry but I think this is one of the most significant. To reward technical people with technical responsibilities. Making a great developer into a mediocre manager costs the organization double. Tying compensation to number of direct reports is a non-starter strategy in the software business. And just about everyone is in the software business these days.

#JustMigrated

This line of argument is how we got the TSA, and how they squandered billions fondling balls and confiscating nail clippers

Testing like the TSA David Apr 11

84 comments Latest by Cássio Marques

When developers first discover the wonders of test-driven development, it’s like gaining entrance to a new and better world with less stress and insecurity. It truly is a wonderful experience well worth celebrating. But internalizing the benefits of testing is only the first step to enlightenment. Knowing what not to test is the harder part of the lesson.

While as a beginner you shouldn’t worry much about what not to test on day one, you better start picking it up by day two. Humans are creatures of habit, and if you start forming bad habits of over-testing early on, it will be hard to shake later. And shake them you must.

“But what’s the harm in over-testing, Phil, don’t you want your code to be safe? If we catch just one bug from entering production, isn’t it worth it?”. Fuck no it ain’t, and don’t call me Phil. This line of argument is how we got the TSA, and how they squandered billions fondling balls and confiscating nail clippers.

Tests aren’t free (they cost a buck o’five) Every line of code you write has a cost. It takes time to write it, it takes time to update it, and it takes time to read and understand it. Thus it follows that the benefit derived must be greater than the cost to make it. In the case of over-testing, that’s by definition not the case.

Think of it like this: What’s the cost to prevent a bug? If it takes you 1,000 lines of validation testing to catch the one time Bob accidentally removed the validates_presence_of :name declaration, was it worth it? Of course not (yes, yes, if you were working on an airport control system for launching rockets to Mars and the rockets would hit the White House if they weren’t scheduled with a name, you can test it—but you aren’t, so forget it).

The problem with calling out over-testing is that it’s hard to boil down to a catchy phrase. There’s nothing succinct like test-first, red-green, or other sexy terms that helped propel test-driven development to its rightful place on the center stage. Testing just what’s useful takes nuance, experience, and dozens of fine-grained heuristics.

Seven don’ts of testing But while all that nuance might have a place in a two-hour dinner conversation with enlightened participants, not so much in a blog post. So let me firebomb the debate with the following list of nuance-less opinions about testing your typical Rails application:

Don’t aim for 100% coverage.

Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink.

You’re probably doing it wrong if testing is taking more than 1/3 of your time. You’re definitely doing it wrong if it’s taking up more than half.

Don’t test standard Active Record associations, validations, or scopes.

Reserve integration testing for issues arising from the integration of separate elements (aka don’t integration test things that can be unit tested instead).

Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you’re there!)

Don’t force yourself to test-first every controller, model, and view (my ratio is typically 20% test-first, 80% test-after).

Given all the hundreds of books we’ve seen on how to get started on test-driven development, I wish there’d be just one or two that’d focus on how to tame the beast. There’s a lot of subtlety in figuring out what’s worth testing that’s lost when everyone is focusing on the same bowling or bacon examples of how to test.

But first things first. We must collectively decide that the TSA-style of testing, the coverage theater of quality, is discredited before we can move forward. Very few applications operate at a level of criticality that warrant testing everything.

In the wise words of Kent Beck, the man who deserves the most credit for popularizing test-driven development:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

via 37signals.com

Great sanity check by David of aaaa37signals discussing the cost of testing and chasing 100% coverage. While I love the analogy to the TSA, I'm not so sure code coverage isn't a noble goal, at least in the enterprise software realm. To me, the real value of unit tests is not protecting the code from mistakes I typically make but rather the mistakes that the next developer may make. By the time, code reaches production and needs to be refactored, it has undergone many (many) iterations, and hopefully, is concise, succinct, and descriptive enough to be maintainable. What isn't always obvious (though, probably visible in some version) are the multiple layers of intention that got to that end. Unit tests are one window into that thought process. Ends and means are often different when it comes to code.

#JustMigrated

The Free Universal Construction Kit

via fffff.at

How awesome is this? Having loved Legos as a kid and seeing all the new generation of construction toys my boys have to play with today, these are a dream come true. Now we can mate Tinkertoys to Legos to Lincoln Logs all in the same piece! The Free Universal Construction Kit is a set of 80 interoperability adapters between 10 popular construction toys including the aforementioned sets.

They're also available as download if you have your own 3-D printer. Now to I finally have a reason to buy a 3-D printer.

#JustMigrated

Software is the future

I've heard many times how software and the people (architects, designers, developers, testers, et al) that make it happen is the currency of the future. How companies and industries will have to learn to do more with less and make up the difference with software. The other side of that equation see it that companies are replacing people with robots and processes. So how are we, the implementers of software, supposed to operate in order to be most effective? The Agile process has taught us our goal should not be to create perfect software but to gather feedback to eliminate the bad software. Well, what if those giving the feedback are incentivized to not give genuinely useful feedback since it's quite possibly their job they are eliminating?

My task as a developer is to decompose a complex problem into easily solved or solvable problems that limited computer logic can accomplish that task. I can spend the time to learn the business domain as well as the back of my hand or, more often, rely on business analysts, product owners, subject matter experts to fill in that gap. The problem that I've seen in more than one Line-Of-Business application is that those people may not be in the best position to offer constructive feedback. Professionals, which is anyone who gets paid to perform a task, want to feel valued. They want to be the keeper of the "secret sauce" that makes the machine work so well. They don't want their contributions reduced to the sum of its elementary parts. It devalues their effort, experience, and training. They don't want to see their legion reduced or eliminated by process or software.

That is the single greatest hurdle to producing quality effective software. We are using requirements from sources that have no incentive to produce quality or even valid requirements. By de-humanizing the process and workflow, we de-incentivize the very people we are trying to help.

#JustMigrated

The Daily Mash - Why I am leaving the Empire, by Darth Vader

I hope this can be a wake-up call. Make killing people in terrifying and unstoppable ways the focal point of your business again. Without it you will not exist. Weed out the morally bankrupt people, no matter how much non-existent Alderaan real estate they sell. And get the culture right again, so people want to make millions of voices cry out in terror before being suddenly silenced.

via thedailymash.co.uk

If I had Galactic Moon Coin for every time I've sound the culture alarm at a company...

#JustMigrated

Trending Blogs

Recently Viewed Blogs

First, by reflection...