These auctions include a total of over $11,000 worth of software. Each disc—whether Mac or Windows—contains about $1,100 in applications, all donated by a lot of very generous developers.
Get some great software and help fund cancer research.
Neither Google, nor any person or corporation, has any legal right to a digital copy of any book I own just because Google wants it and I’m willing to let it make the copy. I may have a “fair use” right to a digital copy of a book I own, for my own personal use, but that doesn’t mean I can give the digital copy to anyone else without also giving them the original book. Any of these libraries may have the right to digitize copies of their collections, but if that’s the case, the copies belong to them, not to Google or whoever made the copies.
So, as a Mac programmer, I should really get a good handle on these floating point thingies. But floating point numbers seem pretty mysterious. I know that they can’t represent every integer, but I don’t really know which integers they actually can represent. And I know that they can’t represent every fraction, and that as the numbers get bigger, the fractions they can represent get less and less dense, and the space between each number becomes larger and larger. But how fast? What does it all LOOK like?
In a “normal” programming language, the equivalent to “
path to fonts folder from user domain” might be something like:path_to("fonts folder", "user domain")And the equivalent to “
path of fonts folder of user domain” might be:user_domain.fonts_folder.pathThe point being that in most languages, these two calls don’t look at all similar. Which is a good thing, because they aren’t at all similar: one is a global command taking two parameters, the other is a property of a property of an object. AppleScript’s slavish devotion to English-likeness, on the other hand, gives us two very different syntax constructs that read, to humans, as though they’re semantically identical.
John C. Welch, Rick Schaut, and Pierre Igot discuss the Microsoft re-organization and Mac Office.
Josh Aas (Firefox developer):
Secondly, Macworld put Firefox 1.0.6 ahead of Safari, which is almost as ridiculous as putting Camino behind Opera. See, I’m not biased towards Mozilla browsers! Safari 2.0 is simply a better browser than Firefox 1.0.6. Its [sic] not even close. The story is a little different with Firefox 1.5b1, but that isn’t what they are reviewing.
I agree that the Macworld rankings are odd. I think I would order them Safari, OmniWeb, Camino, Firefox, Opera. I couldn’t care less about Firefox themes or extensions, and I deduct huge numbers of points from it and Opera because they don’t look or feel like Mac apps.
Wil Shipley’s heart is in the right place. It’s obvious that he cares about quality, and his experience and common sense rightly make him skeptical of process. But I think he’s absolutely wrong about unit testing. In brief, I think he misunderstands what unit testing is (or should be) and what it’s useful for. He shoots down a stupid way of doing testing, throws the baby out with the bathwater, and concludes that it’s better to write good code in the first place, do manual testing (“Try odd things. Whack keys.”), and rely on beta testers.
I don’t deny that this approach has worked for him. He’s written a lot of code, people have generally been happy with the products, and they’re not known for being buggy. But my hunch is that Wil’s teams have gotten good results because they’re unusually smart, experienced, and hard-working. They’ve succeeded in spite of their testing philosophy. Wil makes a great case that manual testing and defensive programming are necessary, but I think most programmers would be more effective and efficient if they combined these with extensive automated unit testing.
Now, I’ll be the first to say that by-the-book XP/TDD goes overboard. If you need a new class or method, I think it’s a waste of time to write a test that simply checks for the existence of the class or method, then write a stub, then run the tests, and then then flip back and write the real tests. Perhaps that example is just for pedagogical purposes and one isn’t meant to do that in production code.
I also think it’s a waste of time to write tests for everything. Some parts of the code are so simple that they don’t need tests, though this applies less often than you might think. Other times, it would take so much work to write a proper test that it’s better to punt and check that item manually. (I’m thinking of user interface details that you’d immediately notice when running the application, as well as more elaborate situations/interactions. In the latter case, write the test down in English and make sure that you really do it manually before shipping.) Again, though, this applies less often than you might think.
My overall point is that time is limited, so you should use it wisely. And this is why extensive unit testing is a big win. Yes, it’s not possible for your tests to cover all the pathways through the code, with all the possible inputs. And even if they could, it probably wouldn’t be a good idea to spend your time writing tests to do that. This does not mean, however, that you should reject unit testing as impractical and try to test everything manually. That’s not a good use of time, either. In brief, proper unit testing saves time and improves quality because:
A lot of people seem to think that automated testing is only for frameworks, or for tools without graphical user interfaces and interaction, or for academics, or for software that’s directly responsible for people’s lives. Not true. I think unit tests are useful in writing Mac applications, and even for testing large chunks of the user interface (i.e. checking that a table is showing the right rows in the right order, that clicking a button has the right effect, that a certain sequence of actions causes a view to refresh in the right way, etc.).
That said, your tests will not cover everything, or even close to everything. GUI software has many sources of input—all the different user interface items, in addition to the disk, the network, etc. It also has complex interactions with huge chunks of operating system and library code that you didn’t write and don’t have access to.
So, yes, you shouldn’t believe that because you have unit tests you don’t have to do manual integration tests. I doubt anyone is in danger of thinking that. Wil says:
Testing is hugely important. Much too important to trust to machines. Test your program with actual users who have actual data, and you’ll get actual results.
And I doubt anyone would disagree with that. However, testing is also too important to trust to humans. This is one reason that you need automated unit tests. The other is that it’s not all about how many bugs users will find in the binary that you ship. It also matters how long it took you to create that binary, and how easily you’ll be able to develop the next version. People who like automated testing find that it helps them write better code more quickly. I believe it’s at least as beneficial for small teams.
Don’t miss the comments from Chris Hanson, Marcel Weiher, and others.
I may have to face the fact that my days of living off a PowerBook are over, perhaps for good. If so, I’ll probably go with big-honkin’ desktop machines and one small cheapie iBook for presentations and conferences. I fear the Macintel in the mail is the first step down that slippery slope.
Do we really want to doom users of desktop apps to a lot of web-style scrubbing around with the mouse to discover features?…Have we just been conditioned to click and double-click around everywhere in case we can edit the text? It seems to me that kind of behavior only makes sense inside a text editing view, not just anywhere in a window.
Hopefully, Michael’s questions are rhetorical, but in case they’re not: Apple, this design sucks. Editable fields should look editable.
Does this make Entourage a 1:1 match for Outlook? No, not at all. There are a lot of functions in Outlook that require Windows, or a level of integration with Exchange that Entourage doesn’t yet have. Does that make SP2 any less of an improvement? No, not at all. The Exchange and other fixes in this release of Entourage take care of a rather large amount of complaints about earlier versions of Entourage, and show that the MacBU hasn’t been sitting around twiddling their thumbs.
A few days later, I received my order. Inside I found my gear along with some candy (apparently each order comes with a handful of “Sweetwater candy”). I unpacked my loot and realized that I’d been sent an extra Midi cable. I didn’t think I had ordered two but on the invoice it did say two cables. I sent Mac an email about returning the extra cable. He replied, “I threw in another cable for you. If you look at the price, nothing changed from your initial order. It never hurts to have an extra laying around! Thanks again for your business.”
Sweetwater delivered a solid customer experience from top to bottom. No wonder customers sing the company’s praises to others and come back for more.
Sweetwater’s made a loyal customer out of me, too. The service is great, and having a knowledgeable personal sales rep makes sense. However, I think that phone follow-ups, just to make sure that I received the order and everything is working properly, is going a bit too far. Interrupting me for no good reason makes me slightly less happy.
The main reason for these revisions is that Apple has done something truly unexpected: they’ve actually made Backup a useful backup application. I can’t overemphasize the significance of this move. I’ve made no secret of my disdain for earlier versions of Backup, which lacked basic features I consider crucial. Although I’ve only spent about an hour so far testing Backup 3.0, I have to say that so far I actually like it. I might even use it. In fact, I might even go so far as to recommend it—for certain kinds of users in certain situations—in lieu of my old favorite, Retrospect.
A lot of Apple’s “iApps” have a standard mechanism for browsing media (photos, music, movies).…It would be great if this was a public framework that we could access.…Apparently, Comic Life just wrote their own by parsing Apple’s XML files. OK, so you can do that. But it’s a hassle. It would be nice for Apple to provide a standard way to access media, so that developers don’t have to keep inventing the wheel.
And, conveniently, Mac OS X 10.4 (“Tiger”) has a new framework for reading and writing images, and it understands JPEG2000 natively (based on the commercial, C++ Kakadu library). And, in this new Apple framework, there’s a function CGImageSourceCreateThumbnailAtIndex() where you can create a thumbnail of an image you haven’t read in yet, by specifying a maximum side length (kCGImageSourceThumbnailMaxPixelSize). This would be EXACTLY the kind of call in which one would implement the partial-reading of JPEG2000s in order to quickly read in a low-rez versions of high-rez files.
Today Google informed me that I’m not allowed to use the word “Mac” in ad copy.
We hear about “Enterprise Software” all the time. Or, this is a product for “The Enterprise.” Let’s see what you think it means. In this context, explain “Enterprise” in 10 words or less.
Well, you don’t have to use the tofu file system APIs. You can use Carbon’s granite FSRef-based APIs, which offers high-fidelity file system entity routines. They’re not path-based, and thus don’t suffer from the inherent flaws of path strings.
But! Hilarity ensues when you mix the competent FSRef APIs and the tofu path APIs: it’s possible to “blackhole” a file.
Pierre Igot has some interesting observations about iTunes’ source list compared to Mail’s and the Finder’s:
What if you want to create a new folder the root level? Well, same as in Mail: You first need to make sure that nothing is selected… Hold on a second! In Mail, in order to deselect what’s currently selected in the mailbox drawer, you can click on the empty area at the bottom of the list. Not so in iTunes! In iTunes, you cannot have nothing selected in the source list! So what do you have to do if you want to create a new folder at the root level of the source list? Well, you have to select an existing source at the root level of the source list first—but not a folder! (Otherwise, iTunes will create the new folder inside that existing folder.)
John Siracusa (on his new blog):
State retention sounds like a Nerd Feature, but surprisingly few people, nerds or otherwise, seem to request it. It’s also a pain for developers to implement, blah blah, read all about it. But once someone experiences it, it’s hard go back. What’s rare is the unprompted desire for state retention, not the love of the actual feature in practice.
The iPod competitors are all so focused on music file formats, and music delivery formats, and subscription vs. buying that they forgot about getting people who aren’t online music services to build toys for their stuff. So now, Apple has one primary interface, and three four case designs. They have a developer program that gets you information on the iPod. As of iTunes 5, the iPod integrates with Outlook. The iPod’s no longer a player, it’s a platform. The others? Just players. In truth, they’re nothing but accessories for Microsoft’s Windows Media platform. That’s why each one is an endpoint, and the iPod is really just a starting point.
I like that the huge margins are gone, but the rest of the changes make it uglier without quite matching any of Apple’s other non-standard applications, either. It still uses modal dialogs and fudges the display of the keyboard shortcut for Play.
The first thing I tried to do was search my library for podcasts that matched a word, and it didn’t find any even though I have many matching tracks with that Genre.
The second thing I tried was the new Show Duplicate Songs feature. But this doesn’t compare the file contents like iPhoto does; it just compares the metadata, finding tracks with the same name and artist (case insensitive) even if the content and duration differ. What’s the point of that? First of all, there are some songs that I have many different versions of—on purpose. Second, it’s worse than useless for some classical albums: Albinoni’s “The Complete Concertos, Opus 9” has six tracks called “Adagio” and six more called “Allegro.” I don’t think Yo-Yo Ma, who was in Apple’s audience yesterday, thinks that he played the same track 16 times in a row on his 1999 solo album. CDDB is weak for classical CDs, but still.
Here’s what other people are saying:
How much have they broken their HIG this time? I think square is the new black. For some reason, everything I see is square.
iTunes’ improved search functionality is nice, but a little inconsistent. Some fields, like Album, are always searched, but others, like Description, are only searched when they are displayed.
I think iTunes 5.0 is UGLY, especially the new glossy playback status bar & the volume slider.
Burnt Aqua isn’t ideal, but it’s hopefully some movement, and I’ll get similar pleasure if and when we see everything move to Aqua Unified. If everything starts getting those horrid Mail.application icons, I shall rail, but for just one day I’d like to see it as a hopeful sign of improvement instead of more weirdness, even though those in the other camp have just as high a chance of being right.
Now all Apple have to do is add this stuff to the HIToolbox and (on a more selfish note) AppKit, and fix Safari and iChat already.
But why, oh why- do we need yet another custom window on osx?
I was really hoping the unified/plastic look would replace brushed metal but it looks like we are just going to get a new smooth metal variant which I think is actually uglier *sigh*. Seriously someone needs to gift wrap the ugly stick and send it back to Redmond.
Me, I don’t have a lot of opinion yet (just observations).
The new paint job is nice (still visually distinctive in Exposé, though not as heavy as the metal), but I’m not impressed thus far. With regard to lyrics, the lesson is: if you are going to implement a feature, do it right or don’t do it at all.
I’m going to put off downloading iTunes 5 for as long as I can. It is butt-ugly. I don’t mind the smoothed over brushed metal look too much, though the gradients are a bit over-done. But everything is so horribly crowded now.
What’s up with the corner radii of these windows?
…in the previous version of iTunes there was consistency in these widgets. The widget layout was the same between the large iTunes window, and the smaller utility version. Now it’s inconsistent and widgets rearrange themselves depending on the window type.
The iPod nano looks to me like a home run. Take that for what you will, since I thought the original iPod would flop; and though, it was much better than the competition, I found the 3G frustratingly inelegant. But, if you like the other iPods or the iPod mini (and tens of millions presumably do), it seems to me that you’ll like the Nano even better. Personally, I’m happy with my Shuffle. It does exactly what I need and does it better than the Nano would.
John Gruber’s new CSS Syntax Checker tightly integrates with BBEdit. It can be automatically invoked when you choose “Markup ‣ Check ‣ Document Syntax,” and the errors show up in a standard (separate) BBEdit results browser. Built with AppleScript, Perl, curl, and the W3C CSS validator.
There’s now a del.icio.us tag for the Report-an-Apple-Bug Friday blog meme that Dan Wood started.
The new version of Sync Pro no longer fills the verification log with spurious entries for alias files.
The September issue of ATPM is out:
