As someone who has used Macs since my dad purchased a Mac SE in the 80s, certain segments of the Apple-using population are a constant source of embarrassment to me.

Like this one: Sorry Adobe, You Screwed Yourself.

In what universe not solely populated by overinvested Apple fanboys is it a good idea to anthropomorphize and simplify the complex relationships between multi-billion dollar companies to what is, essentially, not sticking up for your bro?

Or, less flippantly:

Apple in the 1990s without the rosy glasses

I think it’s pretty revisionist to say it’s Adobe’s fault that they started focusing on Windows in the late 90s.

Apple had really crappy developer tools. It took a third party, Metrowerks, to make a usable, let alone decent environment. If it wasn’t for Metroweks, Apple would have been crushed. Meanwhile, during all of this, Apple would release technology after technology that was poorly documented and poorly supported. Does anyone remember Quickdraw GX? OpenDoc? The promises of Rhapsody and Gershwin?

Meanwhile, Microsoft was going on all cylinders with developer relations. For all the crappy Win95 programs, at a certain point it did everything Apple did only with more stability and without the weaknesses. Of course, Microsoft then screwed it all up with horrible security and generally bad PR. But really it was Apple who was the cause of most their own problems in the 90’s. They didn’t need anyone else to drive the nail in their coffin. They were doing poorly enough by themselves. If not for NeXT and Jobs, Apple would have almost certainly ceased operations.

People like to make fun of Ballmer’s “Developers! Developers! Developers!” monkey dance, but it really was one of the things that Microsoft did exceedingly well when compared to Apple. They coddled their developers: provided them with roadmaps, sneak peaks, and resources that Apple (to this day, in some parts) didn’t come close to matching.

So Apple didn’t exactly have the greatest record when it came to thinking and caring about their developers.

But it makes sense if you look at it this way…

John Gruber and many others have very comfortably put themselves in Apple’s shoes. They’ve been able to easily — and rightly — point out that many of Apple’s recent moves make sense when viewed from Apple’s perspective.

Why then, is it so hard to afford that same understanding to other companies?

Adobe, at the end of the 90s was faced with a choice: to continue devoting significant resources to a platform that appeared, from all indicators, to be dying, or to refocus efforts on Windows, which was in no danger of disappearing.

Even OS X didn’t really change things all that much from the perspective of major software houses trying to determine the extend of their Apple engineering resources. Until then, no company in the history of the industry had successfully introduced a new OS outside of Mac Classic and Windows. Be tried it. IBM tried it. NeXT tried it. They all failed.

The logical choice, and in many ways the responsible choice for companies like Adobe was to look towards Windows for growth.

So now to have so people point fingers at Adobe’s decision a little over a decade ago and say “I told you so!” is fairly exasperating and annoying.

• Many of them probably hadn’t even used Macs yet at that point.

• A person, using knowledge contemporary to the late 90s, could have not reasonably advised a company to stick it out with Apple. Any arguments to do so would almost have to be an argument made from unreasoning emotional investment. Unreasoning emotional investment is great for some. It’s not for a company aiming to keep its employees employed and its investors happy.

These are corporations we’re dealing with here. Let’s not turn this into the equivalent of a spat between once best friends.

Adobe wants to do what’s in their best interest and what’s in the best interests of their platforms (Flash, AIR, etc).

Apple wants to do what’s in their best interest and what’s in the best interests of their platforms (iPhone, iPad, etc).

To crib from the Joker, why so personal?

Why is there a need to point with gleeful fingers that Apple is wreaking vengeance against some gross injustice?

Keep it civil. Keep it contextual. And for all that is holy, keep it sane. Unbridled zealotry is ugly in any form.

James Tauber has a post up where he goes through a list of languages he’s learned in chronological order. Thought it was neat, so here’s mine. I’m not including anything I only dabbled in, like Erlang or Ruby.

• BASIC Apple ][

• HyperTalk On my dad’s Macintosh SE. I remember trying (unsuccessfully) to make a Myst clone.

• Logo Fear the turtle! I actually taught this in summer camp in 2002. Logo had progressed at that point where you could launch new threads to do things like make a basketball dribble autonomously whilst a player ran down the court.

• TI-BASIC On the TI-83. Gave me something to do during Algebra. Highlight? Writing a Legend of the Red Dragon clone. I can still type faster on the TI-83 than I can on most smartphones.

• C Picked up a book. It was something like Learn C on the Macintosh. It included a stripped down version of the Metrowerks compiler.

• HTML/CSS There wasn’t much of CSS at that point. Ah, Geocities. My first site was about cheat codes for the game genie.

• C++ In high school. Using the old Borland Turbo C++ suite. I miss it sometimes. There was a note of elegance to its expanses of pixelated text and blue.

• Perl In high school. At Whitman, a bunch of us wrote an online homework submission system in Perl, and tied it in to me school directory. Interesting times, though at its peak, only about half the teachers used it.

• PHP In high school. Used it because I wanted a blog and I didn’t like pushing via FTP with Blogger (still operated by Pyra at the time).

• Java In college. I use the term “learn” loosely. I’ve forgotten most of it.

• C++ In college. More C++ stuff.

• Bash/shell scripting I brough my old PowerMac 8500 tower into college. At the time, it was running LinuxPPC. I had a version of mkLinux running on an old-world PowerMac at home, so the PowerMac 8500 felt like a speed demon to me. Eventually switched over to Debian PPC, before dumping it all for a Powerbook running OS X 10.1.

• Python In college. Python rocks. I got into it because it seemed to disdain so much of what I hated about Perl.

• Javascript Post college. Most of my Javascript knowledge comes from on-the-job experiences. Decent language, if having a larger share of implementation quirks than normal.

• Objective-C Again, I use the term “learn” loosely. Like what I saw, even if the super verbose parameter names still drive me batty sometimes.

• Actionscript 3 Learned this for a Flash project. In many ways, feels like Javascript Done Right.

Over the past several months, I’ve interviewed a bunch of people for a Front-end Developer position at Threespot. Candidate quality has varied, but I’ve gradually developed an internal list of things prospectives should know going into an interview.

This doesn’t cover Javascript. But I will state here that Javascript is equal to HTML/CSS in the front-end developer’s skill set. The complete candidate knows Javascript and at least one framework.

This also doesn’t cover accessibility and related best practices.

Caveat: technology changes, so really, this list can and will fall out of date. Also, this list is obviously non-exhaustive.

The basic

These are things that every front-end candidate should know well:

• The difference between margin and padding, and how margin, padding and width interact with the box model.

• float, float-clearing, and the different methods of clearing floats. Also how floats affect the flow, and the uses of floats in general.

• The differences between class and id, and how CSS specificity uses each.

• CSS sprites, and using :hover and background for rollover images.

• Firebug. Really, I’ve not met a single good front-end developer who doesn’t have Firebug in their arsenal.

• CSS resets: what they are, why they’re useful. Eric Meyer’s is a common one, but others do exist.

• Class composition with multiple classes.

• The concepts of semantic markup and progressive enhancement.

• Image production. You should be able to get around in Photoshop well enough to cut your own art.

• Knowledge of the font stack: what the common web fonts are.

The intermediate

Good front-end candidate should know these items in addition to the stuff above.

• Transparent PNGs, IE6, and the use of filters. They should also know where a transparent gif will serve.

• Conditional stylesheets for IE browsers.

• Using display: block and display: inline to achieve and resolve layout issues.

• The use of position: absolute and position: relative to achieve various layout and centering (both vertical and horizontal) effects.

• background repeats: where to use repeat-x or repeat-y, and when to anchor background images to corners.

• In addition to Firebug, having an IE Debug toolbar, plus being familiar with Webkit’s inspector.

• Knowledge of common cross-browser issues. See below for a list.

• Form styling: when to use padding, when to rely on line-height, how borders, backgrounds and margins are rendered in multiple browsers.

• The traits of image formats like gif, jpeg or png; and where/when each format should be used.

• Using the technique of super long or tall background images to do things like decorated elastic buttons or containers.

• Faux columns.

• Flash embeds. i.e., swfobject and the like.

• The use of negative numbers for margin and the like.

The advanced

Ideal front-end candidate should know this stuff. Some of these are more soft and less strictly technological.

• Judging and evaluating a design comp for cross-browser issues.

• Similarly, judging and evaluating a design comp for places that require disproportionate developer effort for small visual gains.

• Deciding when the extra effort required for the two points above are necessary or preferred, and when the extra effort is unneeded.

• Developing a balance in the markup between potentially fragile cascades and more robust and verbose containments.

• overflow: hidden, and when it should be used to preserve aesthetic integrity.

• CSS2 and CSS3 selectors, and when they can be used versus when a more compatible fallback should be used.

• HTML5. Should at least be familiar with the goal, if not the nitty gritty.

• Embeddings fonts into pages via sifr, custom image replacement, and browser-support font mechanisms.

Terms, browser bugs, and patterns

A majority of cross-platform bugs are caused by a minority of fundamental browser issues. Additionally, certain fixes have been accepted into the standard language of front-end development. The intermediate candidate should have an understanding of most of these. The ideal candidate should know all of these well.

• clearfix

• IE double margin

• IE peek-a-boo

• IE select z-index

• z-index and position: relative

• Unclickable anchors and position: relative

• hasLayout, zoom: 1

• box model differences

• min-height

• expanding box problem

Resources and sites

Good candidates are familiar with most of these.

• A List Apart

• QuirksBlog

• Position is Everything

• 24ways

• Smashing Magazine

• StackOverflow

Ämne: Re: Dear mr. Jobs
Från: Steve Jobs <sjobs@apple.com>
Datum: 5 mars 2010 17.01.29 CET
Till: Jezper Söderlund <>
Return-Path: <sjobs@apple.com>

No.

Sent from my iPhone.