There’s are two reasons for this: 1) I don’t want to be on call all the time, and 2) I don’t want to spend a lot of money. Reason #1 is frequently misunderstood: yes I know that I can simply turn off the phone. Duh. But what’s the point? If I get a cell phone and have it off all the time, it’s just as good as not having one at all. Besides, even if I did, I would be tempted to have it on all the time, and that’s the problem for me. I don’t trust myself not to answer the phone when I shouldn’t.

(For what it’s worth, I hate it when people interrupt an in-person conversation to answer the phone. I also hate it when people make a call in the car, or in a closed place where other people are forced to listen to your conversation and can’t have one of their own. It’s obnoxious. Stop it.)

Reason #2 is an easier point to get across: how much are you all paying for your iPhone plans again? (I think my bro pays almost $100/month.) I’m not willing to throw that much cash at AT&T.

My current setup is a 2-year-old MacBook, and a Skype subscription. For 45 euros (that’s ~$68) per year, I get unlimited phone calls to the U.S. & Canada and voice mail.

Per year.

Oftentimes I lug my laptop around just to be able to have Skype access, though. And that also requires that there’s a wireless hot spot I can access, or have access to a friend’s wireless network. So it’s definitely inconvenient at times.

I’m looking to maybe get a cell phone if it can fit my requirements. Here they are:

1. The “phone” must be an iPhone or iPod touch. I’m going to be doing iPhone development, and besides, I’ve used all the other phones a bit and I’ve read about them, and they’re just not going to work out for me. So just don’t bother with even mentioning any other device. Seriously, just don’t.

2. I want a persistent, unlimited wireless data connection, available when I need it, with reasonable coverage. Achieving this must not require a laptop.

3. I will pay no more than $30/month.

4. I do not care about phone “minutes”, and I do not give a shit about SMS or MMS (seriously, why do you guys pay for that crap when you can just use AIM?). I do not want them, nor will I pay for them. I will continue to use Skype.

5. I am willing to entertain hacks or add-ons that can help fulfill the previous requirements (i.e.: if there’s a dongle that acts as a cell phone modem and doesn’t cost much per month, that is acceptable). I am not willing to endure hacks that continually break or are unstable, etc. It can have an up-front time and/or money commitment (up to $200), but this must be a one-time sunk cost only.

6. I must be able to upgrade to the latest software update as soon as it comes out. No delays. (This pretty much rules out any jailbreaking/unlocking of any kind.)

7. I need at least 40 GB of space. My music collection is already 30 GB in size, and I’m not picking and choosing what music I want on my device.

Here’s what I’ve looked into:

1. My bro and dad have a family plan. I could attach on to that, but that costs $10/month just to add another device to the plan, and another $30/month for the data. That violates requirement #3. Also, that would require an iPhone, which, at max, goes to 32 GB of storage, violating requirement #7.

2. AT&T has a pay-as-you-go plan. I would never use the minutes so I would never need to refill. However, it seems that using such a plan, the data is also pay-as-you-go. That’s going to violate requirement #3 as well. Also, still the problem with not enough space.

3. Verizon has a dongle-thingy (MiFi) that hooks into its wireless network and provides a roaming wireless hot spot, but last I checked this was way too expensive. It’s $40/month for a piddly 250 MB/month, and 10¢ per MB above that. Hah! Sorry, but no.

Any other suggestions?

The problem is, the code to load the YouTube H.264 files is entirely custom. What if we wanted to do the same thing for a different video site, like, say, Vimeo? We’d have to write completely new code to account for this.

Well, I want to tackle this problem sooner rather than later. Eliminating more bits of Flash from the web is cathartic. There has been sparse talk about how to implement this (see the ticket for the feature request), but no concrete plans. (@atnan has already figured out a general method for getting H.264 videos from Vimeo.)

I’ve been thinking about this problem for a while. But before figuring out an implementation proposal, we have to think about the goals of such a feature:

1. Easily-supported code. This means that we need to have all site plug-ins go through the exact same mechanism. This includes the current custom YouTube support. We want only one mechanism to maintain. If there are bugs, we can fix it in one place, and all site plug-ins will reap the fix.

2. User-extensible. We want users to be able to create their own site plug-ins and share them with the world, without having to learn Objective-C or go through the horrible UI that is git. Part of this means site plug-ins that are relatively easy to create, with little programming knowledge, if possible.

3. Flexible. Video sites will do weird things. With YouTube, we already have to do HTML scraping for embedded videos. And we can’t rely on the flash variables that YouTube videos include, because sometimes they indicate the existence of a H.264 file that just isn’t there! So we have to test for file existence at a certain URL. In short, the mechanism needs to be able to support whatever video site users think of throwing at it. If we need to add a feature, we want to be able to do so without breaking existing site plug-ins.

4. Secure. One possible example of an implementation is simply to have site plug-ins be executables which return a string for the URL of the video file. But think about how much of a security hole this is: the executable could happily delete your home folder! We don’t want that possibility with our site plug-ins. That can conflict with our goal of flexibility, but we want to achieve a happy medium between the two.

Today, on Twitter, I mentioned that I wanted to get this feature moving, and @boredzo came up with a preliminary implementation: define site plug-ins as a dictionary file. His proposal lacked some flexibility even for YouTube, but it was a good jumping-off point. I spent a few hours looking through ClickToFlash’s YouTube code and created a dictionary file format that I think can reasonably satisfy all of the above four goals.

Because “site plug-ins” sounds boring, and ClickToFlash already is a “plug-in”, having plug-ins for a plug-in is kind of weird. The name “extension” is already used by Firefox (let’s save a rant about Firefox for another day entirely). So I think we need a new name for these site plug-ins.

In the spirit of the cheeky copy on the ClickToFlash website, I’d like to dub this feature “Flash killers”, or “killers” for short. Yeah, yeah, I know, some of you will disapprove, but it’s one of the little things I do to keep me sane as a programmer.

Anyway, I’d like to walk you through three sample killers: two that replicate the existing functionality of ClickToFlash for YouTube, and one that would introduce H.264 support for Vimeo. Note that not a single line of Objective-C code has been written to support killers, at this moment in time. The whole reason for this post is to receive constructive criticism on the proposal before implementation.

