I’ve not had any time to try out Jaxer yet, but the idea of a single platform for both client and server-side processing sounds good.
On trying to get started, though, one problem I encountered was that the installation instructions on Aptana’s site didn’t quite get Jaxer running on my default Ubuntu 8.04 install. The reason seems to be the built-in Apache trying to load an external library from
/usr/lib
which doesn’t exist.
The library in question is libexpat.so.0; however, there is a libexpat.so.1.5.2 installed! You can check this by running:
$ ls -l /usr/bin | grep libexpat
Creating a link to this file in /usr/lib with:
$ ln -s libexpat.so.1.5.2 /usr/bin/libexpat.so.0
seems to have got Jaxer running and the server status looks good. If you’re having trouble getting a Jaxer server running on the latest Ubuntu, this might be worth giving a go.
At work, I have been developing a custom framework loosely based on my experience with the symfony and Propel. One of the requirements for the application under development is to store the application’s state both on the server and the client, so that information can be passed by means of AJAX requests.
To aid this process, each page controller PHP class has a corresponding Javascript class. In order to maintain state through the application, each class as a Singleton. With the help of Prototype, singleton classes are quick and easy to implement in Javascript:
First, declare the class itself using Prototype’s Class.create() method:
PageController =Class.create({/**
* @type {integer}
*/
userId:null,// ... more properties .../**
* Constructor
*/
initialize:function(){// ...},/**
* A method to do something...
*/
doSomething:function(){
console.log('doSomething()');},// ... more methods ...});
Once the class is created, we can declare a static instance of the class and a static method, getInstance(), that will be used to return the single instance of the class:
/**
* @type {PageController} Static instance of the page controller
*/
PageController.instance=null;/**
* Return the static (singleton) instance of
* the page controller object
*/
PageController.getInstance=function(){if(!PageController.instance)
PageController.instance=new PageController()return PageController.instance;}
With the class now declared, the singleton instance can be accessed in your application using the static getInstance() method:
I noticed today that Google has finally launched an API for its contacts application. I’m sure I’m not alone in wanting to easily and properly synchronise contact data amongst Gmail, Address Book, mobile, etc. and use Gmail contacts as a single repository.
The API uses Google’s GData format, which is something I’m yet to look into. It would seem to be a‚ good time to put into practice some Python‚ - or maybe dust off the Objective-C - and‚ Cocoa.
I’ve been a long-time fan of Google Calendar, mainly because I can see where I need to be from any web connection. But probably its most useful feature is the thought that has obviously gone into the interaction design.
The Problem
When using calendar software, it is painful to have to click between each field, setting hours and minutes, locations etc. then confirming with an OK. I have been known (more often than not) to forego any form of calendar, instead relying on scrawl left on scraps of paper around the office. Whilst less organised than a calendar, this said scrawl is a lot easier to jot down. Needless to say, though, it is also a lot easier to lose.
A Solution
In Google Calendar, the designers have captured my need to quickly jot down when, where and who. No longer do I need to tab between fields, carefully tapping out 24-hour clocks (or 12-hours, depending the software’s mood). Instead, events can be entered as simply as:
meet joe at company friday 11am
Google Calendar will then automatically pick out the important information and add the appropriate event. No fussing around with mini-calendars or remembering to use mm/dd instead of dd/mm - the app just works. This is, for me at least, near-perfection user design - and I hope more software begins to take note (Apple’s new iCal 3.0 does not).
Google Calendar’s ‘Quick Add’ is an example of removing layers of abstraction (or barriers) between the user and the system, and quite correctly why should the user conform to the system? It should surely be the other way round. Mobile phone OS designers should note, why should it take 4 menu items to get to a message inbox? Perhaps Google’s new Android will help to iron that one out…
In writing HostManager 2.0, I’ve come up against a lot of problems caused by the dark magic that is Cocoa bindings and key-value observing. One of the most troublesome of these has been with transient (calculated) properties.
For example, a Client managed object can get a count of owned domains that are expiring soon. This is a transient propety, accessed through a key of expiringDomains. It simply returns an NSSet which is built from a fetchRequest.
Previously, I was running this fetchRequest each time the key was accessed. This was admittedly inefficient, but seemed functional - at least until you saved the document.
Something crazy happens when a Core Data document is saved - all the objects in a context are released (faulted). There is a good reason for this, as it frees up any memory that was being used to temporarily store the managed objects. However, it caused very strange results to appear in my transient properties; namely, they would all vanish.
Even forcing the fetch request to refresh didn’t pick up any objects from the context (I’m not sure why as I would have expected the faulted objects to be ‘refired’). So I took the plunge and refactored the Client object to cache its expiringDomains value. After some extensive testing and finger-crossing, I’m fairly sure this is the correct way to handle transient relationship properties:
