Author Archives: admin

Buggy software

Should I love or hate buggy software?

I mean, the hate part is somewhat obvious, in that it interrupts work and takes one out of flow and dammit I paid $apple and I should get orange performance, etc.

But the love part comes from the following facts:

  • in cases where I’m paid by the hour, I make the same amount of money for struggling for a hour with OPB as for doing, ya know, some real work.
  • I learn things from struggling with bugs. Not only “this crap doesn’t work in this situation” (which is commercially valuable knowledge), but also things about the technologies involved, theoretically things that transfer to other contexts. Wasn’t it Heidegger that had a whole theory about how tools are invisible until they fail to work?
  • (third entry because a list of two things is weird.)

“We Feel Fine”

This is pretty amazing, on a few different levels: We Feel Fine.

A choice

We can choose to see the past as a set of templates against which we can train our souls to perceive the peace and joy of every configuration of the universe.

Teaching programming

Someone (I don’t really like to mention a lot of specific names on my blog) asked me today what suggestions I might have to someone who’s about to start teaching a university course in programming in MIS. I had some fun hypothesizing about it; here’s what I wrote:

[I have to preface all my remarks with: I’ve never taught anything bigger than parts of a three-day course in the architecture of a specific application, and even then I didn’t try any of the blue-sky ideas I’m about to mention. But, if I did try to teach something like a college course, I would try them.]

My first thought is that the most important thing to emphasize is that programming is about structuring thinking and activity, and not really about the structure of computer programs, so I think a project-based approach seems like a good idea.

I’m going to just go full-hypothetical here and give a transcript of the first monologue I’d give :-). Hopefully people would interrupt me…

“Contrary to what you may have been told, programming is not really that much about languages and syntax and stringing together a series of canned solutions. Well, good programming is not about that. Mediocre programming is about that, and you can get by in the commercial sphere being a mediocre programmer, so if anyone is truly satisfied with that, we can have an independent study course where I assign you a textbook and you do problem sets and tests.

However, what I’d rather we all do is learn good programming, and by the method that I think makes most sense, which is to actually build something together and enjoy building it. Good programming is about structuring thinking and activity, both on your own and with others. It’s really just a particular discipline of problem-solving and communication, both of which I assume you all know a good deal about.

The project we’ll be doing is the software for a POS system. You might think “that’s boring”, which I hope to convince you doesn’t have to be true, and you might think “that’s quite practical”, which is true but not all that relevant.

What is relevant is that it’s something big enough that it will take the whole semester. Today is the last ‘lecture’ of the class. I mean, there’ll be plenty of opportunities to take notes if that’s your thing, but what I’ll be doing is not lecturing; I’ll be participating in the discussions that come naturally from the project, and bringing in whatever I can from my years of experience when the need arises. You’ll want to take notes on what you and your classmates say more than on what I say.

If you’re thinking about grades, and it’s OK to admit that you are, I think everyone will be graded by classmates. I won’t let you be too hard or too easy on one another, but other than that, you’ll be deciding grades. Inherent in the structure of a complete software system is some sort of assurance that what you’ve built is high-quality. So, for example, there’ll be people making test systems that will test modules that other people are making. It will be clear to both of those teams how well the other team did. You’ll be giving grades at the end of the second, fourth, eighth, and sixteenth weeks.

Speaking of teams, let’s start talking about the pieces of the system and the workflow for building them. I think we can accommodate everybody’s interests and talents somewhere in here.”…

[Some pieces of work/ideas I might bring up if they didn’t come up: user interface/ease of use, network protocols, language and coding style decisions, source control (use SourceForge and get the added effect that ‘anyone in the world might see your code’), error handling, exception handling, auditing, security, existing code and libraries, storage and redundancy, issue tracking, performance, testing, data formats (i.e. floating point is not necessarily good for financial data), customization/branding, data mining, what happens if the whole thing ‘crashes’, legacy system integration, self-check systems, …]

Remembering a name

Funny the things one remembers. I’ll probably never forget the name of a mythical COM interface from a project I worked on: IWendyPointerToGuts. This was a name for, let’s say, an anti-pattern that we wanted to avoid in the project. I’ve long since left that project and have no need for the name any more, but it still sticks.

Spam brain

Ha, I was amused to find that a sci-fi story had the same idea I’ve had, about spam filters eventually being a source of artificial consciousness:

“AOL is the origin of intelligence?” She laughed, and
he couldn’t tell if she thought he was funny or stupid.

“Spam-filters, actually…”

— Cory Doctorow, “I, Row-Boat”

Great story, by the way. And free for download, thanks to Doctorow’s enlightened attitude about sharing-as-marketing.

The switch flips

It seems like the direction of technological progress has been to reduce the number of moving parts in use, but now we may be starting a trend in the other direction. MEMS are getting hot, for example: MEMS switch tops 26 GHz, or DLP Pioneer….

[Ha, I accidentally made a funny when I said they’re ‘getting hot’. See, cuz the thing about MEMS systems is that they don’t get hot, like larger-scale mechanical systems. Ha.]

It’s pretty amazing that we’re seeing switches that thunk back and forth 26 billion times in a second, or projectors where every single pixel has its own little mirror wiggling independently hundreds of times per frame. What would Archimedes think of these?

And (of course) I see interesting roles for software coming up in concert with such systems. Whenever you can affect something in the real world at a rate of MHz or GHz, you can drive it with software and do some things you wouldn’t have believed…

Psychology of info-space navigation

I’m also fascinated by the psychology of getting around in unfamiliar info-spaces. In order to find a workaround for my problem outlined in Geek TV: open source rocks, I had to:

  • find anchor points
  • learn terminology
  • learn systemic interactions
  • build an environment for experimentation
  • build models of a system with dozens of components
  • perform experiments
  • twiddle code

and finally, reason about interactions between things I don’t understand, within a system I don’t understand, driven by a practical problem that I wanted to solve. And this all took place in a period of days, in a total of a couple dozen hours, on and off, with the final effort between getting annoyed with the problem and having a workaround occurring in a couple hours.

I’d really like to know more about how all that happens. I know that lots of academics have spent lots of effort on learning about that, and I have spent some time delving into their research, but still, I don’t feel like I have much of a feel for the most important parts of the whole process. It’s fun, in any case.

Sociology of software

I’m pretty fascinated by the concept that there’s a sociology of software, that the patterns of relationships in the little world of software components installed on a computer mirror, to some degree, the patterns of relationships in the world of users and developers. I suspect that some academics out there study such things, so I’ll have to see what they’ve learned some day.

I did find one interesting paper in an earlier search: Sociology in machines (PDF). It’s not hitting quite the nail with the exact hammer I’m thinking of, but it might be a good starting point.

Anyway, I was reminded of this when I was researching my problem in MediaPortal as mentioned in Geek TV: open source rocks. In that situation, we have at least three development groups (Nero, Team MediaPortal, and Microsoft) plus one user participating in transactions, specifically, User wants to use software from all three groups on the same computer. The sets of components are developed pretty independently of one another, but there are significant dependencies on Microsoft for both Nero and MediaPortal. Each set of components can be installed and uninstalled in somewhat independent ways. Nero and MediaPortal make calls to Microsoft components, but Microsoft also makes calls back to both. It’s in that particular web of interactions that problems arise.

I could go on, but won’t.

Geek TV: open source rocks

I’ve said it before, and you’ve heard it before me, but open source rocks.

I had a problem with MediaPortal that was bugging me. Certain things were taking too long, and too much memory. Long story short, I worked around the problem, in code, it in a couple hours of work. Given that it would have taken a similar amount of less intellectually stimulating work to find such a problem in a closed-source program, and I probably wouldn’t have been able to fix it, I consider this a great thing.

