Mac@Work : The Ultimate Business Machine

The
Ultimate
Business Machine

Technology, business
and innovation.

And, not least, about
the Mac.

Weblog • Archive • Cutedge

by: Bernard Teo

Wed 26 Jan 2005

AppleScript Studio Course @ Apple Singapore

Category : Technology/AppleScriptStudioCourse1718Feb05.txt

Apple World Wide Developer Relations is sponsoring an AppleScript Studio Course on the 17th and 18th of February. It's free.

Just sign up on-line as an Apple developer (also free) before registering for the course.

If you're registering, you're using Hai Hwee's course booking and training administration system - all written in PHP plus MySQL, all on the Mac.

We've got one registration within a minute of Leon Chen sending out the course invitation. That was fast. An update: as I was writing this, another five's come in. Great!

Posted at 7:23AM UTC | permalink

Tue 25 Jan 2005

Application software development on the Mac? Let me count the ways

Category : Technology/softwareDevelopmentPathsOSX.txt

Last week, I was too busy, but not that busy that I'd miss this discussion at silicon.com. "CIO Jury: Apple irrelant to businesses."

"... CIO Jury was invented by silicon.com to take the pulse of the UK's top IT users. We regularly put questions to our pool of key CIOs, IT directors and other heads of IT ..."

Key CIOs? Top IT users? Sure don't look like it. Read the readers' comments. The tide is turning.

One CIO said, "Proprietary hardware and software, overpriced, few applications." Microsoft is proprietary but that doesn't seem to stop them buying Microsoft. "Few applications"? If they only knew.

I've been wrapping my head, these last few weeks, around all the different ways we can build custom applications on the Mac. So I'm going to do a summary, as much for myself, as for anyone who's reading these pages.

Firstly, where Windows has Visual Basic, the Mac has Real Basic. Or AppleScript Studio. Or FileMaker Pro. These are good for custom applications that don't need to be "professionally" done, but that need to be put together in a hurry, and can be "thrown away" without too much bother once they've done the job or served some need. They don't need a deep investment in technical knowledge, and they're often cobbled together by the more knowledgeable (and committed) among the end users, themselves.

Now, when more "serious" programming is required, we can turn to Java - on both platforms. Java is great for building server-based applications that can run on any hardware platform on earth.

On the Mac, there's a twist. You can build native Mac OS X Cocoa applications using Java. And re-use a lot of your code at the data model end of the MVC (Model-View-Controller) continuum.

Java-Cocoa is eminently do-able. We've mapped out a large enough part of the Java-Cocoa API to be able to help people who want to port code they've already written in Java to the Mac so that it gets a Cocoa front-end.

With Java, too, you can get access to any SQL database engine that you want. From Oracle to MySQL to PostgresSQL. Oh, the choices. Thy name is legion.

There is one problem with Java, though. Java applications are easily de-compiled. Unless you first try to "obfuscate" your code, it's really quite possible to recover the source from the compiled byte-code, thus turning away people who'd rather keep their source code hidden. But obfuscation is really so much extra bother. Java is great for server-end stuff, or for in-house system development (as contrasted with shrink-wrapped applications), or for open-source projects. That is still a lot of areas, as far as productive work goes.

Now, shrink-wrap software developers might want to do their software development using Objective-C. (I know, the term shrink-wrap itself is so 20th Century). No doubt that keeps the selling opportunities within the smaller world of Mac users, but there are compensations in the sense that developing Cocoa applications using Objective-C is fun, and you can do quite involved and seemingly difficult things using relatively little code, and you're, on the whole, super-productive, allowing you to build better quality products with a lot less people.

I used to think there was a deficiency in the area of database access when I switched from Java to Objective-C - that meant losing the ability to use the JDBC database-connectivity mechanism and its bountiful harvest.

That was why we've been trying a few approaches over the last few weeks.

One was to use Objective-C and keep all the database access using Java. But that got too messy.

The solution turned out to be quite simple, actually - at least conceptually. A lot of the relational databases we want to use have C API's - MySQL, SQLite, Oracle. Now, following the example of the MySQL Cocoa Project at sourceforge, we now know that it is possible to build a Cocoa framework that is callable by the rest of the Objective-C code, but hides the actual implementation of the database access. In effect, it does what the JDBC layer does for Java applications.

That turned out to be quite exciting. We could use the Open Source sMySQL framework. Or we could build our own, now that we understand the concept.

What we want to do is to build something that will mirror the JDBC calls so that it'll make it easy to port our Luca Accounting System code from Java to Objective-C.

What's more. SQLite is expected to be included in the next revision of our favourite OS. It's currently quite limited in features compared to MySQL but it's usable, and has a pretty liberal usage policy (none of that copyleft viral stuff that comes with GNU licenses). We've tried modifying the Cocoa framework to work with SQLite. The idea works. My friend, Hai Hwee, has also built a little prototype of Luca that works with an embedded SQLite database. That idea also works.

All these is so that we can avoid having to install a database for the users before they can use our applications.

If we're careful with the design, we can take the inspiration from JDBC and build the Cocoa frameworks so that we can access different SQL databases, just by swopping in and out the relevant Cocoa frameworks, without needing to re-write much of the calling Objective-C code. That will be super-powerful.

There's Core Data in Tiger that does something like that. But it's good to know how to do your own thing, just in case that's not good enough for our purposes.

Zooming out from the trees and surveying the forest, I believe in the phenomena whereby, when the time is right, many people around the world suddenly see the same possiblities, almost simultaneously. I can't remember what this phenomena is called. But the Internet surely makes this even likelier to happen.

Whatever it is, I expect to see an explosion of useful database-linked software coming out for the Mac. The ingredients are in place. And when it arrives, those top, top CIO's aren't going to know what hit them. And, perhaps, where their jobs had gone.

Posted at 2:55AM UTC | permalink

Mon 24 Jan 2005

Programming on Mac OS X

Category : Technology/Feb2005OSXProgrammingCourses.txt

This is a teaser. There are a couple of courses on Mac OS X software development coming up at Apple Singapore for the month of February. More details will be available soon. Watch this space if you're interested in attending. It'll probably be absolutely free. (That should get some attention.)

Posted at 1:56PM UTC | permalink

Fri 21 Jan 2005

Follow Your Dreams

Category : Commentary/followyourdreams.txt

Bruce Whitred came down all the way from Japan to sit with me through an AppleScript Studio Course at Apple Singapore. (In the picture below, I had asked Hai Hwee, who knows some Japanese, to come along and show Bruce how to do English-to-Japanese localisation using AppleGlot.)

Actually, at the end of the two-day course yesterday, I realised that it was really my privilege to have met up with Bruce, who's a most interesting guy. Dreamsclub.com is his website and this was what he told me when we first corresponded, which I reproduce below because I feel you really ought to hear him in his own voice :

Regarding the home page, I really must get it set up in English, sorry. It`s probably hard to understand the concept without reading it but one of my dreams is to inspire people to be the best they can be. Hence our company`s slogan "Follow your Dreams". To that end, I decided four years ago to try something out of my normal sphere of activity to inspire others. So with everyone saying I couldn`t possibly do it (having had no experience with running) I set off to run 3,100 km over 4 months from the northern tip of Japan to the island of Okinawa in the south.

My degree was in bio-resource engineering though I found quickly that my true love was with education, computers and challenging people to take control of their life more like an artist or writer would develop something beautiful out of an idea and effort. The street performances were originally added into my motivational speeches to jolt people into seeing themselves and their potential beyond the limited framework of what they do now.

I believe things happen for a reason. Talking to Bruce did jolt me out of a rut I had got into lately. We really ought to be glad we're alive. Living life to the full, stretching ourselves to meet our potential, believing that anything is possible - if we set the goal, put in the effort, and work out the process to get there. I watched Bruce grope around with the key concepts on the first day, clicked into gear at the start of the second, and then accelerate as his understanding took root at the end of the day. This is a guy who can prove that the idea works. I think I learnt more than I had taught.

Posted at 3:54PM UTC | permalink

Mon 03 Jan 2005

I get a breakthrough

Category : Technology/spamblocks.txt

We know for a fact that some mail servers are rather picky. They will reject mail coming from a dynamically assigned IP address, or one without a domain name, or follow any some other rule.

I've been wondering why my mail from cutedgesystems.com (which is on a dynamic IP address) sometimes get through to the people at Apple Singapore and sometimes they don't (when Apple's servers' decide that it could be spam).

It's puzzled me for over a year - i.e., what has changed in my configuration that makes those servers decide one way or the other, because obviously I want my mail to get through all the time.

I rebooted our server today and realised that I couldn't send mail out to Leon Chen at Apple anymore, even though I've been able to do so for months now. So something has changed.

I dug around and found the answer - it's the DNS server. I've been playing around with setting up a DNS server, on and off, over the year. Turning the DNS server off causes the mail to be bounced back from a picky server. Turning it back on gets the mail through.

If there is a DNS service running on our local network when the mail server starts up, it'll be able to correctly discover its own domain name. (Otherwise it knows itself as, say, roadsteadserver.local). Seems like, when it knows that it should be cutedgesystems.com, it'll be able to send mail out to other servers without getting bounced. (Or some such explanation.)

I don't know if I really understand what is happening but the moral of the story is - it's good to be able to run your own DNS service.

I've got a version of Postfix Enabler (in Obj-C) that will work with the next revision of our favourite OS - except that it leaks memory. Lots of it, I'm sure, until I figure out how all these retain and release stuff works. (Mike Beam's article at O'Reilly is a great starting point.) It ought to be known as Postfix Configurator or something because it won't be doing much enabling anymore.

Posted at 5:31PM UTC | permalink

The Sun Breaks Through

Category : Commentary/newbeginnings.txt

After four days of torrential rain, we greet the sun for the first time in the New Year. Like the sky has been crying buckets, for the trail of devastation left behind in Asia.

Posted at 10:37AM UTC | permalink

Wed 29 Dec 2004

Java Debugger in Xcode

Category : Technology/XcodeJavaDebugger.txt

The nice thing about getting hit with problems is that you often discover new things in the process of solving those problems. We thought we had lost the ability to debug Java code when we moved from Xcode 1.2 to Xcode 1.5. That was something that was asked about quite a lot during the "Java on OS X" course last week. So we were planning to move back to Xcode 1.2 the next time.

However, while trying to stop the Java code from crashing, doing Cocoa Bindings, we really needed to know what was happening to the code. Finally, Hai Hwee, who could have been a top-notch detective in a previous life, found out how to turn the debugger back on, while fortuitously following a random Google link about remote debugging.

The control's hidden in the Get Info pane for the project executable. With the debugger back on, we really made a lot of progress after that.

The great thing is, we discovered that debugging now works for AppleScript Studio projects, too. At last. So, Xcode 1.5 is it. No use going back. What will 2.0 bring in Tiger?

Posted at 6:53AM UTC | permalink

Mon 27 Dec 2004

At the Sungei Buloh Wetland

Category : Singapore/sungeiBuloh.txt

We were at this nature reserve at the northern end of the Singapore, just across the Straits from Johore. It's called the Sungei Buloh Wetland Reserve. It's a wonderful place - a transit stop for migratory birds among the mangrove swamps, with crocodiles (though we didn't see one), sandpipers and otters.

Siva, otterman and Mac user, writes a blog about nature, bio-diversity, conservation, and the Mac. Glad I've finally had a chance to make it to his home ground.

Posted at 5:17PM UTC | permalink

Doing Cocoa Bindings in Java

Category : Technology/JavaCocoaBindings.txt

We've found a way to stop our Java-Cocoa demo of Cocoa Bindings from crashing - comment out the call to "super.windowControllerDidLoadNib". Of course, why this should be so remains a mystery, since "[super windowControllerDidLoadNib:aController]" works okay on the Objective-C side?

But, with this out of the way (for the moment), I've converted the project we use for our Java-Cocoa course to Cocoa Bindings :

What does this show?

One, there are places in the framework where you can step in and make a call to an existing database. The resulting data will get picked up by the Table View.

Then, Cocoa Bindings takes over to synchronise the display of the detail view with the table view. This is where we save a lot of writing of Controller-type code. All the notification-related code can disappear. In fact, some of the things handled automatically by Cocoa Bindings work better than the code we write.

Then, at the end of the cycle, we should be able to find a convenient place to push the changes back to the database.

The things left are to figure out how and when to do data validation, how to open the detail window by double-clicking on a selection in the table view, and how to have more than one detail window open (because it's possible that a user may want to compare two detail records side by side). Also, I still don't yet know how to do handle check-boxes (though I've just had an idea).

In summary, this is seriously useful technology, though quite a few kinks remain. I keep watching out for when I'm going to fall off the deep end.

Database access is so good on the Java side - we have an embarrassment of riches using JDBC to connect to a wide range of databases, remotely as well as locally. The down-side is that you get more problems using Java with Cocoa than with Objective-C. But then, there is none of the database capability we've come to expect on the Objective-C side (though Tiger promises to correct this - but is the database access there only going to be single-user/single-machine, and only via SQLite?).

This situation is so typically Apple. Simultaneously brilliant and clue-less - like a well-loved idiot savant.

Posted at 4:14PM UTC | permalink

Sun 26 Dec 2004

Cocoa Bindings

Category : Technology/CocoaBindingsAndJava.txt

I'm trying to understand Cocoa Bindings, to see if I can write less code. My starting point is Michael Beam's O'Reilly article, "The Cocoa Controller Layer". I've been playing around with extending the sample code and it's starting to become clearer - like when and how to step in and do custom things, like interfacing with a database.

This will make a great demo (of the jaw-dropping kind). But my databases are all accessed through Java JDBC drivers, and we've got tons of Java code I'd like to plug into. So, I started on a Java-Cocoa version and got things to the point where the Table View shows the right data but the application crashes soon after.

Reminds me of Aaron Hillegass' "Don't write Cocoa applications with Java" comment. It's a fair point. But you may have code that already work well in Java - modelling the business rules, putting stuff in and out of databases, running off web servers, and providing web services - and that's often the case in the enterprise.

It's possible to map out a large enough part of the Cocoa framework to allow Java programmers to work safely and predictably, putting Cocoa front-ends on top of their Java code. You don't have to be able to build things like Create and OmniGraffle. Enough of Cocoa already work well in Java to allow us to do productive things with it. If that could help us bring a lot of that enterprise data onto the desk of Mac users, wouldn't that be a good thing?

Downsides to Java-Cocoa at the moment - like poor documentation, bugs, and lack of speed - ought to go away with time. It shouldn't stop people doing Cocoa using Java.

But back to Cocoa Bindings. Other good sources of information include "Introduction to Cocoa Bindings", "Cocoa Bindings Examples and Hints", and the "Cocoa Bindings" discussion at cocoadev.com. I'll put up more links when I find them.

I'll leave you with another comment from Aaron Hillegass. Cocoa Bindings look great in demos, but may be less than useful in practice. However, this is a most interesting development with a lot of potential. Hope Apple continues to build on it.

When I was working at our Ministry of Defense, we used to put new hires in front of a Mac and watch their eyes - watch if they light up. If they don't, we didn't want them in the Technology Group. These Cocoa Bindings demos can serve the same purpose. Put a developer in front of these demos and watch his eyes. There's probably a measurable correspondence between intelligence quotient and the degree to which the eyes light up.

Posted at 11:37AM UTC | permalink

Fri 24 Dec 2004

Java on Mac OS X Course (Dec 21 and 22, 2004)

Category : Technology/JavaOnOSX2122Dec.txt

Usually, when you see a picture like this at Apple Singapore, you would think Final Cut Pro or QuickTime or iLife or, at most, an OS X Server Administration class is underway.

But we had about 18 people turning up at Apple Singapore for "Java on Mac OS X". Quite a lot of them were Java programmers - some new to the Mac, some already Mac users who will bleed in seven colours, having used the Mac since pre-OS X days.

Most are seeing the Mac do these things for the first time - Oracle running on a PowerBook, and an iBook and every other Mac in the room turned into Java 2 Enterprise Edition web servers. Also, by the middle of the second day, they're all not just able to build Cocoa applications, but Cocoa applications using Java. Surely, not your grandfather's Mac anymore.

If you put all these things together, it's difficult to deny that the Mac is a serious enterprise-class software development (and delivery) platform. Really, nothing else even comes close.

I think we're getting better at explaining things and getting people up to speed doing productive work during the two days they spent with us.

The feedback from the attendees has been pretty good and that meant a lot of us. We really put in a lot of effort designing the course so that the topics flow smoothly from start to finish. And all using original material, culled from the systems we have built, unavailable elsewhere on the Internet, at least not as the one single integrated whole - from command line, to Cocoa, and to the web.

There is a book in there somewhere.

Posted at 6:58AM UTC | permalink

Mon 20 Dec 2004

Java on OS X Course @ Apple Singapore

Category : Technology/JavaOnOSX21Dec.txt

We're setting up the equipment for tomorrow's Java on Mac OS X course at Apple Singapore. About 17 to 20 people are expected to come (and sit under the gaze of Einstein, Picasso, Gandhi, and company).

As with all the other sessions we've done at Apple Singapore, we get a wide assortment of Macs to try our stuff on - there're a couple of new PowerMac G5s with the liquid cooling system, the new iMac G5, and the new LCD displays.

This is what we hope to cover : Java from the OS X Command Line, Java with Cocoa, and Java on the Web.

The idea is to show how Java is implemented on the Mac, and how we can be productive re-using our code across all three interfaces.

And the sample code we're using as the basis of the exercises is not a toy. It's a complete Cocoa application in miniature - with check boxes, radio buttons, pop-up-menus, sheets, drawers, tables, data source, notification, and handling double-clicks on a table, multiple windows, and accessing a JDBC-compliant database - all callable from Java. Raw material to build a wide range of Cocoa applications from.

While building Cocoa applications with Objective-C feels more natural, is smoother, and is a lot more fun, lots of people have code in Java. And it makes a nice continuum being able to deliver enterprise-scale applications across the web and on the desktop, using a wide range of relational databases, including Oracle and MySQL.

Java is important for the Mac in the enterprise. But what will tomorrow bring?

Posted at 4:16PM UTC | permalink