Simon Fell > Its just code > November 2006

As I mentioned the other day, CoffeeGeek are running an auction fundraiser for CoffeeKids. On the auction page I'd noticed that Stumptown was listed as one of the sponsors, I'd figured they perhaps have a coffee of the month, or perhaps some of the cool coffee brewing gadgets they have in the Annex, but no, In the forums I found a post from Mark (chief CoffeeGeek) that says that Stumptown are going to be offering an expenses paid trip to Guatemala with Stumptown head honcho Duane Sorenso to visit finca el injerto in HueHue, the farm that won the Cup of Excellence this year. Yowzah!, that's absolutely completely insane, what an amazing once in a lifetime opportunity for someone, Stumptown once again take things to a whole new level, way to go.

Looks like Doug is having some fun putting together a Atom Publishing Protocol client in Cocoa, and Doug, thanks for the Quicken recommendation, I'll give it a go.

OSX has something called document bundles, these work like regular application bundles (i.e. Finder shows a single Item, but really its a directory), but for documents instead. Pages & Keynote both seem to use them. If they never leave your Mac, then they seem fine, but otherwise, the fact that they're not really a single file doesn't seem to get hidden that well, try attaching one to an email in GMail, or uploading one as a document in Salesforce, its a most unsatisfactory experience, I though at least Safari would at manage it, but no, that didn't help either.

The guys & gals over at coffee geek are busy running an auction benefiting the CoffeeKids charity, now's your chance to pick up something for the coffee lover in your family, and donate to a good cause all at the same time, there's all sorts up for grabs, from beans, tampers, cups, grinders to 1 on 1 training session with top notch baristas. Check it out.

Scott over at Perspectives on Salesforce has a post about an API Authentication List feature, a way to restrict what API based applications can do. This is something I've been thinking about a lot, allowing application white listing (i.e. you can use Outlook Edition and Offline, but not the data loader or sf³), or Application X only requires access to accounts, make sure that's all it can access. All great ideas and features, but wait, how can the API server tell that the application making the request is in fact Outlook Edition and not SoqlXplorer ? The problem is that while you can authenticate a person, authenticating an application it impossible to do 100% securely (unless the client OS has TPM, and it can authenticate the application for you).

In his idea's exchange entry, Scott has a screen shot from Flickr which provides some similar features. If you go look at the Flickr authentication spec you'll see that it identifies applications using a shared secret, this secret never goes over the wire, so that's good, and if the application is another web based application, then its reasonable to assume that the secret is reasonably secret, you've got to hack the web app server to try and find the secret. However for desktop client applications, that shared secret has to be on the client machine somewhere, and in that case, its not reasonable to assume its safe, any determined person will be able to dig the secret out of where ever you've stashed it away. (and today's threat model is that it only take one determined person to work it out and post it for all to find, not that everyone has to work it out themselves)

Is that secure enough? I don't know, it largely depends on what you're trying to prevent. To stop people trying out random applications on their production data, yeah, I'd think so. To stop a 3rd party application stealing all your data? not if they were determined enough, to stop a disgruntled employee who's about to quit and want to take a copy of all the sales data with them? would likely depend on how well they can drive google. What other options are there? well a blanket profile level API access enabled yay / nay would work, although I'd suspect this is only useful in a fairly small subset of cases.

Microsoft Money, as much as I loath it, is about the only Windows app left that I run on a regular basis, pretty much everything else I've already switched over to the Mac. I took a look at Cha-Ching the other day, It looks really pretty, but any financial app that can't import transactions downloaded from a banks website is doomed to never get used for longer than about a day. There's always Quicken, but its not hard to imagine that it would annoy me as much as MS Money does. Ahhh, iBank looks much more promising.

I ended up building my own Cocoa client library for accessing the Salesforce.com API, I decided a while back I'd open source this, I just posted the first version. This is the library that powers both SoqlXplorer and SF³. Its released under the uber liberal MIT license, so have at it. Feedback welcome.

• See Scoble's interview with Sforce's very own Adam Gross (via Salesforcewatch) (yeah, I know, its not sforce anymore, but after a while all the branding changes just become a blur)
• API traffic now over 50% of all traffic. (The rate of change here is more interesting than the actual number, as I'm sure the heretic will be quick to point out a number of reasons why API traffic might be higher than it could be). (via Charlie Wood)
• Winter '07 will be live RSN, if you were at Dreamforce I'm sure you know that this is probably the biggest API release ever, there's a ton of new features, the combination of SOQL-R, Outbound Messaging and Upsert-R should put something of a dent in the heretics arguments on API traffic. (again, via Salesforcewatch)

update: here's a couple more.

• Most if not all of the Dreamforce presentations are available for viewing on the Salesforce blog, including the insanely packed session that Adam Gross, Craig W and I did on the Apex language and runtime. (ignore all the blurb around it, its wrong). Unfortunately my compelling explanation of why query/queryMore is a good idea is on the cutting room floor. (You want all the data? you want all the data? you can't handle all the data!).
• Some people using .NET 2.0 have been plagued with de-serialization errors relating to xsd:dateTimes, there's details on the developer forums about a fix from Microsoft to address this issue.

There's a new build of SoqlXplorer up, this improves the schema explorer when faced with large schemas (either lots of fields, or objects with lots of relations), including switching to a scroll view when necessary and fixing some of the drawing performance issues. Let me know what you think. If you have a version already installed, you'll get prompted to upgrade next time you start (or choose check for updates from the help menu).

The movie every coffee drinker should see is on in San Francisco, yes, the wait is over, Black Gold will be on at the Roxie starting today. Panel discussions will be held after the 6:15 and 8pm showings Friday and Saturday nights this weekend featuring local Fair Trade activists, roasters, etc. I believe a bunch of the Ritual folks are going to be at tonights 8pm showing.

SoqlXplorer 0.7 is out, it include the fruits of the UI rework labor, and of course the new schema explorer. If you have an older build installed, you fire it up and it'll prompt you to upgrade and do all the work for you.

From the CocoaDev on AddTrackingRect - Now the important cleanup method. If you forget to remove tracking tags before the view is removed from its window, NSApp could send events to this view after it has been deallocated. The source of this type of bug is hard to find. The stack trace will only show that NSApp is trying to send an event, with no reference to the the view the event is trying to send the event to, because the view has been deallocated.. Yeah, been there done that, where can i get a t-shirt ? Anyway CocoaDev is proving to be invaluable.

Fellow Salesforcer Ron Hess & I headed over to the CocoaHeads meeting thursday, Scott's talk on TextMate rocked, I learned a ton of stuff, and I'm trying to try using it as my primary editor for cocoa code for a while, see how it goes. The extensible bundles seem to give it a ton of power, I've already twiddled the objective-c bundle to do a couple of extra things i always seem to be doing, and the ability to add your own new bundles opens up all sorts of interesting avenues, seems like it would be possible to add an apex specific bundle that includes all the apex syntax, and plugs into the apex API to upload/compile your code. Something I'm going to try out when i get some spare time. I wasn't planning to, but ended up demoing sf³ and soqlXplorer to the group, I got a bunch of great suggestions for the schema viewer and I also got a suggestion on how to use NSBezierPath to layout the boxes on a path, rather than having to do all the math myself. I put that together and it worked out rather well, here's a screenshot of the schema viewer as it stands.

Will I go to the next one? I'd like to, but I need to work out some better transport options, I took caltrain this time, but there's no way that 44 miles each way should require a total round trip travel time of 5 hours (yes it was late when I finally got home).

I got the layout fixed up, the splitter hooked up (RBSplitView was easy to integrate into the app and use), I realized that i needed a column header for to caption the soql text area, so that it matches the object list. Unfortuantly NSTableHeaderView which draws that UI needs to be part of an actual table, so it didn't work out the box, but I was able to easily subclass it to generate the caption text in the bar. The only thing left to clean up is the execute query and query more buttons (and possibly the progress bar that flashes up next to them). Not sure what to do with them at all. I'm hoping to get to the CocoaHeads meet-up tomorrow, perhaps someone there will have some ideas.

In his post Trade-Offs, Sam points to my post last year on trying to have SOAP headers with simple types in .NET. In the comments Asbjørn Ulsberg claims that the behavior is related to handling nulls, and that its fixed in .NET 2.0. Well, lets see shall we.

To start with, the header defined is not nillable, therefore that's a complete read herring. as a reminder, here's the element definition that's detailed in the post and in the WSDL.

<s:element name="ValidFrom" type="s:dateTime"/>

I fired up .NET 2.0's WSDL.exe tool and pointed it at the first wsdl (you can play along at home if you want to)

C:\sampleCode\dotnet20_headers>wsdl http://www.pocketsoap.com/weblog/2005/08/test_1header.wsdl
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
Writing file 'C:\sampleCode\dotnet20_headers\TestService.cs'.

And lets take a look at the generated code

[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://www.w3.org/2001/XMLSchema")]
[System.Xml.Serialization.XmlRootAttribute("ValidFrom", Namespace="http://test.sforce.com/", IsNullable=false)]
public partial class dateTime : System.Web.Services.Protocols.SoapHeader {
    
    private string[] textField;
    
    /// 
    [System.Xml.Serialization.XmlTextAttribute()]
    public string[] Text {
        get {
            return this.textField;
        }
        set {
            this.textField = value;
        }
    }
}

Looks remarkably like the .NET 1.1 version (except for the fields vs properties thing), so, no, not fixed, not any better.

yes, the color scheme is inspired by iCal.

Somewhere in the last few weeks I got totally hooked on doing Mac/Cocoa development, once you're over the initial learning curve (which is fairly steep), its a ton of fun, and a pretty productive environment. I recently re-wrote my blogging tool in Cocoa, and it turned out to be really straightforward, between cocoa bindings, user defaults and interface builder, I only actually wrote a fairly small amount of code, and most of that deals with the actual process of talking to the blog server (as it should be). (I now have versions of the blogging tool in C#, Java, Python and Cocoa). I have a ton of ideas (mostly Salesforce related), all I need now is some time to actually work on them. I've been working on some soqlXplorer features, and some UI rework for that, its coming along nicely. (I need to do something with the execute query button)

The v0.43 release of SF³ is available, as well as the revamped UI it'll sync calendar events (in additon to the existing support for contacts and tasks). If you have an older release installed, it'll prompt you to upgrade next time you run it.

SF³ with its new UI and icon, and now while its actually busy syncing.

Mac developers in general appear obsessed with usability and appearance, I don't think this is a bad thing, its one of the things that makes using a Mac an enjoyable experience. However for graphically challenged developers such as myself (there's a reason I concentrate on web services :)) it leads to a frustrating number of hours with graphics tools and interface builder. Anyway, the unofficial apple weblog was quick to point out that SF³ isn't pretty, and hey, I'm not going to argue, even more depressing is the fact that there was about 4 different, equally ugly UIs before it. However unlike my first trip into OSX land, there's now a bunch of great blogs and resources for the youngling cocoa developers

• Matt Gaemmell has a bunch of useful code, including RoundedBox which I used to tidy up the SF³ UI (see below)
• CocoaDevCentral has some great tutorials to get you pointed in the right direction, and links to a bunch of great blogs.
• Wil Shipley has an invaluable series of posts called pimp my code.
• The red sweater blog has a great post on some UI changes in FlexTime and how they were done.
• The CocoaDev wiki seems to have something to stay about anything you might run into.

Here's what the reworked SF³ UI looks like, still need to do some work on the S Icon/button.

There's a great video of spanning sync in action over on the spanning sync blog. It looks really cool, nice job.

Remember to read the note about backing up your data!, I just started work on synchronizing events, and in short order has managed to delete all my tasks and events from both iCal and Salesforce.

getting closer, looks like there's a time-zone issue to fix