Category: Geekery

This is sad

I don’t know if this is a comment on the sad state of Java, or the sad state of the way my mind works.

I’ve been a Java developer since 1998. I think it’s a great language and I love working in it. But when I’m starting a personal project, I look for excuses not to use it. I don’t know why. I can code up beautiful and powerful GUIs in it, but I usually choose not to. It’s so ridiculous that I’m going to a meeting to discuss a possible freelance project very shortly, and I think I’m going to end up deciding to learn Python and wxPython and coding the GUI in that rather than do it in Java. And I don’t really know why.

A good morning, but not a great night

This morning, I went over to Frank’s to see if he could help me with my rudder pedal assembly. I had an idea of how to jury rig the pedal, but I wasn’t sure how to implement it. Fortunately, Frank is a lot smarter than me when it comes to fixing things, and he has the advantage that he installed this rudder assembly originally. It took us a couple of hours of reaching around into the depths of the kayak with screwdrivers and ratchets, but it worked.

It seems to be holding, but I’m looking forward to getting the replacement parts next week – the company that made the rudder system redesigned the tracks a few years ago to make them out of aluminum instead of plastic, and they tell me I can just swap out the tracks without changing any other parts – but of course first I’ll have to undo all the great jury rigging that Frank and I did. Tim of PaddlersSupply.com and Tom of TopKayaker.net got me hooked up and they are sending me the new parts, so I should have them in time for the Rochester Open Water Challenge.

The Time Trail kind of sucked tonight. First problem was that I forgot my GPS and heart rate monitor. Dan loaned me his GPS but I still didn’t have the heart rate chest band, and he took it home afterwards so I didn’t get to download the info. It was raining, but not too cold. The wind was blowing from the south, meaning that you started into the bay with enough tail wind to make waves, but not enough to really help you go fast. I think I was making around 6.2 or 6.3 mph. Turning in the waves was the usual adventure, especially when I wasn’t too sure about the rudder, and then coming back into the wind was slow, probably around 5.8 or 5.9. My split was around 9.9 minutes, compared to 9.53 last week. Going up the creek was a little better in spite of the headwind and the increasing rain, but it was a struggle to keep the speed up over 6.1. I did the turn the “normal” (counter clockwise) way – last week Jim Mallory convinced us that doing it the other (clockwise) way is probably faster because of the geometry of the final turn before the buoy, but I wanted to avoid full right rudder tonight. The way back was faster, of course, with a good tail wind and the current, so I was seeing speeds between 6.4 and 6.8. My final time was around 19.6 (compared to 19.20 last week), so my second half was faster than the first half. Paul D was a tiny bit faster than me tonight – I think Ken said he beat me by 7/100s of a minute. Oh well, when you’re only a few hundreds of a minute faster than a guy one week, you’ve got to expect that he’s only got to make a tiny improvement or you a tiny mistake to change the order the next. I’ll get him back next week.

Today’s Discovery

If you have a Core Data data model with one Entity, say “AircraftCategory” that has a “to-many” Relationship to another, say “AircraftClass”, you can access the AircraftClass objects for an AircraftCategory using an NSMutableSet. But if you Fetch an NSMutableArray of AircraftCategory, and are doing a “fast enumeration” through the AircraftCategory objects, and you happen to remove one of the AircraftClass items from the current AircraftCategory object using one of the generated accessors, the fast enumeration will see that as a modification of the NSMutableArray of AircraftCategory and throw an exception. This is in contrast to Java where you would only get an exception if you were to add or remove things from the actual Collection that you were iterating, and not from calling setter methods on the objects in the Collection.

So instead of removing the AircraftClass from the AircraftCategory, I discovered that what I have to do is remove it from Core Data directly, using
[managedObjectContext deleteObject:aircraftClass];

I haven’t tried it yet, but I wonder if this wouldn’t happen if I assigned the fetch results to an NSArray instead of an NSMutableArray?

Why I find Objective C a hard language to learn

Lots of methods get an NSIndexPath as the argument, and all the sample code that I’ve seen gets the current row out of the indexPath object using [indexPath row]. Sometimes they get the section number using [indexPath section]. Ok, that seems simple enough. Now look at the documentation for this class, which is what you see if you use the XCode research assistant to show you the documents:

NSIndexPath Class Reference.

I cannot for the life of me see any way to extract the information that you get the current row using “row” out of that document. It’s not there. No, instead you have to figure out that UIKit has added some methods to NSIndexPath, and find ‘row” and “section” in a different document called “NSIndexPath UIKit Additions”. Isn’t that intuitive?

iPhone app

I haven’t written much about my iPhone app, but now that I have some time on my hands, I’ve put some more time into it.

I’ve been watching the Stanford iPhone course on iTunes U. They had a couple of successful iPhone app developers come in to give lectures, which were very useful. One of the things that stuck with me was an insistence that you prototype the user interface. They recommended sketches, but my sketches are horrible so I decided to try Photoshop. I grabbed this Photoshop template which is really great except it’s missing some important UI elements, like the symbol that looks like a “Do Not Enter” sign that iPhone apps use to indicate “delete this element”. In spite of that, I managed to mock up some screens, get some feedback, try running through a few scenarios, etc. You can see my current iteration on my gallery. Keep in mind that I don’t think I’ve got the correct fonts or font colours for the standard iPhone UI, but I mostly did it for looking at layout and program flow.

As well as that, I was working out the data storage, including the SQLite tables and stuff. I was trying to figure out how to get the lazy load the data and only keep what I need in memory. That’s when I started reading about the 3.0 software and the Core Data API. It seemed like exactly what I need, so I paid my registration fee and downloaded 3.0 to see if it will be as useful as it appears. One unfortunate side-effect – all the code I’ve typed in from the iPhone book I’ve been working through has tons of “setText is deprecated” warnings. Oh well.