(Heh. Post photos if it comes out well. That sounds cool.)
I used to do that job, sort of. I had pretty much no technical know-how. I knew how the program worked. Someone would tell me they had a problem. I'd take down the info, try to re-create the problem, find the programmer who handled that part of the program, show them the issue, ask what to do, reply to the customer. It was a system that could drive a lot of people crazy, but it worked for a number of reasons. 1. Only I bugged the programmers as opposed to customers. 2. The customers were English speakers and the programmers weren't. 3. Since most problems are recurring, once I'd dealt with it once, I would leave the programmers alone about that problem thereafter.
I did it as a student making about 1.5x minimum wage.
Just a thought.
Sorry, no cameras allowed there. But I'll tell you where to buy it. Look at the thread in your local Wal Mart supercenter. It should have something that's multi-colored. We are doing something for the seats in railroad cars, so commuters on the LIRR will not wear out the seats having sex. I did ask my rocket scientist relative about using some stuff on Mars proposals.
Where I am now, they have a whole department just for that.
My first job was like that. ahhh the good old days.
So they're penalizing the good guys.
The level of stupidity sometimes. These people should have their computers taken away from them.
A friend of mine told me a long time ago that your boss and coworkers don't want to hear "no" as an answer to a request to do something. It took me a while to completely understand what he was saying, but I do now and try to practice it when I can.
Instead of saying, "No, I can't do that," rather say that you can, but explain the consequences. For example, I maintain a number of automated test beds here at work. We have similar test beds at different sites around the world.
Every so often I get asked, "Why don't you maintain those test beds, too?" or "Could you take a look at this problem with this remote test bed?" My typical answer is, "Sure, I can take a look at that, but I only have remote access, so I'm limited in what I can do. It may take some extra time, and if it takes too much time, I'll need to clear it with my boss otherwise I may compromise my schedule." Usually, that will get the requestor to change their mind and retract their request.
Spell
do you run something like buildot and such?
What is buildot?
a typo.
its actualy buildbot
its python/twisted, and can run compiles & unit tests plus can be triggered by post commit hooks...
bart: I'll have to look into that. The systems I maintain are geared for functional, systems, and performance testing, not unit testing, but I know our developers are always looking for way to improve their unit testing.
Thanks!
Spell
its primarily for running stuff over and over and display a 'successfull executed' - or not and display that.
"The customer is reporting the box as dead on arrival. He can't start it up. I know you're taking vacation next week, so I need a set of instructions for making a new box."
Not likely. I can't remember how to build any of our boxes anymore. I fly by the seat of my pants, because our rate of change outstrips my ability to keep anything documented, or to prepare appropriate scripts for creating anything new.
I suggested he just replace the parts that are broken and leave the hard-drives alone.
As it would turn out, the box works okay... just wound up soldering some wires to the motherboard *shudder*.
Heh, not really.
I knew which pins to use for starting the thing up. I think something happened when my boss provisioned the box for shipment. The connector used by the wire used to work, but doesn't anymore for some weird reason. So, the customer took the connector off and just soldered the wires directly to the pins. Not the best solution, but if it gets it working...
Around 15+ years ago (it seems so much shorter and so much longer at the same time..) I worked for a company that was developing a videotext system.
In order to insert our VBI data we used a 1U sized device, forget who made it, which connected to a PC via a fat ribbon cable, actually I think several of them.. lots of pins. We had that device hooked up to a generic instrumentation I/O card which had enough inputs and outputs for us.. and then interrupt service routines to give this not-very-intelligent device all the attention it needed when it needed it. Took a lot of playing around to get it to work properly.
But apparently we could not use anything other than this relatively archaic device because it was the only one that broadcasters would trust inline with their broadcast video. Actually I can totally understand why they would be particular about that.