talblog

« June 2005 | Main | August 2005 »

July 8, 2005

Sandvox Designs-a-Plenty

Dan mentioned a couple of days ago that we're hard at work on Sandvox, which is of course absolutely true and what keeps me up at night, rather than posting every little thing that crosses my brain, but one of the really fun aspects of this is working with designers to come up with new looks for web pages.

Although talblog clearly doesn't show it (yet...hint hint), I'm getting pretty tired of boring, boxy designs for web pages. I'm a pixel slut. I admit it. Show me some eye candy.

So, in that spirit, and seeing as how Dan's already let the cat out about the absolutely rockin' Trippy Bubbles, here's a sneak peak at Sunburst:

Yes, a little more reserved than trippy – kind of like me – but shining with a sleek Art Deco-sensibility. I keep telling Dan that the most beautiful part of the design is actually the footer, but for that, you'll just have to wait. (We have to keep some surprises, don't we?)

Posted by ttalbot at 8:22 PM

Diagrams that break

One of the things I've been working on since WWDC is streamlining Sandvox's Core Data model. (Yes, that's part of it there, on the left. It'll likely be public when we publish the plugin spec, so I don't think I'm giving away too much.)

Even though, many months ago, I came up with some really kick-ass model merging code that grabbed partial models from a bunch of different plugins and hooked up all the attributes, relationships, fetch specs, and parent/child relationships in just the right way, it turned out to be absolutely the wrong approach since, as soon as one thing varies in the model – oh, say, the presence or absence of a plugin – you've effectively broken your file format, requiring a lot of gnashing of teeth and grindage of CPU while you migrate from whatever your model used to be to whatever your model is now.

Thunderstruck to learn that I'd have to toss all (twelve lines of) my brilliant code, I decided to just suck it up and simplify, simplify, simplify. (Always, always, always a good thing to do anyway.)

So here's the good news: writing a plugin for Sandvox now requires virtually zero knowledge of Core Data: we just do it all for you behind the scenes using one simple, easy-to-maintain (and upgrade) model. You just create a delegate that implements and customizes what you need to. Just like it should be. Thank you Cocoa.

And here's the better news, at least for me: the modeling tool in Xcode, and Core Data itself, actually made this streamlining really, really easy. How? Visual development of (compiled) models, with copy/paste, and datastores that validate against the model at Save. In other words, Diagrams that break.

As I mentioned somewhat off-handedly, as soon as you start seeing Core Data as fundamental to how you use Cocoa, you stop worrying about a whole class of problems. Not only can you whip up a pretty powerful object model by clicking and dragging (and, well, thinking), the system actually tells you if you get it wrong.

Actually, it does this in two ways: first it compiles your model on the front-end, into a .mom. If you've done something really stupid, your model won't compile. You have to fix it in the modeler before you even get to the code. And then on the back-end, when you go to save a document, Core Data actually verifies that the data you want to store matches the requirements you set out in the model. Say hello, one would hope, to referential integrity. That's not to say you can't put bad data in, but at least you're not leaving good data out. And that, I think, is a real step forward for fast, fast, fast Cocoa development.

On a related note: Apple just updated the developer documentation. Be sure you've got the latest. Xcode Preferences > Documentation > Check Now.

Posted by ttalbot at 7:57 PM | Comments (3)

aARDvark

Ok, a break in the code, I've got a backlog of posts...

