Today I got a tweet that Unison 2.1.1 was released, and truth be told, I knew this as I've been beta testing all the Unison 2.x releases for the great guys at Panic. It's got a few nice crashing bugs, and even a few really nagging UI issues all solved. It's just getting better and better.
Great to be a part of great software.
Well... I found out that iOS 4.1 is out for my iPhone and it includes a lot of the nice little things that we've all been hearing about for the last several months: Game Center, the improved proximity sensor, lots of bug fixes and the new camera features.
While I certainly can remember my life before the MacBook Pro and the iPhone, I can't imagine going back to that old world of desktop computers and cell phones that I turned off and only made calls on. It's a different world, and I like where it's headed.
The update isn't going to be quick, I'm betting there are thousands upon thousands of people trying to get that 500+MB file from Apple right now, but I can wait. It's enough for me to know that it's coming, and it'll all take care of itself in time.
Far be it from me to say Google shouldn't try new things. I wish they'd try not messing with Verizon on the net neutrality, or maybe just not being so overt about the complete and total lack of privacy from it's upper management, but today they released, in a very haphazard way, Google Instant, and I hate it.
OK, in my book there were a few reasons that people switched from Yahoo! to Google in the early days - one was certainly the search results, but in the beginning they weren't that much better - it still had a lot to do with the terms you asked for, and the best "search engines" were browsers that would hit a dozen search engines for you and bring it all together.
The other big driver - and certainly this was a biggie for me, was the simplicity and speed of the Google homepage. You typed into a box, hit enter, and got answers. You didn't have to wait for Yahoo!'s "portal" to load - measured in seconds, and you didn't have the distractions of the entire page. Simplicity was the rule of the day, and it was wonderful.
This morning Google has been rolling out, in fits and starts, their new offering - Google Instant. Now when you type, it immediately jumps to the answers and updates them as you type. While this may seem like a real time saver, to me it's at least a distraction, and at most, a horrible time waster.
If I need to type in a series of key words, or maybe my search criteria is more than 15 characters. The fact that it starts "searching" for me after four or five is a waste until I get to 15. I'm not done, I'm not liable to stop, and I wanted to get the search string in there. They already do "predictive searching" on the search string, which is nice to a point, because if there's a hit there, I can save myself the time, but there's no way showing me the entire search results is a time-saver. Not a chance.
I was worried that it was ON, and there was nothing I could do about it. But after a few hours, it became clear that it's something that I could turn off. I did so immediately and without a single reservation.
Guys... first, make your rollouts a little smoother - No, make that a lot smoother. There's no need for this to take an entire morning and have so many people wondering what's going on with no way of stopping it.
Next, make sure it's clear how to turn the crud off. You should have learned from Wave, and the full graphic homepage, but I guess that wasn't enough. Here... take the lesson... make it obvious how to disable the new crap. Lots of folks just want what you're good at.
I'm still shaking my head...
This morning I noticed that DrawIt 3.10.6 was out - with the ability to read/write Sketch files. Now I hadn't heard of Sketch, and I'm not sure I need to dig into it as DrawIt does all my vector drawing needs - and if it didn't, ZeusDraw does, but it's nice that they are moving in that direction. More choices and better apps are always nice to see.
This morning I noticed that I had updates from Apple - Safari 5.0.2 and iWeb 3.0.2. Very nice! I looked at the skimpy release notes with Software Update, and there are a few things for Safari - like the extensions being updated over SSL now, but for the most part, both of these are the "security and stability" update category. Someone reported the holes, and they responded by patching them.
Seems reasonable.
This morning I noticed that they had released another update to Cyberduck: 3.6.1. The 3.6 update was a few days ago, and I got it, but hadn't the time or inclination to write about it. It's now got a "nag tag" in the title bar, and while I don't begrudge anyone the ability to do what they want with their own code - especially if it's free, I do realize that I'm far happier with Transmit 4 given it's new design. It's all about file transfer, but I just enjoy the interface of Transmit 4 more.
So I got it, and then the 3.6.1 update as well, but I'm not sure I'm going to be doing a lot with them in the near-term future.
The last half of today I spent trying to figure out a really good way to incorporate a good, fast, caching scheme for these messages that are the heart of my ticker plant. The problem is that I know I'm going to be hammering the messages as fast as I can possibly take them, so a cache that locks is just right out. I wanted to make it simple as well - something parametric so it'd be easy to turn on or off and see what the difference in timing and throughput was.
The problem was, it wasn't really obvious how to do this with the given design I had.
I thought that it'd be best to put this into an existing class in the design - as low a level as possible. I was thinking maybe the component that handled simple message distribution to a list of registered listeners. It'd be nice there in that any component that "pushed" messages would be able to take advantage of this by simply "turning it on".
But there were a lot of conceptual problems. First, the messaging API used references for the messages, which is what I wanted to use, but that meant that in order to make the caching fit in without altering the API, I'd have to be making copies of the messages. That's not a good plan. Nothing good is going to come from copying a hundred thousand messages a second. That's a recipe for poor performance.
Next, if we changed the API to use pointers, and thought of the send() method as a "sink" of the message, then we'd have a nice, transparent, caching scheme, but the problem is that the messaging system relies on calling send() several times - once for each listener. This means I can't have the one method "eating" the instance as there'd be nothing left for the other listeners.
I messed around with this for a while, each time coming to the conclusion that the design I had wasn't really workable. I finally backed off and tried to think of the problem in vastly different terms.
What came to me was very simple, very clean, and in the end, far better than I'd ever have been able to do in the previous approaches.
I began to think of the cache as something of a component as opposed to a capability of the objects in the design. I started to look at the cache as something that I could put as an ivar in the few components that needed it, and make it self-contained and easy to integrate and use, and all of a sudden things started to really look up.
Now I didn't have to worry about the passing of references and how many times something is called. In anything that deals with messages, it's possible to have a cache, and that cache will "eat" messages created on the heap. It will either delete them right away (if it's inactive), or it'll save the latest, and delete the older version, so as to keep the most recent in memory and yet at the same time handle all the housekeeping for the memory management of the created messages.
Most of the components that need this caching are things that create messages. Maybe it's coming in from a serialized data stream. In that case, the created message needs to be passed to all the registered listeners, and then deleted - or cached. It's similar for different "translation components", but the model fits very well. So I started coding it up.
I didn't get finished, but it's well on it's way, and it appears to have beaten all the problems that were really dogging me with the other approaches. I know there's more to deal with - like the "fast" part, but I'll deal with that in the morning.
This morning I spent the entire morning messing with getting a new machine at The Shop working for me. I'd spent a little bit of last Friday making sure all the software I needed on it was installed, but that didn't prepare me for what I was to experience first hand with Windows 7.
Normally, I'm a live and let live kind of guy for work machines. It's what the company wanted to get, it's what tools the company has supplied, and so I make due with it because that's really the only possible outcome. If I dislike it that much, then it's my choice to leave and look for a place that provides the tools I like. I've turned down a lot of positions in the last decade for Windows development jobs - I just don't want to do it.
So today when I got the new machine - and by 'new' I mean 'different' with Windows 7 installed, I set about making it workable with the software and set-up I needed. A few things I couldn't have done remotely - like the virtual windows and such, but no matter, I had penciled in the morning for just such activities.
So I got the box, and while I'm not a great fan of the look and feel, I can see it's positives, and understand why they did it. But on the hardware that was provided, it was quite literally, a joke.
I am required to use NX Machine to get to my linux servers, and when I did that, I was stunned to see an 80-line Vim session take 2 seconds to redraw. The full screen was on the order of 10 sec. It was amazing... and totally unusable.
I tried all the things I could find on their web site - nothing to address the horrible slowness of the redrawing. Then someone pointed out a setting to skip DirectDraw on the refreshing. It seems it's the "budget" video card and Windows 7 that are at odds here. Had my machine had an accelerated video card, I'd have been fine. But with the hardware I had, I was forced to change the refresh method.
Thankfully, that worked. A little later the head of desktop support stopped by to ask how it was going. I had shared my problems with him earlier, and I was glad to see he was following up. We talked, and he pointed out that he turns off all the "new" Windows 7 features to get his box working quickly again.
Amazing... I go back to a Windows NT look-n-feel to get Windows 7 working OK. I'd have been better off sticking with XP! Really. The cost, and the time, and the now degraded UI... it's a joke. An honest to goodness joke. I don't expect the company to spring for all new hardware because of Windows 7, but they should have had a far more graceful degradation of performance so I could look like XP, and have the Windows 7 engine, as opposed to dropping all the way to NT.
But hey... I'm sure there's tons of people saying "Buy a $100 video card!", and they'd be right. For me. But for the hundreds of other machines? Now we're talking real money. Not so easy to say "Buy $30,000 in video cards so Windows 7 is nice!" But that's really what Microsoft is expecting you to do - invest in more hardware to get the user experience they ship out of the box.
This morning I finally finished up the client library I've been working on for a while. I finished up yesterday with it functional, but not the way I wanted it. I spent a little time this morning cleaning up the code - adding comments here and there, and clearing out the logging using only during the debugging phase.
Nothing very exciting so far...
Then I was beginning to think that I might be able to get the best of both worlds with the existing design. One of the problems with my one request - one socket is that we can possibly end up with a ton of sockets in use. We can also be spending a lot of time creating them, only to tear them down right away. Not as efficient as it could be.
Yet I didn't want to have the one bad apple problem, so I think I've got a nice idea that I'm going to be putting into the codebase this morning - pooling of sockets. It's a simple thing - have a list of "unused" socket connections, and when a request comes in, grab one from the list, or if there are non there, create one. Then, as you use it, great. Everything is isolated. Then, when you're done with it, return it to the pool, and it'll get re-used the next time someone needs one.
Very simple, but the socket stays open, all the resources stay allocated, and in general, we have the best of both worlds. Very nice. That's going to be my morning - pretty excited about it.
I've got an interesting problem that I sure wish I'd checking into the linux C libraries a lot more before getting too far into this, but so it goes... It's the old UUID problem. It's a 16-byte, unsigned number, but it's far too big to hold in one atomic data element, so it's often a union:
union UUID { uint8_t bytes[16]; uint16_t words[8]; uint64_t blocks[2]; };
but the problem with this union is that you can't do something like this:
UUID a; UUID b; a = b;
or:
UUID a; UUID b; // ... if (a = b) { // do something... }
C++ just doesn't allow for the default operator=() or operator==() overloading like it does the default constructor, the default (shallow) copy constructor, etc. You have to build these things into a class.
However, there is one nice thing that these unions allow: it's the un-biased use of the union as the start of it's member data. For example, if we have:
UUID a; // ... memcpy(&a, src, 16);
we can write the 16-bytes of data into the union's elements by simply referencing the UUID itself. This is not the case with a class. There's the vtable, and that ends up throwing off all the offsets for the ivar data.
But what can a guy do to get these methods on a union?
The Answer is really the anonymous union:
struct UUID { union { uint8_t bytes[16]; uint16_t words[8]; uint64_t blocks[2]; }; // the constructor/destructor set... UUID(); UUID( const UUID & anOther ); UUID & operator=()( UUID & anOther ); UUID & operator=()( const UUID & anOther ); // the equality/inequality operators... bool operator==( const UUID & anOther ) const; bool operator!=( const UUID & anOther ) const; bool operator<( const UUID & anOther ) const; bool operator>( const UUID & anOther ) const; bool operator<=( const UUID & anOther ) const; bool operator>=( const UUID & anOther ) const;
where I added in the inequality operators so the UUID could be used in a std::map as a key. The problem now is that I'd really love to have the following still work:
UUID a; // ... memcpy(&a, src, 16);
but it won't. I have to reference the first part of the data to get past the vtable, etc.
UUID a; // ... memcpy(&a.blocks[0], src, 16);
It's not horrible, but it's no better than really building a class. I got the syntax I wanted, but the consequences weren't without their costs. Kind of bumming to get it all going and then remember the vtable, but that's life.