As virtually every good developer can attest, the first thing you do when stuck with a hard computer program is....
...Google for the answer!
I wonder if that violates the spirit of the competition?
Is this why proof-reading is so hard?
on
Can You Raed Tihs?
·
· Score: 1
The first line has an error. It reads "Aoccdrnig to a rscheearch". It should read "Aoccdrnig to rscheearch" - "rscheearch" is considered plural. Or perhaps they meant "Aoccdrnig to a rsearecher"...:)
I think this indicates why it is so hard for people to proofread documents - the typos barely affect comprehension so most people ignore them.
This is actually what the whole Wiki revolution is for. Wiki is an easy-to-use web-based collaboration system. It's been in use for years at a number of great sites.
One interesting site, Portland Pattern Repository, contains lots of pages that various programmers have put together to describe their experiences programming. For instance, you can find a lot of information about the Singleton Programming Pattern.
Another site that really shows the power of Wiki is Sensei's Library (a website for learning Go.)
So I would look through the available Wiki's and see if any match your intended audience. Then start creating your pages and go to town...
I'm moderately colorblind (y'all have WAY too many names for 'blue' - "purple", "mauve", "navy blue", etc.) I have even been known to take black and white photographs of fall foliage because I really can't see the subtle colors in the fall (yellow looks like green to me, red looks like brown).
I'm not sure that I have a good answer for the writer, but I have some suggestions:
1) Use icons to convey meaning, not just colors. So put up a triangle with an exclamation point instead of just writing text in red.
2) It really doesn't matter that we can see the colors, just that we can differentiate them! Most of us cheat by seeing contrast rather than hue - that is, if I see a dark purple and a light blue, I can see the difference between them easily. It's just when they have the same intensity that I get stuck.
3) we're pretty good at distinguishing a couple of colors - not so good with lots of them. So pick only a few colors - and change the intensity so they don't overlap.
4) Consider building a "simplified" UI (ie, a graphically minimal UI). In my experience, I can operate fine through a minimal UI - usually because the colors are reduced. And I never mind losing out on the "pretty" interface because I can't see the colors anyway.
5) Sometimes the ZOOM interface works wonders. If I can enlarge a picture 10x, I can usually see the subtle differences in the interface. It's just when they are really small and close together that I can't tell the difference.
Speaking as a manager, I think it's interesting that there's a large focus on the "fairness" of the schedule. In my experience, there are a lot more issues to be concerned about. In order, I think they are:
1) How responsive do you need to be? Generally the shortest time period you can rely on is 15-30 minutes - if you need faster responses, you better keep people on-site 24-7. But there's a big difference between being "on-call" with a response time of 2 hours versus being "on-call" with a response time of 15 minutes. With a 2 hour window, people can see a movie, go on a short trip, and generally have a normal life. With 15 minutes, the "on-call" period is really a "please stay at home" order. Generally, we've found that the more responsiveness you want, the shorter the on-call periods have to be.
2) Manageability of the rotation: On-call duty is a pain. People end up doing all sorts of things that cause management problems. Do you have a person who always seems unavailable - so you always end up calling the back-up? Did someone go off on a trip because they forgot they were on-call? Ultimately, someone will be responsible for the rotation and will need to call non-performers on the carpet. It's MUCH easier if you have a defined system, you know who is behaving well and who isn't, etc.
3) Predictablity of the rotation: Do you ever page the on-call person and they don't respond? Or they aren't sure they are on-call? In our shop, that was a sure sign that the on-call rotation wasn't working. Having a predictable schedule makes life much easier.
4) Fairness - everyone needs to share the burden equally. Sometimes you get certain people who are just better at dealing with crises, and some people who are just awful at it. (For example, we often had the case where person A could never solve the problem and we always had to call the backup.) You need to make sure that the schedule is fair - don't simply give the effective people more work and avoid the ineffective people. That rewards the wrong behavior.
5) Flexibility - flexibility comes at the end. Yes, people need to be able to trade shifts - but not if it breaks any of the above rules. For example, it's not efficient to allow people to trade "part of a shift" - you need to trade the whole shift or none.
So with those comments in mind, there are some helpful tips:
Test the on-call people - set up some kind of system where you can check whether people are available. (eg, send them a message that requires them to click on a URL or something)
Penalize severely for not being available (eg, if you're not available, the shift doesn't count, and you have to take one of the backup's shifts.)
If possible, have a physical token for the on-call person (eg, pass the pager around physically, etc.)
MAKE SURE THE PAGER GETS GOOD RECEPTION! There's nothing worse than the on-call person not being able to receive messages.
ALWAYS publish the on-call schedule in a well-known location. Make sure people who change their shifts mark it on the well-known schedule.
Try to publish the schedule at least a month in advance.
(Just a note on my background: I've been a programmer for 10+ years and a sysadmin for 4+ years. I've also managed software development teams and Operations (sysadmin) groups.)
Tip #1: Be aware that system administration and programming are different things. Understand the differences - in some cases, your sysadmin background will be invaluable. In other cases, your background will be useless. The rest of this comment is a description of some of the differences.
Tip #2: Software development is largely about solving business problems. While system administration is largely about keeping machines/networks/infrastructures running, programming is all about building a product for a customer (even if the "customer" is really an internal user and the "product" is just a program). Thus, when you switch over to programming, you focus on building what your [customers|users|product development team] wants. You need more people skils, more UI skills, more "analysis" skills.
Tip #3: Programming is different from "sysadmin scripting". Other posters have definitely mentioned this, but understand that programming is very different from scripting. Admittedly, some system administration scripting is really programming but most of it isn't. Some of the key differences:
Usually, you work on a component of a system. Thus, other people will use your work and may require a specific interface/design. You have to understand what the users of your program need it to do.
Programming usually requires more discipline. Your code may be reused in other systems - thus, it has to be more strict about checking for errors, needs to be error-free even when used differently than you imagined, needs to have some level of documentation, etc.
The design of the code matters - not just that it gets the right result.
The "process" matters a lot. People care whether you are writing code that meets the right requirements, whether it's testable, whether you're sticking to the schedule, etc.
There's a lot more - see some of the references below to read more on this subject.
Tip #4: Software development is a team-effort. You'll need to conform. Software development (in all but the smallest efforts) involves a team. Thus, you'll find:
Other people become dependent on what you write. If you're late or your code doesn't work (or there are bugs in it), it usually affects someone else - who usually gets upset.
You have to get along with the rest of the team - including accepting their design instead of yours, picking up work that other people haven't gotten to, etc.
You'll have deliver to a schedule, warn when you miss it, and sit in innumerable meetings to discuss whether everyone is going to make the schedule (hint: they aren't.:)
You'll have to conform: you'll need to use the same editor/development environment as everyone else. You'll need to conform to coding standards, etc.
Tip #5: Good system design/architecture skills are very different from system administration skills.
System design/architecture is complicated - and involves a completely different set of skills than system administration. Don't assume you can build systems just because you can administer them. Luckily, you don't need these skills when you begin - just be aware that system design is very different than programming.
Tip #6: Most programmers haven't a clue about system administration - use this to your advantage! I apologize to all the great programmers who I'm offending, but most programmers/architects tend to ignore the system administration issues surrounding a system. For example, do they have a rollout/rollback procedure for releasing components? Do they have an interface for stopping/restarting components - or do they just expect the sysadmins to 'know how to do it'? This is one area where
At the risk of disappointing you, here's what I think:
1) Try for a compromise solution - pick an open-source ticketing system which you can modify. Thus, your boss saves money because he's not buying a commerical product, and you can eventually customize the product.
This will work really well as long as you pick a good system - see item 2 for my favorite open source ticketing system.
It's an open-source Ticketing system that can run on MySql/Postgresql/etc. It has a nice web-based interface, and supports all the functions that you usually need with tickets (linked tickets, watchers, email support, attachments, etc.)
Lots of people have also written plugins for RT - you can pick your favorites, and also write your own. Hooking in the KMS sounds like a good example.
One key advantage with RT is that it stores its tickets in a database that can be easily reported on via any standard reporting tool. We always want some specialized reports from our ticketing tool (how long each operator took to answer tickets, how many tickets come from each account, what are the longest tickets to resolve, what's the mean time between open and resolve, etc.) Anyone who knows a little SQL can write all of these.
3) Get your requirements straight. Make sure you know what features you want out of a ticketing system - and then be sure to illustrate which ones Parature will not support. RT will almost certainly support anything you really need - and you can always add features if you really need them.
I'm also a consultant, working for a not-for-profit, and I added a specific contract clause allowing me to contribute to OSS.
The big code issue for my client was that they wanted explicit ownership of the code. They didn't want partial ownership, or to give me the rights to reuse the code, etc. I wanted the right to reuse what I developed elsewhere. We ended up compromising with a clause that allowed me to contribute any "fixes or improvements" to open source code back to the community. Interestingly, they were quite willing to accept this clause at contract time.
So I actually have an explicit contractual clause that allows me to contribute back. It makes me happy.:)
As an H&R horror story, I went to H&R Block when I was an independent software consultant. I specifically asked them to calculate my estimated quarterly tax forms for the next year.
The preparer created federal estimated forms but not the State ones, telling me that it wasn't necessary to file estimated quarterlies for the state. Cost me several thousands of dollars in penalties, and HR Block claimed they weren't responsible because they hadn't filled out those forms (which was the whole reason I had to pay penalties.)
We used Cricket at my old company - it was great. We essentially replaced MRTG with Cricket and it just rocked.
We ended up graphing all sorts of interesting stats (CPU time, disk access, network latency times, etc.).
One of the best things that Cricket gave us was the ability to see correlations between our webserver response times and various other stats. So, for instance, we found out that our webserver response times dropped at the same time that our NFS file system times dropped and our iostats on one box skyrocketed. A little investigation found the culprit that was flooding the network.
At our dotCom company, we bought EMC boxes and I was REALLY excited about the TimeFinder concept. But then I found out that it doesn't really find time, it just makes backups.
I had thought we had found the answer to getting a six-month project done in 3 months - use "TimeFinder" by EMC.:)
-Peter
And avoid any "interesting" homepage
on
The Tyranny of Email
·
· Score: 2, Funny
As another timesaver/productivity enhancement, I strongly recommend choosing either a "blank" homepage for your browser or a static "non-interesting" page.
I have Slashdot as my homepage and find that I stand a very strong chance of being distracted every time I open a new browser window!
In fact, I'm supposed to be browsing our Javadoc to find the name of a function right now - but instead I got suckered by yet another slashdot headline...:)
The dangers of extrapolation
on
The Big Rip
·
· Score: 4, Interesting
Mark Twain wrote on nearly this exact topic in 1883. He wrote a great essay on extrapolation , basing his conclusions on the fact that the Missippi between Cairo and New Orleans was shortening an average of a mile per year for the last two hundred years or so....
To quote: "Therefore, any calm person, who is not blind or idiotic, can see that in the Old Oolitic Silurian Period, just a million years ago next November, the Lower Mississippi River was upward of one million three hundred thousand miles long, and stuck out over the Gulf of Mexico like a fishing-rod. And by the same token any person can see that seven hundred and forty-two years from now the Lower Mississippi will be only a mile and three-quarters long, and Cairo and New Orleans will have joined their streets together, and be plodding comfortably along under a single mayor and a mutual board of aldermen. There is something fascinating about science. One gets such wholesale returns of conjecture out of such a trifling investment of fact."
-Peter
And then the lawsuit will come...
on
The Big Rip
·
· Score: 4, Funny
Hmmm... if I read this correctly, the universe will be "ripping" all the digital media in existence in about 22 billion years.
Sounds like it could be the target for a RIAA/DCMA lawsuit! "Your honor, we would like to sue the universe for clearly premeditated copyright violation."
According to the article, it appears that you look for buffer overflows, freeing memory early, and other memory issues.
What errors are currently hard to detect automatically but which you would really like to be able to find? What is the next category of errors that you're trying to detect with automatic code inspection?
To give you some ideas, what about:
"unrefactored" code - code which has a lot of duplication and should be cleaned up
"untested" code - code (or branches in the code) that are currently untested by unit tests?
"programmer intention" errors - code which doesn't do what the programmer intends
Imagine the fun of testing out EVERYWALL on some level to make sure that you don't walk through it.
Yeah, and imagine that all your co-workers shooting you at the same time! "Boy, Jim is an easy target today. It's like he's always running into walls!"
(On the other hand, if you do find a buggy wall, it would be "Hey! Where did he go?")
We used to do the same thing, but not because we wanted to. We routinely got notified by police officers who wanted to have our logs (for a particular user) handed over to them. At first, we asked about a warrant and got the following response (paraphrased):
"Look - if you make us get a warrant, we'll get one. But then we're not only going to ask for the logs, we'll actually seize the machines. We may to have take all your machines to be sure they don't have logs or other information on them. Do you really want to lose your servers? "
We ended up with a policy where we would release records to any law enforcement agent who could provide us with proof of their identity - because we didn't want our service to go down! Law enforcement folks have a lot of weight they can place on service providers in order to gain cooperation.
At the risk of being modded Off-Topic, I will also state that RequestTracker (a system that's currently being built by Aegis) is a great tool for tracking software bugs, issue tracking, trouble-ticketing, and general to-do list issues.
It rocks, it's free, and it does virtually everything that you need it to do without complexity!!!
I admit that I'm looking at this from a NY perspective but...
How do you lock the dang things? Can someone just hop on your Segway and drive off? Even if you lock it, can't someone (according to the article) "just lift it into a truck"? And if you got a bicycle lock, where would you attach it?
Considering that, in NYC, most delivery people carry heavy chains and locks and drive beat-up bikes so no one steals them, I can't imagine that the lifespan of a Segway on the New York City streets would be much more than 5 minutes.
"Hey, guys! Come down and see my cool Segway. Hey, where did it go??!!!"
Hmmm... so they send you to the trouble site in a Lear jet if a server goes beserk? Sounds like time for a clever bit of system administration scripting.
"Gosh, Boss, I have no idea why the servers in LA are down. Even rebooting doesn't seem to fix it. I guess I'll have to be flown out there - such a shame since it's 75 and sunny over there and we're buried in snow here."
$ cat/etc/init.d/tempcheck if (LA.server == true) {
if (CH.temperature < 15 || CH.expectedSnowFall > 10)
{
shutdown -halt now
} }
Slashdot Mirror
...Google for the answer!
I wonder if that violates the spirit of the competition?
The first line has an error. It reads "Aoccdrnig to a rscheearch". It should read "Aoccdrnig to rscheearch" - "rscheearch" is considered plural. Or perhaps they meant "Aoccdrnig to a rsearecher"... :)
I think this indicates why it is so hard for people to proofread documents - the typos barely affect comprehension so most people ignore them.
This is actually what the whole Wiki revolution is for. Wiki is an easy-to-use web-based collaboration system. It's been in use for years at a number of great sites.
One interesting site, Portland Pattern Repository, contains lots of pages that various programmers have put together to describe their experiences programming. For instance, you can find a lot of information about the Singleton Programming Pattern.
Another site that really shows the power of Wiki is Sensei's Library (a website for learning Go.)
So I would look through the available Wiki's and see if any match your intended audience. Then start creating your pages and go to town...
...and I bet this is one of those stupid "one save for the entire party" situations.
Can you imagine the pressure of being the person who has to roll the saving throw for the whole world?
-Peter
Step right up! Make your guess where the ill-fated
Mars Polar Lander ended up.
It's kinda like a scavenger hunt, but on another planet!
It makes perfect sense!
They claim not to have found Saddam and Osama because they're keeping the film secret to make a surprise ending for the video game!
"Want to know what really happened to Saddam and Osama? Buy the game and find out!"
[ I also hear there's going to be cheat codes that allow you to find the weapons of mass destruction on the final level.]
-Peter
"Commentsedness" - Sounds vaguely Gollum-like, I think. Visions of Gollum as a twisted jedi knight come to mind...
"We hates the dark side. Hates it!"
"No, we loves the dark side! We finds your lack of faith disturbing! "
I'm moderately colorblind (y'all have WAY too many names for 'blue' - "purple", "mauve", "navy blue", etc.) I have even been known to take black and white photographs of fall foliage because I really can't see the subtle colors in the fall (yellow looks like green to me, red looks like brown).
I'm not sure that I have a good answer for the writer, but I have some suggestions:
1) Use icons to convey meaning, not just colors. So put up a triangle with an exclamation point instead of just writing text in red.
2) It really doesn't matter that we can see the colors, just that we can differentiate them! Most of us cheat by seeing contrast rather than hue - that is, if I see a dark purple and a light blue, I can see the difference between them easily. It's just when they have the same intensity that I get stuck.
3) we're pretty good at distinguishing a couple of colors - not so good with lots of them. So pick only a few colors - and change the intensity so they don't overlap.
4) Consider building a "simplified" UI (ie, a graphically minimal UI). In my experience, I can operate fine through a minimal UI - usually because the colors are reduced. And I never mind losing out on the "pretty" interface because I can't see the colors anyway.
5) Sometimes the ZOOM interface works wonders. If I can enlarge a picture 10x, I can usually see the subtle differences in the interface. It's just when they are really small and close together that I can't tell the difference.
I hope this helps.
-Peter Hamlen
1) How responsive do you need to be? Generally the shortest time period you can rely on is 15-30 minutes - if you need faster responses, you better keep people on-site 24-7. But there's a big difference between being "on-call" with a response time of 2 hours versus being "on-call" with a response time of 15 minutes. With a 2 hour window, people can see a movie, go on a short trip, and generally have a normal life. With 15 minutes, the "on-call" period is really a "please stay at home" order.
Generally, we've found that the more responsiveness you want, the shorter the on-call periods have to be.
2) Manageability of the rotation: On-call duty is a pain. People end up doing all sorts of things that cause management problems. Do you have a person who always seems unavailable - so you always end up calling the back-up? Did someone go off on a trip because they forgot they were on-call?
Ultimately, someone will be responsible for the rotation and will need to call non-performers on the carpet. It's MUCH easier if you have a defined system, you know who is behaving well and who isn't, etc.
3) Predictablity of the rotation: Do you ever page the on-call person and they don't respond? Or they aren't sure they are on-call? In our shop, that was a sure sign that the on-call rotation wasn't working. Having a predictable schedule makes life much easier.
4) Fairness - everyone needs to share the burden equally. Sometimes you get certain people who are just better at dealing with crises, and some people who are just awful at it. (For example, we often had the case where person A could never solve the problem and we always had to call the backup.) You need to make sure that the schedule is fair - don't simply give the effective people more work and avoid the ineffective people. That rewards the wrong behavior.
5) Flexibility - flexibility comes at the end. Yes, people need to be able to trade shifts - but not if it breaks any of the above rules. For example, it's not efficient to allow people to trade "part of a shift" - you need to trade the whole shift or none.
So with those comments in mind, there are some helpful tips:
Tip #1: Be aware that system administration and programming are different things. Understand the differences - in some cases, your sysadmin background will be invaluable. In other cases, your background will be useless. The rest of this comment is a description of some of the differences.
Tip #2: Software development is largely about solving business problems.
While system administration is largely about keeping machines/networks/infrastructures running, programming is all about building a product for a customer (even if the "customer" is really an internal user and the "product" is just a program). Thus, when you switch over to programming, you focus on building what your [customers|users|product development team] wants. You need more people skils, more UI skills, more "analysis" skills.
Tip #3: Programming is different from "sysadmin scripting".
Other posters have definitely mentioned this, but understand that programming is very different from scripting. Admittedly, some system administration scripting is really programming but most of it isn't. Some of the key differences:
Tip #4: Software development is a team-effort. You'll need to conform.
Software development (in all but the smallest efforts) involves a team. Thus, you'll find:
Tip #5: Good system design/architecture skills are very different from system administration skills.
System design/architecture is complicated - and involves a completely different set of skills than system administration. Don't assume you can build systems just because you can administer them. Luckily, you don't need these skills when you begin - just be aware that system design is very different than programming.
Tip #6: Most programmers haven't a clue about system administration - use this to your advantage!
I apologize to all the great programmers who I'm offending, but most programmers/architects tend to ignore the system administration issues surrounding a system. For example, do they have a rollout/rollback procedure for releasing components? Do they have an interface for stopping/restarting components - or do they just expect the sysadmins to 'know how to do it'? This is one area where
Another brilliant use of sudo! Not only can it make your machines more secure, it can also make your sysadmins less vulnerable to RIAA!
-Peter
At the risk of disappointing you, here's what I think:
1) Try for a compromise solution - pick an open-source ticketing system which you can modify. Thus, your boss saves money because he's not buying a commerical product, and you can eventually customize the product.
This will work really well as long as you pick a good system - see item 2 for my favorite open source ticketing system.
2) Try RequestTracker - RequestTracker
It's an open-source Ticketing system that can run on MySql/Postgresql/etc. It has a nice web-based interface, and supports all the functions that you usually need with tickets (linked tickets, watchers, email support, attachments, etc.)
Lots of people have also written plugins for RT - you can pick your favorites, and also write your own. Hooking in the KMS sounds like a good example.
One key advantage with RT is that it stores its tickets in a database that can be easily reported on via any standard reporting tool. We always want some specialized reports from our ticketing tool (how long each operator took to answer tickets, how many tickets come from each account, what are the longest tickets to resolve, what's the mean time between open and resolve, etc.) Anyone who knows a little SQL can write all of these.
3) Get your requirements straight. Make sure you know what features you want out of a ticketing system - and then be sure to illustrate which ones Parature will not support. RT will almost certainly support anything you really need - and you can always add features if you really need them.
-Peter
I'm also a consultant, working for a not-for-profit, and I added a specific contract clause allowing me to contribute to OSS.
:)
The big code issue for my client was that they wanted explicit ownership of the code. They didn't want partial ownership, or to give me the rights to reuse the code, etc. I wanted the right to reuse what I developed elsewhere. We ended up compromising with a clause that allowed me to contribute any "fixes or improvements" to open source code back to the community. Interestingly, they were quite willing to accept this clause at contract time.
So I actually have an explicit contractual clause that allows me to contribute back. It makes me happy.
As an H&R horror story, I went to H&R Block when I was an independent software consultant. I specifically asked them to calculate my estimated quarterly tax forms for the next year.
The preparer created federal estimated forms but not the State ones, telling me that it wasn't necessary to file estimated quarterlies for the state. Cost me several thousands of dollars in penalties, and HR Block claimed they weren't responsible because they hadn't filled out those forms (which was the whole reason I had to pay penalties.)
So I got an accountant, and I'm much happier.
We used Cricket at my old company - it was great. We essentially replaced MRTG with Cricket and it just rocked.
We ended up graphing all sorts of interesting stats (CPU time, disk access, network latency times, etc.).
One of the best things that Cricket gave us was the ability to see correlations between our webserver response times and various other stats. So, for instance, we found out that our webserver response times dropped at the same time that our NFS file system times dropped and our iostats on one box skyrocketed. A little investigation found the culprit that was flooding the network.
I give Cricket a big thumbs up!
-Peter
At our dotCom company, we bought EMC boxes and I was REALLY excited about the TimeFinder concept. But then I found out that it doesn't really find time, it just makes backups.
:)
I had thought we had found the answer to getting a six-month project done in 3 months - use "TimeFinder" by EMC.
-Peter
As another timesaver/productivity enhancement, I strongly recommend choosing either a "blank" homepage for your browser or a static "non-interesting" page.
:)
I have Slashdot as my homepage and find that I stand a very strong chance of being distracted every time I open a new browser window!
In fact, I'm supposed to be browsing our Javadoc to find the name of a function right now - but instead I got suckered by yet another slashdot headline...
Mark Twain wrote on nearly this exact topic in 1883. He wrote a great essay on extrapolation , basing his conclusions on the fact that the Missippi between Cairo and New Orleans was shortening an average of a mile per year for the last two hundred years or so....
To quote:
"Therefore, any calm person, who is not blind or idiotic, can see that in the Old Oolitic Silurian Period, just a million years ago next November, the Lower Mississippi River was upward of one million three hundred thousand miles long, and stuck out over the Gulf of Mexico like a fishing-rod. And by the same token any person can see that seven hundred and forty-two years from now the Lower Mississippi will be only a mile and three-quarters long, and Cairo and New Orleans will have joined their streets together, and be plodding comfortably along under a single mayor and a mutual board of aldermen. There is something fascinating about science. One gets such wholesale returns of conjecture out of such a trifling investment of fact."
-Peter
Hmmm... if I read this correctly, the universe will be "ripping" all the digital media in existence in about 22 billion years.
Sounds like it could be the target for a RIAA/DCMA lawsuit! "Your honor, we would like to sue the universe for clearly premeditated copyright violation."
What errors are currently hard to detect automatically but which you would really like to be able to find?
What is the next category of errors that you're trying to detect with automatic code inspection?
To give you some ideas, what about:
Imagine the fun of testing out EVERYWALL on some level to make sure that you don't walk through it.
Yeah, and imagine that all your co-workers shooting you at the same time! "Boy, Jim is an easy target today. It's like he's always running into walls!"
(On the other hand, if you do find a buggy wall, it would be "Hey! Where did he go?")
We used to do the same thing, but not because we wanted to. We routinely got notified by police officers who wanted to have our logs (for a particular user) handed over to them. At first, we asked about a warrant and got the following response (paraphrased):
"Look - if you make us get a warrant, we'll get one. But then we're not only going to ask for the logs, we'll actually seize the machines. We may to have take all your machines to be sure they don't have logs or other information on them. Do you really want to lose your servers? "
We ended up with a policy where we would release records to any law enforcement agent who could provide us with proof of their identity - because we didn't want our service to go down! Law enforcement folks have a lot of weight they can place on service providers in order to gain cooperation.
At the risk of being modded Off-Topic, I will also state that RequestTracker (a system that's currently being built by Aegis) is a great tool for tracking software bugs, issue tracking, trouble-ticketing, and general to-do list issues.
It rocks, it's free, and it does virtually everything that you need it to do without complexity!!!
I admit that I'm looking at this from a NY perspective but...
How do you lock the dang things? Can someone just hop on your Segway and drive off? Even if you lock it, can't someone (according to the article) "just lift it into a truck"? And if you got a bicycle lock, where would you attach it?
Considering that, in NYC, most delivery people carry heavy chains and locks and drive beat-up bikes so no one steals them, I can't imagine that the lifespan of a Segway on the New York City streets would be much more than 5 minutes.
"Hey, guys! Come down and see my cool Segway. Hey, where did it go??!!!"
Hmmm... so they send you to the trouble site in a Lear jet if a server goes beserk? Sounds like time for a clever bit of system administration scripting.
/etc/init.d/tempcheck
"Gosh, Boss, I have no idea why the servers in LA are down. Even rebooting doesn't seem to fix it. I guess I'll have to be flown out there - such a shame since it's 75 and sunny over there and we're buried in snow here."
$ cat
if (LA.server == true)
{
if (CH.temperature < 15 || CH.expectedSnowFall > 10)
{
shutdown -halt now
}
}