There is a lot to like about Mac GUI. There are also noticeable shortcomings. Mac's menubar, for example, sucks with large and/or multiple displays because the distance between application windows and the menubar can be ridiculously far since only one display can have the menubar and it's always at the top.
My big screen is shared by my MBP and my desktop. Since I use the big screen as my main screen, menubar is shown there and the MBP screen is filled with windows of 'always-on' apps like mail and IM clients. This means menubar for apps displayed on the MBP screen is not only at another screen but another input source. Making the matter worse, the big screen insists on stepping through all five input sources in sequence instead of just toggling back and forth between active input sources. Very annoying.
With Mac, you have to click-to-focus. That sucks with big and/or multiple displays because having lots of screen area means having lots of windows open side-by-side. When I click on something in a window, I expect it to do something more than activate. Because I have to click twice to close a window (once to focus, another to click on the red button) and because I find it annoying to have windowless applications loitering around, I use command-Q more often than window close button. That's nutty.
I am going to stop before my blood pressure gets any higher. This rant wasn't very therapeutic. Rather, it's making me want to recommend Mac to others so they can suffer the same.
Mac is like marriage. It's simply great.
When it's ugly, it's ugly. Compared to XSD, even DTD looked good. When XML-DEVers first got a whiff of XSD, the prevailing opinion was negative. Some, like James Clark, disliked XSD enough to suggest an alternative: RELAX-NG. Like I wrote before, one of the problems with W3C is that it doesn't have a reverse gear. Instead of scrapping XSD and adopting RELAX-NG, it put all of its weight behind XSD, smearing the filth across the board. In retrospect, I wish I screamed louder but I doubt that would have made any difference.
So it's no surprise that I wholeheartedly support Elliotte Rusty Harold and Tim Bray's call to abandon XSD in favor of RELAX NG. But it'll take at least 2-3 years of everyone working together to turn this ship around because a) XSD is engrained in many key XML standards and b) RELAX NG support in XML tools is still too sparse. In particular, SOAP-based web services will have to hold off on switching to RELAX NG until specs and tools with first-class RELAX NG support arrive. REST-based web services will have an easier time though since they are not as tool-dependent as SOAP-based web services.
It's ironic that we are in this mess because it was too late to use RELAX-NG and now it's too early. At least, new XML-based standards should have strong, if not first-class, support for RELAX NG from now on.
Postscript: I think Schematron is superior to RELAX NG in some areas like for specifying client requirements.
While I am not fully convinced that Ruby is the best language ever and that Rails rules, I think RoR (Ruby on Rails) is great for prototyping and maturing webapps.
Setting up Ruby and Rails for development on a Mac is not as easy as with Windows but it's mostly just a sequence of the usual *nix get-expand-configure-make-install dance step. My recommendation is to avoid the easy alternatives like Fink, DarwinPorts, and Locomotive. I've heard great things about the first two but I think they have since fallen behind far enough to be inappropriate for leading edge development works. Locomotive is better and flexibility offered by bundling is great but I found their setup awkward and, well, I have little need for bundle silos.
To setup my MBP (running OS X version 10.4.8) for RoR development environment, I followed the instructions in Building Ruby, Rails, LightTPD, and MySQL by Dan Benjamin but using the latest versions of packages and also installing rake and mongrel gems. Afterward, I upgraded Rails to 1.2 RC1 to give its REST support a spin.
Re IDE, both TextMate (~$50) and RadRails (free) are great for RoR development on OS X.
Who we are affects what we make. Engineers are focused on functionality. With IM, a key ubiquitous feature is knowing when contacts are available. While this feature is useful, it falls short as a social user interface.
When I launch my IM client, Atrium on Mac, I know who is online at that moment. I also know that, unless they disabled the feature, people on my contact list know that I know. While this is fine normally, an awkward situation develops when recent communication with someone on the contact list didn't have proper closure. The sense of closure is relative so the awkwardness could be felt by only one party. Still, it's awkward.
Not all communication is need-driven. One might just want to chat casually with a friend over nothing, to say hello, to maintain the bond. This is hard to do with IM because starting a IM chat session is too abrupt for casual situations. SMS is less abrupt but still noticeable enough to signal to sender when a SMS message is ignored.
Groups as Rooms
In real life, chance encounters provide the opportunity to communicate with friends. Likewise, IM clients could turn each contact list group into a chatroom. But this doesn't work well if the groups are not shared, like rooms are. Better approach is to leave groups as is and add rooms in parallel.
In real life, one can briefly peep into cube or office of the person one wants to talk to. If the person is busy, a brief non-verbal gesture is all it takes to set up a chat at some later time. Peeping could be easily added to or on top of IM clients by allowing one party to send peeps, some visual *ignorable* hint, to a contact and the recipient to see a log of recently received peeps. IMHO, peeping is too strong a gesture *if* contact status monitoring is also available. It's just right when one must peep to find out whether a person is online or not.
Right-click on my wireless Mighty Mouse started to fail last night and, by morning, it stopped working altogether, registering all right clicks as left clicks. First solution I found suggested removing the battery under the right-side. That couldn't be right… Hmm. That actually worked! Looking further, general solution was to turn the mouse off and on again. Now that makes more sense. The problem now is that Mac doesn't rediscover the mouse automatically, forcing me to set it up fresh every time right-click fails which can be as often as 2-3 hours. Annoying.
I would get another wireless mouse but MM's tiny roller ball is such a pleasure to use that I am reluctant to switch.
Update: Aha. I didn't realize that I had to push a mouse button to reconnect the mouse after turning it off and on. Rather odd design but at least I can now live with the secondary button problem (off-on-click-wait to restore right-click ever 2-3 hours in the worst case).
Oh boy. Kevin Kelleher buries Brad Garlinghouse, the Peanut Butter Manifesto guy, piling his past sins on top of him: Yahoo mail, Dialpad, and CMGI. Brad comes out looking like a real yahoo.
According to Washington Post, Pentagon is considering three options re Iraq:
- Go Big – send in more troops.
- Go Long – shrink the force but stay longer.
- Go Home – pull out
I would add to that list another option:
- Go Up – switch to air power.
This option pulls most of the ground troops out but retains enough to secure a handful of key air-fields from which air power can be projected. From these unassailable towers of air power, we can strike down any large scale anti-government forces and aid pro-government forces as needed to keep it from spinning out of control. Death toll among the Iraqis will be heavy but I think this is the best compromise.