For that reason, I ask that you read this entire post before commenting. I’ll explain the decisions behind everything.

As mentioned before, killers are simply .plist files, or a dictionary of objects and keys that define how ClickToFlash will construct the URL for a video file. Here’s the root view of a killer for YouTube:

“Killer Name” and “Video Result MIME Type” are pretty self-explanatory.

Here’s the same killer showing the contents of the “Matching Regular Expression” and “Rejecting Regular Expression” dictionaries:

There are three things that we use in the current ClickToFlash code to check for YouTube videos: the URL of the page that you’re on (the one you see in Safari’s address bar), the URL of the source flash file (the “.swf” file), and the flash variables themselves (which can contain the URL). For embedded YouTube videos, we need to support regex matching of each of these URLs. This killer does not support embedded YouTube videos; I’ll explain more about that later. This one just supports actual YouTube pages.

So for non-embedded YouTube, we just need to match “youtube.com” or “youtube-nocookie.com” at the start of the page URL with an optional “http://” and an optional “www.” (Please note, I am a regular expression rookie, so if you see any mistakes, please let me know.)

The “Rejecting Regular Expression” is the opposite — if the URL matches the regular expression in this dictionary, ClickToFlash won’t attempt to load the video file via this killer. Because standard YouTube pages will also match the regular expression for source URL and Flashvars, which we use to check for embedded YouTube videos, we don’t want two killers matching for the same video. (It actually probably doesn’t make that big of a difference if two killers match a given video, as the first killer to be loaded will just take precedence.)

Here we see support for the variants of YouTube. Remember, YouTube has standard H.264 and HD H.264 versions available. We want to support both, and add support for additional variants from other sites without having to create additional killers (which would cause problems, because the regular expression matching for the killers would be identical, at least in the case of YouTube).

Here, “Display Name” specifies what text will be displayed in the ClickToFlash view if the URL successfully loads. “Return URL” also specifies the steps to construct the URL and the return URL string (the format of which we’ll get to in a moment.)

Here we can see how we construct the URL of the MP4 file for YouTube. ClickToFlash will support a limited number of step “types”, including flash-var-retrieve, regular-expression-match, download-resource, and because of this format, we can add support for additional step types in the future if deemed necessary.

Each step can contain three objects: “Type”, “Victim”, and “Action”. Type indicates what ClickToFlash will do in that step, “Victim” indicates the string to perform the step on, and action represents the specific form of the type of step. For flash variable retrieval, we don’t need an action, because this step simply retrieves the string for a given flash variable (specified in “Victim”). Other steps do require an action: for example, a regular expression match actually needs a regular expression.

In addition, each step always returns a string. If a certain step returns nil, then we’ll cancel out of the killer. The result of each step is stored in an array for later retrieval. So in these two steps, we retrieve the video_id and t flash vars.

In the “Return URL” object, we see how we refer to the results of the previous steps. “%3A” and “%4A” represent the results of the steps in the killer. Why start with “%3”? Because “%0” is reserved for the page URL, “%1” is reserved for the Flash source URL, and “%2” is reserved for the Flashvars string. The trailing character of the entity used for retrieving the results of a single step is to allow you to retrieve results from a different variant, which we see will come handy in a sec.

In this pic, you can see that the YouTube HD variant has no steps. How can that be?! Well, we already retrieved the required strings in the previous variant, so we just refer to them again in the return URL. “%3A” and “%4A” will return the same video_id and t flash vars as it did in the previous variant. If we had a third variant, we could refer to the steps of the previous variant using “%3B” and “%4B” instead.

Why support this? Because it saves processing time, and it will save network time in the case that you need to download an external resource, and need to refer to the same resource in two different variants. You don’t want to download the same HTML file twice to scrape (as we might do for this killer), and you don’t want to spend the CPU time to scrape it twice, either.

Now let’s move on to embedded YouTube. Remember how I said we didn’t want proper YouTube page videos to match for two different killers? Here we use the “Rejecting Regular Expression” to that effect. It’ll match “youtube.com” or “youtube-cookie.com”, but if those strings appear in the actual webpage URL (as it does for standard YouTube videos), then this killer will reject the match.

Here’s how we actually construct the URL. Remember when I said we had to do HTML scraping? Here’s where we do it. Our first step is a regular-expression-match on the source URL of the Flash file, to extract the video_id parameter. Then we actually have to download the HTML source of the corresponding YouTube page, which occurs in the second step. In the third step, we do a regular expression match against the HTML source of the previous step, searching for the flash arguments. The last step searches the results of the previous regular expression result to match the “t” flash var, which is the last item we need to construct the URL.

Note that victims do not need to be single entities, which are the results of previous steps. You can construct strings that include the previous step result as a subset, if necessary.

Also, note the regular expression matching here. (?< ) is a “look behind” parameter, forcing a string to have a certain other regular expression come immediately before the string. Similarly, (?= ) is a “look ahead” parameter.

How does the HD variant for embedded YouTube videos work? Easy-peasy! We’ve already retrieved the “video_id” and “t” flash vars from the previous variant! We don’t need to do any work here. Just construct the return URL using the results of the previous variant (which in this case uses “fmt=22” to get the HD version rather than “fmt=18”)!

There’s one more thing you need to be aware of: in ClickToFlash’s current code, we need to actually check for the existence of a file at the constructed URL in order to make sure that one exists. YouTube sometimes lies, and gives you “video_id” and “t” flash vars even though there’s no H.264 or HD version. But this can be handled in ClickToFlash code — ClickToFlash will just check for the existence of a file at the return URL for you!

I hope you agree, this step-by-step method for constructing URLs is sufficiently powerful to allow for flexibility for the various websites out there. Because the number of steps isn’t limited, if you need to download two external resource files, that’s absolutely supported! If you need to do a vast number of regular expression matches and not just one, that’s supported! And given the flexibility of the “Type” parameter, we can support future step types, like CSS selectors, XPath queries, and possibly even AppleScripts!

How does this live up to our original four goals?

1. Easily maintainable code. A defined set of steps and matching regular expression allows us to write one Objective-C class for every killer.

2. User-extensiblity is pretty evident. Also, I believe the step-by-step mechanism makes it easier for novices to understand how a killer is set up, and attempt to make one of their own if they so please.

3. Flexibility is also pretty evident: this mechanism has been designed from the ground-up to support all the quirks of YouTube, and allows for future-proofing by adding additional step types, so I’m confident that it can handle the majority of the video sites out there.

4. Security: with this proposal, all that a malicious user can do is fetch flash variables, download resources, and match regular expressions on pieces of text. I think that pretty much avoids any potential security holes that such a plug-in mechanism may have. The only exception would be AppleScripts, since they could delete files if they so wanted, but we can discuss whether we want to add support for those or not.

What are the deficiencies in this proposal? I can see a number of them.

1. It’s verbose. I did this on purpose to aid “readability” of the killers, but I can see how it might be annoying to set up.

2. Kind of related to the previous deficiency, the mechanism for referring to results of previous steps is kind of awkward. What if someone had a large number of steps? Or what if they wanted to use a victim such as “http://asdf.com/?%4A=something&%3A=something-else”, and not have the “%4A” match the result? Would escaping the entity work reliably?

3. Localizability. How to localize the keys in the dictionary for other languages, so that non-English speakers can still create killers and get them to run under any system language, including English? Not sure how easy it will be with this mechanism.

I’m not sure the answers to these questions, and maybe they’re things that we don’t really need to worry about. In any case, if you’d like to play around with my Dictionary files, you can access them here:

• YouTube Proper killer
• YouTube Embedded killer
• Vimeo Proper killer

I’ve even added one that should support Vimeo’s H.264 files!

And now that you’ve read through the whole thing, comment away! I welcome any and all discussion, since this is probably the single biggest feature I’ve attempted to undertake in ClickToFlash, and I want to get it right the first time.

I’ve never been involved as a participant, customer, or developer in any of the three MacHeists. So my most recent post was written mainly from the point of view of a conscientious consumer (although, it seems that some will dispute that assertion), analyzing the value of MacHeist to developers purely on a monetary basis.

After posting, I received a tweet asking me if I had asked the developers themselves about their participation in MacHeist. I had initially dismissed this since this was round three of MacHeist, and besides, I’d probably worn out my welcome even before contacting them. But I figured it was worth a shot, so I fired off some e-mails.

To my surprise, almost every developer that I contacted wrote back, and everyone was actually quite agreeable, despite the tone of my previous post. All of the responses I received were thoughtful. One even wrote back in Italian, and was quite poetic. Each probably represented far more than a few minutes of time out of their day to respond to a troll on the internets. For that, I must say that I am quite grateful.

Although a couple developers asked me not to publish their replies to my initial e-mail, some did allow me to do so. Two developers, Oliver Breidenbach of Boinx Software Ltd. and Gus Mueller of Flying Meat, Inc., also answered some follow-up questions. Andrew Welch, el Presidente of Ambrosia Software, Inc., consented to an extended interview.

The sheer amount of words spent on MacHeist in the following responses and Q&As is pretty extensive. I still highly recommend reading them unfiltered, especially the interview with Welch (in which we touch on the iPhone app store, similarities to retail store promotions, the Tweetblast, protectionism, and even penis sizes). Here’s an executive summary of the main points that were made by developers:

1. MacHeist is, first and foremost, used for marketing. This is, by far, its main purpose. All of the developers, even the more well-known ones, benefit greatly from the brand and product awareness generated by MacHeist. They are all happy to sell their apps at a substantial discount in return for the sheer recognition that MacHeist creates for their company.

2. MacHeist is extremely effective at marketing. They do it very well. Time is simply better spent letting the marketers do the marketing.

3. None of the developers are particularly concerned about saturating the Mac marketplace with their products. Every developer believes that even MacHeist’s reach is a miniscule proportion of the entire market for Mac apps, and that MacHeist helps them reach customers that never knew they wanted their app.

4. Since MacHeist is temporary and only comes once a year, developers don’t fear that it causes consumers to value their apps less. In comparison, the factors causing the continual push towards 99¢ iPhone apps are always in effect.

5. All of the apps included in the MacHeist III bundle are fully-functioning, fully-upgradeable apps, just as if you had purchased it directly from the developer.

Welch, in particular, adds some interesting insights:

1. There is more than one reason to put an app in the bundle. One is to spur awareness of a new product. Another is to attract more users specifically to spur online play of that app.

2. Ambrosia found it similarly effective to bundle one of their apps on every new Mac, under a deal with Apple.

I will refrain from additional commentary of my own since my opinions already shine through via the questions I posed. Below are the e-mails and transcripts, straight from the devs.

Developer: Zac Cohan
Company: Acqualia Software
Product: Picturesque

E-mail Response:

Personally, we think MacHeist is great for consumers and developers and we don’t see them as a middle man, rather more as a marketing service. As you’ll probably know, for indie developers like ourselves it’s hard sometimes to get out there in the marketplace and we generally spend a lot more time on development than we do on marketing.

That’s where MacHeist comes in for us. They put a lot of time, energy and capital into building the MacHeist community, with the missions for example, and get our app out there in front of people. This really brings a lot of value to our company.

Here’s a quote from a comment on your blog post:

“I, for one, would never have thought to purchase Picturesque. for any price. but i’ve been so impressed with it i can definitely see paying for upgrades in the future, not to mention the word of mouth it will certainly receive in my own community.”

Awesome.

Cheers,

-Zac Cohan

Developer: Oliver Breidenbach
Company: Boinx Software Ltd.
Product: BoinxTV

Brief Q&A via e-mail:

Initial E-mail Response:

I actually wrote my post the second after Acorn was announced, beating alllll the other posts on MacHeist, because I knew what was coming.

Anyway, I don’t think consumers will think less of my applications. Did people think less of Delicious Library? Textmate? Speed Download? Launchbar? I know I don’t.

It’s business. I thought the tradeoffs were good for me, at this particular time. I’m most happy about getting Acorn into that many people’s hands. I want people to use it, I think it’s a good app and it deserves to get the attention.

Interview via IM:

Later, after the MacHeist III promotional event ended:

[I]t’s also a beautiful piece of design. After cooking in it and cleaning it up, I’ve spent a lot of time just looking it over, marveling at how its very deterioration has been incorporated into the design of the object, at how it’s gotten more attractive — less ignorant — the more I use it. I’m not particularly sentimental about much in my kitchen, but I would be heartbroken if you took away this iron skillet

He contrasts this with the wear and tear that his PowerBook had received:

Looking at the digital technology I own, what moderate deterioration to be found — dents in my laptop, a gash in the side of a laser printer I own, the accumulated grime on my computer keyboard — doesn’t make these items more desirable at all. In fact, when I see the way the corner on my aluminum PowerBook has been warped due to a nasty fall from a chair, I cringe. Through this obvious, glaring example of use, of accumulated knowledge, the object itself hasn’t attained an additional whit of beauty.

I first read this article over a year ago, and it’s always been in the back of my mind. Every few months a new editorial or a new video rant about how digital technology (especially products from Apple) is too much about form over function, about how it deteriorates way too quickly, and how computer manufacturers should concentrate more on making their products last longer. (Remember that whole hooplah about the iPod’s battery lasting only 18 months?) I also frequently see complaints from people when they have to bring their computer in for repair, and then have to wade through the inevitable complaints about how digital technology is trash.

My gut instinct is always to roll my eyes at these kinds of articles. And while Vinh’s article is probably one of the more eloquent ones to make this point, his article still elicits the same reaction from me.

Flawed Comparisons

My first thought about Vinh’s article is this: is he seriously comparing a suitcase or a skillet to a computer? Did he really just do that and expect us to take his article seriously?

For the most part, Vinh is comparing the outsides of computers, suitcases, and skillets. But consider the contents of each: a suitcase is designed to keep one’s belongings protected and all in one place. The typical contents of a suitcase are clothes. Clothes can be bumped and tossed around and won’t be the worse for wear. Clothes don’t have electrical components. Clothes don’t have connections. Occasionally you may be transporting fragile objects (like glass or maybe ceramics), but aside from their fragility (which can be mitigated with your clothes), they don’t have nearly as many potential problems with their innards as do computers.

In contrast, a computer’s contents are highly sensitive. If you get a single scratch or a single speck of dust on the platters of a hard drive, you lose data. If you spill liquid on the electronic components of a laptop, they typically short out and require replacement. If a connection inside your computer comes loose — one that isn’t user-serviceable like RAM or your hard drive — it’ll require opening up and removing so many parts inside the laptop which requires skill that most users don’t have.

And therein lies the answer to Vinh’s question about why we take pride in pristine looks of our computers but not in the pristine looks of our suitcases. It’s because of the contents of each. A computer’s contents are fragile, so we try to minimize nicks and cracks on the outside, the result of which could have caused problems on the inside. The higher the sustained damage of a computer on the outside, the more likely it is that damage has occurred on the inside. A suitcase doesn’t inherently have any fragile contents, so we’re not as concerned about the outside sustaining damage.

The suggestion that computer manufacturers have not designed for deterioration is actually pretty ludicrous, especially because beauty is in the eye of the beholder. Some people like the looks of scratched iPods.

Putting psychology aside, though, I question even the premise that suitcase or skillet manufacturers have designed for deterioration. My dad is one of the best cooks that I know, and he prides himself on having absolutely pristine pots and pans. Metal utensils are strictly forbidden when using his skillets; only wooden spoons and spatulas are allowed. (He breaks this rule occasionally, but he’s still very careful when using metal utensils.) It’s practically a sin to burn something on his pans, because it takes painstaking work (and is sometimes impossible) to get the burned material off.

It’s funny, because even Vinh himself cringes at the thought of having “seasoning” in his pan, the result of hundreds if not thousands of uses of the skillet. But then he goes back to thinking that his skillet is indispensable.

The reason Vinh actually doesn’t want his skillet taken away is because he’s found a skillet that works well for him. There are numerous little aspects of a skillet that make it enjoyable to use: the shape of the handle, whether the handle gets hot when you cook with it, whether the skillet is light enough to easily flip things with, the weight balance, the material used to create the skillet, etc. If I brought him a skillet that worked better in every way to his old skillet, I bet he wouldn’t hesitate to start using the new one.

A Better Analogy

I can also think of a number of other products that are decidedly non-electronic that don’t get better with increasing wear and tear. Bikes, for example, look worse when they’re dirty and dinged. Many buildings look like eyesores when they get dirt and smog and cracks on them. Even suitcases and skillets, to a degree, look pretty bad when they’re banged up.

Overall, I think that suitcases and skillets are pretty poor objects to which to compare computers.

Here’s a better analogy: cars.

Cars are designed to look pristine on the outside. When people get new cars, they try to delay that moment when they get their first ding. (My dad, for example, recently got a new car. Now he insists on parking in far-away spots that are at the end of a row, which only have one adjacent spot instead of two. If that requires parking in the next lot over, he’ll do it.) When people see an old classic car, they fantasize about buying it and fixing it up, and that includes getting a new paint job and banging out the dents and dings.

Not only that, but automobiles have reasonably complicated innards. They contain engines and moving parts and potentially flammable liquids, in addition to some electronics similar to what computers contain. More importantly, they always contain humans.

Is it any surprise that people are afraid to ding and bang up the outsides of their cars, when they contain ourselves?

Planned Obsolesence

Vinh’s ulterior motive for penning this article, I suspect, is motivated by a more pernicious myth:

Of course, the blame for the absence of designed deterioration from these products can be laid squarely at the feet of a more widely accepted design concept: planned obsolescence. I will probably never buy another skillet to replace the one I own for as long as I live, even though a new one is extremely affordable.

Bullshit.

Planned obsolescence is a myth, pure and simple.

The analogy of a skillet, here, is even more preposterous than the skillet’s use when talking about “designed deterioration”. A skillet doesn’t contain millions of electronic components, which, if broken, can cause issues when using the skillet. No, a skillet is composed of two things: the skillet and the handle. That a skillet is more durable and has a longer lifetime than a computer is, seriously, no fucking surprise at all.

Let’s go back to a more reasonable analogy: automobiles. Automobiles require constant maintenance and repairs, especially when they near the end of their life. Not only do you have to fill your car with gas, but you have to continually add oil. You have to add air to your tires. It’s recommended to have your engine serviced every 50,000 miles or so. Sometimes your transmission or radiator or carburetor breaks, and you have to spend hundreds or thousands of dollars to fix it.

