Yesterday was a hectic morning and I had no time to get to the Firefox web site to get the released Firefox 3.0 - but I was able to get it this morning. With 3.1 already in the works, I don't expect the Firefox team to have much of a break, but that's the life of a browser developer these days. Seems it's faster, better, faster, better... a never-ending cycle.
Glad they are doing it. Get Firefox 3.0 - you'll be glad you did.
This morning I got news that one of my cron jobs was behaving badly - and by badly I mean very badly. The script was built to clear out the logs of some very verbose processes that are really not very necessary to monitor, but if they get too big and can't be written to, will crash the processes. And those processes are important.
The problem was that when running the script I made the assumption that I was in the directory I was in when I ran it manually. This was a big mistake and all the scripts I typically create have at the top:
# # Now let's get right into it... # program=`basename $0` dir=`dirname $0` cd $dir echo 'Running '${program}' from '${dir}
so that we get into the directory of the script and then all the moves are relative to that directory. The problem was that this was clearing log files but the names of the log files weren't specific. This means that without this code, the directories I tried to clear weren't there, and then without sufficient checks to make sure they were there, I started clearing out all the files from the $HOME. Not good.
Thankfully, we have .snapshots of all the directories so that everything I cleared out was easily restored. But I needed to fix things so it didn't happen next week. In addition to the code (above) I also added in checking code for each directory so that I know the directory exists and don't get into the situation where I think I cd somewhere, and don't really move at all.
It was funny, in a way. It's been a very long time - about 15 years, the last time I remember making a script that wiped out data accidentally. Then, too, I was able to get it back from backups, but it was still a shock those first twenty seconds when it was gone and there was no 'undo' to easily bring it back. Everyone makes mistakes, me too. Live, learn, and code better next time.
I was talking to an old friend this weekend - it had been ages since we talked and we spent a lot of time on the phone getting each other up to date on what's been happening lately with the families, etc. It's fun to play catch-up with an old friend as they know a lot of the old jokes, but a lot of the neat, new stories are new to them, and it's always fun to tell stories about the kids.
Anyway... after a while we got to talking about work, and he has been going through a really tough patch at work where the place is not doing well, and the morale and attitudes of nearly everyone there is really taking a beating. People are slacking off, not doing their best - and the work shows. But I know my friend, and that's not like him - nor is quitting as he's big into the loyalty, commitment, etc. But he had a recent story to tell that even made me cringe.
He's been doing all that's asked of him for years, and recently, because this other group of developers is really not pulling their weight (I'd say they were lazy and inept, but he's nicer than that) he's been asked to do a little of their work because they are too busy with other things. Well... he does it. In my experience, it's worth lodging a complaint - respectfully, to let your manager know that this is not 'ordinary' - no more so than them asking you to be a janitor or security guard, and even though "The Team" needs you to do this, will the "Team" be there when you need them? Not bloody likely, which is my point about lodging the complaint - respectfully. But I digress.
He's been forced to do this work of the others and even on occasion told to get it done by deadlines when the principals are out of the office. It's like "Hurry up and get this done for Steve by Friday" and then Steve takes Thursday and Friday off. Why the rush, if they aren't going to be in the office? It seems reasonable that if the work needs to be done that fast, that he'd be in the office. But maybe it doesn't need to be done that fast, it's just the manager's way of trying to suck up to the guy.
This is why I really don't like these kind of 'rush' jobs - many times they really aren't a 'rush', they are just a rush from the point of view of the manager looking for some brownie points with their management. Which, again, is the reason I always try to make a respectful point of properly setting expectations.
In the end, my friend is unhappy, but he's resigned himself to the fact that this is the job. Much like any relationship, it takes work, and it's a given-and-take with a natural ebb-and-flow that means that sometimes it's not a lot of fun, and sometimes it is. I can certainly understand his point - having been married more than two decades, but there can come a point when a job - or an relationship, for that matter, is destructive for one or both parties. There are tons of times when people aren't fitting in at a job and are 'let go', or 'right-sized', but the other side of this same relationship happens as well. Jobs and managers can get overly oppressive, thankless, demanding, and in general, one-way. When that happens, it's time to step back and realize that there are times to sit out the ebb and flow, and yet there are times when it's really best to step away and decide if it's really a good idea to stay in the relationship.
I'm not going to tell him to get another job, I respect him too much. I know he's a good guy and when it's the right time to make a move - or re-set expectations, he's going to do the right thing. But it's hard to see a friend having this much trouble, when he's such a nice guy. Sigh.
Nice to see that the auto-updating of Firefox 3.0 is working, and that the Team has released RC3. It's getting better and better, with fewer issues on Windows, and stellar performance on my Macs and Linux. I'm guessing we're getting close to the final release as it's June, but no idea when the final release will be delivered. Great work.
UPDATE: this news story puts the release of 3.0 on this coming Tuesday, June 17th. Looks like it's only a few days away. Nice! Looks like it'll be official in just a few days.
Over the past two days I've been forced back into a project that I have been out of for a very long time. There's a need to get something done quickly, fixing a long lost (and wished forgotten) developer's code, and so I get pressed into this. Whatever... it's not what I wanted to do, and I stated that I was probably not the right guy for the task, but was forced into it anyway.
When I originally started this project - Oh so many years ago, my partner and I decided to make it cross-platform: Windows and Linux, IE and Firefox, because you never knew, and maybe someday we'd move to Firefox. So we made it that way. Things progressed, he left, another guy came, I gave the project to him, and I moved on.
Now I'm back, and I'm very surprised at what I'm seeing. Gone is the cross-platform capabilities - it's IE only now, Baby! It's not that hard to make it cross-platform, it just takes a little bit of effort. Why they didn't put this in, I can only guess - like most people, they all are looking for the easy way out. Since they don't have any users running Firefox now, they don't need to worry about it, so don't even spend a second thinking about it.
Problem is, it only takes a few minutes to get things so they work on both platforms. It's not that hard. I had to change a little Javascript to get the applet tags written out properly. I added a little compressed string code to the applet writer to make it faster to download and pretty much bing! it's done. Not that much to it. But you'd have thought it was weeks of work that just weren't worth it.
It's always worth it. Forget that someday you might actually need it, there's value in making something a little more generic than you need. Just in case you want to see if it's the platform or your stuff. Isolate the problem or variable. Easy. But I guess they are so wrapped up in IE they don't even care to look outside that box. I understand the logic, I'm just disappointed.
It's like the line out of Illusions by Richard Bach - Argue for your limitations and sure enough, they're yours. It's as if they wanted to make the system less capable. They aren't bad people, just not really making any effort to see beyond their immediate horizons. It's a waste.
I'll finish this page and then bow out and hopefully not have to deal with it for another several years. It's just not fun to come back to a system you had pleasant memories of to see it's all decayed and in need of repair. Sad.
Today, while doing a little work on a web page, I ran into a bug in the Sun Java plug-in for Firefox on Linux that I've known about for quite a while. Basically, if there is a very long PARAM tag on the applet, the plug-in gets stuck in the read loop parsing the data. The Firefox developers have confirmed this - saying it's not in their hands. It doesn't appear on Windows - only Linux. Sad, but true.
Anyway, I was thinking that maybe it was just the length of the tag, and a way to make it shorter would be to compress it and then decompress it in the applet. Since I've got a BKCompressedString from previous XML work (large XML files compress very nicely) I decided to add this to the web system to see if it would buy me enough headroom to get the job done I needed done.
The tricky part was that I needed to have something that could pass through HTML, so after compressing, I had to Base64 encode it, and then decode it, decompress it in the applet. Not a problem. In keeping with the other serialization methods I've put in BKit and CKit, it was easy to put in the serialization scheme on the BKCompressedString and it should work.
Almost.
OK, not even close.
The compression and decompression was lossless. The Base64 encoding and decoding was lossy depending on the data you were giving it. I spent a lot of time working through the bits trying to figure out what the problem was only to be bitten by this lovely little Java byte primitive feature.
If I have the code:
// mask these into the four 6-bit chunks dest1 = (byte) (src1 >>> 2); dest2 = (byte) (((src1 & 0x3) << 4) | (src2 >>> 4)); dest3 = (byte) (((src2 & 0xf) << 2) | (src3 >>> 6)); dest4 = (byte) (src3 & 0x3f);
and the variables dest1, src1, etc. are byte values, then one would think that the right shifting in the middle lines would obey the logic that an 8-bit value (a byte) would. What I found out was that based on the data I was converting, the byte values either weren't actually only 8 bits, or the shifting was adding in a little something special - because there were ones getting put in the shifted bits where, logically, nothing should be.
When I changed the code to look like:
// mask these into the four 6-bit chunks dest1 = (byte) ((src1 & 0xfc) >>> 2); dest2 = (byte) (((src1 & 0x3) << 4) | ((src2 & 0xf0) >>> 4)); dest3 = (byte) (((src2 & 0xf) << 2) | ((src3 & 0xc0) >>> 6)); dest4 = (byte) (src3 & 0x3f);
then everything worked fine and the encoding was lossless as well and then the compression followed by the encoding and decoding and decompression was lossless.
It took me the better part of 3 hours to figure this out. I was stunned when it finally presented itself, as I initially thought that the bit-wise operations on byte quantities were flawless. I know better now.
I've been working pretty feverishly the last several days on getting my market data server updated with a new API from one of my data vendors. It's been a significant update because of the fact that in this new API they have implemented (and forced us to enforce) login validation and data permissioning. I don't begrudge them the validation and permissioning because it's their bread-and-butter, and it's up to us to decide if it's too much to deal with, but it's the way in which they are doing it that's a real pain.
Based on experience, exchanges charge fees to see their data. Seems reasonable. But they don't really care if you see 1 instrument's price 1000 times in a day, or 1000 instrument's price 1 times a day - or even if you only see 1 instrument's price 1 time a day - it's still the same price. So the permissioning for standard exchange fee-liability is by exchange. Very reasonable.
Given this, we should be able to have a list of valid exchanges for an individual user and then check each instrument for it's exchange and be done. It would mean that we'd have on the order of a few dozen exchanges per user - a very manageable set. But this vendor isn't like that - they want to be able to know exactly what instruments you're asking for, so you have to permission the data at the instrument level. This, too, isn't horrible, but it does mean that instead of having a few dozen things to track for a user, you now have upwards of a few hundred or more. It's still possible, just a lot more work to do with each request.
Then there's the way they do the permissioining... a user has a list of entitlements, and each instrument has a list of entitlements and we need to find a common entitlement between them for the user to see the instrument's data. Why not have a single ID for a user - or an instrument? Why have lists? I'm sure you can have the degenerative case of one item in a list, but from the looks of things, that's not the way it's going. Just really odd. Not impossible to work with, but odd.
So it feels good to be out from under that weight. It's all working, and we'll be able to move to the verification phase with the vendor (certainly understandable) and then on to the roll-out to production.
This morning's WWDC Keynote by Steve was nice, but everything there was leaked with such high reliability that there was nothing - literally nothing that wasn't on the rumor site's round-up of rumors for the keynote. Steve even passed on saying anything about Snow Leopard in the keynote, referring to another speaker after the lunch break. Not too surprising, because it's not going to have wild new features, but still... unusual for Steve to have nothing up his sleeve.
iPhone 3G was expected... Mobile Me was expected... iPhone 2.0 apps was expected... that's about all he talked about. I was a little disappointed that they spent a good 45 mins talking and demoing apps for the iPhone. Leave that for the show floor, guys. Spend 10 mins on that and then the other 35 on Snow Leopard, or something else. I understand why - he wants to generate a lot of buzz and therefore a lot of sales, and this is a good way to do it.
So it was something I glad I kept an eye on, but nothing I saw or heard is making my buy anything in the near future.
This morning I found an old co-worker on chat - Pete E. Pete used to work right next to me but then moved to another division and then to another Bank. Now he's in the middle of a six-month stint in Singapore for Morgan-Stanley. Amazing. I haven't talked to Pete in at least 3 years. We spent a little time catching up and I really liked finding out what he's doing and where he hopes it's taking him. Computers and the 'net really are making communication so effortless that the world has changed, and I was in the middle of it and didn't see it really close-up until today. Wow.
I was talking to a friend today that is looking for a new position. He's interviewing at a place that uses online tests as a measure of the skill of a developer. Problem is, he and I know that the ability for an online test to predict your ability to program is virtually zero. He likened it to having an online test for tending a garden.
Oh, he'll take the test, but the fact is that he's probably not going to perform on the test to the same level that he can perform in person. It's an entirely different kind of knowledge. That's not to say that online testing can't be done well, but it can't give you a good measure of a large spectrum of individuals. Even the best tests can't do that if they don't have some real human being interpreting the results. Multiple-choice tests are only able to really discriminate a very narrow band of skills.
For example, if you have a simple test - like a driver's license exam. That's good because it's measuring a minimum level of competency. You aren't called upon to make judgement calls in these tests (like you are in real driving) - that's left for the driving part of the exam. But it does register well your level of basic understanding of the laws governing the use of an automobile.
But let's see if that works for programmers.
Can you generate any multiple-choice exam question that can even remotely test a person's ability to 'use' a language? You can test if they can spot a syntax error... or what the result would be if this code was executed... or even what would be the proper form of a certain statement. But you can't really tell if they will be a good developer.
Mastery of the basics of the language is possible - do you know what the basic data types are, that kind of stuff. But what happens if a person hasn't used a certain class library - or a certain feature? Is it essential to mastery of a language to use every feature? I can't think of a language outside of assembly that I've used every feature of. Nor do I think that many really can. Maybe a compiler write could, but then that's all they are writing - tools that turn code into machine instructions.
But you can't really tell if one developer is going to be faster at implementing new features or bug fixes than another. Or if the designs one guy will create are going to have longer staying power than those of another person. Yet these are the essential questions of a developer's worth. How quickly can they add features and fix problems? How does their design stand up to the test of time? Knowing that they know the difference between an STL set and vector is not nearly as important.
Yet that's the only thing these online tests can really point out.
I would like to see more employers asking for code samples. The problem there is that almost every company I know of late would not want even one coding example shown to a potential competitor for fear of losing the 'edge' they felt they maintained. Artists of all kinds do this every day - it's their portfolio. I'd like to see developers build a portfolio as well. Show it to someone - if they are in the business of writing code it's not going to take them 15 mins to see if the code you've written is good, fair, or poor.
Do you have comments? Is there a basic style to the code? How are errors and exceptions dealt with? What level(s) do you take with each of these? It's all there in black and white if you look at the code. Even moderate to bad coders will be able to recognize good code.
I'm sure my friend will do fine. I've known him for more than twenty years and he's a good coder. If the test is even close to measuring what it claims to measure, then he's going to do fine. It's just interesting that as two ex-teachers with a lot of love for a good test, that we got to talking about this upcoming test of his today. Good tests are hard to write and even harder to grade. Anything online and multiple-choice is dodgey at best.