Droplets With Automator

April 29th, 2008

Automator is a cool little app that comes with OS X that makes it much, much easier to programmatically control the various applications on your computer (all the good ones anyway). It’s all done by dragging and dropping actions into a workflow - the output of one leads to the input of the next. In Leopard, Automator got a big upgrade so it can now handle loops and variables but most of the time you don’t need them.

One handy feature that’s not obvious though is that if you save your workflow as an application (File->Save then select Application instead of Workflow) you can drag and drop files onto it and they become the input to the first action. So to create a droplet that resizes images to 50%, just drop the resize image action into a workflow and save it as an application. Any image you drop onto it will be resized to 50% (overwriting the original - you might want to take Automator’s advice and add a copy task too).

This proves particularly useful when combined with the wireless printer/scanner I have since it can automatically open the scanned file in any application you specify. I now have a “Process Receipts” workflow that copies the file to my Ephox Receipts folder, adds the date to the filename, resizes it to 25% (seems to be the right balance of file size vs readability) and opens a new email in Entourage with the file attached and template text, ready for me to send off to the magical fairies that know what to do with that stuff (we call them Irene, Therese and Michelle). In the time I saved, I wrote this blog post…

iPhone SDK

March 7th, 2008

So the iPhone roadmap looks very promising. The enterprise functionality is really impressive and places the iPhone extremely well as a mobile device for corporations. The SDK has a lot of power and seems to have access to pretty much everything you'd need (there's already an SDK for access to the dock connector). Even things like instant messaging and VOIP will be allowed, though obviously the carriers don't want to deal with all the traffic from VOIP so it's just wireless but that seems quite reasonable to me. I'm not sure I'd want to try VOIP over an edge network anyway…

The biggest problem I see with the SDK is the $99 entry fee. $99 is nothing to anyone with a decent idea for an iPhone app and the skills to develop it. Heck, if you don't have $99 to spare how the heck did you manage to afford an iPhone?? Still, once you plonk down that money you're very unlikely to release your application for free which means just about all the iPhone software is going to be payware. I like the concept of selling software and thus paying developers, I earn my living that way, but it's just so nice to have a bunch of freeware or opensource that you can just grab and try out and maybe it'll be great maybe not. Little ideas released for free make an awful lot of sense and make the world a better place (in a very techno-geek way). That's unlikely to happen with the iPhone.

That said, how hard would it be to set up a donation pot to buy access to the iPhone SDK for open source projects? Not sure how it would all work but it would be a great idea and if you don't donate enough the software really does go away so there's more than just altruistic incentive.

Bottom line for me, I can't wait to get the exchange functionality because I've been wondering what the best way to get my exchange calendar synced with my iPhone (I use exchange for work and iCal for home but iPhone for both) and I'm really keen to get an instant messaging client on the iPhone as well. I can live with AIM if that's all I get though most of the people I know are on MSN. Beyond that it's just a bonus so I'm really quite happy with what's come out.

Doable vs Shippable

March 6th, 2008

All the hubbub about flash support on the iPhone highlights an interesting "gotcha" that many people fall into: there's a world of difference between having something running and having something you can actually ship. The funny thing about software development is that it is generally much quicker and easier to solve all the "hard" problems and create the software you need than it is to polish off all the little loose ends that turn code into an actual product. It's also surprising how many ideas that sound really good on paper turn out to actually make things worse.

For example, recently I spent an evening and developed a fairly basic image editor that could plug into EditLive!  Just the basic operations like crop and resize that people want to quickly do without switching to a separate program. It took all of about 3 hours work and dealt with error conditions, was well coded etc etc etc. Of course, the UI was hideously ugly because I didn't have any icons to use and it wasn't my primary focus but it was an impressive, if ugly, little program. The trouble is, it will take a month or two of full time effort to bring that program to a point where it can really be shipped to our clients. There are just so many little details you need to consider that aren't obvious until you've gone through the process a few times.

There are also times when you develop something, sort out all the loose ends and are really ready to send it out to the market, until you realize it sucks. I spent some time a while back improving the standards compliance of the caching we do in EditLive! It basically cached everything and ignored even the basic Pragma: No-Cache directive which does cause issues for a number of our clients so it seemed like a no-brainer to fix. The trouble is, far too many servers and developers default to disallowing caching even when the content isn't going to change. This has a fairly minimal effect on browsers because you don't go back and forward through pages all that often so the site feels a bit more sluggish but it's not too distracting. In a HTML editor, you want the images to be cached, no question. The number of times the document changes around, when you cut and paste that image etc etc you really don't want to have to download the entire image again - even more so if the image size isn't specified in the HTML since then the document content jumps around when the image finally does download. It turns out you have to be pretty clever in how you apply the caching standards in a HTML editor - they do work, it's not that the standard is wrong, it's just that it takes a lot of careful thought to get it all right.

