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.
It has advanced, but remarkably, it's still rather stifled.
We're trying to advance it further. I know of only two companies that transmit the a/v in a stream over the internet so the stenographer can see the technology without having to resort to sat feeds and the like (and we're one of those companies)... and we're the only ones who have pushed things as far as we have. Frustratingly, we're just using pretty ordinary technologies to do what we do, but people think it's magic, and mistrust it. Our real innovation is to combine technologies in specific ways to make captioning less expensive, and easier to do.
But then again, how much money is to be had in this business, really? How viable is the future of broadcasting in general anymore? Stuff like Youtube might start to become the norm... and where will deaf folks be then?
Google is doing a lot to try and make captioning more viable, but it has a ways to go. And what they've done still won't really work for many things that the deaf would like to see in captioning... it also kind of throws away a lot of work that has already been done in the past.
And, honestly, I wonder about the future of videos once the FCC gets more control over internet content. Things might start to get really weird.
Fortunately, our company is already comfortable with working in a digital age. I'm not so sure a lot of the companies currently involved in broadcasting are. The world is going to look very different in about five years.
The broadcast industry needs a rebellion.
It's completely eaten up with proprietary this, and proprietary that. It needs a heavy dose of unencumbered standardization to fix its many ills.
This customer wants captions embedded in their proprietary QuickTime-encapsulated file. So, it looks like I'm going to have to learn how to deal with that API... which wouldn't be so bad, but there are like a million other proprietary pieces of crap out there.
And trying to get these things to work *together*... it's like herding cats.
heh, heard about that in the context viva / mtv over here in europe.
mtv, grown up in the eighties with conventional tv technology.
viva grown up in the 90ies, innovative, and open to new technology.
- Viva live ticker sms -> screen >1minute + SMS voting for the _next_ video
- MTV voting for the video for the next day, plus the SMS'es broadcasted the next day too.
- Viva NL having Cable head stations with programm gerenation, so _one_ part of a city could choose the videos they liked...
- MTV - whole everything
- Viva plus being a full robotted thing (after dropping viva2 which was pretty much independent loaded, so you could see some metal, goth and punk stuff... but not paying the bills...)
- mtv being random repeat with focus to the top 10
oh, forgot to mention... after MTV bought Viva, and wanted to make them move to berlin... the technological kernel made their own company:
(which pretty much is about generating tv content computer aided, like adding scrollbars with _instant_ live texts etc.)
Yeah... we're trying to do innovations that would lead to the possibility of doing live feeds like that, in a relatively simple fashion. But, again, we're busy herding cats.