picture home | pixelblog | qt_tools

omino code blog

We need code. Lots of code.
entries for category "Uncategorized"
David Van Brink // Sun 2012.03.11 09:55 // {Uncategorized}

Site hacked.
A compromised user on tobias.dreamhose.com (which hosts omino) looks for world-writable directories and adds in a PHP shell tool. Then access that tool from the web, runs as me, and puts eval(base64_decode(‘hack’)) on every php file.

Removed with:

find . -name '*.php' | xargs sed -i -e 's/eval(base64_decode("[^"]*"));/\/\*hack gone\*\//'
oh, i dont know. what do you think?


David Van Brink // Thu 2011.09.8 15:28 // {Uncategorized}

Fluff: Architecture

And in the nondisprovable content-free feel-good department, I offer you my deep insights on what makes good architecture.

High Performance
Just kidding! But this is what they cover in the classes entitled “computer architecture”, and is the sort of thing “architects” are supposed think about. Throughput and simple math to figure out thingums per second, and redundant paths needed, and how many zillabytes the database would take if you do it *that* way.

Maintainable
From down in the trenches, if you get a bug report or a feature request, and you’re able to just dive in, find the right spot to put it, and put it there, and you can test it, while at the same time not leaving a mess, that’s often a symptom of good architecture.

Explicable
If you can draw it on the whiteboard, and explain it, and the picture is reasonably attractive, and you’re not lying: You’ve got good architecture! Hooray.


I believe the last one is the most important. Maintainability falls out of explicability. (Remember — I said it’s got to be a pretty picture *and* you’re not lying!) And if it’s maintainable, you can properly scope which parts, layers, subsystems, or strategies need to be improved, from time to time, to meet performance.

You know, I guess I’m defining “maintainable” code as code where small changes are trivial, and huge changes are just more work, without risk.

oh, i dont know. what do you think?


David Van Brink // Wed 2007.08.1 17:36 // {Uncategorized}

the basics

I’ve assembled a handful of notes about basic coding and architecture practices which might prove useful to you. These are mostly Java-oriented (with the exception of the notes on file formats), and might be a bit confounding if you’re not at least a little bit fluent in Java. But the ideas are of a general nature, and would find application in most languages.


Where to Put A New Method

  A note on creating new methods and gradually promoting them into the core libraries.


Null and Nuller

  A note on handling and returning null values


The Name of the Assertion

  A note on informative JUnit failure messages


Know Your Document Format

  A note on file format design


Write Short

  A note on contextual brevity


(in progress) Relativism And Absolution

  A note on relative paths


(in progress) In Praise Of Static Methods

  A note on the art form formerly known as “Subroutine”

oh, i dont know. what do you think?


David Van Brink // Sat 2007.03.3 16:29 // {Uncategorized}

Hacking Sawdust Part IV: The Render

This is the fourth and, frankly, anticlimactic part, of four parts. Start at the first part.

Suppose you wanted to make one of these:

One way to do it would be to follow the steps in the first three parts of this article, and then going to Sears to get a primitive replicator called a “Compucarve”. Or a “Carvewright”. There’s some branding confusion. But it’s a nifty device, and, given a bitmap, will carve wood.

After preflighting the whole Photoshop file through my viewer to my satisfaction, its finally time to put it into the “Carvewright Designer” software, which comes with the carving apparatus. It’s an ok application, but importing and viewing a bitmap takes about ten clicks and a new unique name. And that’s the motivation for my faster viewer program.

From there, you save the design to their proprietary flash card, carry the card to the garage (if you’re me) where the wood printer is, and pop it in. From the front panel, choose the name of the design you like, and press go.

If you’ve done any computer-media projects, you’re probably familiar with the “Waiting For The Render” experience. For most such projects, the logical time to fire off the render is at night, so you can spring out of bed in the morning and “Check On The Render”.

(I had two weeks of that doing the five distinct camera angles for the “Planetarium of Dreams” part of this little movie.)

Rendering the final sawdust is no different. Except that the renderer is insanely loud and you can’t just go to sleep with it running at night in a decent neighborhood which is where I live thank you. So unfortunately it’s midday rendering only, for this gadget.

Wear ear protection!

It takes about an hour to carve medium-sized projects, and it’s rather hypnotic to watch.

Eventually it grinds to a stop. And there’s your atoms.

And a lot of sawdust.

With the toolflow in hand, it becomes possible to create many fascinating bits of art with endless decorative uses, indoors and out.

I love this future!

oh, i dont know. what do you think?


This is the third of four parts. Please start at part one.

Suppose you wanted to make one of these:

In photoshop, we arrange copies of our rendered heightmap sphere to resemble bubbles.

But one wonders: What this will look like carved in wood? If you’re me, which I assume you aren’t, by the way, you answer this question by finally learning Cocoa (with lots of help from Dan Jalkut, thanks!) and writing a quick little Mac OS X application for realtime rendering of such images.

