Brent Kearney

Apple successfully pulled of its switch from the PowerPC architecture to Intel’s latest and greatest, the “Core Duo” 2-in-one x86 processors. The new machines have been selling like crazy, and for good reason: they’re blazing fast and have a feature set that, for the price point, is unmatched in the personal computer industry.

Part of that feature set is their amazing new UNIX-based operating system, OS X. It’s stable, fast, secure, easy to use and it looks so good that it makes you want to lick it. For the first time, there is now a viable alternative to Microsoft Windows on the Intel platform. With rising security concerns about Windows, people are actually looking for alternatives.

Some pundits are saying that the availability of this alternative, together with the news that Microsoft’s next release of Windows will be delayed until 2007, will result in a significant blow to the Redmond giant’s market domination.

There is a catch, of course. OS X runs on Apple’s own hardware, only. At least, officially it runs only on Apple hardware. Unofficially, hackers have managed to circumvent the software protections that are supposed to prevent OS X from running on non-Apple hardware, and booted up OS X on their Dell, HP and generic PC systems. However, using hacked versions of OS X is probably illegal, its difficult to install, and users who do it will miss out on the frequent updates that Apple sends out.

Another catch for people considering a switch, even if they’re willing to buy new Apple hardware, is that they may have some applications that only run in Windows, and they’re not sure that they’ll be able to live without. For these people, Apple has just released a new product that allows users to boot up Windows on their Intel Mac. Its ingeniously named “Boot Camp“.

Boot Camp is free to download, and will be included as a standard feature with the next release of Mac OS X, due out this year.

Rumour has it that Windows runs faster on the new Macs than it does on currently available PCs. Long-time Windows users will now be able to upgrade to slick new Apple hardware, and dabble in OS X at their leisure, without the risk of not liking it and being stuck without crack, I mean, Windows.

John C. Dvorak today offered an insightful prediction on how this situation might develop in 2006:

So, is this how it will go in businesses across the country? I bet Apple does.

February – “We don’t do Macs. Windows only.”
March – “Windows runs faster on those new Intel Macs than on my pc?”
April – “Since we can run Windows on a Mac, let’s buy one and check it out.”
May – “It is faster! And this OS X stuff is interesting.”
June – “I just created some widgets that will really be useful for everyone. Since we have to replace all our pc’s anyway, let’s only get Macs.”
2007 – “Vista’s released? So? We don’t do Windows. Mac only.

The trail crews at Sunshine have been busy every night, pouring cement on the runs around the resort. For the past couple of weeks, spring has been creeping up on the local resorts, and the rocks are starting to sprout up through the crusty snow. As usual however, there are still some sweet spots to be found. Today I found some decent soft snow underneath the Teepee-Town chair, including The Shoulder. Riding that chair is like aging at 5-times the regular rate, but its still better than chattering around on the crust. Watch out for the rocks though, they are popping up here and there. If you go to the shoulder, take the lowest route in that you can find — up top are roots and rocks with little room to maneuver.

Using dojo.io.bind() for XMLHttpRequest()

Since the introduction was so verbose in Part 1, I’ll just skip it in Part 2 :). This time, I’ll look at what is probably the most popular function from the Dojo I/O class, bind(). The bind() function is used to connect to external scripts or websites using XMLHttpRequest() in JavaScript. It really simplifies the whole process.

Here’s the basics:

var myUrl = 'myscript.php?var1=foo&var2=bar';

dojo.io.bind(
	url: myUrl,
	type: "text/plain",
	error: errorFunction,
	load: resultFunction
);

function errorFunction(type, errorObject) {
	alert("Error! We got: " + type + ", and, " + errorObject);
}

function resultFunction(type, data, event) {
	alert("Success!  We got: " + data + " back from the server.");
}

The things to note about the above:

* myUrl can be anything; typically a php script, local or remote (http://somehost.com/somescript.php?myvars…). I put the variables and their values in the URI, as is typical in XMLHttpRequest() usage.

* By default, bind() uses the GET method to send the URL-encoded data, but you can change it to the POST method by invoking the method named “method”:
method: "POST",

* function parameters in the error: and load: methods are passed implicitly, as opposed to:

load: resultFunction( param1, param2, param3 ) // doesn't work


* errorFunction and resultFunction could be anonymous javascript functions, and judging by the Dojo documentation, that is the norm. For example:

dojo.io.bind(
	url: myUrl,
	type: "text/plain",
	error: function(foo, bar) {
                 alert("Error! " + foo + " and, " + bar);
              },
	load: function(type, data, event) {
                alert("Success! Script returned: " + data);
              }
});

* the parameters returned by the error: method are “type”, which is always “error”, and “errorObject”. From the manual, “The errorObject is transport specific, but should provide details about the type and details of the bind failure.” I haven’t played around too much with the error method.

* there are many more methods that could be used to tweak how dojo.io.bind() works. See the API manual for a list of them all.

That’s it, until Part 3!