Since we've started using FogBugz to track issues at Karelia, I keep Joel on Software tucked over in a corner of NetNewsWire just to see if there's anything going on at Fog Creek I want to keep an eye on. (What? Too many links in one sentence? What's the rule?)

So, sometime during the spring Joel announced that they were hiring a few select interns for the summer to work on a new, super secret product, code-named Project Aardvark. The premise sounded pretty interesting: take a few smart interns and throw them at a new project that's supposed to ship at the end of the summer.

It sounds new and fun and cool and sexy and not that dissimilar to how Dan and I are spending the summer, to ship something new and fun and cool and sexy for Karelia, except of course that they're in New York and we're in California and they're working on a Windows product and we're working on a Mac product and they're interns and, well, we're, um, clearly not.

Anyway, last week they announced that Project Aardvark is to become Fog Creek Copilot, a Windows app that puts up a VNC window of your friend's computer so you can take over the screen and the mouse and the keyboard and fix whatever horrible thing has gone awry with their Windows box.

A couple of interesting observations here: the core of Copilot is based on an open source version of VNC (as is pretty much everybody's, though how often do you see open source leveraged in a Windows product?), it apparently has a strange e-commerce use model that I don't yet really understand, and it should be incredibly useful for people who need to keep up with their friends and family PC support obligations.

I was really surprised that this is what Aardvark turned out to be. I guess I thought these things existed already. I've been doing this for Lisa's parents and mine using Apple Remote Desktop for a couple of years. It really is the only way to fly. And then it hit me. Aardvark. aARDvark. The clue was there the whole time...

Posted by ttalbot at 2:45 PM | Comments (2)

July 6, 2005

Undelivered Mail Returned to Sender, Fixed!

When we announced Sandvox at WWDC last month, Dan and I put a signup form on Karelia's main page to gather email addresses for sending out announcements as we get closer to shipping. (The sheer quantity of signups and positive comments, by the way, has been tremendous. Thanks!)

As a matter of course, we send back a welcoming email to the person who signed up, along with an unsubscribe link and other information. Less than 1% of these bounced back as undeliverable, which I think is actually pretty good, but I started to notice things in the bounces that worried me. Things like,

Diagnostic-Code: X-Postfix; host fe.mail.saunalahti.fi[62.142.5.25] refused to talk to me: 554 : Client host rejected: No mail accepted from you

and

Diagnostic-Code: X-Postfix; host smtp3.parasun.net[204.174.18.100] said: 550 Administrative prohibition (in reply to RCPT TO command)

and

Diagnostic-Code: X-Postfix; host relay.verizon.net[206.46.232.11] said: 550 You are not permitted to send mail. Please visit http://www.verizon.net/whitelist to request removal. (in reply to MAIL FROM command)

didn't look like ordinary bounces. That last one was really annoying as Verizon's a pretty big ISP and I didn't want their mail relay to prevent us from talking to (potential) customers at their request.

Long story short, and here's where it gets stupidly technical, we recently changed our ISP from one DSL account inside SBC (nee PacBell) to another DSL account inside SBC. Although SBC was actually surprisingly good about switching over the account, they never updated their PTR (aka Reverse DNS) records to show that our IP addresses inside their IP block legitimately point back to our servers. This meant that Verizon and AlamedaNET and some other ISPs thought we were just a rogue zombie PC somewhere on SBC's DSL, sending spam willy-nilly. Apparently this is a big problem in the Windows-world.

Here's what I learned in straightening this out:

www.DNSstuff.com is an invaluable tool for tracking down DNS probblems. Use the Reverse DNS lookup form to see if your server's IP matches its hostname.

Whenever you have a problem with SBC DSL and have to call the 877 number, immediately ask for tier-two support. This gets you somebody "stateside" -- as they themselves say -- rather than somebody, I'm guessing in India, doing nothing more than reading from a rather limited number of choices on a screen. I'm not sure why, but asking for tier-two support was the only way I was able to break the loop of

"What version of Windows are you using, sir?"
"I'm not using Windows."
"Windows XP?"
"I'm not using Windows."
(pause) "Windows XP?"
"I'm running Mac OS X Tiger Server."
(pause) (pause) "Windows XP?"
"I'm running FreeBSD."
"Windows XP?"
"I'm not running Windows, I'm running Unix."
(pause) "Windows XP?"
"I need to speak with tier-two support."
"You want to speak with tier-two support?"
"Yes."
"Please hold."

There, see how that works?

Finally, once you get to tier-two support, insist that the problem can be solved and that you just need to speak to somebody in DNS support. After your fifth transfer you finally get to speak with a woman, probably sitting at a desk in Northern California, who understands every technical word you are saying and who then gives you the email address where you tell PacBell how you would like your PTR record(s) to look. You then send off your email and all is well.

(Update: It turns out that if I had just done a Google search on the issue and taken a leap of faith, instead of picking up the phone, I could have avoided a lot of hassle, 'cause, you know, Ameritech and PacBell are the same. Windows XP?)

So, if you had signed up and didn't receive a response from us initially, our apologies. I've gone through the bounces and resent out everything again this morning.

Posted by ttalbot at 2:15 PM | Comments (1)