What's it all about, Alfie?

Most of today I've been messing with getting the secondary Y axis on the BKSimpleLineGraphApplet in BKit to work with an additional list of the columns of data for the secondary axis. Basically, a guy stopped by and asked if it would be possible to make the dual-Y axis line graph have two lists at the top: one for the primary Y axis and the other for the secondary Y axis. That way, the user could pick what they wanted to plot on the "left" and what they wanted to plot on the "right".

Something like this:

The problem is that I got a lot of it working with just a few additional applet param tags, but there were problems with the selection of the columns of data for the secondary Y axis. I'd say show me the third column, and it'd show me the first. Very odd. I spent quite a while on this until I checked how the BKFixedLineGraphApplet worked -- It had the same problem! This shouldn't be as I wasn't messing with it at all. So there had to be a low-level issue in the BKBaseGraph when dealing with multiple Y axes.

I started running a lot of tests. What it appears to be is an issue with VantagePoint where no matter what 'Variables' you tell it to put on the secondary Y axis, it's only going to put one of the first two. Essentially taking the column number modulo 2.

Ask for columns 2 and 3 (zero-biased indexes) and you'll get columns 0 and 1. Ask for 1 and 2 and you'll get 1 and 0. Very odd. When I tried out the BKSimpleLienGraphApplet with multiple lines on the secondary Y axis, I saw that I picked up on what VantagePoint had thrown down: the first two columns - no matter what. Wild.

So tomorrow I'm going to have to send Gordon an email saying what I've found and asking if the most recent version he's sending me to fix the problem with multiple Y axes and version 4.6.6 will fix this as well. Because I'm sure not going to deliver this to the users - they wanted the pick lists in order to select what's on each axis. As it is now, it's really too broken to deploy.

I'm working with a vendor's product where they have kindly created the possibility of adding customer-specific fields to each object in the database. It's a nice touch, and if done correctly, it makes the system very flexible and expandable, but if it's done wrong, it can make the system horribly slow and difficult to deal with.

Yes... I know... it's easy to see which this one is.

But to the point at hand. Each of these Customer Bits is tagged with a datatype and what object (both type and instance) it belongs to, etc. The interesting thing is how to add a lot of data to the system very fast. If we need to add in the base object and then, say, a dozen of these bits, then we need to do it all very fast - if it's going to be on something like tick processing, or trade processing. You get the picture.

So today I learned through the School of Hard Knocks, that when adding these bits to an object, you can add them one of two ways: individually, or in bulk. If you add them in individually, you're basically adding the base object, committing it, and then one by one, adding the bits, and committing each as you go. If you add them in bulk, you're creating the base object and all the bits and then committing just once.

What I learned was that if you take the individual approach, the data you place in the bits doesn't matter - specifically, you can place an empty string in a bit and it's all OK. But if you try to do it in bulk, you get a very cryptic error message that it's clearly tied to the bit you're setting to an empty string.

So it's an easy fix - once you know the problem. Simply don't allow setting bits to empty strings. But you'd think that this shouldn't be a problem in the first place. But there you go thinking again.

UPDATE: I heard from a developer deep in the Vendor's shop and he said that there was a bug report about this already and the answer was to disallow all empty string usage in the bits. That's certainly one way to handle it.

I got a tweet from Twitterrific itself about using it with Present.ly, and in that posting, it mentioned that 3.2b3 was available. I wasn't sure if I had the latest beta - which uses https:// for transfers as opposed to the previous http:// protocol. Not that I think anyone is really trying to snoop my tweets, but there are other improvements, and if security is free, why not take advantage of it?

Nothing spectacular, but it's nice to be up to date (for certain). It'd be great if they incorporated Sparkle, but that's up to them.

I was monitoring one of my price injectors this morning and several weeks ago I had worked up an interesting little addition to monitor the app that's processing the prices I'm injecting. I worked up the log-based monitoring, and at the time I was a little concerned that it was too loosely coupled, and that we'd get into trouble because of this. Because of this, I worked very hard to try and anticipate a lot of the conditions that might occur, and as of this morning, I'm very glad to say the efforts have certainly paid off.

Sometimes, it's good to be loosely coupled. I had no real choice, but even if I had, this was a vendor's closed package and what was I really going to do? I have done pretty much all I can. In this case, it was really thinking about what might happen that did the trick. I can see that my app detects that their app is frozen and simply stops sending. I can see it detect that the app has been restarted and starts sending again. Little things, I know, but it's going to make it possible to have my app proactively restart theirs.

That would be a great kick in the pants, wouldn't it? "Hey guys... your app freezes on me -- a lot, so I put in code to detect it and restart it. You might want to work on that stability someday." Man, that would be s...w...e...e...t.

It's just what the doctor ordered.

I'm coming off being exceptionally angry with a Vendor. I got a Diet Coke, had a few sips, and tried to calm down, when it hit me - It's amazing what these people didn't lean in Kindergarten. No really... from the poster/book All I really Needed to Know I Learned in Kindergarten I'm amazed that these people didn't learn these things.

Maybe they did, but when they deal with us, they casually "forget" the important things: Don't lie... Be Honest... Take responsibility when it's yours to take, and help people even if it isn't. These are simple things. We expect them from our kids - we tell them to tell us the truth, and we honestly go easier on them when they are honest and tell us the truth. It really does work.

So why do people dealing with a 'customer' act differently?

If it simply because they want to look good? I don't think so. I don't think these contacts at the Vendor really even care if they are seen as nice and helpful, or mean and unhelpful. Does it effect their pay? No. They do a job for a company, and unless it costs the company money (like a client leaving) they're not going to get involved. So I don't think they care about being seen as nice. They just don't want to get fired for losing a client.

Is it because they need to protect the company's reputation? That probably happens sometimes, but in a big global corporation, they are more interested in who recommends them and not necessarily likes them. Face it... Oracle might not be liked but they are going to be used by people because of their reputation. So, I don't think it's for the company's image they do this - again, most of the time.

I think it's because they know their product has faults - everything does, and when they are confronted by it, their first instinct might be to confess the short-coming, but then a call from here is made to there, and CTOs are involved, and all of a sudden honesty evaporates. All because someone else, higher up in the chain of the vendor, starts to scream.

They're being a bully to their people. Nothing more, nothing less. These people dared to tell us the truth, which was uncomfortable for them and for us. But if it was the truth, then we should know that, do our best to deal with it and move on. This isn't the time to bring out the rubber hoses and beat people on the feet... it's a time to recognize the limitations of something and work within those limitations to try and make something that might work.

There's two ways to handle disappointment - suck on the sour lemon, or make lemonade. I'm all for the latter. Let's try to remember what we learned in Kindergarten - take turns, share, work together... all these things are going to make the situation better not worse.

I was formally introduced to Python in the context of a vendor's application. They used it as the glue that binds and controls the individual components of their system as well as the internal language of operation. It's a gigantic python collection. And the experiences I've had with the product, and therefore by extension, the language have been bad. Miserable, in fact. But I'm trying to overcome them.

Python is a very simple language with great power because, as in perl, people have taken a liking to it and have written tons of libraries and add-ons to it to provide all the power the original author(s) and designer(s) didn't have the time or vision to write. Both languages are impressive in that way.

I have to admit that I'm not a fan of a language where control rests in the level of indentation, but I can see the reason for it - uniformity of the look of the code. You can't have the religious arguments about tabs/spaces or where to put the bracket if you have to indent to create the structure of your application. But I have to admire a simple language where the creativity is in finding and using those additional libraries and putting them to good use.

So I'm trying to warm up to Python, and I think I'm going to make it. It's just got this major handicap right now - it's connected with a product and a vendor that I really can't stand, and getting over that is hard.