Most people who use cars don’t have the expertise to repair their own cars, and when they take it to a mechanic, it often costs at least several percent of the original cost of the car.

Same for a computer. Usually, your computer works pretty well and without problems for the first year or two of its life. Then you start getting problems with the trackpad button not clicking correctly, or your optical drive failing to correctly burn DVDs, or your battery life starts deteriorating. Without constant maintenance or repairs to your computer, it can fall into disrepair and stop working.

Not only that, but computers can and do last a long time. The whole notion that a computer lasts a maximum of a few years is bullshit. Our family’s original Mac Plus, bought around 1986, still works. My original iMac, bought in 1998, still works to this day, without (if I remember correctly) a single repair. My G4 iMac, bought in 2002, still works. My dad’s aluminum PowerBook, originally purchased in 2005 or so, also still works. And it’s not really limited to Apple computers either. There are several computers still running Windows 95 at Stanford which operate expensive lab equipment.

More to the point, though, your bad experience with your computer does not indicate anything about computers as a whole. People make this mistake all the time. Repeat after me: the plural of ‘anecdote’ is not ‘data’.

I’m not suggesting that computers typically last decades like automobiles do. But they can. And with continual maintenance, you can extend the life of any computer for at least half a decade, if not more.

Do people really think that computer manufacturers sit in a room and decide the average lifetime of their products? Do executives really sit down and think up new features that use excess processing power simply to prevent older computers from running newer operating systems at acceptable speeds? Do people really think that computer manufacturers would not jump at the chance to improve the reliability of their products without significantly increasing the cost? Of course they fucking would. They’d trumpet and parade their newfound reliability in front of all consumers and other manufacturers (cf. Apple).

There’s no real reason to believe that intentionally shortening the lifetime of a computer would work to a manufacturer’s advantage, anyway! Moore’s Law takes care of obsolescence. Processor, memory, and graphics card technology are increasing so quickly, with programmers taking advantage of that increase in power so immediately, that even a perfectly functioning computer in pristine condition that lasts ten years would be hard-pressed to run cutting edge applications and operating systems. Sure, you can do it. But it’s ridiculous to expect that it will be able to run cutting-edge software at an acceptable speed. The pace of the computer industry is just too fast.

There are always new scientific applications and games that require more processing power, there is always new hardware and software innovations that take the place of older ones, and even if programmers optimized the crap out of operating systems and software, it wouldn’t take the place of the sheer processing power that newer computers provide. Time is simply better spent obsoleting older computers through faster hardware and newer software than trying to maximize the lifetime of an individual computer model.

The Human Computer

Reliability of hardware and even software is always a problem in the computer industry. Physical components break down, and software inevitably has bugs created by imperfect code that cause it to function incorrectly. It’s always worth it to try and find and fix bugs in software and to find ways to cost-effectively improve the reliability of hardware. But it’s also worth it to realize that the current situation is to be expected.

Think about the human body. It’s the result of billions of years of evolution of life on our planet. Modern humans have only been around for hundreds of thousands of years — a very brief period of time compared to the age of the earth — but humans have still benefitted from all the previous evolution of life.

And despite all that time, humans still have problems. Our organs still sometimes fail, requiring replacement. Bones still get broken in accidents. Humans still get sick from viruses as common as influenza.

And people expect computers — complicated tools created by humans — to not be subject to the same pitfalls that humans are?

Please.

Put it this way: would you rather pay $10 to Universal Music Group for a music album, or $15 directly to the band in question?

Also, please see my three previous posts on MacHeist before commenting. Thanks.]

Gruber over at Daring Fireball writes:

I’m unsure why there seems to be lingering controversy regarding the new MacHeist bundle. My issue with the first MacHeist bundle two years ago was that developers were offered flat fees, rather than percentage cuts. Clearly this is no longer the case. Gus Mueller, critic of the terms of the original bundle, is participating in this year’s, and he puts it plainly:

So why is Flying Meat participating in MacHeist time around, when I blasted it a couple of years ago? Well, it’s pretty simple. The folks at MacHeist fixed the payment terms after MacHeist 1, and developers are getting a much better deal now. Tada.

Gruber is a smart guy. Sure, developers are getting percentage cuts now, but it’s hard to not come to the conclusion that developers are still getting screwed over, despite Mueller’s protestations to the contrary. I’m surprised that Gruber doesn’t see this.

Really, I don’t care about what Phill Ryu or John Casasanta said or didn’t say. Let’s do the math.

First off, let’s assume that the three “unlockable” apps will be unlocked this time around. (I mean, really, do they ever not get unlocked? It’s a stupid gimmick.) That means that the value of the bundle is $950.75, and $975.70 for the first 25,000 buyers. The bundle itself is selling for the “insanely low price” of $39. Let’s put into perspective really how “insane” this actually is.

Assume the percentage cut for each developer depends upon the value that app adds to the bundle. So we’ll use price as a proxy for the percentage cut that each developer makes. iSale is worth $39.95, so the iSale developers might be getting 39.95/950.75 or 4.2% of the profits. Pictureseque is worth $34.95, so its developers might be getting 34.95/950.75 or a 3.7% cut of the final profits. And so on.

Now, remember, 25% of the profits go to charity. So for every purchase of the bundle, $9.75 gets lopped off the top. Of the leftover 75%, iSale gets 4.2% of the cut, or $1.23.

Let that sink in. The developer of iSale is getting $1.23 for a single license of iSale, rather than the full $39.95. The iSale developers are devaluing their own product, supposedly [EDIT: striking out the weasel word, thanks Flooey] of their own free will, by 97%. In fact, all developers are devaluing their product by 97%.

Kinemac, which regularly retails for $300, is not even getting $10 for each sale of the bundle. Who in their right mind would do such a thing? I mean, really? Talk about insane.

This is all assuming that Phill Ryu and John Casasanta get no cut whatsoever. This also assumes that the developer of Big Bang Board Games also gets no cut. Who knows what percentage Ryu and Casasanta are taking this time around? The iSale developers are probably getting $1, not $1.23, for each bundle sold.

Fundamentally, what it comes down to is that those consumers who are participating in the MacHeist bundle are tightwads. Even if you’re only interested in one of the apps in the bundle, it’s likely that only a little more than one of your dollars is going to the actual developer of that app. And you’re doing it all because you can get that app for a really cheap price, especially if you’re looking to get BoinxTV or Kinemac, which normally cost $200 or $300, respectively.

And people are complaining at the bargain basement prices of iPhone apps.

Marco Arment is being nice when he says:

My point is whether it’s a good idea, as conscientious consumers, to accept such steep discounts on the products that we use and love.

My argument is that it’s not.

Let’s just say it like it is, Marco. If you’re buying MacHeist, you’re a cheap fucking bastard, and it makes me queasy that so many in the Mac community would buy into such a thing.

So to let your program still run even when the framework in question isn’t present, you weakly link the framework instead. Apple has some good docs about weak linking that explain the details.

Suffice it to say, if you’re weak linking a framework, uncheck the target membership box in the project sidebar for the framework you want to weak link, then get info on your target and add “-weak_framework framework_name”, where “framework_name” would be “SDL_mixer” if you want to weak link SDL_mixer.framework.

Apple’s documentation also helpfully includes code that you can use to check whether or not the framework in question is installed or not. Instead of specifically checking for the framework, you simply check if the pointer to the function you’re about to call from that framework actually exists. Here’s the code from Apple’s docs:

    int result = 0;

    if (MyWeakLinkedFunction != NULL)
    {
        result = MyWeakLinkedFunction();
    }

So you check if MyWeakLinkedFunction exists, and then execute it if it does. Now take a look at a QuickTime movie of me debugging an example of such code. No, I’m not debugging with optimization on, and ignore all the other weird stuff about this code like the duplicated lines. Just focus on which lines the debugger goes through.

Mix_OpenAudio is a function from SDL_mixer, correctly weakly linked in my project. Notice that the debugger simply skips over the first Mix_OpenAudio if statement, and skips the entire second #ifdef __macosx__ block, even though __macosx__ is clearly defined since the debugger went through a similar #ifdef __macosx__ block at the top.

What’s going on?

The short explanation is that Apple’s suggested code simply doesn’t work.

Here’s what’s happening. When you compile on Leopard, Mix_OpenAudio, or MyWeakLinkedFunction as in the case of Apple’s sample code, always evaluates to true regardless of whether the framework is present or not. So in the movie of me debugging, the line if (Mix_OpenAudio == NULL) always evaluates to false. The compiler simply doesn’t compile those lines of code because of this, which explains why it simply skips over that if statement. The compiler actually generates an “always evaluates to true” warning if you change the line to if (Mix_OpenAudio).

Similarly, the second identical if statement inside the #ifdef __macosx__ block also always evaluates to false, and so the compiler omits that entire block, since no lines of code will ever be executed regardless of the outcome of the if (gameOptions [0].sound.bUseSDLMixer) { line.

Apple’s docs spout BALD-FACED LIES.

A Google search for “compiler weak linking” actually produces the solution as the second search result. Instead of the Apple sample code in the docs (as reproduced above), use this code instead:

    int result = 0;

    uintptr_t address = (uintptr_t)(MyWeakLinkedFunction);
    if (address != 0u)
    {
        result = MyWeakLinkedFunction();
    }

You need to specifically get the address of the function as a uintptr_t, and then test its equivalence to the literal “0u”, not “0”.

Thanks Richard Wright, I’m glad you posted your solution to the internets.

UPDATE 2009-03-11: Actually, it looks like that (now striked-out) solution doesn’t work either. This was working fine in a debug build, but when I finally made a release build, the program crashed yet again when the weakly linked framework was not present.

After banging my head against the wall for a long time, I finally e-mailed the Cocoa-Dev mailing list, and Greg Parker from Apple helpfully suggested that the compiler was optimizing my code out. He also included some other code that isn’t optimized out, and I have confirmed that it works under both Debug and Release builds:

    int result = 0;

    void * volatile function_p = (void *)&(MyWeakLinkedFunction);
    if (function_p != NULL)
    {
        result = MyWeakLinkedFunction();
    }

Unsurprisingly, when studies are actually done, it turns out that there’s not really a problem with underage sexual solicitation on the internet. So concluded the Safety Technical Task Force, which was created by attorneys general of 49 states in the U.S.

According to the New York Times:

The task force, led by the Berkman Center for Internet and Society at Harvard University, looked at scientific data on online sexual predators and found that children and teenagers were unlikely to be propositioned by adults online. In the cases that do exist, the report said, teenagers are typically willing participants and are already at risk because of poor home environments, substance abuse or other problems.

Furthermore:

Among the systems the technology board looked at included age verification technologies that try to authenticate the identities and ages of children and prevent adults from contacting them. But the board concluded that such systems “do not appear to offer substantial help in protecting minors from sexual solicitation.”

Unsurprisingly, Richard Blumenthal, attorney general of Connecticut, “said he disagreed with the report”, says the New York Times.

When is it going to get through to people that this isn’t a problem? I don’t think it ever was a problem. Throughout my life, I’ve participated significantly in chatrooms on Hotline (remember that?), GameRanger (remember that?), various message boards, instant messenging, and website commenting all when I was under 18, and I never once got approached by anyone for sex.

In fact, the internets have significantly improved my ability to do things with random people that never would have happened otherwise. I helped people fix problems on their Macs. I wrote documentation for a programmer in Belgium who wrote a Hotline client. I’ve learned a whole lot about Mac and iPhone development via Twitter. All by communicating with people I hadn’t known before and whom I had never met in person.

Furthermore, I’ve met many, many people in person whom I first met online. I’ve never had a problem with any one of them. I’ve met some oddballs, and some people who I probably don’t want to meet again, but I’ve never been in any danger.

When are people going to realize that this is false outrage? When are we going to stop devoting so much money and effort and time to try to stop a problem which doesn’t exist? Meeting and conversing with people on the internet is pretty much the same as meeting and conversing with people in person. You just have to be a little more cautious.

Would you give your physical address to someone the first time you meet them in person? No. So then don’t do it with someone you just met on the internet.

