Jonathan "Wolf" Rentzsch is the first to announce that MacHack will stick to its scheduled date of June 19-21. When Apple moved WWDC last week to the week of June 23rd, the MacHack crew was left wondering what to do. Apparently they've decided that enough people will attend if they stick with their original schedule.
I've noted at TidBITS and elsewhere that people are concerned that Apple employees won't be able to attend MacHack if WWDC is immediately after it. While I can't speak for anyone else at Apple, that concern seems somewhat misplaced to me. Apple employees who aren't directly involved in WWDC presentations aren't tied to Cupertino immediately before the conference. I won't be giving a talk at WWDC, so I'm free to head off to MacHack and speak there. I think the same is true for the other Apple speakers, but I can't be certain.
I am concerned that developers won't be too keen on flying to Michigan for three days, then flying to San Francisco and returning home. One-way plane tickets are expensive. I'm sure the MacHack organizers realized that, though, and found that it didn't outweigh the cost of moving the conference. Personally, I'll miss being able to talk to people about Panther, and I wonder if Metrowerks will discuss CodeWarrior Pro 9 before WWDC. But it'll still be a tremendously fun conference -- at no other time or place can you find such an impressive collection of Mac programmers, all doing nothing except talking about, and writing code for, Mac OS X.
If you haven't signed up for MacHack yet and you're thinking of going to WWDC but find it a bit expensive, I'd really encourage you to attend MacHack. It's not like WWDC in that you don't have Apple talking to the crowd; instead, you get to meet all kinds of people from many different areas of expertise who are doing tons of interesting things. It's a terrific way to make connections, or even just to put faces to the names that you see in various forums online. If you've never been to MacHack before, now's a great time to start.
William Safire's weekly On Language column in The New York Times covered hyphenation this week. I'm a stickler for grammar -- coworkers at both Microsoft and Apple will tell you that I'll edit anything when given the chance -- but my concept of proper grammar comes from a sense of whether something sounds good, not any memorization of rules. Since hyphenation is a writer's tool and often wouldn't make an audible difference, I've never really had a coherent view of when it should be used. Consider the title of this post -- when I wrote the latter half of it in an email message earlier tonight, I added hyphens where the friend who originally mentioned the strawberries had left them out. The phrase just seemed better with them.
Fortunately, Safire's column shows that nobody else really has a coherent view of hyphenation in English, either. The best explanation he can arrive at is that the writer should avoid confusing the reader. That's good enough for me, since that's what I'm striving for when I edit. Another small victory for descriptivist grammar, I suppose.
I can't believe it's been almost a week since my last post. It's not like I've slept the whole week, or anything like it. Quite the opposite, rather, as I've been buried in a variety of different things, mostly related to work. I think there's an understanding in any new job that for the first little after you start you're not very useful -- you muddle your way through while learning things as fast as you can. Eventually, though, the little light bulb flashes on in your head and you can jump right in.
That's what it's been like for me. I didn't contribute too much for a while, but now I'm starting to make a difference. Or at least, I know enough that I can accomplish some things, and with luck they'll even turn out to work well in the end. But along with being able to get stuff done comes the realization of just how much there is to do, and that's what I've vanished into for the past week.
I finally went out and bought a TiVo today. I've heard too many people rave about it for too long, so I had to get one. I resolved the question of which unit to buy fairly easily. They have 40-hour and 80-hour units, and since I didn't watch 40 hours of TV last year, I figure the smaller one should be fine.
Setting it up was more complicated than I expected. We have a cable box, so I followed the "satellite and cable box" instructions. They have a pretty diagram in the quick setup manual showing where all the wires should go, so I started to follow that and rapidly ran out of cables. It took me a few minutes before I realized that the diagram showed all of the possible placements of cables, while the written step-by-step instructions on the side skipped various steps depending on your configuration, ensuring that you only plug in the cables you need. Oops. I guess I just proved that users don't read manuals.
Things were complicated further at the cable setup step, since we're in one of those fun transitions between AT&T cable and Comcast. The TiVo showed Comcast as an option, so we picked that, but none of the plans matched the name of the plan on our bill. Of course, our most recent bill is from AT&T, not Comcast. Fortunately, Ruby knew what station Telemundo is for us, so I just went through the plans one by one until I found the one that had Telemundo as channel 18.
Then I had to figure out how to get the TiVo to communicate with our cable box. It uses some nifty infrared thingies to act like the cable box's remote control, but they have to be positioned just right above and below the infrared port on the cable box. The manual suggested using a flashlight to find the infrared port, but we don't appear to have any flashlights with batteries around. Oops. It also mentioned fastening the infrared controllers to the cable box with the provided adhesives, but I couldn't find those in the box. I had to resort to trial and error, iterating over the front of the cable box an inch at a time, while iterating through the zillion different infrared channels the TiVo showed and hoping the lack of adhesive didn't cause the infrared controllers to fall slightly out of kilter and screw everything up. Eventually, it all worked, and there was much rejoicing in our living room.
Shortly after that, the TiVo asked me to choose a local phone number for it to use. It displayed a long list of San Jose numbers, but none with any exchange I recognized. We haven't received a phone book from AT&T yet, so I went to their web site to see if I could find out which exchanges are local for us. No such luck -- all of the AT&T Digital Phone pages redirect to Comcast's home page, which has no information about local phone service. Wonderful. I picked one randomly and moved on. Here's hoping we don't have a huge phone bill next month.
Eventually I got to the point where the TiVo wanted to process its data. It put up a screen saying that it had to process the data for 4 to 8 hours, and that it couldn't be turned off in that time. While moving on from that screen, I managed to hit the buttons on the remote in a way that turned the unit off. Oops. I've had that problem with the remote the whole time -- I keep hitting right when I mean to hit up, or perhaps pressing down in the middle of the arrows. I'm not sure, but I really don't like the design of the arrow keys. I'm continuously selecting things that I didn't intend to select, because the right arrow often selects the current item in a list.
I turned the TiVo back on and waited four hours, hoping that it would recover. In the meantime, I went to the customer support site (which doesn't work in Safari -- is it Safari's bug or TiVo's?), but I couldn't find anything there about what to do when you turn the TiVo off after it tells you not to. I even wandered over to the TiVo Community Forum for a little while, but I couldn't find an answer there, either.
As it turns out, it came through just fine, and four hours later I had a happy TiVo. Now it was time to record a few things. We only want two things to be recorded at first -- a Spanish soap opera that Ruby enjoys called Terra Esperanza, and The Simpsons on Fox (not the syndicated ones; the current season). I went to record Terra Esperanza, but it wasn't listed under Daytime TV. Weird. I found it under All Programs, set up a Season Pass, and all was good. Then I tried to record The Simpsons. No such luck there -- the TiVo seems convinced that The Simpsons is only on in its syndicated version, at 6, 7:30, and 10 every day on some random channel whose call sign doesn't mean anything to me (the non-TV-watcher). I've tried searching by title, by channel, and by time, but I can't find it. Hmph. It's all complicated that much more because I don't know what local station Fox is, but I suppose that's not typical for TiVo users. Still, it'd be nice if they displayed the affiliation along with the call sign.
I don't mean to come across as down on TiVo. I've barely used it, but I can tell that it'll change a few things around here. I'm looking forward to watching The Simpsons and Baseball Tonight for the first time in years, and I'll now be able to do that without having to remember when they're on and reschedule the rest of my life appropriately. I'm also incredibly excited to have a remote that turns off my TV again, since the movers lost the TV remote between Washington and here and I didn't want to pay for a replacement. The TiVo remote is nicely programmable, so we don't need to deal with the cable box's remote control, either. The whole system looks like it's incredibly easy to use -- I've only read a page or two of the manual, and that was just to affirm some guesses I'd made about how Season Passes behave. It's just that the initial steps were more complicated than I anticipated. I won't have to go through that again, though.
Ever since Google bought Pyra, various people around the web have been posting their concerns about Google.
Today, I join that crowd, for I have lost faith in Google. Why? Because today is St. Patrick's Day, and Google hasn't changed its logo. How dare they? They've honored St. Patrick's Day three years in a row. Now, they acquire Pyra and suddenly fail to treat St. Patrick's Day with the respect it deserves. I'm going to have to switch to doing my searches on a site more respectful of the holiday, like Albertsons.com. That'll teach 'em.
On Saturday I mentioned that the only thing I wanted for my birthday was Entenmann's St. Patrick's Day cupcakes. To my complete surprise, some of my friends actually read this page and they independently set out on multiple extensive quests for those cupcakes. Retailers throughout Silicon Valley must have been wondering where the sudden demand for those cupcakes came from. Alas, no such cupcakes were found, but perhaps the measurable surge in demand (albeit localized to the Bay Area) will prompt Entenmann's to ensure that the cupcakes are easier to find next year.
First place in the Great Cupcake Search of 2003 goes to my friend Ronnie, who discovered that Albertsons makes adorable miniature St. Patrick's Day cupcakes and gave me a box of them. They're not quite as good as Entenmann's -- they're missing the candy on top -- but they're definitely a treat, and much appreciated. Thanks, Ronnie!
I turn 25 today. I'll be celebrating with a few friends at Max's Opera Cafe in Palo Alto, where they have good food and really good desserts. Of course, when there's a birthday you always have to have room for dessert....
Speaking of desserts, there's only one thing I want for my birthday, and I'm having some trouble finding it. For many of the last 20 years, I've enjoyed Entenmann's St. Patrick's Day cupcakes on my birthday. They're a delicious combination of a chocolate cupcake and a circle of green frosting on top surrounding a soft chewable candy four-leaf clover. They're really good, but they're also incredibly hard to find -- that's why I said "many" of the last 20 years above and not "all". And no, it doesn't make any sense for a Jewish guy to associate St. Patrick's Day cupcakes with his birthday, but as soon as I had them for the first time around second grade I was hooked.
Erik Barzeski notes that there's a difference of opinion as to whether the operating system originally developed at Bell Labs in 1969 should be spelled as "Unix" or "UNIX". Interestingly enough, I did an informal survey of this while I was at Microsoft, since we wanted to figure out the correct capitalization for our documentation. The best conclusion I could come up with was that more commercially-inclined organizations -- commercial Unix vendors, Apple, all three major BSDs, RedHat, and other similar entities -- write "UNIX". On the other hand, the GNU project and other less commercial organizations write "Unix".
A quick check of the International Trademark Metasearch shows multiple trademarks for "UNIX" and none for "Unix". The obvious conclusion, then, is that those who are concerned about trademark infringement -- which would include just about any company with its own trademarks to protect, and might not include the GNU project -- use the trademarked term as it's intended to be used. On the other hand, those of us who aren't concerned about misusing a trademark and dislike the look of acronyms that are used as regular words but written in all caps will continue to write it as "Unix".
That conclusion leaves one unanswered question: Why does O'Reilly use the lowercase version? See "Mac OS X for Unix Geeks", for example. In a publishing company, something like the spelling of "Unix" must fall under some corporate policy somewhere. I wonder what led them to decide to spell it the way they do.
Derrick Story announced O'Reilly's Mac OS X Innovators contest today. O'Reilly is looking for the most innovative software for Mac OS X -- software which drives the industry forward while taking advantage of Mac OS X technologies and maintaining its ease of use. And what a prize...an ADC Premier membership (which includes a free WWDC pass, multiple Apple hardware discounts, and more), a pass to O'Reilly's Mac OS X Conference, and a subscription to O'Reilly's Safari collection of online books. Runners-up get an ADC Select membership instead of the Premier membership, but the rest of the prize is the same.
That's one heck of a prize offering. I can't wait to see the winners. My choice for first prize: Brent Simmons' NetNewsWire. Only a few pieces of software have changed the way I interact with the rest of the world, but NetNewsWire has done just that. There are other news aggregators and there are other weblog editors, but NetNewsWire handles both tasks wonderfully. For demystifying RSS and making weblog editing easy, NetNewsWire definitely deserves a place among the most innovative software on Mac OS X. In my mind it's first, but I'm curious to know what other folks would pick.
While I was walking down the hall tonight at home, I tripped over a PowerBook box that I'd left out in the hallway half an hour earlier and hit my head on a corner of the wall. Ouch! One trip to the ER and a few stitches and staples later -- the first I've ever had -- I'm back home safely. My forehead will look nice and gauzy for my birthday next week, but other than that I'll be fine.
What a way to spend a Saturday night. This is when I'm glad to have a roommate -- Ruby was a huge help tonight. I really owe her one.
News.com reports that Real Networks will be charging a third more for Major League Baseball's live audio streaming this year. That sounds like a lot until you realize that the new price is $19.95 -- in other words, it's less than you'd pay for a ticket, parking, a hot dog, and a soda at most stadiums. It's not like I can get an equivalent service elsewhere, either. If I want to listen to Phillies games, I can move to Philadelphia, pay for the audio feed, or not listen at all. I'm a captive member of the audience. With all that in mind, I can't believe they charge so little.
Erik B. writes about a Business 2.0 article on Apple's retail stores, in which retail expert Paco Underhill analyzes the stores to try to explain why they're successful and how they can improve. Erik finds a lot to criticize in the article, but I liked it. The commentary about what works well in the stores was largely on target, and much of the criticism made sense as well.
Erik's comments include one thing that I wanted to address in a bit more detail:
Do Apple stores sell Apple merchandise, like t-shirts, keychains, or other trinkets? No. Could they make a lot of money doing so? I think so. What's stopping them? The stores would look like crap. They'd lose the austerity, the cleanliness, and the entire "feel." They'd look junky.I don't think that's why Apple stores don't sell T-shirts. As the company store in Cupertino shows, you can sell branded items while maintaining the classy look. Instead, I think it's more a question of the stores' target audience.
The stores exist because Apple wasn't reaching typical consumers in the retail market. There simply aren't enough Apple resellers in high-traffic areas with the exception of chains like CompUSA, and in the chains, Apple's computers don't get significantly more sales effort than computers from other manufacturers. The stores are designed to bring in traffic, to cause people who wouldn't otherwise consider a Macintosh to think about buying one.
That's not the crowd that will buy Apple shirts. The branded-item-buying crowd is the Mac fanatics, the ones who will buy a Mac regardless of whether there's an Apple store within a hundred miles. They're the ones who don't need Apple's advertising to know what new products are available, and who can find T-shirts at places other than Apple's stores. If Apple included branded items in its stores, it would make the fanatics feel more comfortable at the expense of those who are looking at a Mac for the first time. Apple already has the hearts of the first group, but it needs to do everything it can to attract the second.
I have to say this is a really interesting concept. I currently don't get anything of any value back from my credit card, so anything at all would be a bonus. The chance to get money back reasonably quick and to trivially invest it, all without any fees, is intriguing. I think I'll give it a shot and see if it turns out to be worthwhile.
About two months ago, I complained about the problems with the O'Reilly Network weblogs. Today, Derrick Story announced a variety of new features for those weblogs that includes just about everything I asked for and more. Wow.
Among the new features: A new site for all O'Reilly Network weblogs, RSS feeds for every weblog author, permalinks for every entry, contact information for every author, and even trackbacks. The only thing missing is a combined RSS feed for the weblogs as a whole. I'm very impressed -- I never expected them to change this much in so little time.
William Safire's column in yesterday's New York Times mentions that the prom dress component that we call "duct tape" and which supposedly confused people often call "duck tape" was in fact originally spelled with a 'k' and not with a 't'. Languages never fail to surprise me....
I just bought two tickets to Tori Amos's April 11th concert in San Jose. Believe it or not, I've never purchased concert tickets before, or even attended a concert (not counting orchestra performances and plays). Since I discovered iTunes, though, and the joy of having whatever music I want wherever I am, I've started buying a lot of CDs. (Side note to the RIAA: The advent of MP3s caused me to increase my CD spending by a factor of 100 or more, so y'all don't know what you're talking about.) About six months ago, Katie and Marc told me to get a Tori Amos CD, so I bought one, loved it, and promptly bought a few more.
Two weeks ago, I heard a note on the radio mentioning that Tori was coming to San Jose on April 12th. I made the mistake of waiting until a few days after tickets went on sale to try to buy them, and there weren't any available. That's my first complaint against Ticketmaster -- their web site made me type in a random word and then wait about fifteen seconds just to tell me that there were no tickets available. If there's nothing to buy, don't make me walk through the steps of buying anything. Just tell me up front, and don't waste my time.
For reasons I can't explain, I was at some other web site tonight that said that Tori would be performing in San Jose on the 11th and 12th. I clicked a different Ticketmaster link, and what do you know -- she will be there on the 11th. And, to my surprise, there were tickets available, so I bought two.
The buying process was awful, though. Let's see how many things were irritating:
That leaves the privacy issues. Those are really absurd. I shouldn't have to hand over my contact information to random companies who aren't even listed just because I want to attend a concert. It'll probably take me hours to get off of the mailing lists (email and snail mail) that they can sign me up for. I really wish California had a law against sharing contact information with companies with whom I don't have a business relationship, and requiring that companies remove consumers from their contact lists on request. I don't have a problem with opt-out lists, but I have serious problems with lists that I can't opt out of.
Erik Barzeski has some interesting commentary on interviewing programmers, which was largely inspired by an article entitled "How to Interview a Programmer" that Slashdot pointed to last week.
Erik's comments are mostly about the problems with being asked to write code in the middle of an interview -- it's a high-pressured situation, it's easy to make mistakes, you don't have language references or a compiler around, and you might be writing in a language that you haven't used in a long time. He mentions that Apple interviewers tend not to ask candidates to write code, but Microsoft interviewers often do.
I have to say that from the perspective of someone doing the hiring, I like Microsoft's interview process much more than Apple's (and if I ever end up being a manager at Apple, my team's going to do interviews differently). I can't talk about the details of either company's process, but I'll mention that I really like having candidates write code. If I'm hiring a programmer, I want to know that they know at least one programming language well enough to solve difficult problems in it quickly, and the best way to determine that is to ask them to write something.
As an interviewer, I couldn't care less about details of syntax or even what programming language they're using. When I ask a question, I'll just present a problem and ask the candidate to solve it. If they want to write the answer in C, Java, Perl, or even Objective-C, that's fine. They'll be able to show me their best solution if they're using a language that they're comfortable with. And if they leave out semicolons or misspell variable names, I don't care. The compiler would catch that.
What I'm looking for, though, is a sense of whether they can come up with a good design and then implement it correctly. I don't even expect the best solution first -- I like asking questions that have a simple solution that can then be improved to be more efficient or modified in interesting ways when the constraints of the problem change. Assuming the candidate comes up with the simple solution, I'll then ask them to do one or more of the modifications. At each stage I'm interested in the algorithms they choose and the reasons behind their decisions, since that will tell me much more about their abilities than anything I might ask about C++ intricacies. Anyone who can design good code can write good code in any language, but not everyone who knows a particular language in depth has any sense of good code design.
Erik quotes a passage from "How to Interview a Programmer" that says that writing code on paper is silly because programmers have auto-completion, macros, context-sensitive help, refactoring, and so on. That may be true for some positions, but it certainly hasn't been true for most of my coding. I'm used to having to write code in vi because emacs isn't available (to say nothing of BBEdit or Visual Studio!). I'm often in a position where I have to understand code that I haven't written, which calls APIs that I don't know, and which might even be in some random macro language that I've never seen. When I hire someone, I want them to be comfortable with situations where they don't have all of the whizzy features of modern IDEs to help them out. Those are a huge help, certainly, and everyone should use them whenever they can, but you have to be able to write code when they're not around.
I should also mention that most of those features are specific to certain libraries or APIs. When I ask a programming question, I don't require the candidate to use any particular library or API, and I won't ask questions that would be much harder in languages that don't have certain APIs. I won't ask a question that requires hash tables, for example, because anyone who chooses to use C will be at a significant disadvantage to anyone who uses Java. On the other hand, I might ask someone to implement a hash table, or I might tell someone to assume that they have a certain hash table API that they can use. Along the same lines, if someone I'm interviewing is trying to use an API but they can't remember its name, I'll tell them what it is, and I'll tell them the order of parameters, too. I don't mind being the documentation to the candidate, as long as it's something that they'd easily find on their own.
One last thing: Both Erik and the person he quotes, Matt Gerrans, suggest asking candidates to write code ahead of time and bring it in. I'd never do that, for the simple reason that there's no way to ensure that the candidate wrote the code. Sure, I can ask them detailed questions about it, but I don't know if they were given the solution and then studied it hard enough to be able to answer my questions. I'd much rather have them write code in front of me. Perhaps just as importantly, if they only write code ahead of time I can't lead them through a series of problems to see how they think or whether they can adjust their solution as constraints change in interesting ways. I don't want to hire someone who's going to be asked in a meeting, "Will things change if we need to handle twice as much data" and respond with "I'll get back to you in a few days" (unless, of course, the question really is so complex that it can't be determined any faster). In other words, I want people who understand the design decisions inherent in writing software, and I can determine a lot of that by asking them to write code to answer design-centric questions.
I should mention that I've mostly done systems programming. I'm sure people writing applications in which architecture and performance aren't as important as the user interface and basic functionality will have different priorities for the candidates they interview. When you're looking for a job, it's important to make sure that your knowledge can translate into what your prospective team does. As I learned the hard way with one unfortunate candidate who completely failed to write a memory allocator for me a few months ago ("Here's a whiteboard and a marker. Implement malloc."), not everyone thinks of that before sending in a résumé. In his case, he was applying for a lead developer position on a systems programming team, but he'd never contemplated how a memory allocator worked. He might have been a terrific programmer, but not for that team, and certainly not in a lead's role.