Christmas can be a long day. Hopefully these two YouTube gems will help pass the time.
How to fold a T-shirt in 5 seconds:
Orange teeth:
Comments rssIt crashes a lot.
I’ve been using Soundbooth to clean up speech from about 10 people recorded in a conference room, on a tiny digital recorder, while it sat next to a projector’s fan, under an air-conditioning outlet, in a slightly echoey conference room, open to a common area where people gather to take the elevator.
Cleaning up the audio was a reasonably fast, if crashy, experience.
Once I had a reasonably clean recording I thought I’d try out the automatic transcription feature. This feature performs some cursory speech recognition on an audio file to produce tags that match recognised words to their location in the audio file along with the speaker’s identity (e.g. speaker 2). As it’s only 75% accurate (for my samples, forgivably, it was much worse) it’s more useful for finding points of interest in an audio file than as an auto-transcription service.
I don’t think it ever completed the transcription task. At some random point it would offer to send Adobe a copy of a crash report.
Though it doesn’t have transcription capabilities, I think I prefer Audacity.
Comments rssTomorrow, December 5th 2008, marks the 20th anniversary of my starting work in “the industry.”
This calls for five minutes of reminiscing.
I turned up for my first day of work as a trainee systems programmer at a big Australian bank’s EDP department. I recall being more than a little shocked at having to be at work before 8:06am each day. I was introduced to everyone I’d be working with shortly before being sent off to North Sydney to do MVS and IBM System/360 Assembler training for a few weeks.
At training I learned that the most powerful instruction in Assembly language was the no-op. The coding standard dictated that you sprinkle them throughout your code so that smarter programmers than you could patch your code, in memory, while running by overwriting your no-ops with useful code and then adding a statement to branch to the patch code over the defective instructions.
The bank had some great people. Some were consummate professionals and some were real cowboys.
Towards the end of my time at the bank I was introduced to the pointy-end of the economics of software development and process improvement.
A colleague returned from a long liquid lunch and let me in on the “big secret.”
He said only fools write good code. Code has to break for you to get called in. Being called in gives you overtime and visibility. Overtime is extra money. Being called in is heroism. Develop skill in writing bugs that are serious enough to call you in about, yet easy enough to fix soon after you get into the office. Overtime was paid for in four hour minimum units. Nobody notices people who write reliable code because they never get to perform heroic acts. Notice that the people who get promoted are those that handle high stress situations. Notice that the people handling these high stress situations are generally responsible for creating the high stress situation in the first place.
It was good motivation to find a new job.
Comments rss
