Leopard Wiki Server

I suppose I should first do some research to see if the wiki server that comes with Leopard Server is open-source or licensed or whatever, but for now, suffice it to say that it erases every last nasty thing about contributing to a wiki.

Lots of Javascript and excellent graphics make me all the more psyched about the SproutCore-based applications that you’ll get with MobileMe.

Very nice. My world should change significantly after .Mac transfers to Mobile Me.

As for my own development, well, someone with the experience to speak on such matters offered the following advice:

  • 64-bit
  • Computationally expensive
  • Graphically intensive.

If your requirements include any of those things, write a native (Cocoa) app. If none do, write a web app.

I’ve never much liked anything to do with a serious application inside a browser window. I never EVER write long pieces in a web text field for fear of losing it all (e.g., I have used a blogging client—two, now—ever since I started blogging). For those of you keeping blogs, I highly recommend ecto and MarsEdit (oh, and check out Red Sweater Software’s other offerings. Daniel Jalkut is a brilliant developer.)

There’s so much more you can do with a local client than in a blogger or typepad web editor, like add Amazon references or graphics by a built-in search function. And indie developers are some of the best out there.

For example, Wil Shipley of Delicious Software is the smartest man on earth (and probably a space alien—he’d have to be). If you’re not a Mac user, go to an Apple store—or find a friend who’s a Mac user—and download the demo of Delicious Library. Oh, and bring a book or a CD or DVD with you just to try out the built-in barcode scanning. If this app doesn’t make you want a Mac yesterday, well, Microsoft has won.

Baby It’s Cold Outside

The Phoenix mission to Mars has been picture perfect so far. It landed only slightly askance from where they’d pinpointed it, but it landed One quarter of one percent degrees off of vertical. Holy crap.<?p>

phoenix_lander1.jpg <br/>

It’s near the north pole, so two things:

  1. It’s frickin’ cold outside, Mr. Bigglesworth.
  2. Lots and lots of life-preserving/sustaining/archiving ice, I hope!

All my life I’ve dreamed of space and have believed all obstacles to be impermanent. So while I can’t say I’m surprised we’ve gone where we’ve gone, it’s just an unbelievably huge thrill to see it, understand it and live with the implications of it.

And if #2 above is true, how will that taste to dogmatics who put Earth at the center of the universe?

People Who Write Lame Software

My full disclosure: I work for the company that this guy has been flaming at and he’s been doing it for a while now.

Disclaimer: Everything I say in response to this guy comes from years of experience with software development before I started working for Apple and in no way nor context am I disclosing internal specifics about my employer.

There was an old hypocrite who lived in a shoe. And by shoe, I mean glass house. And by old hypocrite, I mean, well, a lame, hypocritical stone-maker who throws stones.

Here’s a little background information on software development. Development is more than just writing a program. It involves interaction with ‘domain experts’, in other words, those people who will be using the software and who know best the tasks they need the software to accomplish. It’s also up to engineers who either have a background in the domain or at least do some seriously legwork in learning about the domain. This is the fundamental catch-22 that’s usually one of the most difficult parts of software development. Think of it as, say, a Tibetan historian trying to communicate with an American engineer alone in a room with no moderator nor translator. This stage is arguably also the most important. Software exists to enable or enact…people, businesses, teams, other computers..whatever. Software’s purpose is to accomplish something.

People usually pay far too little attention to this. From small developers to large ones: Microsoft doesn’t care about people who need to produce documents so much as they care about the marketing people who need add extra features bullets on their Powerpoint slides.

The software itself—that is, the final product that goes out to the public—often lives or dies mainly on how much care was spent at this stage of the game. The short version of all this: know your audience!

•••

There’s a piece of software out there called Xfile, written by a guy who also has lately been on a tear taking potshots at Apple for their lack of attention to his own needs. Does he file bug reports to Apple? No, he says, because they don’t pay attention to them. So instead he expects a large corporation to pay attention to his strident rants and ad hominem sarcasms and that’s the better way to get things fixed. Uhhhh, what?