How do you meet someone in person whom you first met on the internet? The same way you do when you first meet someone in person: you’re almost always in a public place, during the day, maybe with a friend or two, maybe over coffee or something.

When do you trust someone from the internets enough to give them your phone number? After you’ve talked with them a few times, you get to know a little bit about them, after you’ve met them in person, etc. This is probably less of a big deal now that cell phones have proliferated everywhere, and you already have a means of communicating with someone whom you met on the internet.

Seriously, it’s not that hard to exercise common sense.

Typically a sheet is only associated with one kind of parent window (like a document editor window), meaning it usually makes sense to simply include the sheet inside that parent window’s nib. But putting the sheet in a nib by itself is useful if you have a lot of different kinds of windows, but you want to be able to attach an identical sheet to any one of them. This is what I do with kill sheets in Memory Usage Getter, since they can attach to both the Tab View and List View windows, as well as to individual process history windows.

I was using the same technique when adding some sheets for TidyWeblogger, except I was encountering a weird problem: the sheets weren’t attaching to windows like they were supposed to do. I was passing a valid reference to the sheet and to the parent window when using NSApp’s beginSheet:modalForWindow:… method, too.

Instead, the sheets just appeared in midair, attached to no window in particular, and as such, they couldn’t be moved around either. Furthermore, when I clicked a button to dismiss the sheet, they didn’t go away immediately. They only disappeared from the screen when I started interacting with a different window.

I posted about this problem on Twitter, and Fraser Speirs pointed out the problem:

In the nib I created for my sheet, the “Visible At Launch” box for the sheet window itself was checked in the Behavior section of the Attributes inspector tab. As soon as the nib was loaded, the window would appear, instead of waiting for me to tell the sheet to attach to a parent window.

The fix is simple. For any sheets, make sure the “Visible At Launch” box is not checked. After saving the nib and recompiling, everything worked perfectly.

In Interface Builder, you can set NSTableViews to have autosave names, which allow table views to automatically save and restore various “settings” about the table view, like the column positions, column widths, hidden columns, column sorting, etc. Just by virtue of giving the NSTableView an autosave name in Interface Builder, it should start saving and restoring all of these settings.

It was the column sorting that was giving me trouble. Column widths and column positions were being saved perfectly fine, but my column sorting was always being reset to a default value after each launch. This problem pissed me off for a day, and looking through various documentation didn’t help, because it suggested that sort descriptors should be autosaved and restored.

Other oddities with this problem is that it seemed that the NSTableView was saving the sort descriptors to my app’s plist preference file, but wasn’t restoring it. I tried binding the NSTableView’s sort descriptors to an NSUserDefaultsController, and even that didn’t work. I tried manually getting the preferences via an NSUserDefaults object, hoping to programatically set the NSTableView’s sort descriptors on launch. What was weird was that when I tried to retrieve the sort descriptor settings that were clearly saved to the preference file, the NSUserDefaults object was returning null values for that key.

I’ve seen a few posts about this, but no answers. Because the almighty Google indexes all, I thought I’d post my solution.

The issue is that your NSArrayController or NSDictionaryController also has sort descriptors, and these seem to take precedence over the NSTableView’s own sort descriptors. But these sort descriptors don’t get autosaved along with the NSTableView’s other settings. So while the NSTableView does seem to save the sort descriptors, it would seem that it attempts to restore them but then they get obliterated by your NS*Controller’s sort descriptors, which are reset to default values on every launch.

The solution here is to bind your NSArrayController’s (or NSDictionaryController’s) sort descriptors to an NSUserDefaultsController. Select your controller, switch to the bindings tab in the inspector, and then click the “Sort Descriptors” disclosure triangle under the “Controller Content Parameters” section.

Check the “Bind to:” box, and select “Shared User Defaults Controller”. (This will automatically create an NSUserDefaultsController instance in your nib.) Set the controller key to “values” and the model key path to the key you want to use in your prefs file (for example, “sortDescriptors” is fine). You’ll need an NSUnarchiveFromData value transformer, and you’ll also want to check the “Validates Immediately” box so that your sorting gets saved to prefs as soon as the user clicks a column heading to change the sort order.

You’ll also want to make sure that your NSTableColumns have sort keys and selectors. This is easily done in Interface Builder as well. Select each of your NSTableColumns in turn (the inspector should start with “Table Column” if your column is correctly selected), and switch to the Attributes tab. For “Sort Key”, you’ll want to enter the model key path to your column data (in my case, my bindings controller key for the column is “arrangedObjects” and the model key path is “value.entryTitle”, so I put “value.entryTitle” in for my sort key). For “Selector”, type in a method name that tells your program how to sort your NSTableView items (for example, “compare:” or “caseInsensitiveCompare:”). Do this for each table column.

You should probably unbind your NSTableView’s sort descriptors as well, if you’ve left them bound from pulling out your hair trying to figure out this problem.

I’m not sure if I would classify this as a bug or not. Is there any time when you would want sort descriptors for both the NSTableView and the NS*Controller that’s providing the NSTableView with data? Otherwise, NSTableView’s sort descriptors bindings should probably be grayed out when its corresponding controller is connected.

In any case, hopefully this helps anybody else who comes across this problem.

• TidyWeblogger is now generating every single page on my weblogs. Category pages, archive pages, entry pages, main page, RSS feed, dummy files, and a new addition, a JavaScript file that just contains an array of recent entries to use on other pages. I’ve republished all pages so that they conform to my new templates, and everything’s working just dandy!

• Take a look at the new archive sidebar item, as well as the new archive page itself. The category stats are once again being updated, and the browse by date archive page is simply one long list of all entries on a single page. I realized there’s no need whatsoever to have separate month and year archive pages, since it’s just a bunch of unnecessary clicks when a single page can present all the necessary information all at once. It’s also convenient if you’re looking for an entry and not sure when it was posted.

