What's it all about, Alfie?

Well... it's not cheap at $142/mo, but that's not on top of the existing $65/mo so it's still a doubling of the price, but it's 50Mbps down and 10Mbps up. That's impressive. It certainly puts the snap in all the stuff I have at home... and even when I'm not at home - being able to get home with a 10Mbps response is pretty nice. I dare say it's better than most of the download speeds I'm getting where I might be plugged in.

The trick will be getting Liza to agree to it. Yeah... she's not a fan of Comcast, and I have to say they haven't proven themselves to be a great company, but they have the best internet service in the region, and I need that connectivity, so I've got to pay the man.

I'm pretty sure I'll be ordering this tonight. I know there's a new cable modem involved to get the DOCSIS 3.0 speeds, but that's OK. I'm guessing they'll have someone come out and install it, but I'd rather they send it to me and I call them on a weekend when I install it myself. But we'll see.

Well... it's finally shipping. I know there is something for everyone in my house in this release. iWeb's new ability to publish to any hosting provider will be a huge boon to the girls. Joseph will love the GarageBand lessons and might actually get going with iWeb. Liza will love the new features in iPhoto. It's going to be a hoot. I can't wait.

Ordered this morning... ships within 24 hrs. and then 5-8 days (free) shipping. I figure it's going to be at the house late this week, early next.

This morning on Software Update I noticed that Apple had posted a new iDVD and an updated iLife '08 Browser. Both of these are going to quickly be replaced by iLife '09 - which is shipping as of today, but in the interests of being up to date I got the updates anyway. It might be a week or more before I get iLife '09 in the mail.

I'm not a big used of iDVD - I think Marie has used it far more than I have, but I keep thinking that I want to get a few movies, put them in the new iMovie '09 and see what I can come up with. True, a DVD is not the format I'd choose, but for the Grandparents, it's ideal.

Bean is a nice, lightweight word processor - somewhere between Pages and Word on one end and TextEdit on the other. It's got the ability to read and write Word docs, and it's pretty good about the rendering. It's fast to start and load, and is just the right tool for those in between jobs.

Well... today I noticed that they had finally released Bean 2.1.0 - a major step up from 1.3.3, which was the last stable release. The release notes are significant as they have changed a ton of things in this release, and I'm only just now starting to dig into all the features. What I'm hoping is that they didn't loose the target audience - that middle-ground of word processing. More than TextEdit with Word compatibility, but not as heavy and feature-laden as Pages.

We'll see as time goes on.

I've decided this afternoon that I haven't been able to really give Python a clear chance. I've been using it for over a year as part of this vendor's application - it's the embedded language that virtually everything is done. That, in itself is not bad, as one of Python's strengths is the ability to embed it easily in C/C++ applications. No... it's what they have done to it that makes it hard to get a really good read on Python.

For example, you should be able to run a python script, and upon proper loading of libraries, get all the added functionality of the loaded module - like sybdb. Standard stuff. In fact, you should be able to use any python of the same version on the same box, and if you can load those libraries you should be good to go

The problem is, they have fiddled and monkeyed with the language to the point that this isn't really possible. You can get some things but others are only half-working and others still are completely broken. This means that you need to run their python and set up a very complex environment to get this running.

This represents a huge initial cost to running a python script. No such thing as a quickie... no sir. You have to really want to run a new python script. It's a pain. They are not really flexible. It's a system that makes python look bad. And I'm only just coming to realize what part of this train wreck is the vendor's stuff and what part is the python.

As I get more experience with the system I realize that there are a few things I'm not a fan of that are indeed python. However, they are completely overshadowed by the vendor's mistakes and limitations. It's amazing.

So I'm trying to give python the benefit of the doubt and realize that 99% of all the problems I'm seeing with this system is not the fault of python, but the implementation they slapped around it. Too bad. I'm sorry, python.

UPDATE: case in point: the difference between the '=='/'!=' and 'is'/'is not' operators in an if statement. For example, consider the two code samples:

  if value == None:
      print 'Value is not defined.'

and:

  if value is None:
      print 'Value is not defined.'

The difference is that the equality ('=='/'!=') operators call a method on the objects to do a value comparison, and the instance operators ('is'/'is not') do a instance comparison (pointer comparison) on the two instances. This means that the latter is significantly faster than the former, and in the case of None, it's the preferred method as well as there is one and only one None object in the python runtime. This makes the latter test preferred, and faster. That's pretty cool.

