Good news for my scripts

Apologies for not blogging sooner. Between slow network connectivity here and the generally fragile state of, I’ve been unable to get to my site all day.

I had some insights on the problems with my scripts on the flight back. By reviewing the Apple-published scripting list archives, I realized that others were having problems publishing via XML-RPC (and probably SOAP) any text that contained unescaped HTML tags (e.g. < instead of &lt). This explains why my iTunes2Manila script was publishing with an empty body and should be easy to fix. There were also suggestions that processing the arguments to an XML-RPC or SOAP call to use plaintext instead of Unicode (or vice versa) would result in successful RPC calls. I may have some head down time on that shortly and hope to be able to bring my scripts up to Jaguar compatibility soon.

I hope Craig has seen this…

When I was a programmer we would have killed for something like this. There are a ton of business benefits too. It’s really hard to get all the stakeholders in a system design case to sit in the same room for three weeks to come up with the right structure for a data model. This collaborative ER tool provides people with a way to discuss ideas (albeit at a very limited level) from their own computers and collaborate in realtime on the design.

What this isn’t is a sufficient solution. In these sorts of scenarios, especially when building the first-pass data model for a system, you will spend the first week or more just arguing over the right entities and the implications that that has on the software that you’re building. So bundling this with voice collaboration, IM, and certainly a way to save and retrieve your work, might make this a pretty darn compelling product–or add-on to a development environment.

Making progress…but not on company time

I narrowed the problem with iTunes2Manila down last night. It’s got to be in the code that handles creating and posting the news item to Manila; the sister script (iTunes2TextEdit) works fine putting the same information into a TextEdit document, so the disappearance of the track information must be happening somewhere else.

I haven’t made much progress on my apps recently, largely because:

  • I’m employed and doing anything with them on company time would be crazy stupid
  • We are still catching up with the house–the garden and general house improvements and unpacking continue to take a lot of time
  • My wife works east coast hours and I need to maximize the time that I can have with her, meaning after dinner programming is a no-no
  • I finally got the Diablo II Expansion Set working (I had had a damaged Diablo II install disc, which prevented me from installing the expansion set), and I’m addicted again.

I think I’m going to have to schedule my late nights. Programming Monday, Diablo Tuesday, unpacking Wednesday…

Desktop Calendar as Weblog Interface?

I haven’t had nearly enough wacky programming ideas recently. Here’s one:

  1. Apple is rolling out iCal, a free calendar application, for Mac OS X 10.2 (aka Jaguar)
  2. All weblogs have calendars
  3. What if iCal could be an interface to a weblog?

I don’t have Jaguar yet, but it might be interesting to play with this. Maybe an RSS aggregator that converts individual blog postings to vCal; maybe just a batch downloader that you run every couple of weeks that uses the Manila APIs. We’ll see where things go.

New Release: AmazonHandler

The AmazonHandler script is an AppleScript glue script for the Amazon web services released this week. It uses the built in SOAP capabilities of AppleScript and requires Mac OS X 10.1 or higher to operate. It requires my SOAPXMLRPCHandler script library. Both scripts are available from my scripts page.

I’m working on a sample script to illustrate using Amazon web services from AppleScript with my glue. As usual, it’s simple to request the information, and the glue script I posted works for that; now I need to demonstrate wading through the copious information that Amazon returns to make it really useful.

Convergence on metaweblogs…

UserLand just released an implementation of the MetaWeblog API for Manila. This is pretty cool—this API is more robust than the Blogger API and is supported by both Manila and Radio.

Coincidentally, I’ve just been playing around with the API for some of my existing scripts. Updates as I go. It’s a faster learning path than the Manila API, since I have a local server in which I can investigate the code and problems as they arise.

Silent blogroll addition

Quick shout out to Craig, whom I added to my blogroll yesterday. He’s a former coworker from my first job out of college—a very gifted programmer and occasional Slashdot contributor. Still in the greater DC area, he’s now working at a Maryland startup. And he doesn’t blog as often as he should. 🙂

OmniOutliner as an AppleScript tool

Jesse Shanks: More AppleScript and OmniOutliner: OmniOutliner as a Script Analysis and Management Tool. Jesse emailed me Friday to ask if he could use my OmniOutliner2OPML script as the basis of the script in this article. It’s a good thing I was checking email in Bar Harbor! Of course, the server apears to have fallen over and died now, so I’m guessing I’m not getting a lot of traffic from Jesse’s piece, but welcome any new visitors anyway…

New iTunes2Manila v 1.0.2

New version of my iTunes2Manila script out today. This little script, which posts the currently playing track in iTunes to your Manila weblog as a news item, now uses proper typography (curly quotes!) and includes an automatic wrapper for a Google search on the artist name.

Future to do: have a way to update a playlist message automatically, so that “currently playing track” can easily be included in your site template.

Bug announcements for OmniOutliner2OPML

In the spirit of full disclosure, faithful reader Oliver Wrede pointed out that he had problems using my script OmniOutliner2OPML with certain outlines. I don’t have a fix yet, and it may be a while, but I wanted to report what’s up for other users that may run into the same thing:

  • If a cell in your outline is a pop-up list and has a non-blank value selected from the list, the script will error out with a NSReceiverEvaluationScriptError: 3.
  • The exported text in a given outline element in the OPML file will be truncated if it contains international accented characters (e.g. é).

As I say, I’m still working on both these issues. If anyone has suggestions on how to get around the problems, I’d appreciate it.

Outline browsing – personal deja vu

Getting in late on Dave’s Google Outline Browser. I have a hell of a lot of respect for this—because it feels really familiar.

Before I left my former company, I wrote a new feature for our flagship application, a client server application that supported government procurement. The feature traced complex relationships between contracting documents—requirements, solicitations, contracts, modifications, delivery orders, etc.—by means of an outline browser. For the first time, contracting agents could explore in a simple interface the path a contract line item took from requirement through closeout, regardless of the number of contractual documents it passed through.

The relationships Google tracks, as explored by the Outline Browser, are much subtler than this, and potentially infinite (well, within the 1000 call limit imposed by the beta). Mind bomb, indeed.