Here’s how software product development works in every development house I’ve ever worked for:

  1. Create a proposal for a feature set based on what you expect the app should do.
  2. Speak to domain experts before and/or during this process.
  3. Prioritize those features, again using the expertise of the domain experts’ assistance
  4. Produce a schedule and have engineers write the appropriate code, designers produce the graphics, HCI/UE people approve or create workflow scenarios within the app
  5. Have QA people come up to speed on all these things and along the way, test and file bugs against each interim build of the app.
  6. Jettison features for which there is no time to implement or get working acceptably.
  7. Continue QA, including filing bugs against errors and broken features
  8. Along the way, all bugs filed into a database are reviewed by managers and engineers. When bugs are fixed, they are re-categorized so that the QA people can verify the fixes.
  9. Eventually, all high-priority bugs are fixed and decisions are made whether to release the software or not, with remaining bugs deferred until a future release (like Mac OS X was released as 10.5.0, quickly followed by a 10.5.1 version which included fixes for many of those bugs that were deferred from 10.5.0.

The point here is that there are so many people involved in a significant software product that all defects (bugs) in the software—and in the documentation, packaging, etc.—must live in a central repository so that they aren’t lost and so that anyone can access not only the bug itself, but information on how it can be reproduced, what its history has been, who has worked on it, what its priority is, etc. That’s the only way it all works. The bug database is god: if it’s not in the database, it doesn’t exist. period. This is a matter of logistics, not ideals. Of necessity, not convenience or excusability.

In many cases, it’s a user out in the field that has discovered a bug. And for reasons already explained, those users are encouraged to file the bugs through official channels. That almost always means filing the bug directly to the company, which adds the bug directly to the aforementioned database of bugs, which means they go to god, which means they end up in the only place they can possibly be found and tracked.

So this guy at Rixstep hasn’t gotten fast-enough satisfaction when he’s filed bugs, so he stopped submitting bug reports for the bugs that bug him. Completely illogical, unless he actually believes his cheap potshots posted solely on his own little website is going to be more effective in getting Apple to fix bugs than actually getting bugs entered into a bugs database. Then it’s not illogical, it’s delusional.

But I read most of these rants and found them a bit hysterical (unraveled, not funny). After a while I discovered that he puts out his own software, one of which is called Xfile. He touts it as a replacement for the Finder because he hates the Finder and its bugs.

Fair enough. That’s what official SDKs are for: writing software as a third-party. I even applaud him for it, did applaud him for it. Until I started on the path to obtain and install and use it.

The software downloads as you’d expect, and the Finder (irony!) uncompresses the file, leaving you with a folder. Ok, we’re still well within a user’s expected experience, all’s familiar.

But what’s in the folder? A bunch of applications, a “readme.html” file, and something called APC.framework.

Most of my friends don’t know what to do with a .framework item. Certainly my mom has no idea what the hell ACP.framework might be. Most Mac users might have heard of a framework, but only from a certain distance, thanks to Apple for shielding as much of the techie stuff as possible from a user.

But there’s that “readme.html” You have to drag the ACP.framework into the /Library/Frameworks folder and you have to create that folder if it doesn’t yet exist. Then you drag all the other contents (other than the framework and the readme.html) into your Applications folder.

Does the Rixstep guy know that the Mac comes with an Installer.app? Does he understand how to build one? The behind-the-scenes reasons why it’s preferable to build an installer package?

So I ran the app, cuz I’m a software guy and I happen to know how and why those steps exist (even while I fail to understand why I must perform them manually), and this is what showed up (click for full-size):

thanks for putting so many icons in the toolbar that you had to set it to Icon-only just so that they’ll all fit in the toolbar. And for moving, willy-nilly, the standard user folders from a sidebar (where both icon and text label can be shown) to the toolbar, a non-standard location for any Mac application. There’s no use of space to group icons by function or meaning. (see iWork’s Numbers app for an excellent example of toolbar icon grouping).

And thank you so, so, so much for the frequent modal nag dialogs that remind me I haven’t yet purchased it. Or are you going to blame the Dock for bouncing at me every time any app puts up alerts?

I should have asked you rixstep folks for the webpage wherein I could formally submit bugs, but hell, you’ll just ignore those because you believe that petulant, petty ranting on a blog is the better way to go to get your concerns addressed.

Rixstep doesn’t stop there with all the duplicity, they have a page with the incredibly misnamed “Industry Watch”.

A sample, about a well-loved and popular blog editor called MarsEdit:

Everybody loves MarsEdit - but that’s not the issue. A lot of people loved their Fords before those Firestone tyres started exploding. It’s not about what you see - it’s about what you don’t see. And the likes of the Macosphere are not good at seeing these things. Irretrievable tards like Jonathan Wight, Gruber, and all the people Malcor hates simply don’t have the chops to do a lot more than use good old MarsEdit to write more blogposts about everybody else’s blogposts and crisscross links.

This is about as productive as it gets there.

They did offer some help, tho:

Do not accept half-arsed half-baked pieces of shit software from the Landed Gentry of Mac Development™. They want you to sit down and shut the fuck up. They’re used to getting away with murder. Don’t do it. Don’t sit down, don’t shut the fuck up, don’t let them get away with it.<br/> <br/> There’s only one way you’re going to get quality software from this crew: by demanding it. They’ll never give it to you for free.

Ok, so here I go…

So the developer of MarsEdit left a few tiny and harmless files within the shipping application bundle? You fucktards at rixstep don’t even know how to build an installer package! When I tried to quit the POS that is Xfile, first I had to answer the nag alert one more time that I most certainly didn’t want to buy their lame-ass software.

Rix-dicks, your own back yard is a pestilent swamp. How’s about you dry that up and remove the that contagion from the world before you go taking unfounded and overblown potshots at people who actually write software that people love to use?

But hey, at least your terminal-window-with-a-toolbar “application” can count the number of files in a man-pages directory lickety-split! Well done you.