The last few days Drew has started a few threads on the CorePlot discussion Google Group and it's brought out a lot better discussion than I really expected to hear so early in the game. There are clearly a lot of folks that have done plotting work - several PhDs in the sigs. Nice. It's a group of guys like myself that have tried and had some success (or not) on different platforms, and certainly more than a little experience on the Mac platform.

All the ideas I had - preferences and strong beliefs, have been covered already so I don't yet feel the need to get into the discussion, but if I hear something that makes me nervous about what they plan, I'll be sure to chime in.

The basics are very nice:

• All ObjC - this is nice as the DataGraph work is a lot of C++, which isn't bad, but it's not as clean as ObjC and it means that a lot of the nice things available in ObjC aren't going to be in DataGraph. Specifically, categories for being able to "front" datasets to the data graphs.
• Protocol/Category for Data Access - like this as it means that I can make a data source object (like the NSTableView) and feed multiple things. Very nice.
• Healthy Debate on Datatypes - lots of discussion on double versus NSDecimal. I can see merits of both, but speed is going to favor the double, and as long as that's an option, that's OK. It seems there may be two ways to do this and one essentially feeding the other. Not bad.
• Signal Processing is Out - good, that should be done by the caller, or they can make a layer between the CorePlot stuff and their stuff. Keep it to graphing.
• Solid 2D Graphing - all the things you'd expect are there for 2D graphs. Everything seems solid and even really nice for a few things like CoreAnimation for plot fading in/out. Nice goodies, but stuff I might not use very often.

There are a lot of things I'm looking forward to use this for: the Potientials code I have - been waiting on some nice graphing for a while. Then there's a series of "monitors" that are accessible via DO or sockets library in CKit - for example. It'd be nice to be able to have a general "strip chart recorder" for data coming out of an app. Like an interesting take on debugging. Hook this up, and bang! you have an independent plotting window that takes your data and plots it nicely. Neat ideas. Can't wait to get started.

This is certainly going to update my ObjC (2.0) skills as well as all the new classes in 10.5... going to be an exciting time.

Base 1.2 has been released with a few new additions: SQL syntax highlighting, support for views and triggers, and saving columns widths in data browser. Nice additions, but nothing earth shaking. The additions look good, and seem to work as advertised. If things keep moving in the direction I think they are going with the open source graphing toolkit I'm volunteering for, I may have more use of this than previously thought.

Nice to see the update.

I was pulled in this morning to a problem with trade committals using a Python server that interfaces to a certain vendor's application. The python server is pretty nice - uses the built-in XMLRPC server and it's as clean and easy as pie to work on. Python - Good. The system it feeds - not so much.

I was getting an exception in committing a new trade to the system. I was getting a very unhelpful exception message, and as a result I had to run this guy several times with the same inputs and different levels of logging statements to see where in the code this was throwing the exception. It's python 2.3, so the really nice exception stack trace printing wasn't available to me, and the custom logging package in use wasn't my pick and I had no idea if it re-directed stdout/stderr.

What followed was about 30 mins of print debugging and about 5 mins of input data conditioning to make sure that none of the incoming data values were illegal and causing the problem. Good stuff to do, but given that this is all system-to-system interaction, this shouldn't have been strictly necessary. Nevertheless...

So I kept looking and finally got it down to the one field that was causing the problem. It was a string that was 23 characters long and the data description in the vendor's docs said it was limited to 20. OK, that's understandable in some systems like old-style client/server stuff. But in this day and age why are we limiting ourselves to 20 chars when we know any decent database has varchar fields and by their very nature, they are variable in length up to a point. Make that point 256 chars, or even 1k - what's the harm? Yes, it might not all fetch back in one packet, but given gigabit ethernet, is this still really a concern?

But even if it is, how about giving me a really useful exception like "Data value out of range" or something like that. Then you can use that for integers that are too big, strings, etc. It is pretty universal and then you are really helping out the guy trying to debug the problem.

As it was, I was forced to check "Why?" by searching around and finding in the docs the limit. But wait... there's more.

This vendor publishes a limit of n, but the limit is really n-1. Why? Good question. If the limit is 20, make the field in the database 21 or something. In fact, most varchar fields can hold up to their maximum, so why the offset? I can only imagine it's something from the designers/developers that is so silly as to be laughable.

I'm not laughing. I'm shaking my head.

