What's it all about, Alfie?

I was working with a subversion workarea (the check-out of the repository) today and tried to do a simple 'svn status' and got the following on the console:

  svn: This client is too old to work with the working copy '.';
      please get a newer Subversion client

What?! I had been using subversion version 1.3.2 (FedoraCore 5) for a while, I've used 1.4.4 (Mac OS X 10.5.6), even 1.4.3 on a shared install for Linux at the Shop - but I've never seen this.

So I do some digging. First, upgrading the FedoraCore 5 subversion install to 1.4.x is virtually out of the question. There are so many links to that RPM that it's possible to build from source and put it in /usr/local/bin/, but it's just as easy to soft-link the shared drive version (1.4.3) into /usr/local/bin/ and leave it at that.

So why the horrible upgrade path? Sure, subversion uses the apache libraries and such to provide functionality so that they didn't need to write it. That makes sense - to a point. But if I have links to 50 different shared libraries and I want to update my source control client - I shouldn't have to upgrade my OS. It should be something relatively simple. But it's not.

OK, RedHat (Fedora) can take a bit of the blame and the package management. But not all. There's not reason for this. CVS doesn't need it. Git doesn't need it. There's nothing that requires it. It's just the way they decided to do it. Freeze subversion at the OS level (by RedHat), and build it on so many shared libraries (subversion). Together, they make it ridiculous to upgrade the subversion client on a Fedora Core box.

But the big issue was not that the update was exceptionally hard, it was that is was required at all! What were they thinking? Honestly. What version control system makes a repository or workarea schema change that locks out an older version of the client? Amazing. I understand that they are trying to bring better features to the system. That's great. But they have a schema that's been established for a long time. They decide to change it now? I'm blown away.

Don't get me wrong. I understand progress. I understand new features. Xcode updates the old files and makes them unreadable by the previous version. Got it. But Xcode is not a source control system. The problem domain didn't change on them. If that didn't change, they they either did a very poor job putting the schema together in the first place, or they believe source control needs to have new bells and whistles for some reason.

In either case, I am re-affirming my stance with subversion. Won't use it except where I'm forced to. And then, only if there's no possible better alternative. CVS still wins, in my book, for centralized SCM, and Git wins for decentralized SCM. This isn't something that needs to have fancy new features. You need to have stability and reliability. Period.

Want to change the schema? Fine, make it part of the schema - XML does it. Then the client doesn't have to change as it reads all the descriptive information about the repo at runtime. Again, the client doesn't need to change.

I am forced to believe they are either poor designers or interested in shiny buttons. Neither of which is never a good thing. More than anything else I'm stunned that they'd mistakenly design the schema. This was an update of CVS, they knew all the 'limitations' of CVS, and set out to 'fix' them. That they missed the primary reason for source control -- stability, is beyond me. It's just amazing.

I'll keep my distance from subversion, thanks. There are plenty of other, better, alternatives out there.

Over the course of the last few months, I've had a few run-ins with a co-worker and while I initially put it off as a bad manners, lately, I've come to realize that this person is really exceptionally rude - yet thinks of themselves as humorous.

I'm sure there are literally thousands of people we all meet every day like this. They believe that the way to establish some connection with a person is to prod, poke fun, and then with a wink and a nod, let that person know that they aren't serious. To a point, this is understandable. People can be nervous in all manner of ways, and this can manifest itself in a lot of weird behavior, but when this goes too far, it's really quite counter-productive to the work environment.

Unprofessional Behavior. That's what it is. Simple as that. Out on the street, you are free to be as rude and nasty as you can stand. Doesn't make it right, just means that no one really has to deal with you - but you. But in a work setting, this is not really helpful. I've probably made it worse by allowing it in the first place. I should have just spoken up and said "Hey, funny 'Ha ha', but please, let's keep it professional, OK?"

Unfortunately, I've had to get far more blunt with some folks I've worked with. Sad that they didn't take the more mild hint, and I've had to actually say "You're making fun of me, right?" and when they agree, I say "Have you no shame? Please stop." I've been lucky - that usually does it, but in some cases, it's best to just walk away.

There are people that believe they know you, that they are you buddy, and so they say these rude things, as if to say "Hey, you'd only let a friend do this - right?". Wrong. I would never let a friend do that, and I'd never do it to a friend. What kind of friends do you have, anyway? Convicted felons and Wanna-be Stand-Up comics? Give it a rest.