If you want lots of detail about the problem, and maybe its ultimate resolution, you can check out the forum thread I started over at MediaPortal support. We’ll see how that turns out. Could be that I’m an idiot, so my pointing to this thread may turn out to be a bad idea :-). Anyway, Slow graph rendering for analog card. I’ve reproduced my first three posts below for my own reference later, but you can read them too: I totally give you permission.

———

Slow graph rendering for analog card

Hello,

I hope nothing in this message is obvious or dumb; I don’t know MediaPortal, DirectShow, or Microsoft TV technologies all that well. However, I did find a problem and found a workaround for it, so maybe with some help we can find the right fix for it.

On my system with a Hauppauge WinTV-HVR-1600, it takes a very long time (probably 90 seconds), with the CPU maxed out, to bring up the Edit form for the analog side of my card in Televison->Capture Cards in MediaPortal Setup. It also take a long time, with a maxed out CPU, for MediaPortal to start up.

The line of code that takes a long time is line 297 in TVCapture/Graphs/Analog/SinkGraph.cs (from tag “Version 0.2.2”, I’m trying to stay with the stable build)
int hr = _captureGraphBuilderInterface.RenderStream(cat, null/*new Guid[1]{ med}*/, _filterCapture, null, _mpeg2DemuxHelper.BaseFilter);

I don’t know how to debug further down, since that’s a call to Microsoft code. I did notice in my early investigation that there’s lots of registry activity that looked consistent with DirectShow searching hard for matching filters.

It does eventually find a rendering (hr is 0 upon return), and everything works from there.

I saw that there is fallback code after the line above. So, I commented out the line (and the three lines after, and re-declared ‘int hr’) and let the fallback code try. It quickly finds an acceptable answer. After that change, the setup dialog comes up quickly, MediaPortal starts quickly, and analog TV is still available for viewing and tuning.

This problem may have become worse after I installed Nero ShowTime, which probably installs some DS filters. I’ll have to try uninstalling that to see if that really was a factor.

What are some good next steps to narrow down this problem and find the right solution? Or, is there enough data here for someone else who knows this system better to fix it?

[By the way, in looking at this, I noticed that the FillInAll method in EditCaptureCardForm gets called three times in the process of bringing up the form. I suspect it really only needs to be called once, which would lessen the problems with the form coming up.]

Thanks,

Steven
—–

Here’s a little more info. Nero is possibly part of the problem, but definitely not all of it.

Here are the actual timings for bringing up the Edit form in a few situations. (The ’90 seconds’ above was just a guess).
Original configuration: 196 seconds
After uninstalling Nero completely (I had a mishmash of OEM 6 Suite and Ultra 7 Suite installed; I uninstalled and deleted everything I could find): 20 seconds
With the workaround described above (removing the call to RenderGraph): 1 second

—–

And some more info:

After I reinstalled part of the Nero Ultra 7 Suite (details below), the Edit form took 168 seconds (without the code workaround). So Nero must be installing some filter(s) that are confusing to DirectShow’s search. However, if I capture the filter graph in GraphEdit before executing the RenderGraph, then render various pins in the graph, none of them take very long.

Nero likes DS filters; Program FilesCommon FilesAhead includes 46 files with extension .ax. (I deleted that directory before installing the Suite again, so I know these are Nero-related files).

Now, the question is: is there something wrong with how MediaPortal sets up its graph, or is it something bad about Nero’s filters? Or does it really matter, since Nero is a fact of life and it seems likely that MediaPortal can work around the situation?

Here’s what I installed from Nero:
Burning ROM
Vision
CoverDesigner
WaveEditor
SoundTrax

Recode
CD-DVD Speed
DriveSpeed
InfoTool

But I didn’t install:
Home
SmartStart
BackItUp

ShowTime
MediaHome
PhotoSnap
InCD
BurnRights
ImageDrive
Fast CD-DVD Burning Plugin
Mobile