So I finally put in the code to clean up the limits on the strings and log that data was getting truncated. Then I passed it off to the guys that were supposed to have figured this out, and they ran the tests and things worked. But we're still not done because with this truncation they have to make sure that it's not going to break anything moving forward. At this point, I don't know and don't really care. It's a messed-up system with horrible exception messages, pitiful documentation, and tech support that's virtually non-existant. I don't like it, and hope soon to be rid of it.

This morning I was looking at the logs of one of my price injectors and I got an exception on the CKStopwatch saying that the number of time events and time structs didn't match, which is a serious data integrity problem. I'm never gotten this before, and so I had to dig into it right away.

When I looked at the code, I saw something I knew was there, but it hadn't hit me in all the months this thing had been running. You see, in this injector, I need to have a few (configurable, based on load and number of processors) threads that take the prices and send them to the destination - inject them into the message stream. In these threads, I need to have an idea of the elapsed time they have been running so that I can print out statistics on their operation. Nothing big, but I need to have the number of prices they have injected over the time interval they have been working. Ticks per sec.

Since I needed to have this persistent over several loops of this thread's main processing method, I decided to declare it static at the top of the run loop:

  int SPPoller::process()
  {
      bool        error = false;
 
      static int         totalSent = 0;
      static CKStopwatch interval;

and then it checked to see if this was the first time through and reset the stopwatch. But all this was a horrible mistake waiting to bite me.

The static reference is going to give me one and only one value for this guy regardless of the number of threads using this code. The fact that the int was thread-safe was lucky for me, but the CKStopwatch wasn't. That's where I got the exception from the other day, and a different one this morning.

The reason I did this was to try and keep the variables close to their location of use. And had I gone with thread-local storage, I'd have been in good shape. But I didn't. I debugged this with a single injector and it was fine. I only have two in most configurations, so it's a little more dangerous, but still not as bad as if I had 50 threads.

The solution was easy - make the total sent count and the interval timer instance variables of the class and then in the constructor, reset the timer and zero out the count and everything will be just fine. This was only effecting my logging, and so it's not a horrible problem, but the exception caused the poller to die, and that was a serious issue. Had to be fixed. Easy to do.

Whew! That one caught me by surprise.

Today again, I was reminded that I don't work in a friendly environment. I can't open up my journal, I can't tweet... there are people literally looking at me waiting for me to make a mistake so they can yell at me - or worse. I'm not so dumb as to think that the issues with the weblog are over and forgotten with. I know there are at least a few people that would love to have me give them a reason to have me fired.

I have not made any friends in the current crop of co-workers here.

Those that I did get along with are all gone. And with each one, a little part of me knew that this place was getting a little more hostile towards me every day.

There are folks that come by and ask me to help them because for the last year they haven't taken the time to learn a new system and how to find things in it. They think they only need to know what they know, and don't believe that they need to stretch themselves. I was busy, but I had to make time to help this person find their problem in the code. Why? Lazy.

But I'll be seen as the Bad Guy... I have in the past, and will again. I'll be seen as short-tempered and unhelpful, but he will not be seen as lazy or directionless.

I read an email by another 'developer' saying that there was a limitation in Python that would not allow it to reload modules when embedded. I knew this to be wrong because a friend was doing it here in a C++ program before he left. He's still doing it where he is. I privately emailed this 'developer' to say it's not a limitation of embedded Python, it's a limitation of the embedder. He said I didn't understand, and that it was dangerous and not standard Python. I knew better.

I double-checked with my friend that had escaped a while back, and he verified that indeed it works just fine, and that he did it, and is still doing it. No questions. Sure, there are a few issues and limitations, but those are true in any reloading scheme. I tried to explain this to the 'developer' but finished off the email saying that I was very unsure if I should have sent this email exchange.

So often these things degenerate into an ugly exchange where one person is convinced that they are right - and really aren't. Their limited knowledge of the subject matter is not relevant to their belief that they are without question the authority on the issue. The person that attempts to correct them - right or wrong, is in for a dogmatic argument, not a learned discourse.

Yet this guy is considered the "expert"? You gotta be kidding me. He's not an idiot, but if he's making arguments like this, it's not a matter of knowledge, it's a matter of character. You either are open to the idea that you might be wrong, or you're not. I try to stay firmly in the former category. He is clearly in the latter.

It's exchanges like this, and others that I've had today, that make me feel once again, like I'm really better off just nodding my head and letting people believe what they want. THey clearly aren't interested in the truth, why should I bother them with it?