• JavaScript improvements have been made across the board. And by “improvements” I mean that a lot of JavaScript has been ripped out. iBlog created HTML files that constantly referred to the CommonLib.js file to create the sidebar items, the weblog and category titles, etc. My templates do all this generation beforehand and create mostly static files.

  It takes more time on my end, but I prefer that to more JavaScript on my pages. For example, since the category stats are all static, all pages need to be regenerated when I publish a new entry in order for the stats on all pages to be accurate. This is another case where it makes sense to publish a separate JavaScript file with the category stats, and have all pages get the stats from that file so that every page doesn’t need to be regenerated.

  In any case, the only things that JavaScript is handling now is the Linkable Supernova sidebar item creation, and comments. Category stats will probably be migrated back to JavaScript at some point.

• I mentioned that TidyWeblogger creates dummy files. It’s been doing that for a while: dummy files are needed in order for the comments system to work. But I’ve added a new class of dummy files that TidyWeblogger creates now: for those entries that have the old crufty URLs from iBlog (the ones like “http://homepage.mac.com/simx/technonova/C486203617/E20071118034738/index.html”), TidyWeblogger creates a redirection page that points to the new URL. Old comments on the new page are preserved, too. In this way, both the old URLs are preserved, but everyone sees the new ones since the crufty ones redirect to pretty ones.

• I also mentioned the new JavaScript file of recent entries. This allows me to retire that ridiculous hack that I was using to get a self-updating list of Linkable Supernova entries in the sidebar here. Technological Supernova is no longer loading 11 invisible iframes with pages from Linkable Supernova just to get the titles of the pages.

  The result is that loading pages here should be much faster now, and this should be especially noticeable on the iPhone or iPod touch. It just now loads the RecentEntries.js file for Linkable Supernova, and then writes the list to HTML via JavaScript. It’s much more reliable, too — previously, it used to fail to write any links sometimes.

  Also, eliminating this hack allows my pages to validate again, at least according to the W3C validator. Previously, it was throwing an error because I was using an “onLoad” attribute for the iframes. I know, I know, validation shouldn’t be an end goal in and of itself, but it’s still a good indication of using web standards.

• Speaking of validation, TidyWeblogger is using NSXMLDocument’s NSXMLDocumentTidyHTML option so that any generated content is transformed into valid XHTML automatically, as much as possible. There are some validation errors it can’t correct, like adding a title attribute to all images, though.

• Various other things have been fixed: I can force TidyWeblogger to republish all entry pages in one action, now. Entry published dates now automatically update in the main window after a publish, and comments now will get enabled on publish even if the initial publish fails.

I think another factor in my excitement to develop this app is that I’m learning a whole ton of new stuff in Cocoa programming, some of which stems from the Leopard improvements. Here’s what I’ve learned over the past few days:

• Bindings! I’ve finally gotten around to seeing the benefits of these things. My initial attempt at bindings in TidyWeblogger was pretty unseemly because I was using a dictionary of entries with an NSArrayController, which controlled a proxy object that I would update programatically to synchronize with the dictionary of entries.

  I later used bindings on a smaller problem, implementing an NSDictionaryController to control the values and titles of an NSPopUpButton. Then I back-tracked and re-factored my initial attempt at bindings, with great success.

  Bindings are really useful to eliminate glue code when initializing interface objects in an entry editor window, for example. There’s absolutely no code whatsoever to make the popup buttons present the correct categories according to the relevant weblog, which is nice. It also eliminates the need for any manual sorting code that was necessary when I created Memory Usage Getter; my table view of entries is automatically sortable by title, category, and date simply because it’s using bindings.

• I finally figured out how to use the replacement for NSCalendarDate. You need to use a combination of NSDate, NSCalendar, and NSDateComponents. This is a change that came with Tiger, and it seems to have been done to accomodate calendars other than the Gregorian calendar which is used in the United States.

• Creating toolbars in Interface Builder. This is incredibly useful, because it eliminates the need to create any code for getting toolbars and their buttons to work. You just drag and drop them into your window, and then connect outlets and actions just like you would do for a standalone NSButton.

• I’ve been using more Objective-C 2.0 paradigms, like fast enumeration, which is pretty useful. I haven’t started using @property and @synthesize declarations yet, but now that I’m using bindings, I can see exactly why and how they’re used.

• Some of my coding conventions have slowly been changing as well. Instead of using the alloc-init dance for stuff like NSMutableArrays and NSMutableDictionaries, I’ve started just using the -array and -dictionary constructors so that I don’t have to worry about releasing the objects later. Similarly, my setters have gone from retain-then-release to equivalence-release-allocate to accomodate the setting of mutable objects from immutable counterparts.

One of the things I think I’m most proud of in my code is that the method that’s generating all the HTML files is highly extensible, and I’ve only had to make minor modifications to allow the creation of archive pages, entry pages, main pages, etc. It’s pretty sweet.

It’s especially great because when I want to add new template entities (things in the page templates like “{[ENTRYPAGEURL]}” which TidyWeblogger dynamically replaces according to which page is being created), I can do it once and not worry about it again.

My goals for future development, roughly in order:

• Publish category stats to a separate JavaScript file and have entries point to that instead.
• Investigate why stylesheet cookies seem to not be consistently working. Also, I’ll see if I can eliminate the flash of the sidebar in the wrong position.
• Figure out why my table view isn’t auto-saving sorting. Column positions and sizes are being auto-saved, though, so I’m not sure why sorting isn’t. Can anybody help out with this?
• Figure out how to get the table view to re-sort when information is updated, like the publish date.
• Figure out why my NSTextView is loading with small fonts for Markdown entries.
• Thread my interface. Currently, publishing freezes the interface for minutes at a time if there are a lot of entries, because it’s all running in the main thread.
• Figure out why undo isn’t supported in my entry NSTextViews.
• Implement the dirty dot for entries, and update the entry composition windows with entry titles.
• Test a few things that I haven’t been doing often, like reverting an entry, changing an entry’s category, or changing it’s custom URL. Make sure these all work.
• Fix the last remaining feature that’s still disabled: the next and previous links on the entry pages. I might punt on this for a bit, because this may require some refactoring, again.
• Implement the .Mac SDK (has it been renamed the MobileMe SDK yet?), so that I don’t have to rely on my iDisk being mounted in the Finder when publishing.
• Implement local storage and composition of entries, and synchronization of local entries with the iDisk so that you don’t have to compose entries while online.

That’s a tall order, but since I’ve been making rapid progress anyway, a lot of this stuff might get done sooner rather than later.

Yay development!