Seeking help from Washington friends (local to Seattle-ish area)

I have a University of Washington interview at 10:00am on the 8th. Is there anyone out there who can lend a weirdo crash space for the night? It's that, or a motel, or getting on the road at 5:00am for the interview.

Sleeping conditions don't matter as much as you might think; remember, I'm trying to avoid getting up at 4:00am and then driving for four to five hours. If your house is a bit noisy, or chaotic, well, it's not up against stiff competition in the nighttime comfort arena :-). Also, I have an air mattress (queen sized, be warned) if you don't have a couch or spare be, but do have space.

We can arrange payment however you like, but I expect to give *something* in return, even if it's candlemaking, food prep, or somesuch.

Seeking help from Washington friends (local to Seattle-ish area)

I have a University of Washington interview at 10:00am on the 8th. Is there anyone out there who can lend a weirdo crash space for the night? It's that, or a motel, or getting on the road at 5:00am for the interview.

Sleeping conditions don't matter as much as you might think; remember, I'm trying to avoid getting up at 4:00am and then driving for four to five hours. If your house is a bit noisy, or chaotic, well, it's not up against stiff competition in the nighttime comfort arena :-). Also, I have an air mattress (queen sized, be warned) if you don't have a couch or spare be, but do have space.

We can arrange payment however you like, but I expect to give *something* in return, even if it's candlemaking, food prep, or somesuch.

The problem...

So... you want to be able to tell any one of four encoding machines to start a job, and stop it at the right time, with minimal human intervention (but it must *allow* for human intervention!). Three of them have 2 encoder cards; one has only one.

How do you do it?

I thought I had a decent solution.

A machine (one of the four, or another) runs a scheduler. At some time (I chose 30 minutes) prior to a job needing to be started, it would search through its stable of directories - directories? Why directories?

Because we can have seven directories, one for encoder 1, card 1, one for encoder 1 card 2, etc., through encoder 4 card 1. And we can look at a directory and see if there's a "lock" file in there indicating that the card is busy.

So, it would choose a valid directory, and create a lock file in the directory; the lock file contains the start time, the end time, and the file-to-be-recorded name. Five minutes before the show starts, start the capture, and grab the process ID, and rename the file to include the process ID number. (See, that way if you have to kill the process manually, you know which to kill - there might be two recordings running on the same machine).

When the end time rolls around, stop the recording using that process ID you grabbed earlier, move the file to where ever you want it, and then erase the lock file. Bam, you're ready for the next recording. If the automated process fails, a person coming in has all the info they need contained in the lock file, and the scheduler won't send another job because the lock file blocks it.

The scheduler uses the filename to index the recording jobs (pick good file names, and you'll know exactly what each recording is for). Store the schedule in a flat text file; archive the completed jobs in another flat text file.

I thought it was pretty neat; you can schedule a recording for whenever, you can have it stop automatically, or, with minimal effort, change the stop time or set it not to stop (by setting the end time far in the future). I had a heartbeat file to verify the jobs were all running (each time they did their checks, they also changed the date of their heartbeat file), and had alerts set up for when something reasonably went wrong.

My supervisor didn't like this solution. We were going to go in another direction. He'd told me this.

Okay, and the plan for going forward was written down where?

Well... the plan was *told* to me.

So, we don't know what, exactly, he asked for. We only know that what I came up with was something that, he was *sure*, was counter to what he'd asked for. Which wasn't written down, so we can't even tell if he didn't say what he wanted, if I misread what he wanted, or I completely ignored what he wanted. (The last, of course, is not the case. The first two are possibilities.)

So my decent solution (for a person who'd never done any application development - I do not promise that a skilled programmer wouldn't have done it more elegantly) was rejected; I was informed that there was no more work for me there.

Translation: I'm *free!*

I'd been trying to get the scripts to do what I've just described written, so I could blow that popsicle stand for a while. As I warn potential employers, I can program... but I'm a bit slower than most, because I'm figuring stuff out for the first time.

In the mean time, I looked at a problem, came up with a workable solution, determined that I could do what I wanted to do, and started to work on the solution (I was debugging the part that starts and stops the recording this afternoon). It would have worked; if I'd known what was wanted, I could have gotten that working too... I'm sure of it.

I still won't call myself a programmer. This was nothing but a bit of planning and some VB script. But I feel a lot more comfortable looking at a problem that requires a programming solution... and I learned a lot more about video compression than I'll ever need to know.

The pay sucked and the job was stressful until I realized I'd never get hired on permanently, but on the plus side, I learned some valuable lessons about life, and expanded my professional skills. All in all, not a total loss.

Monday, I'll talk to Washington's unemployment office and find out if I can start claiming unemployment again.

The problem...

So... you want to be able to tell any one of four encoding machines to start a job, and stop it at the right time, with minimal human intervention (but it must *allow* for human intervention!). Three of them have 2 encoder cards; one has only one.

How do you do it?

I thought I had a decent solution.

A machine (one of the four, or another) runs a scheduler. At some time (I chose 30 minutes) prior to a job needing to be started, it would search through its stable of directories - directories? Why directories?

Because we can have seven directories, one for encoder 1, card 1, one for encoder 1 card 2, etc., through encoder 4 card 1. And we can look at a directory and see if there's a "lock" file in there indicating that the card is busy.

So, it would choose a valid directory, and create a lock file in the directory; the lock file contains the start time, the end time, and the file-to-be-recorded name. Five minutes before the show starts, start the capture, and grab the process ID, and rename the file to include the process ID number. (See, that way if you have to kill the process manually, you know which to kill - there might be two recordings running on the same machine).

When the end time rolls around, stop the recording using that process ID you grabbed earlier, move the file to where ever you want it, and then erase the lock file. Bam, you're ready for the next recording. If the automated process fails, a person coming in has all the info they need contained in the lock file, and the scheduler won't send another job because the lock file blocks it.

The scheduler uses the filename to index the recording jobs (pick good file names, and you'll know exactly what each recording is for). Store the schedule in a flat text file; archive the completed jobs in another flat text file.

I thought it was pretty neat; you can schedule a recording for whenever, you can have it stop automatically, or, with minimal effort, change the stop time or set it not to stop (by setting the end time far in the future). I had a heartbeat file to verify the jobs were all running (each time they did their checks, they also changed the date of their heartbeat file), and had alerts set up for when something reasonably went wrong.

My supervisor didn't like this solution. We were going to go in another direction. He'd told me this.

Okay, and the plan for going forward was written down where?

Well... the plan was *told* to me.

So, we don't know what, exactly, he asked for. We only know that what I came up with was something that, he was *sure*, was counter to what he'd asked for. Which wasn't written down, so we can't even tell if he didn't say what he wanted, if I misread what he wanted, or I completely ignored what he wanted. (The last, of course, is not the case. The first two are possibilities.)

So my decent solution (for a person who'd never done any application development - I do not promise that a skilled programmer wouldn't have done it more elegantly) was rejected; I was informed that there was no more work for me there.

Translation: I'm *free!*

I'd been trying to get the scripts to do what I've just described written, so I could blow that popsicle stand for a while. As I warn potential employers, I can program... but I'm a bit slower than most, because I'm figuring stuff out for the first time.

In the mean time, I looked at a problem, came up with a workable solution, determined that I could do what I wanted to do, and started to work on the solution (I was debugging the part that starts and stops the recording this afternoon). It would have worked; if I'd known what was wanted, I could have gotten that working too... I'm sure of it.

I still won't call myself a programmer. This was nothing but a bit of planning and some VB script. But I feel a lot more comfortable looking at a problem that requires a programming solution... and I learned a lot more about video compression than I'll ever need to know.

The pay sucked and the job was stressful until I realized I'd never get hired on permanently, but on the plus side, I learned some valuable lessons about life, and expanded my professional skills. All in all, not a total loss.

Monday, I'll talk to Washington's unemployment office and find out if I can start claiming unemployment again.