So, for about three weeks I've had this damn song stuck in my head. I heard it on the radio and remembered the words to the chorus. I figured in this day and age I'd be able to find it again using google or one of those fancy searches we have these days. Nope.
Ok.. so now I'm thinking that I heard the words wrong.. as sometimes happens.. I'm going through every possible thing it could be and still No dice. Then, just as I'm about to leave to go to rehearsals, I hear it on the radio again. I quickly look it on on the radio station's recently played list (thank the internet for that one) and bingo.
The track is called "BIG CHANGE". Presumably it's in all caps because you need to yell it. !!!BIG CHANGE!!!. apparently it's coming. Who knew?
Tuesday, November 20, 2007
Sunday, November 18, 2007
"Goating" is evil
Goddam it. First thedailywtf and now Jeff. Nothing says "I am purile" more than goating.
For the uninitiated goating is the pulling of some prank on someone who has left their computer unattended without locking it. I used to see things like this when someone would forget to log-off their station when I was in university. If you did that in a public computer lab anyone could walk up and use your terminal logged in as you.
This was actually becoming something of a problem since, at least initially, there weren't that many terminal available. If someone forgot to log-off, the screen saver would quickly kick in and then you couldn't log off someone until the full timeout which was something fairly large. When the labs were really busy it we often asked an admin to kill their ghost session.
For a while there was much pranking but it became clear that many people took this sort of thing extremely personally and so I, and a few others, started to log off people who left there terminal unattended before anyone else could get at them occasionally sending an email off to them mentioning that they forgot to logout and this was a bad idea etc.. This played out well because one time, I don't know what I was thinking, but I neglected to log out and was saved by one of the people I had helped earlier.
I am against pranking for multiple reasons.
The first is it's a big waste of time. Some of these pranks are elaborate and take time to undo. That's wasted time. I dislike spending 45 seconds at a traffic like I dislike people spending 5 minutes screwing with my setting and another 5 me tracking them down and fixing them.
The second is it can alienate those with different cultures, backgrounds or mindsets. If you're doing this sort of thing with a close knit group of friends that's fine. They've all agreed to it. Dragging arbitrary people into it can hurt feelings and breed distrust and bad blood amongst the team.
The third is it's absurdly unprofessional.
There's also this notion that Jeff mentioned that this sort of prank is pulled for someone's good. I'd believe that if those doing the pranks didn't have so much fun doing them.
Many places don't need this sort of security policy anyway. It's just creating stress and conflict where it's not needed.
RE: http://www.codinghorror.com/blog/archives/000997.html
For the uninitiated goating is the pulling of some prank on someone who has left their computer unattended without locking it. I used to see things like this when someone would forget to log-off their station when I was in university. If you did that in a public computer lab anyone could walk up and use your terminal logged in as you.
This was actually becoming something of a problem since, at least initially, there weren't that many terminal available. If someone forgot to log-off, the screen saver would quickly kick in and then you couldn't log off someone until the full timeout which was something fairly large. When the labs were really busy it we often asked an admin to kill their ghost session.
For a while there was much pranking but it became clear that many people took this sort of thing extremely personally and so I, and a few others, started to log off people who left there terminal unattended before anyone else could get at them occasionally sending an email off to them mentioning that they forgot to logout and this was a bad idea etc.. This played out well because one time, I don't know what I was thinking, but I neglected to log out and was saved by one of the people I had helped earlier.
I am against pranking for multiple reasons.
The first is it's a big waste of time. Some of these pranks are elaborate and take time to undo. That's wasted time. I dislike spending 45 seconds at a traffic like I dislike people spending 5 minutes screwing with my setting and another 5 me tracking them down and fixing them.
The second is it can alienate those with different cultures, backgrounds or mindsets. If you're doing this sort of thing with a close knit group of friends that's fine. They've all agreed to it. Dragging arbitrary people into it can hurt feelings and breed distrust and bad blood amongst the team.
The third is it's absurdly unprofessional.
There's also this notion that Jeff mentioned that this sort of prank is pulled for someone's good. I'd believe that if those doing the pranks didn't have so much fun doing them.
Many places don't need this sort of security policy anyway. It's just creating stress and conflict where it's not needed.
RE: http://www.codinghorror.com/blog/archives/000997.html
Sunday, November 11, 2007
Exponents, ram, 64-bits...
Ok, I really should be doing something else but I'm going to take a moment to give my two cents on this topic:
http://www.codinghorror.com/blog/archives/000994.html
In it Jeff Atwood ponders the move to 64-bits. Apparently he's a bit surprised at the speed at which the 32-bit addressing limit is becoming a problem. Actually I'm surprised it hasn't become a problem sooner.
I seem to remember, back in the old days, when I first started computing, machines came with 4 megs o ram. This was a mac, BTW. Macs were used quite allot for Photoshop and Photoshop demanded stupid amounts of RAM.. I mean you could have 32 or 64 megs of RAM and it still wouldn't be enough.. OMG!
The reason I mention this is because what an average PC user is running is very tiny compared to what people who actually use their machines for RAM intensive things use.
Currently I work on an image viewer program called InteleViewer. The thing is our image viewer likes RAM. I mean, we're viewing large images and we have to remain responsive while downloading the JPEG versions of several thousands images and decompressing them and witting them to disk... oh and did I mention we're using Java.
Yeah, yeah.. Believe me it is possible. What's crazy is we can do this with as little as 200 megs of RAM. It's not super speedy but it's usable.
At any rate, the doctors using our product like speed and will purchase anything to make it faster. Naturally, if they buy a workstation, one of the cheapest upgrades they can do is to buy more RAM. The more RAM then less hard drive swapping our viewer needs to do. Oh!. and if you want to view the stack of images in 3-D you better have enough RAM to fit the whole thing in RAM because we can't do much in the way of swapping when you can be looking at the stack of pixels from any angle.
RAM good. InteleViewer want more RAM!
We started to bump up against this RAM limit thing a while ago.. about the same time Apple was shifting to 64-bits. I can't remember what state we're in when it comes to the java virtual machine but the situation with window vis-a-vis 64 bits is shockingly ridiculous.
A 64-bit OS should not treated as some sort of pro feature. During a transition you want to minimize the pain. 64-bit OSes is a problem, a bug not a *&%$ feature upgrade.
Microsoft's attempt to split their 64-bit OS from their 32-bit OS has probably made the transition more difficult because with fewer 64-bit OSes floating around there's less incentive to make better, more mature drivers.
I'm an extremely gunshy when it comes upgrading so my tendency is to wait quite a long time because getting the new OS. I've only recently upgraded to XP from Windows 2000. I'm a bit cheesed that I'm not going to be able to run yesterday's OS with lots of memory because the transition only became really feasible recently.
At any rat, I'm going to stick with windows XP and 32-bit drivers for as long as I can. Not only does the old stuff tend to be more stable but it also runs faster and uses less of my system resources, which make everything else run faster too. From experience I've found that my idea of "speedy" and "stable" is a bit higher then the average bleeding edger...
http://www.codinghorror.com/blog/archives/000994.html
In it Jeff Atwood ponders the move to 64-bits. Apparently he's a bit surprised at the speed at which the 32-bit addressing limit is becoming a problem. Actually I'm surprised it hasn't become a problem sooner.
I seem to remember, back in the old days, when I first started computing, machines came with 4 megs o ram. This was a mac, BTW. Macs were used quite allot for Photoshop and Photoshop demanded stupid amounts of RAM.. I mean you could have 32 or 64 megs of RAM and it still wouldn't be enough.. OMG!
The reason I mention this is because what an average PC user is running is very tiny compared to what people who actually use their machines for RAM intensive things use.
Currently I work on an image viewer program called InteleViewer. The thing is our image viewer likes RAM. I mean, we're viewing large images and we have to remain responsive while downloading the JPEG versions of several thousands images and decompressing them and witting them to disk... oh and did I mention we're using Java.
Yeah, yeah.. Believe me it is possible. What's crazy is we can do this with as little as 200 megs of RAM. It's not super speedy but it's usable.
At any rate, the doctors using our product like speed and will purchase anything to make it faster. Naturally, if they buy a workstation, one of the cheapest upgrades they can do is to buy more RAM. The more RAM then less hard drive swapping our viewer needs to do. Oh!. and if you want to view the stack of images in 3-D you better have enough RAM to fit the whole thing in RAM because we can't do much in the way of swapping when you can be looking at the stack of pixels from any angle.
RAM good. InteleViewer want more RAM!
We started to bump up against this RAM limit thing a while ago.. about the same time Apple was shifting to 64-bits. I can't remember what state we're in when it comes to the java virtual machine but the situation with window vis-a-vis 64 bits is shockingly ridiculous.
A 64-bit OS should not treated as some sort of pro feature. During a transition you want to minimize the pain. 64-bit OSes is a problem, a bug not a *&%$ feature upgrade.
Microsoft's attempt to split their 64-bit OS from their 32-bit OS has probably made the transition more difficult because with fewer 64-bit OSes floating around there's less incentive to make better, more mature drivers.
I'm an extremely gunshy when it comes upgrading so my tendency is to wait quite a long time because getting the new OS. I've only recently upgraded to XP from Windows 2000. I'm a bit cheesed that I'm not going to be able to run yesterday's OS with lots of memory because the transition only became really feasible recently.
At any rat, I'm going to stick with windows XP and 32-bit drivers for as long as I can. Not only does the old stuff tend to be more stable but it also runs faster and uses less of my system resources, which make everything else run faster too. From experience I've found that my idea of "speedy" and "stable" is a bit higher then the average bleeding edger...
Frustrations, theater etc..
Between rehearsing for the new play I'm in, work and the usual madness of everyday life I've not really had an opportunity to compose anything of note for this space.
That said, I do have a large article (and I mean embarrassingly large article) which goes into how to document code in an effective way. I wrote it because I kept having deja-vu when it came to code comments. The things I wanted to know weren't there and what was commented was completely obvious. I was also getting the vibe from many on the team that code commenting was completely pointless, which was quite obviously bogus since Sun has managed to provide some very decent java doc comments for their code. What I have done is kept track of which things I want to know when I approach new code and put them all into a large document in a check-list sort of form.
The document became rather large when I realized that many of the items in the list only really made sense if you knew how to write good code. As a result I needed to explain how to write the piece of code in a format that doesn't require code comments before getting into what to comment. In fact, many of the items in the list can be thought of as warnings of the form: "Watch out! This code is not written how you think!".
In the end the guide is as much about how to code well as it is about how to document well. It's quite a nice read.
Anyways, that will be coming up as soon as I can figure out how to translate the behemoth into blog form.
Ok, gotta get back to learning my lines. See ya.
That said, I do have a large article (and I mean embarrassingly large article) which goes into how to document code in an effective way. I wrote it because I kept having deja-vu when it came to code comments. The things I wanted to know weren't there and what was commented was completely obvious. I was also getting the vibe from many on the team that code commenting was completely pointless, which was quite obviously bogus since Sun has managed to provide some very decent java doc comments for their code. What I have done is kept track of which things I want to know when I approach new code and put them all into a large document in a check-list sort of form.
The document became rather large when I realized that many of the items in the list only really made sense if you knew how to write good code. As a result I needed to explain how to write the piece of code in a format that doesn't require code comments before getting into what to comment. In fact, many of the items in the list can be thought of as warnings of the form: "Watch out! This code is not written how you think!".
In the end the guide is as much about how to code well as it is about how to document well. It's quite a nice read.
Anyways, that will be coming up as soon as I can figure out how to translate the behemoth into blog form.
Ok, gotta get back to learning my lines. See ya.
Subscribe to:
Posts (Atom)