So how does this relate to Flash and the iPhone? There's a couple of ways - firstly, let's say Apple has the full Flash running on the iPhone with no bugs etc. How fast is it? If it's too slow, users might be better off with the non-flash version that any decent site should provide. How much battery power does it drain? This is your phone we're talking about, having it run out of battery during a day is a major inconvenience. How well does it interact with the iPhone's touch screen input method and the on-screen keyboard? I keep hearing people argue that the iPhone needs flash so it has access to all those little flash games around the internet. You know, the ones where you move with the arrow keys…. oh wait. Sometimes things aren't as straight forward or as cool as you think and you probably won't know until you've actually tried it.

The second question is whether these rumours of Apple having flash running on the iPhone are actually people seeing the mobile version of flash which Jobs mentioned and discarded as too simple for the iPhone. Mobile flash isn't being kept off the iPhone because of technical limitations, but because, at least according to Jobs, it's simply not good enough to handle the real internet. It's also not necessarily a step forward to add mobile flash, even if it can't handle everything. All those sites that do the right thing and provide fall back content automatically if flash isn't available work just fine on the iPhone right now. If you have mobile flash though, suddenly they'll be showing you the flash content and if mobile flash isn't up to scratch it just won't work. Sometimes adding features winds up making things worse.

What's the bottom line? Whenever you hear someone talk about how easy it would be to do something, ask them if they've actually done it. If not, there's a very good chance they're wrong, regardless of their qualifications and experience. Really, really smart people hit unexpected roadblocks every day so unless you've actually achieved something you should be expecting unexpected trouble. Secondly, even if they have proven it can be done, check that it actually works out as well as you'd expect in real world testing. The real world is full of surprises and some of them will almost certainly apply to what you're working on so be prepared.

Of course, this doesn't just apply to flash or the iPhone, it applies to all engineering work that tries to achieve something new. Just remember, if it were simple, someone else would have done it by now.

Kudos To Landon Fuller

November 6th, 2007

With all the complaining about Apple not having shipped JDK 6 with Leopard it's nice that someone has actually stopped whining and started coding. So kudos to Landon Fuller for actually doing something useful. Of course, he hasn't really gotten anywhere because porting Java is an awful lot of work, but if nothing else he'll understand why it takes Apple so long.

It also means we can start the timer to see if the open source model can actually bring Java 6 to OS X faster than Apple can.

Java 5 on Leopard

October 31st, 2007

The rumors of Java 5 being horribly broken beyond all usability on Leopard are, quite frankly, bullshit. It's faster, has better integration with the OS, the Aqua L&F is significantly improved, it has full support for 64 bit and a huge raft of bug fixes and miscellaneous improvements. Everyone's pointing to an uninformed rant on JavaLobby which as it's key example actually highlights a major improvement to the Aqua L&F - the JOptionPane icons should use the application icon, not some obscure artwork that's not used anywhere else in the system. The new dialogs actually allow you to look more like native app, not less. It's even explained in the release notes - heck, the old implementation was probably reported as a bug against Tiger.

Radar #4858198

JOptionPanes did not match the native Mac OS X dialog appearance

Description:

Default info JOptionPanes now use the application's icon, as per the Aqua User Interface Guidelines instead of a message bubble icon. Warning and error JOptionPanes now show the application's icon badged onto the warning or error icon as per the Aqua User Interface Guidelines.

Resolution:

This problem is now fixed in Mac OS X 10.5.

The graphics pipeline has changed in Leopard which means that if you've optimized for the Quartz renderer, you should specifically request it or you may find that suddenly things start going much slower. In most cases the Sun 2D pipeline is faster than the Quartz pipeline - particularly if the code makes Windows specific performance assumptions (most Java 2D code does whether the author knows it or not). So while some applications may run slower by default, most applications run much faster and those that do run slow can switch back to the Quartz pipeline. Change isn't always easy but it happens - stop whining and start coding.

You can complain that there's no Java 6 yet (though all those people complaining aren't getting anywhere with porting their own and there's no excuses now), and you can complain about the lack of information but Java 5 on Leopard is a significant improvement and the engineers at Apple deserve to be congratulated for that - not insulted.