What's it all about, Alfie?

Given that I've looked at Mercurial and decided against using it as my main distributed source control system, and my version of Git was 1.6.0.2, I decided to update to the latest version of Git which was 1.6.4 on my laptop, my Intel iMac at home, and my gitosis server at home. It was just time for an update. Plus, I've read that the newer versions have pulled quite a bit of the old wrapper code into the C codebase so that things are more compact and faster. All around, it looked like it was time to upgrade and get on the latest features.

The updates for my laptop and iMac were easy because there's a Google code project for a Git installer for Mac OS X. It's as easy as downloading the package, installing it and running with it. Sure, there are a few things that you might want to do if this is the initial install of Git, and I've documented these previously. But an upgrade is easy-breezy.

The update for my OS X 10.3.9 box, frosty, at home is about as easy. Again, since I've built 1.6.0.2 on it before, it was as simple as:

  curl -o git.tar.gz http://www.kernel.org/pub/software/scm/git/git-1.6.4.tar.gz
  cd git-1.6.4
  ./configure
  make
  sudo make install

and we're off an running. Yeah, the docs aren't updated, but that's documented in the previous install, and I use my laptop for docs more, anyway.

Getting gitweb updated was pretty simple - just like the original install and it's in the Git distribution. One thing I liked about this time is that I'm a lot more savvy about the use of CSS and layout, so when I updated the code for gitweb, I fixed up the HTML for the gitweb header to be:

<div style="margin: 0px 0px 0px 0px; width: 100%;
 background-color:#2f2f9d;">
  <img src="/icons/repository_title.gif" alt="Dr Bobs Repository"
   width="344" height="61"/>
</div>

so that I get a nice looking header that renders a lot faster than the old TABLE HTML.

In the end, it's been about 30 mins all-told, and we are up to the latest Git at 1.6.4. Not bad at all.

Today I was looking at the fact that my old WordPress passwording scheme was not looking the way it should - clearly from lack of updates and support, and so I went on a search for a better plug-in for password protecting my blog. What I found was Members Only which is a nice plug-in that requires that users have accounts on the blog to read postings, and presents them with the login box if they go to the URL for a posting. Once the authentication is done, it's back to the requested page for a minimum of fuss. It's nice in that it's tied into the regular WordPress accounts. The old one had a single password and to give that to everyone wasn't really a good plan. Better now that I can have accounts and allow them to maintain the passwords, etc.

It's going to make it a lot easier to maintain the blog while allowing those people I know to be able to read the posts without exposing myself to any unnecessary legal exposure. It seems like a very nice balance.

This morning I noticed that many of the traditional news feeds were talking about this:

and I have to agree that the thread of profit for a URL shortening service is not clear to me. While it's possible to track the creator, the target URL, and the hits on that 'shortened' URL, it's not clear why this would be a service that others would want to pay for.

Sure, I can see why a web-based service might want to have URL shortening in it's arsenal of features, but to pay someone else to do this, is a little odd to me. Of course, if they had been able to get a dominate API or enough mindshare - like Google, then I can see it being more of a 'defacto standard'. But that didn't happen because the barrier to entry is so low.

But the cost of maintenance is high: you've got to have a ton of bandwidth and a ton of storage if you're going to be any good at this. So the costs are there, but that's about it for the barrier to entry. The rest is a little script and you can hack that together in a short time.

No, this is Natural Selection at it's best - the weak are weeded out and the strong survive. We don't need a ton of URL shortening tools. Just a few - at most. But for all those people that have these URLs in their blog posts and search pages, it's going to be a mess clearing out the bad data and replacing it with good. It would be nice for someone to take the database and the domain and keep this going - but that's the point of the notice. No one wants to pay for it, and that's why it's shutting down.

Which, of course, is why I don't use URL shortening save when an app does it for me - Twitteriffic.

Well, Liza got her wish and she and I found a gem of a dog at the Humane Society of Plainfield today. Panda (the name given to her by her foster Mom) is a 5.5 month old Black Lab and Australian Cattle Dog mix (they believe). Her birthdate was listed as Feb 21, 2009 and she was the most amazingly calm and well-behaved puppy I've ever seen. She's exceptionally social, and just wants to be around people without really being underfoot.