Well... today I started to 'clear the air' with this guy. I got about a sentence into it and realized that he's completely clueless about what he's doing. Has no idea - honestly. Oh... maybe that's environmental, or maybe it's how he's been raised... I don't know. But I decided that there's no reason to has it out with him. None. He's not going to understand it and it'll just seem like I'm picking on him for no reason. After all, he was being "nice" to me.

In these cases, it's time to walk away. Really. He's free to attract as many "friends" as he can with these particular social skills. I only have to work with him. When I see his particular brand of 'humor' in communication, I'll just have to write it off as nonsense, and move on. I'm not interested in being insulted and winked at, as if that makes it all better, and he's not about to change how he deals with "friends".

I've run into this a lot in at least a few languages - Java and Python. The coder thinks he's saving something by saying:

  import java.util.Date;
  import java.util.Vector;
  import java.util.Stack;

as opposed to simply saying:

  import java.util.*;

I mean really... what are we saving here? Nothing. Exactly nothing. The reading of a file? No... it's still got to read what it reads for the three classes from the one jar file. Microseconds on the compile - maybe. But what have you done? You've forced all additional developers to enumerate all classes they are using. Why? Is it really that important?

It gets worse in Python. I ran into the following code:

  import logging.config, os, sys

where the normal developer would say:

  import logging, os, sys

Can't imagine we've gained anything by just loading the config if we're really do any logging, chances are we're going to actually log. But what I found out today is that this can cause a ton of trouble in systems with the thread package built-in and using the dummy_thread.py stub.

For these guys, you really need to do the following:

  try:
      import thread
  except ImportError:
      import dummy_thread as thread

and in doing this we are able to use the thread package as if it always existed - even when it doesn't. Decent. And the logging package does this - so long as you import it properly. If you try to, oh, I don't know... say import just the logging.config package this isn't done and then all of a sudden the dummy_thread.py isn't pulled into play and you get import errors in the python logging libraries.

Argh!

So I have to ask around and see who might have done this and for what reason. I don't want to make a change that will break something just to get something else to work. We need to have everything working, and if that means we need to put more work into this guy, then so be it, but I'm very clear that this is code written here and not a part of the core Python code.

It's something I'm going to have to deal with on this little project. It's not fun, but it's what I have to do.

I'm continually amazed at the lack of documentation that most developers I meet write. They don't think it's necessary for their work - after all, they wrote it. Who else needs to understand it? Who else needs to use it? Well... if they need to use it, they'll come and talk to me and I'll walk them through it and then they'll be OK.

It's an incredible double-standard. If they ask for docs from me for something (and most developers I work with have, from time to time) I give it to them. Why? Because I wrote it. I wrote it for myself, and then built the code based on those docs. I know they didn't write the docs otherwise, they'd give them to me.

No, and I've run into a class of developer that if I don't have docs for a process or procedure ready, they want them as opposed to the "talk through". I have to provide it for them so they can make their process or procedure. But when I ask for it, they think I'm being unreasonable. These people are just lazy, no two ways about it.

But the general mass of developers that don't write docs, or even comment their code so that it's at least able to be followed by someone are the ones that get me. They know the value of the docs, but still they refuse to write them. They know it'd make things a lot easier, but they aren't concerned about making the other guy's life easier... they had it hard, so why make it easier on the guy following them? Selfish, is all I can think of. Unkind as well.

So I'm sitting here realizing that I have very little in common with developers like this. I'll continue to work with them, but it's a waste of my time to expect them to change. Maybe they'll run into someone that gets them to write them, and then see the value in having them. But until that day comes there's nothing I can do to make them see the err of their ways. Sad.

This morning I read that Audio Hijack Pro 2.9.1 is out with a significant advancement in the Instant Hijack capabilities for 64-bit processes, among other things. I'm sure this has something to do with all the new code that's coming out from developers. With Snow Leopard it'll be even more.

Well... nice to see the improvements.

I was reading Slashdot this morning and saw this post about Microsoft and Windows 7 pricing models - their low-end "Starter Edition" is going to limit the user to running three applications at once. Yikes! I suppose that's OK if you're gaming, but that's a really really small market.

Their research says that the average consumer has just over two applications running at once. Maybe... but I'm not buying that line. Make it 10. What's the problem? Someone working at home and needing the "real goods" is going to up-sell anyway. I just don't get it when they cut these numbers. It makes no sense.

Be the Good Guy, not the Cheapskate.

