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.
jock, what are you talking about ever?
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.
do you run something like buildot and such?
What is buildot?
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.
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.
We interface with any of a number of devices collectively called 'encoders' (a great name, incidentally, when damn near anything could be an encoder... so sometimes people get more specific by calling them something like a line21 encoder, or a caption encoder).
Generally-speaking, encoders understand a series of commands that allow you to block upstream captioning, insert your own captioning, or enable upstream captioning. The language has, over the years, mostly standardized along a specific series of commands, but one or two of them are still rather different, like this horrible series of encoders:
I guess, because the FCC mandates closed captioning in broadcasts, a few companies decided to make something that wasn't quite as frankensteinish as what you described. Also, most of the time, you have people dialing a phone into one of these things to do the captioning, so something like that won't quite fly.