This picture of Panda and Marie was taken during a 'typical' moment in the house. She's loads of fun outside with our large yard. She's fast, enjoys playing chase and fetch, but also just loves laying out in the grass and investigating her environment.

We had a 5 gal bucket on the deck filled with water for her, and she loved it. She would dunk her head, something they have said we should expect as her background is heavily into water and she's not at all afraid of it.

She's bonding well with Nina and the rest of the house. She's not having any problems with Cole, our 3 year old cat that we rescued two years ago. They seem to allow each other to exist and don't really pay much attention to one another. In the future, I'm guessing they'll be fine with each other, but it's great that now they don't fight.

Panda is a big puppy - 40 lbs, and very large paws. She's going to be a big dog, which is exactly what Liza wanted. I can understand it, she's a Farm Girl, and she misses the big, fun loving, dogs that she grew up with. She says it's for the kids, but we both know that Panda is for her. This is the little missing piece of her childhood that she wants to have back in her life.

I can't blame her, who wouldn't want a little slice of wonderful in their lives. We all need to have a few things to hold onto when the times get rough, and she certainly deserves this as much as anyone. I'm glad Panda has started out live in our house on such a great note.

I was doing a little reading this morning and I came across another developer that was talking about how nice Mercurial was. He was mentioning a nice book he'd read on the subject and how much he liked the book. So I decided to take a little time this morning and give it a quick once over. Compare what I knew of Git to Mercurial and see how they stack up for my needs.

First, it's clear that each has a strong following. The linux kernel is in Git, and Google has adopted Mercurial. Both are strong statements to be considered. Certainly, if you're going to work on a project and it's in Subversion, or Git or Mercurial, then you have to do as the Romans do. But if you have a choice, and specifically, if I have a choice, what would I pick?

So what do I need? Well, I work on a laptop a lot of the time. Frankly, most of the time. I want something that's going to be significantly better than CVS - and I know CVS pretty darn well. Thankfully, both Git and Mercurial are winners here. There are Mac OS X GUI clients, and command line clients as well. Check.

Xcode support is important, but with the changes in Xcode to use ASCII files as opposed to binary files for nibs, I don't have to worry too much about this. Also, they have removed the 'bundle' concept for most things in Xcode, so I don't have to worry about directories appearing and disappearing on me. To be fair, Apple did all this work on it's own. That the SCM of choice doesn't have to worry about it is nice, but not leaning one way or the other.

I'll grant you that Mercurial is more like CVS, in that it's file-based and simple to understand. There's even a built-in web server to make it easy to act as a server for remote users to 'pull' a repository. Not bad. But Git has Gitosis, and now that I have it running, it's a server that I don't have to think about. It just runs. Period.

I could try to get Mercurial up on my Mac at home where I have CVS and Gitosis, but then I need to get Python 2.5 on that box, and it's an old Mac - suitable for the serving of these files, but it's not got the up to date Python that Leopard has. So that would be a pain. Not impossible, but a pain.

I guess it comes down to inertia.

I have Git, I have GitX, and they work. I have CVS for the old stuff, and it's never going away. Never. In the end, I might do some Mercurial work, but I'm guessing that it's even money that I'll stick with Git. It's just as nice and I have it all set up.

The changes are coming fast and furious now with NetNewsWire 3.2 - today we have 3.2b14 released with the Sparkle release notes:

• Fixed a bug where & and similar would appear in title list instead of &.
• Sending 30 mark-read/mark-unread items in one call rather than 10, for better efficiency.
• Marking an item as unread is now communicated to Google Reader.
• Doesn't send mark read or unread actions for items where Google has locked the read state (for efficiency).
• Fixed a bug parsing and displaying enclosures.
• Fixed a bug where moving a feed -- but keeping it inside its folder -- would make it jump out to the top level.
• Possibly fixed a crashing bug in drawing titles in the vertical tabs table.
• Report Bug/Feature window now sends NetNewsWire settings info (optionally) instead of system details -- because NetNewsWire info is way more useful in figuring things out. (Saves some time asking questions.)
• Doesn't allow editing the feed URL for a Google-synced feed (since this isn't supported by the API).
• Fixed a bug where showing/hiding read items would get confused.
• Fixed a bug subscribed to a feed and saying it should not be synced -- those feeds were getting deleted right away after subscribing. (No longer.)
• Fixed a bug where feeds set to not sync would still get sent to Reader when merging subscriptions (either at first-run or manually).
• Fixed the query string that identifies NetNewsWire in the URL when downloading feeds. (A little thing Google needs.)
• Easier-to-read formatting of Google feeds in the view-feed-source window.
• Fixed a bug that could cause the description areas of the Combined View to be empty when a feed says that its home page is http://

