 |
Found on the new Google App Services blog :
Google App Engine gives you access to the same building blocks that Google uses for its own applications, making it easier to build an application that runs reliably, even under heavy load and with large amounts of data.
Now, where have I heard this one before?
Scott Byer of Adobe on John Nack’s blog:
Don’t assume that we don’t use Cocoa and CoreImage. Photoshop CS3 already does in places.
Interesting.
I just came across a hack job of an article on O’Reilly’s Network regarding Apple’s iPhone SDK.
It’s by Jonathan A. Zdziarski and you can read a printer-friendly version of it here.
Let’s examine mr. Zdziarski’s claims.
With the release of Apple’s SDK for building iPhone applications, many have plunged head-first into this new platform for the first time, with the new-found excitement that comes in discovering something entirely new and innovative. The energy surrounding the iPhone has been building steadily since its release last June, and Apple’s initial “beta” offering of their SDK gave developers many of the tools they needed to get engaged. Within a short time, however, the community hit a brick wall in many respects, leaving many disenchanted by the restrictions imposed on developers. While Apple insists that the SDK provides the same tools used to create their own software, developers have found that they don’t have access to the same low-level functions of the iPhone, such as the ability to run applications in the background, build certain types of objects, or use low-level frameworks such as CoreSurface, Celestial, or LayerKit — all of which provide direct access to graphics and sound components. These, along with many other features, are found in Apple’s own applications, but nowhere to be found in the SDK.
Em, I call BS here.. Apple never said that the SDK “provides the same tools used to create their own software” in the sense that those are the only tools they use. They really are the same tools Apple uses, just not the only ones. Every developer knows that every SDK has some internal APIs, and for good reason, don’t they? Thus, there is no reason for the sensationalist tone. Besides, Apple explicitly stated the restrictions imposed upon the SDK (no background apps, no device drivers, no using the phone network, etc).
Furthermore, several Mac and iPhone developers pitched in on why such restrictions make perfect sense, especially the no running in the background policy. Reasons include stability, battery life, CPU utilization etc. And it makes even more sense considering that the user will be installing an unspecified number of apps (consider the battery drain of 10 background running apps checking the network periodically). Actually there’s an excellent post from Craig Hockenberry about this.
Jump ahead to March 2008. Apple finally realized what a huge financial opportunity they were missing out on when they snubbed third party developers, and decided to release their own version of what the community already had been using for nearly a year, a software development kit (the Apple SDK) and application distribution chain (the iTunes AppStore). Ironically, due to this delay, Apple was surprisingly the one lagging behind the open community, and rather than the open source community duplicating commercial efforts, Apple embarrassingly became the one trying to duplicate the open source community today.
I’m afraid I’ll have to call BS again. Apple “ snubbed the third party developers”? Apple “finally realized what a huge financial opportunity they were missing out”?
Since mr. Zdziarski is, as it seems, I programmer himself, he should know that releasing an SDK takes time. To get it right, to finalize it, to ensure that you won’t burn your developers with unneeded changes down the road, etc. Isn’t this essential knowledge on Software Engineering 101? It is, therefore, silly to imply that Apple only recently jumped on the iPhone SDK bandwagon. The breadth of work, the quality of the documentation, the preparation of the App Store, the negotiations with third parties —such as Microsoft, shows the exact opposite: Apple has been working on an iPhone SDK for a long time.
I cannot understand the line about how Apple“ embarrassingly became the one trying to duplicate the open source community today”. WTF? Jailbreaking the iPhone and linking to a non stable, internal API somehow amounts to the same as the production of a proper SDK? Besides, Apple is not duplicating anything. The company polished and SDK-ized the internal APIs that they themselves produced, those same APIs that the open source community unofficially used.
It was used to write applications that could look and act just like Apple’s preloaded software, so when Apple announced that their SDK was “the same set of tools,” many expected that it would look and feel like the open tool chain.
Very few had anticipated the many restrictions they’ve come to find in the official SDK.
Only those very few with any sort of programming experience in the real world, I guess.
While roughly 75% of the two SDKs do overlap, the remaining 25% has shown to be very restrictive, removing the developer’s ability to do “the real fun stuff” with their application.
I’m not sure I would want anybody to do “the real fun stuff” on my cellular phone. You know, the same one I carry all day, and use on emergencies and such.
Back to the present, the APIs available in the Apple SDK are useful for building your average game, or your average application, but very lacking for building applications with more sophisticated, low-level requirements. Fortunately, there is another set of interfaces that Apple never wanted you to know about, the “real” set of APIs that Apple uses.
So how the proper API is not real? Especially since it overlaps with 75% of the unofficial stuff, except the low-level stuff. Also, doesn’t mr. Zdziarski know that Apple really does limit itself in using the official API on most of the applications on the iPhone, except where it is critical not to do so (a few selected apps such as Safari, etc).
The rest of the article is a guide for using the unofficial, non-SDK API. Which is all nice and fine, and something that I have no qualms about. Except maybe about this line:
It’s important to note that it is unclear whether using these hidden APIs will disqualify your project from being listed in Apple’s AppStore.
Anybody out there that also thinks that “it is unclear”? I have a bridge in Brooklyn you might be interested in.
I would accept this kind of BS from Dvorak or Thurrott, but mr. Zdziarski is a Mac programmer. And he is writing for O’Reilly. He should know better. Perhaps he does. Maybe he is just bitter because the official SDK came out now that he has just published a book on the unofficial SDK.
P.S Also what’s with the article being on OnLAMP.com? Where’s the L, the A the M or the P?
I am a fan of Joel (of Joel on Software fame). Hell, I even bought two of his books.
Still, his latest post regarding IE8 standards support is, to put it succinctly, lame, what with the contrived examples about martian headphones et al.
I just don’t understand what the whole problem about some pages being broken on IE8 is. Here’s what he has to say:
Almost every web site I visited with IE8 is broken in some way. Websites that use a lot of JavaScript are generally completely dead. A lot of pages simply have visual problems: things in the wrong place, popup menus that pop under, mysterious scrollbars in the middle. Some sites have more subtle problems: they look ok but as you go further you find that critical form won’t submit or leads to a blank page.
These are not web pages with errors. They are usually websites which were carefully constructed to conform to web standards. But IE 6 and IE 7 didn’t really conform to the specs, so these sites have little hacks in them that say, “on Internet Explorer… move this thing 17 pixels to the right to compensate for IE’s bug.”
And IE 8 is IE, but it no longer has the IE 7 bug where it moved that thing 17 pixels left of where it was supposed to be according to web standards. So now code that was written that was completely reasonable no longer works.
IE 8 can’t display most web pages correctly until you give up and press the “ACT LIKE IE7″ button. The idealists don’t care: they want those pages changed.
Some of those pages can’t be changed. They might be burned onto CD-ROMs. Some of them were created by people who are now dead. Most of them created by people who have no frigging idea what’s going on and why their web page, which they paid a designer to create 4 years ago, is now not working properly.
Pages burned on CD-ROM? How more of a contrived example can you give? Who cares about those pages? You can have a seperate installation of IE7 or IE6. Why doesn’t MS make one available? They could even add a “Switch Rendering Engine” button -hell, their customers are used to even worse abuse. But, honestly, I visit the web with Safari and Camino and I very, very, very seldom (like one in a couple thousand) meet a page that does not render well in them. Most of the time the culprit is some abused Javascript code.
For the other cases, like Google Maps, bank sites, portals et al, they will have plenty of time to adapt. In the long run, things will be better, since all rendering engines with have to conform to stuff like the Acid Tests and all.
The fact that most, if not all, of these pages now work with IE7, even though they initially broke, kind of refutes his argument altogether. Yes, for a while some pages will be broken, some people will complain, IE8 adoption might be lower than it could, they all will be OK.
Where by all I mean “every web page that matters”. Maybe Jack’s Chipmunk worship page, with it’s garish javascript animations and ActiveX chipmunk clock will suffer. So be it. Does every old DOS program run on Windows Vista? Not, really. Get on with the program.
He also says:
The victory of the idealists over the pragmatists at Microsoft, which I reported in 2004, directly explains why Vista is getting terrible reviews and selling poorly.
Emm, no. Vista being too little, too late has far more to do with it. Very few of the features promised where there on launch, plus the thing is slow and buggy. While people complain, they do adapt to change. On the other hand they don’t react all that well to crap.
98% of the world will install IE8 and say, “It has bugs and I can’t see my sites.” They don’t give a flicking flick about your stupid religious enthusiasm for making web browsers which conform to some mythical, platonic “standard” that is not actually implemented anywhere. They don’t want to hear your stories about messy hacks. They want web browsers that work with actual web sites.
Really, they are gonna say “It has bugs and I can’t see my sites”? Strange, since, all this 98% of the world will, at large, visit sites that already work fine on Firefox. If a 10% of the US or nearly 20-30% of web surfers in Europe can get by with Firefox then so can those 98% of naive windows users installing IE8.
Will they really care if some obscure site or some “pages burned on CD-ROM” no longer render correctly? Hardly. At large, no. And even if they do, who cares? It’s not like they can do anything about it, except delay switching to IE8. Firefox is also standards compliant, so they won’t get anything by switching to it. So what are the adverse effects on MS? Some complaining?
What Joel calls “pragmatic thinking” is probably what got MS in such as mess. And all this talk about “backward compatibility” with older Windows versions and special modes etc, is what made the computing world so fragmented. Like, how it’s so difficult to provide .doc compatibility, read/write NTFS support, properly support IE html et al.
Now, if what he talks about is “customer lock-in”, yeah, he is probably right. But that is another story.
Wordpress 2.5, the new version that was due on March 10 seems to have slipped its’ deadline.
Nothing official on the WordPress blog yet, but according to a post on Planet Wordpress there are code quality problems at the moment and the new release date is 3/17/2008.
Just a week more then. Nice. Although the lack of an official statement is not very reassuring.
(In my opinion, the KDE project always excelled in this kind of transparency in development).