Hmm. Bit of a chopped up mess. But changing the Layer Mode for every entry to “Lighten” fixes it right up. Since white is “higher”, what this does is let the higher part of any two overlapping bubbles “win”.

So why not do all this in LightWave to start with? No reason; Photoshop did the trick here, and it was fun to see how Layer Modes translate to three-dimensional effects.

With a bit more Photoshop painting and transfer modes, I get the doors, the details. A LightWave-rendered cylinder is incorporated, and the same sphere inverted forms the corner-bolts.

Last step: actual wood!

Thanks to jD for user-testing the software. Feedback is precious, remember to get it early and often.

If you’d like to try the software, download it! Drop me an email or a blog comment if you have any thoughts on it.

oh, i dont know. what do you think?


David Van Brink // Tue 2006.09.5 21:47 // {Uncategorized}

Bad Code (3 of 3): In Hope Of Good Code

Read part one first, please,
and then read part two!

There is Hope
I think there is hope. Perhaps you’re expecting me to now discuss how to refactor Bad Code into Good Code. I’m not. One of the properties of Bad Code is that it’s easier to rewrite than to refactor.

Or, conversely, one of the properties of Good Code is that you actually can refactor it. Of course, when I say “refactor” I’m thinking of benign explicable tasks like “make this its own class” or “gently move this functionality from here to there.” Because with Good Code that’s all you ever need to do.

No, this old engineer thinks the claim that “You can refactor Bad Code into Good Code” is just a glib and meaningless phrase, up there with “agile development.”

But when you’re called upon to rewrite it, here’s some strategies that might help. A little. I can’t help you with rational architecture. But I can offer a few tips that will at least let your code be usable in 20 minutes.

Setup, Then Run
Here’s the general pretty picture approach to managing your dependencies:

Put your dependencies all in one place, and deliver them to the workhorse in one lump. If you gather them up, first, and name them (don’t just pass System.properties or @ENV around!) then you can clearly identify what they are. And then, why then — it brings tears to my eyes — you can control the workhorse completely. And the obligations of a user of the library are clearly spelled out by the empty holes of the SetupInfo object. That setup object can turn weeks into 20 minutes, for the recipient of this Good Code.

Don’t Use Files
Design your core API around in-memory data rather than files:

Files are just another kind of system dependency. If you pass around in-memory objects then a user of the library can create the input however they like, and can manage the output however they like too. And if they do want to read or write files, well, they can do that, too. (Also, this can speed up your unit tests considerably!)

Easy To Say == Easy To Do
Any software library has some purpose. You should be able to say what that is. You should be to easily say, in English (for example), a few of the things that the library can do. And the code to do those things should be very nearly as brief!

If you say “This is a package for analyzing Toves for their degree of Slithiness, and applying Gyre to them,” then there simply must be a complete example that is very nearly as short:

ToveManager tm = new ToveManager(); // by default, no config file
ToveConfig tc = getMockToveConfig(); // something I cooked up
tm.setConfig(tc);
Tove[] toves = tm.createToves(13);
double k1 = toves[0].getSlithiness();
toves[0].setGyreAndGimble(5,Gimble.WABE2);
double k2 = toves[0].getSlithiness();
assertTrue(k2 > k1); // should increase slithiness

Conclusion
I’ve had quite a few years of dealing with mostly Bad Code, with the occasional gem Good Code to be found. But it’s rare. I try to write Good Code, but I don’t always succeed. I think the important thing to realize is that your code is a gift to the future. Sometimes a pet-owner will say something like, “Oh, dear, Fifi left us another gift.” All too often that’s how code is. But it can be otherwise. Try to be generous.

oh, i dont know. what do you think?


David Van Brink // Sun 2006.05.21 19:49 // {Uncategorized}

about

My name is, and always has been, David Van Brink. I live in beautiful Santa Cruz, California with my partner Deb and our cat, Zero.

I got my start programming assembly language for an Autonetics Recomp III computer, using a paper tape punch, in junior high school. That circa-1956 drum-based computer was contributed by our math teacher, Elliott Myron. Since then, I went to college, and have worked at a couple of small companies and startups doing various graphics and audio work, a stint at Apple working on QuickTime, and finally for the mighty Altera corporation, architecting a high-level FPGA system design tool called SOPC Builder. Nice of them to have an office in downtown Santa Cruz, eh?

In the evenings and weekends I can be found indulging in a variety of projects; the technical ones will often be found documented within these pages. Welcome to the subservient astronaut blog.

Here are some quick links:

The Basics: some foundational software advice
WBL: projects involving weird blinking lights

Comments are closed.
/\/\/\/\/\/\/\

(c) 2003-2011 omino.com / contact poly@omino.com