What's it all about, Alfie?

OK, I'm old school, and as such, I'm not a big IDE user, but I recognize that they have a place in this world, and it saves a lot of people a lot of time. Just not me. Not most of the time. But when I'm coming into a new project, and it's already established in this IDE and a certain language, it's just plain silly to buck these established "standards".

But I have to say... C# is one of the oddest languages that I've ever seen. I believe it's written for people who have never seen a programming language before, and it's meant to be "easy" for them to understand what it's doing. Let's look at the setters and getters in C#, shall we?

  private string _farm;
 
  ...
 
  public string Farm {
      get {
          return _farm;
      }
      set {
          _farm = value;
      }
  }

where the first line is the definition of the instance variable, and the thing that looks like a method definition in Java or C++ or C is really a combination definition and meta-data for the getter and setter. The use of this code is simple:

  obj.Farm = "three";
 
  ...
 
  string l = obj.Farm;

Here the first call will end up calling the set 'method' in the Farm definition, and the second will call the get method. C# looks at the usage and then decides what method to call based on the naming conventions. I can see this, in theory, but it's so totally contrary to what you'd expect if you knew Java or C++.

In fact, in either of these two languages it's clear what:

  obj.cnt++;

means, but in C# is it calling the getter, doing the increment and calling the setter? It would appear it would have to. However, it's not clear from the language structure. Call me silly, but I like the language to infer as little as possible about the workings of the code for me. If I wanted that, I'd have written macros for preprocessing.

I have to use C#, so I will, but I can't imagine that I'm going to look at this anytime soon and see this as a good, descriptive, understandable, language. No time soon.

First week here and it's clear that there's no one universal set of development tools or techniques - C#, C++, Java, Flex, even VB... it's a lot of tools and there's very little unification of method, style, documentation, etc. It's very much what I expected - dictated by the needs of each group, but one thing is clear - if I want to be more in-line with the group, it'll mean that I need to get used to Eclipse or IntelliJ. Now, I'm not about to get IntelliJ for my Mac, but I can download Eclipse and then have a go with it.

So this morning I decided to have a run at Eclipse for my MacBook Pro. The download was beefy, but it's got all the tools I should need - even the CVS integration. I know there's a subversion plugin for Eclipse (Subclipse) but I want to chat with Troy about that before I go installing that. Maybe it's nice, maybe it's junk. Gotta get his take on it.

If that works out, then I should have Eclipse running on my Mac like I do on my machines at work. Not bad. Certainly Flex development is all done in Eclipse (the initial motivator) and a good bit of the Java work might be there as well. Don't know. But it doesn't hurt, and it's good to be as versed in the tools the other folks are using as the ones I'm used to.

UPDATE: Troy used it and thought it was fine - worked great. So I looked at the 'Download and Install' page and there it told me exactly how to point to the published install location and from there, Eclipse takes over and handles the install and update. Easy enough to do, and now I'm ready to do SVN work within Eclipse.

A little while ago, Marc Liyanage looked at the ClickToFlash and saw that it was straight ObjC, and with that, he embarked on writing an ObjC plugin for Safari that views XML in a manner similar to how IE shows it - formatted and stylized. The result is XML View Plugin 1.5.

The result is pretty darn amazing:

There's also an automatic updater, as well as the ability to modify the style with CSS and Javascript. Pretty impressive, I must say.

I don't use XML a lot, but when I do, it's really nice to have something that will format and display XML nicely.

Well... it came today and so I left work a little early (3:00 pm) after the last of the meetings and went home to do the conversion. The unboxing was impressive, as always. The set-up started very uneventfully, and then I ran into those things that I keep forgetting about - the docs I have in /Developer/Java that I probably need to move to my home directory if I want to make this a smoother transition next time, and then the amazing fact that all the developer tools (Xcode, etc.) are not copied.

I can understand that, in a sense, but in a larger sense, it's amazingly obvious that they should be copied over. After all, /usr/local/ gets copied - and that's not even visible to the average user. The Developer Tools are something that needs to be copied. Period. No excuses.

Fonts. Fonts are another thing that aren't copied over. Thank goodness that I keep the fonts around for a while, or else I'd have a pickle of a time getting them to install in short order. Let's face it - I have until about 8:15 pm to get this all done for tomorrow or else I'm taking the old notebook back to work, and I'll have to repeat this over again this weekend.

But I got them installed. I had to re-install Safari 4 Beta - but that's completely understandable. I then had to deal with setting up a few preferences on Terminal.app, and Xcode, and then it was looking pretty much normal. Sure, the display size is great, and at the same time messes up the layouts I've been using on the older MacBook Pro, but that's something I can get used to. I just need to work with it for a few days to come to the best layout of the different Spaces.

On the whole, it was a good time. Stressful for a while, but I got it all done in an evening and now I can make sure it's all OK, and then convert the old laptop into a new Kids Computer for the living room. That is going to make things a lot cleaner in the living room and will also provide a nice speed bump from the Mac Mini that's been there for quite a while.

As part of migrating from my old MacBook Pro to the new one I got today, I did an 'svn update' on the CorePlot repo - just to see if anything had changed since I'd put in that fix for the Core Animation NSDecimal encoding issue. I was surprised, and a little saddened by what I saw.

