Schinckel.net

Using Core Data is awesome.

moGenerator makes it even better, as you can have Entitites defined as being of a particular class, and this code generator creates two classes for each Entity - a machine-readable one which is updatable by running the script again, and a human readable one that you can safely edit - it won’t be changed once it has been created.

You can easily make this tool a part of you build process.

First, create a new directory inside your project folder, I called mine MO. Then, cd to that directory, and run:

$ mogenerator -m ../*_DataModel.xcdatamodel

Then add the folder MO to your project.

Now add a new build phase script, and put into it:

cd MO
mogenerator -m ../*_DataModel.xcdatamodel

It’s not quite perfect - if you add a class, it won’t be added to your project automatically. You might be able to get around this by including the -includem switch, but then you won’t be able to have the .m files located in your project, else you will get duplicate symbol errors.

I’m enamoured with Mercurial for all of my version control needs. I’d like Versions to work with it, but the response I got from the developer suggests it never will. “UI of Versions is designed completely around the concept of centralized version control " I can see that the same type of interface would work quite well with Mercurial, or another DVCS, without too many hassles.

Still, even just with the CLI, I’m coping.

A couple of days ago I started playing with Trac for bug tracking. I had used Bugzilla (not for my own projects, but I use it at work), and it doesn’t work properly with Mercurial. The good news is that Trac does, almost out of the box.

The trac-post-commit-hook works fine, and allows me to have a repository linked in with my trac store, and when changes are checked in that have “fixes ticket:X”, it automatically updates the trac for that ticket. It’s a bit of a repetitive process to set it up (you have to manually edit both the repo/.hg/hgrc file, and the trac/trac.ini file to add support for each other, but it’s easy enough to do).

The only annoyance is that the username isn’t quite the same in both - so changes made in Trac have the username matt, whilst those made in mercurial have the default username there - which includes my full name and my email address.

I’m currently learning stacks (and maybe developing a useful application along the way) about Core Data and Cocoa Bindings.

I managed to hook up all of the “first level” Entities to UI elements, but was struggling a bit figurng out how to get the to-many relationships to work.

To make all elements of the type Person appear in an NSTableView, you can create an NSArrayController, set it to the Entity type, and put Person in the relevant field. Then all people will appear in the list.

If you have a manager, who might supervise zero or more people, then how do you get a sub-set of People. More specifically, how do you get a just the other side of a To-many relationship.

I thought I was going to have to resort to actually writing some code, and use a Predicate, or something like that. But there is an IB only method.

You can create an NSArrayController, and as well as putting in the Entity type (and hooking it up to the Managed Object Context), just put that it gets it’s Content Set from another object - in this case it would be People.selection.supervises (or whatever it is called).

This isn’t quite flawless - if you just hook up a button to the “add:” outlet, then it doesn’t quite add properly - the reverse of the attribute is not set. I had to make up an IBOutlet in my window controller that creates a new component, and sets the relationship up.

Which meant I ended up having to write two lines of code. For each relationship.

Three languages. Three different Object Relational Mapping systems. One operating system.

Over the past couple of days, I’ve been madly learning how to create programs in Core Data, using Objective C and Cocoa. It’s given me plenty of food for thought, and made me perhaps think that it’s not that SQL Alchemy rocks my world, it’s just that J2EE/EJB is just ORM done wrong.

I actually got exposure to SQL Alchemy in detail before J2EE - I first came across them at the same time, but using SQL Alchemy was at work, and I basically had to learn in 2 days what a full semester worth of J2EE taught me. Perhaps that was just because learning the python stuff was so damn easy.

Now that I understand just how cool an Object Relational Mapping is, getting into Core Data was easy. Creating the same schema in SQL Alchemy (actually, using Elixir, so it was just object creation), and then in a Core Data xcdatamodel - basically the same process, was even simpler in Core Data: simply because it is a GUI tool, and you can see the whole model in one go, instead of having to scroll through a text file examining classes.

But doing GUI programming using the ORM is where Core Data really shines. Using Cocoa Bindings, you can just plonk down an NSTableView, and tell the object where it gets it’s data from. If you have two GUI widgets using the same data model, and you change selection in one, it even changes the selection in the other!

Core Data also helps look after Undo, Saving and all other sorts of goodness I haven’t even come across yet.

The only thing that Core Data isn’t good for is a multi-user system - or more precisely, a system where multiple users are accessing the data at the same time. I’ve used SOAP as the messenger format, where I had a rich client accessing services provided by my server, but this is cumbersome. I’ll just use Pylons, or perhaps Django to do a web application - where the interface is largely a Web Browser. In this instance, it will probably be best to just stick to a python-based approach. I’m tempted by WebObjects, but that would still require me to use Java.

If only Apple would release a distributed Core Data. I might be able to do something kind of cool with Distributed Objects, for a rich client, at least, but for Web, I may as well do the whole thing in python.

All of the cool kids are talking about Joel Spolsky’s post about disabling menus.

I agree with Gruber et. al., he’s dead wrong. Disabling a menu is a simple, yet powerful method of implicitly informing the user what she can or cannot do at the moment. Hiding menus, a-la Windows/Office “Show only recently used items”, however, it truly evil. This is not even hiding disabled items, just hiding ones that haven’t been used recently. Now, if I use one machine, and then go to another, it doesn’t know which ones I have used recently. Bullshit Incarnate!

Anyway, real users don’t use menus. Other than to learn the keyboard shortcuts.

The Old New Thing had a post way back in 2004, which has a mostly sensible answer: When do you disable an option and when do you remove it? Not strictly dealing with just menu items, but regardless, still logical.

Categories are pretty cool in Objective C. Say you have some special methods, which you’d like to have another class to have, or wish to override a method for every instance of a class.

You can, with every OO language, just create a sub-class. However, this would mean having to use the sub-class in all of the locations throughout your program.

With categories, you can just (re)define a method, and use the same class. All of your code will know that this new method is available, or will automatically use the overriden version.

This to me obviates the need which is apparent in most OO languages to sub-class the hell out of everything. This in fact is what I like most about Cocoa/Objective-C. Most of the time, you don’t need to sub-class the widget and other API classes. Instead, you have archived instances of them.

Much tidier.