Well, I'm not shocked, but I am slightly disappointed in the leaked views of the new Kindle. It's nice and thin, and with an aluminum back, it'll be rigid which is nice. But there's a lot of 'border' around the screen, and that really increases the size of the unit.

Also missing is any visible sign of the switches for the 3G modem. Maybe it's in software now, which would be nice, but they may also have made it "always on" - we'll have to wait and see.

For now, this is interesting, and supposedly shipping at the end of this month. We'll see what the details are later today and if they can actually make enough of these to satisfy demand.

I was rebuilding a few machines today - web servers, that were using the mod_proxy_ajp now a part of Apache to forward the non-static requests to the co-resident Tomcat instance on the box. As a part of that set-up, we had a custom conf file that we loaded into /etc/httpd/conf.d/ to handle all the configuration of the web server. Well... 99% of it, but still - all the proxy forwarding and virtual hosting is in this one file.

The wrinkle came in with a Redirect line in the VirtualHost section of the file:

  <VirtualHost yummy>
      Redirect /index.html http://localhost:8888/yummy/app
      Redirect /UAT http://slushy.funstuff.com:8888/yummy/app
      ...
  </VirtualHost>

where the primary machine has a DNS entry for yummy and that's how most folks get to the web site. The UAT box is called slushy, and this way, the users can hit the URL http://yummy/UAT and get right to the UAT box. Pretty nice.

Or so I thought.

The problem with Apache and the mod_alias, it seems, is the use of localhost in the redirection of index.html to the local machine. When I try to hit it, I get that the web site is not available - like the URL doesn't point to the right sight.

But when I go directly to http://yummy:8888/yummy/app I see the web site - so I know it's there. Also, if I use wget to grab http://localhost:8888/yummy/app on that box, I get the initial page.

It's as if the Apache mod_alias or the mod_proxy_ajp are somehow not using the standard methods of name-to-IP resolution. For if I change the configuration to:

  <VirtualHost yummy>
      Redirect /index.html http://yummy.funstuff.com:8888/yummy/app
      Redirect /UAT http://slushy.funstuff.com:8888/yummy/app
      ...
  </VirtualHost>

Everything works. I looked at the Apache docs for the Redirect command, and it says it needs a fully qualified URL. I have given it that - and verified with wget that it's working. But something in there isn't working.

What this means is that we need to customize these configuration files for each machine so that they can properly redirect to the host it's on. Odd. Very odd. But it's a work-around for now. If this comes up again and again, I'll look into it to see what I might have to do, but very odd.

I was reading the feeds this morning and came across this wonderful little hint about removing the older version of the Flash plug-in for Safari. I had mistakenly thought that when Flash installed itself, it removed older versions of same, but I was clearly wrong.

The old version was in /Library/Internet Plug-Ins/ and was a file called flashplayer.xpt. I removed the file and restarted Safari and we'll see if I see faster Flash load times. Even if I don't, it's nice to clean out the old dead weight every now and then.

So today I was digging into the custom language code of a vendor's package that was customized by the vendor's consultants for us. The language is designed to be simple and fast to update - everything is based on function calls. Everything.

I can see the advantage - it's a simple function call graph. If there's a value in the tree that doesn't change, then there's no need to make the next level call because nothing is going to change. Seems reasonable, until it's taken to extremes. Like this code.

If you're going to base a language on functions, then you need to have functions that can handle if statements and conversion of variable types: boolean to integer, for example. That's kind of obvious. What this vendor did was to make the bare minimal set of functions that can be used to derive most other things, but there was not care put into it to make the language easy to use.

And they took advantage of that.

Case in point: using a max() function to find the only non-zero value in an array. Why do that? What happens if your assumptions are wrong and there isn't only one non-zero value - say there's two. What then, Sherlock? Yeah, it breaks. Why not be a little smarter and filter out the data and then call the function on the one object you want. Seems pretty simple to me.

But that's not how it was built. It's like they planned on doing a lot of extra work and then "making up for it" in volume, or something like that. It's crazy. No filters means that you have to filter on each value and then pick the max() of the set. What a waste.

Sure, I got it done, but had I been able to write it in a more expressive language, it would have been far easier, and I probably would not have had to go in and fix it in the first place. The original author probably would have gotten it right the first time.

So I spent an hour in Function Land, and I can't say I'm a better person for it. I know it's not the last time I'll have to do this, but I'm hoping that as time goes on I'll be able to remove this horrible code and make it simpler. Like basing it on the non-function-based scripting language they use for everything else. Yeah, it'll be slower, but it will be 100x more maintainable.