Virtually all the changes I'd made were gone. All the comments - Gone. The files looked exactly like the skeleton files I'd seen in the project. I had no idea that's what Drew thought was done. I didn't. Not even close.

Drew's checkin comment was pretty insightful:

Reduced the interface of new CPPlotRange class to make it 'minimal but complete'. Also removed a lot of commentary in the class, which wasn't really necessary, and just made understanding the class more difficult.

Removed the function 'CPMakePlotRange'. It was a quasi-initializer for the old struct, and has been superseded by a class method.

While I understand the comment minimal but complete, I don't think that's what Apple does on it's - init methods. There are a ton of them taking all different kinds of (relevant) data types: double, NSDecimal, NSDecimalNumber - all were valid in this case, but Drew has decided that only the NSDecimal one was needed.

Furthermore, I don't agree at all with his assessment of the comments. I'm clearly a comment-focused person. I live it every single day of my professional life. But it seems that Drew is of the belief that code should be simple enough to be self-documenting, and that's something I simply cannot work with.

So it makes me sad to say that I have no further desire to work with, or even use the CorePlot framework. I respect Drew's ability to do what he wants, but he's going to lead it down the path of a poorly documented pile of junk in a few years. I'd rather stick with commercial and live with the licensing issues and costs. In the end, Drew isn't going to take any real responsibility for the code, and yet he's completely unwilling to see the value of good, solid, commenting.

Too bad.

The OmniGroup are now giving away four of their lesser-developed applications, and of these, one is something I've wanted to have for a while - OmniObjectMeter. Back in the NeXTSTEP/OPENSTEP days, OmniObjectMeter was the tool for finding object leaks. And on the Mac, that's about the only memory issue you should run into. So having it is a real feather in your cap. But it was expensive for as often as I needed it. Now that's not the issue any longer.

If you are having issues with memory allocation in Mac OS X - get it. Trust me, it's worth the time.

The group at 280 North are getting very close to what I've been looking for in a web development framework with Atlas. The idea is essentially Interface Builder for the web. You can drag and drop components onto a window, wire things up, and it all works. Of course, it's still nib-ware, so to speak, if you want to create new objects it's going to require code, and the code required for a serious web site might still be a considerable bit of coding, but for the user interface, it's about perfect.

It's what I've wanted since Apple ditched WebObjects, and if we're lucky, Apple will give these guys a bucket of money and have them work on this as the next WebObjects front-end system. I would still love to have the back-end be Java or ObjC and be able to be written with Xcode, as that's my favorite environment, but I'd understand if it needed to be something else.

But what a deal that would be. State management in Java or ObjC and Atlas as the GUI builder. That would be an impressive bit of work. Can't wait to see where it leads.

A few days ago, I started working on Issue #2 for CorePlot. I worked on this for quite a while trying to get the NSDecimal ivars on the CPCartesianPlotSpace to encode properly in Core Animation, but to no avail. The things I read on Google are basically that if it's not an object that conforms to the NSCoder protocol, then the data type has to be understood by Core Animation. That means it has to be a CG-prefaced data type. Fair enough.

The problem manifests itself as a run-time error message like:

2009-02-11 13:49:39.126 CPTestApp[26427:10b] unhandled property type encoding: 
`{_CPPlotRange="location"{?
="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"_mantissa"[8S]}
"length"{?="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"
_mantissa"[8S]}}'
2009-02-11 13:49:39.128 CPTestApp[26427:10b] unhandled property type encoding: 
`{_CPPlotRange="location"{?
="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"_mantissa"[8S]}
"length
"{?="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"
_mantissa"[8S]}}'

I talked to Drew about this and told him that the only way I could see to fix it was to either drop the precision on the CPPlotRange by using CPDoubles or to update the CPPlotRange to a full-blown class with instance variables that are (NSDecimalNumber *). These guys implement the NSCoder protocol, and with a little extra logic, the new CPPlotRange can fit into the codebase nicely.

So that's what I did. It was a blast. I then checked it in and sent Drew an email and updated the issue on Google groups. I asked Drew for comments on the code, and we'll see if he thinks I went overboard on the comments (I didn't), or if there's something he thinks I should have done and didn't do.

All in all - very exciting.

The mailing list alerted me that MacVim Snapshot 43 is out and while the changes aren't earth-shaking, there are new icons, and there are gains in the way the forking is done so as to improve the startup time of the windows. Not bad at all.

I have to say, it's nice to have this reliable tool on my machine as I'm moving from one job to another. It's a constant companion.

I was doing a little work on the CorePlot code today - trying to get rid of a bug that's in the running of the test app, and likely to be in all applications based on the CorePlot framework. It has to do with the fact that CoreAnimation is checking the ivars of the subclasses and making sure they are encodable in it's scheme of things. Not that it's necessary, but maybe it is internally.

In any case, I was remembering this article where there's a simple compile-time definition for the framework that forces the Cocoa and CoreGraphics datatypes to be interchangeable. This would have been really nice, but it's not for the more complex data structures like NSDecimal, which is the problem I'm having at the moment.

However, this is really something to hold onto as it's bound to come up several times in the project, and I wanted to be able to put my finger on it quickly.