Developer Week in Review: Adobe raises the white flag on mobile Flash

Adobe immobilized mobile Flash, Eclipse joins the vanity language fad, and one man asks if brainteasers really find good programmers.

To err is human, to err publicly is just plain embarrassing. I ran an item in last week’s review that turned out to be kinda stale news. How stale? Well, it dated back to the last Bush administration. That stale …

Moving forward, I’ll try to avoid posting “classic” developer news, and keep things on the cutting edge. Such as:

Flash – 0, HTML5 – 1

Flash and HTML5For a long time, it appeared that Adobe Flash was going to become the de facto mobile application development platform. Apple’s intransigence to adopt Flash on mobile Safari was considered a major knock against Apple, and when Apple opened the door to AIR-based iOS native apps, it was seen as Apple caving in to the desire for Flash developers to be able to deliver their apps onto iOS.

Somewhere in there, however, HTML5 came along and stole Adobe’s lunch money. Adobe appears to have moved on to Kübler-Ross stage five, and has accepted that HTML5 has trounced Flash, at least in the mobile arena. The company has signaled to their employees that moving forward, Flash will not be supported on mobile platforms.

This is a much bigger story than just mobile, however. Mobile web traffic now accounts for 7% of the total, and is growing at a rate of nearly 1% every three months. As tablets become more popular, this number may skyrocket. Web content providers are unlikely to commit to developing web pages that can’t be used well by such a growing demographic, and publishers/developers are likely to shift from Flash to HTML5 for RIA development. Adobe has a leg up on other tool chain providers because it has rich integration into tools such as Photoshop and Illustrator, but it will have to fight to keep this position.

On the mobile app side, Adobe can try to promote the AIR-to-native path, but it’s going to be competing with a growing number of “write-once, run-everywhere” companies such as Appcelerator, as well as companies that choose to simply develop natively.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

Working toward the one-language-per-developer ratio

Frequent WIR readers will know that I’m no fan of language dilution, the process wherein new languages are developed and promoted with such frequency that software engineering becomes a Tower of Babble. It seems like a necessary step in the developing hubris of an organization that it decides to have the one true language that will make life a programmer’s paradise. Google has done this several times, most recently trying to replace JavaScript. Now, the normally staid Eclipse foundation has joined the fray with Xtend.

Extend joins C# in the “looks just like Java, if you squint” language camp. The good news is that as a JVM-based language, it can share libraries with Java, so it’s not starting from scratch. New code created in Xtend can be used by Java developers. But still, do we need another pretty-close-to-Java language? I spend my days coding alternately in Java and Objective-C, and the cognitive dissonance set up as I switch back and forth can generate major cranial pain. Is it ‘this’ or ‘self’? Do I send a message with a dot or by putting it inside brackets? It’s much easier to switch between languages that share nothing in common because it’s the small differences that screw you up. Xtend is going to be another language close enough to one I already know to make me go nuts remembering the deltas between the two.

Because it’s the only shape that can’t fall into a manhole, that’s why!

Work long enough in the industry, and you’ll end up interviewing for a company that thinks trivia and brainteasers are a good way to test applicants. Increasingly, companies seem to think that tests and code challenges are the best way to find the “best of the best.” Neil McAllister has an interesting essay in InfoWorld questioning if this really leads to the desired outcome.

I tend to agree, somewhat. Tests that require an applicant to pull obscure or advanced knowledge out of his or her head aren’t good tests because they are essentially memory exercises. The best “challenge-style” test I ever had was when I applied for a job at ITA, now (ironically) a part of test-junkie Google. They sat me down in front of a system with carte-blanche Internet access and the ability to install any tools I wanted, and to use any language. Then, they presented me with a heuristic challenge: as I remember, it was to find all the possible anagrams of varying lengths you could find in a provided dictionary.

What I liked about this test was that the company seemed interested in my process, rather than my ability to immediately churn out the right answer. I sat with my minder for several hours, refining the code, adding features that he requested — much more like pair programming than a pure test. At the end of the day, they knew how I worked, how I found things I didn’t know or remember, and my coding methodology. It was time-intensive, but much more useful, to my mind, than knowing why manhole covers are round.

Got news?

Please send tips and leads here.


tags: , , , , ,