So the public beta really is picking up a lot of little things, and Brent is turning them around into a new release almost daily. Pretty impressive.

I'm finally pretty happy that the alerts in my web system are working as they should. The aggregated values are being calculated properly, the alerts are being triggered correctly, it's all working as it should. This is a "Big Deal" as it's one of the important things this guy was supposed to do - alert people via "push methods" (email and chat for now) of problems in the data. With these alerts in place, it's easier to let people not look at the data all day long, and have it alert them to problems. With a good set of alerts in place, it'll be easy to have the right people informed of the proper conditions.

Sure, it's geeky, but this is what it often comes down to - being able to finally bend this code into what I want it to be and seeing the results play out in front of me.

This morning when I was updating to Mac OS X 10.5.8, I checked on DrawIt, and saw that they had released a new version: DrawIt 3.8.4. The list of changes is pretty small:

• Fixes bugs with moving groups around
• Fixes bugs related to the bevel filter
• Minor UI fixes

but anytime someone is still working on code to improve it, I'm a happy guy. Snow Leopard is just around the corner, and I want to believe that all the apps I use are going to be safely ported to that platform.

This morning I noticed that Mac OS X 10.5.8 is on Software Updates with a list of security and stability fixes. Makes sense. They are putting all the new work into Snow Leopard now - due out in about a month. This is a "clean up" release - getting security fixes into the libraries, etc. as they get ready to put this OS into maintenance mode.

Can't blame them, I'm excited about Snow Leopard too. Still, nice to know that I'm a little bit better protected against the script kiddies that live in their parent's basements and have nothing better to do than attach computers.

I was working on a problem today with the alerts in my web system and I was having a really hard time getting a handle on the problem. Basically, I had an object that did n-point moving average calculations on a data stream and I wanted to use that to feed a data aggregator where all the data from the n-point smoothing would be summed up across the firm to get "totals" that could be used in the alert expressions.

I had built the n-point moving average class to expose a 'previous' and 'current' array of data so that it looked just like the incoming data - an Object[]. I did this by having two such Object[] instance variables - one for the 'previous' and the other for the 'current'. When a new value came in, I'd copy the contents of the 'current' to the 'previous', add in the new, subtract out the old, and save the new as the old for this contributor. It worked like a dream.

What I was seeing was that the data going into the firm aggregator was showing the same values in the 'previous' and 'current' data arrays! This simply could not be. In the aggregator, I was saving the data from the n-point smoother, by contributor, similarly to the n-point smoother itself, so that we can add in the new, remove the old, save the new as the old, and get a nice running aggregation.

But it wasn't working that way.

And it took me several hours to figure it out. But I did.

References. Java references are somewhat deceptive. In C++ I'd know what I was doing more clearly because I'd have to be more careful with the heap variables. Stack variables were easy as they went out of scope and were gone. Copies were cheap, relatively.

But in Java, everything is a reference. So when I was getting the 'previous' and 'current' data from the n-point smoother, I was really getting the reference to the arrays I was using as storage. When I then got new data into the n-point smoother, I updated that data, and naturally, the data in the aggregator would change as well. After all, it's the same reference.

Ah!

So what I had to do was to make copies of the data coming out of the n-point smoother and into the aggregator. These, then formed snapshots of the data coming out and were exactly what I needed in the data flow.

In general, there's a lot to like about Java. Garbage Collection is one of them. But there are times that the visual warning of pointers in C++ makes it much easier to see issues - or potential issues. I've been coding for a while, and this guy flew right past me for several hours. That's tough to find.