Yesterday I ran into a roadblock on this one little project I was working on, and I realized that the docs were useless, the data dumps weren't helping, and in the end I needed to talk to the tech support folks. So I wrote up a little message saying in very clear terms what I was looking at in the client, and that I needed to have programmatic access in their development language to those values.

Pretty simple stuff.

I was not expecting what I got back.

The first person responded saying that the values I was referring to were wrong, and why would I want them? Answer: because the user wants me to get them.

But those numbers are wrong... Here... let me show you how to set them properly (with screen shots, etc.) OK... but that didn't tell me how to get them even one they were 'right'

To this last exchange I wrote back saying "Hey, right or wrong, I just need to know how to get the data." Clearly, I wasn't getting through. I thought I'd get the answer I needed. Silly me...

The next reply was from the second level support asking why I needed that data, and what was I going to do with it? Holy Cow, people... is this an Inquisition, or what? I just want to know how to get at the data that I can see with my own eyes in the Client. I can get all the other pieces I can see, why not this one?

"Bob, if you'd just let us know the background, I'm sure we can help you."

Finally, I gave up. I told them I was making a report for the users and needed the data as they have highlighted it as the data they want to see. To this, I finally get "OK, we'll see what we can do".

I was stunned. Why it matters to them what lead me to this place, or what on earth I wanted to do with it was, and is, so totally beyond me I can't even begin to put it into a common frame of reference. I know for a fact that the first and second levels have no idea how to get the data I need, so maybe they are just stalling for time. But to be as belligerent about this as they were is something I never expected from a vendor - Attitude.

So now I know... when I want a piece of data, I have to ask for it in the right way or they're just going to keep at me to ask it in the "right" way until I do. Only then will I get the information I asked for. Needless to say, most of my co-workers thought I showed considerable patience with this interchange. Many were using not-safe-for-work language after the second email.

Just amazing.

I saw today that HostMonster had the update from Fantastico for WordPress 2.6.2 - and I needed to upgrade. These upgrades have become very routine - but the first few were real nail-biters for me. Thankfully, the Fantastico guys know what to do and the upgrades have been flawless.

Now we're on the recent version of WordPress and that's good to know. I have to say that getting an account on HostMonster was an excellent move for me. I can't imagine having a better hosting experience.

This morning I saw that VoodooPad (Pro) 3.5.2 was released with quiet a few fixes and enhancements - some of which are getting the application ready for 4.0 (I've read on the Flying Meat support boards Beta testers are already being sought out).

VoodooPad is the self-Wiki, indexed, free-form database with search capabilities that can form the basis of a nice help-system that you create yourself. I use it to put in all kinds of things that I need to be able to get at occasionally. I know that if I had time, I'd take about a week and put in a lot more, but those docs are OK for the time just being text files and I can search them.

The Pro version has several nice features, and most importantly, it supports the indie Mac developer that goes to all the trouble to make this available. You have to support good work, or there won't be any.

Overly dramatic? Possibly. On target? Dead on.

These last two days have brought a point to light with this product we're trying to integrate into the Shop that is a show-stopper, and we didn't find it out until a week and a half from the completion of all development related to the major deliverables.

Basically, it's insufficient for our needs and we didn't see it until we're virtually done and have spent literally dozens of man-years on the integration. It's like building a car only to find that it's engine is too small to actually move the chassis, and no way to make it bigger.

Major problems.

The vendor is all but saying "Sorry, that's the best we can do for you", and the management tram is scrambling because they know the next question that's going to be asked is "Why didn't you see this coming?" Good question. I wonder why they didn't.

Oh, hey, I know... because they no longer value judgements here - only answers to questions they phrase and then they make the decisions thinking they have all the knowledge necessary. After a while, we stopped trying to do, and moved into a simple reactionary phase. That's all they wanted anyway.

So now we're all sitting on this train... too late to get off, it's a week before the deadline. No way the vendor is going to supply a fix, they've known about this from another customer for 18 months and done nothing about it. Nope... it's a train wreck, all right, and we're stuck on the top of it.

Well... at least I'll have a good view of the fall.