My Hat!

Strange Things People Say About Me (to my face)

Recently, I've been at the center of a trend. That trend is complete strangers asking me "Are you ____?" A quick summary.

For example:

Are you Jewish

The Event: While walking to my bus stop, I saw two lost-looking Orthodox Jews standing on the sidewalk. They stopped me and asked if I was Jewish.
My Theory: I have a big schnoz and was wearing a dark fedora.

Are you related to the lead?

The Event: During an intermission at the opera, someone in the row behind me stopped to ask if I was somehow related to the male lead in the show.
My Theory: We both have pony-tails? I'm really at a loss here.

Are you a dancer?

The Event: At the grocery store, I was moving from one aisle to the next when a portly black man stopped his cart and asked if I was a professional dancer. He was quite specific about the "professional" part. When I said, "No," he added, "Well, you really look like one."
My Theory: Apparently I look fitter than I think I do. But also, this was a moment after where I made a semi-flouncy, over-pronounced "After You…" gesture to someone coming the other way. I do flounce. I cannot deny this.
run the fuck away

Bob Morlang

When I was working at Tri-Mount, we had these camp trucks. They were army surplus, and while they could take a beating, they only sort of worked. And they took lots of beatings. Never in a million years could they have passed a roadway inspection, but they could haul a tent platform from one side of the mountain to the other. When they ran, anyway. To give you an idea of how they were usually maintained, the camp handyman filled the tires with cement so that he wouldn't have to keep a compressor handy to re-inflate them.

There were two trucks, and usually when one broke down, the other was still operable. But one week, both trucks broke down, and they were seriously broken. Nobody believed that they'd work again. One day, I walked past the area where they were sitting and found Bob Morlang elbow deep in one of the trucks, with parts scattered around him. Keep in mind- Bob was with Troop 7, and not a camp employee. He was a guest at the camp, but he volunteered to take a look at the trucks because he knew we needed them.

There was only one problem: he didn't really know much about the sorts of engines in the trucks. "But it's no big deal," he told me, "I can figure it out."

And he did. In the course of a few afternoons, he ripped apart the engines, figured out how they were supposed to work, and then put them back together so that they did work. By the time he was done with them, they were in the best condition that they'd ever been.

I didn't have all that much Interaction with Bob Morlang, but he made a massive impression when I first met him- which was asking him to counsel me on the Atomic Energy merit-badge. Bob was the only counselor in the Council for it, and it just so happened that he worked as an engineer at the Indian Point Reactor. When I sat down with him to learn about that subject, I got much more- Bob was so much of a polymath. Our sessions working on the badge diverged into all sorts of subjects.

I was only 12 or 13 at the time, and my impression of him was that he was the real-world version of MacGyver. For a young nerd, that's an incredible first impression, and it sticks with you.

I'm very sad to say that Bob Morlang recently passed away at the age of 50. He was leading scouts from Troop 7 on a snowshoe hike around Camp Tri-Mount and had a heart-attack. From what I understand, it was sudden and final. He was an incredible person, and the world has lost something special.

run the fuck away

About Computer Programming

I'm trying to run a short, informal survey. What are some things that come to mind when you think about computer programming? What do you think it involves? What do you think it's like? If you have programming experience, feel free to reply anyway, but please note that.
run the fuck away

pwd or "where am I?"

Apples pointed out I hadn't updated my LJ in a looong time. I do read my friends page, and I do comment routinely, but I haven't done much posting.

But I'm not dead. In fact, I've been active writing and posting in a variety of places. So here's a "where's Remy" list:
johnny cash

Dear Pittsburgh

Dear Pittsburgh,
You may or may not know this, but your city is in the Northeast. Yes, the "Northeast" includes New England, and the "Mid-Atlantic" states of New York, New Jersey, and Pennsylvania. Now, one little known fact about the Northeast is that, during the winter, the skies will shit snow like they just ate Satan's chili.

I bring this up, because it snowed recently. Quite a lot, actually. 21 whole inches. Which definitely is a problem, I understand that. But it stopped snowing Saturday afternoon. Maybe I'm spoiled by having lived in Upstate NY, where this sort of snow is common, but in general, 48 hours after a snow storm, it's generally expected that the streets are plowed. Actually, it's usually much less than that- like 12 hours.

I bring this up, you see, because it's more than 48 hours since the snow ended. And not only is my little podunk street not plowed (or paved with something durable, but that's another kvetch), but none of the streets in my neighborhood are plowed. On Sunday, I helped some overly ambitious neighbor find their way back to their parking space after realizing their car wasn't going to make it 20 yards down the road, and today I helped a UPS driver out of the same snow. The same snow, just to remind you, hasn't been plowed.

This is just a reminder. It does snow in Pittsburgh. And when it snows, we generally expect that the streets are plowed. Snow removal is one of those expected services that the city should be providing. My sidewalk, patio, (very short) driveway and a section of street have all been shoveled by my wife and myself. I've unstuck other people's vehicles, and hit my neighbor's (also very short) driveway. I don't think it's a lot to ask for a plow to run down at least one of the streets in my neighborhood. You don't even need to hit mine. One of the more major streets would be nice. Just enough, for example, that I could walk to the grocery store without falling all over the place.

Like I said: just a reminder.
Somebody who will not be voting for the incumbent councilman in District 8.

//My dad was in city politics when I was growing up. The two jobs of a city councilman:
//Keep the streets paved, and keep them clear of snow.
run the fuck away

Is this what the users want?

"Remy," they say, "we've got an application for you to design. Here's the specs."

The application they want is a pretty straightforward data pump application. Like 90% of what my company needs, it involves picking up records from one place and putting them down someplace else. In this case, the data in question represents item information and it comes from the health and safety database and goes to our production processing database.

At first glance, things like this seem like they should be simple, but in practice, they never are. I started asking questions- "Hey, these different types of data you need moved, are there any dependencies between them?"

"Oh, no. Nope. Definitely not."

Well, actually, yes, yes there are. The base record, the item, is supposed to be created inactive, according to the spec, but all of the other data we're moving- technical parameters, formulas, etc. require the underlying item to be active.

Which means, when somebody makes changes in the health and safety database, there's no guarantee the majority of those changes will ever make it over to the production process database, since we can't process half that data until somebody flips a switch in the production process database.

At this point, I make the natural suggestion: "Maybe we should go back to the user's requirements and work from there."

"There are no user requirements," I'm told. Instead, the analyst working on this project reverse engineered the process by looking at some existing code. Code that does a similar role (pulling from a different health and safety database to populate the production processing one), in a process that's being replaced by the one we're building.

Today, days after I had a milestone to finish my technical design, the analysts send an email to a user, "Hey, how do you guys want this to work?"

When I gave my estimate for this project, I was pretty generous. And this is why. Because "just make it work like the old thing" is not a valid set of requirements. The "old thing" has a bunch of assumptions buried in its code built around how the old systems behave. Assumptions that may no longer be valid. Every IT project should be built around what the users actually need.
Tom Baker

Neologism: Unomatopeia

As we all know, onomatopoeia is when a word sounds like what it represents. "Boom", "Bang", etc. Unomatopeia is when a word sounds like what it represents if only what it represented had a sound.

For example: "The cute little sparrow poinged around the sidewalk looking for breadcrumbs." A sparrow hopping makes absolutely no noise, yet "poing" is exactly the noise it would make if sparrows jumping made noise.

"He lurped at her from across the bar," is another one. When we describe someone as "lurpy", there's a vivid sound to that that describes exactly that sort of… lurpy behavior.

Unomatopeia deserves to enter the vernacular.

House: Gotten

We have keys and garage door opener. Paperwork is signed, and a gigantic check has been handed over. This evening, after dinner, we marked our territory by bringing over some boxes and pissing in the corner. Well, okay, we only did one of those. Point is: ours. Yoink. Snagged.

The previous owner did forget to clear the win out of the house, but we're okay with an excess of win. He was also cool enough to leave the patio furniture and some fireplace stuff.

Maybe we moved the win in with us, because everything went smoothly. Closing took twenty minutes, give or take. The bank's agent was a pro, and he banged his way through the paperwork one-two-three. Since neither we nor the seller really felt much need to quibble, that was it.

Our realtor was stunned. Granting that we basically handed this deal to her on a platter, she was just waiting for something to go wrong. But, no. Yoink, house scored, and a package of win delivered for Solstice.
run the fuck away


I'm in training for two days this week (which is annoying, to an extent, because I have 2 days of work that needs done this week, and only one day in which to do it before going on vacation, which means I'm likely going to need to work on Friday, not that this has anything to do with anything). The training is focused on applying "Lean" principles to data analysis. "Lean" is a buzzword laden approach to evaluating and improving the efficiency of a process. Stripped of buzzwords, it's not a bad set of techniques. Nor is it gospel, contrary to some of the enthusiasm of its pointy-haired proponents.

Regardless, I'm looking for the good parts of the training. One of the key focuses has been on value stream maps. Essentially this is a flow-chart used to understand who does what in which sequence to generate output. In a factory analysis, you'd use it to analyze the manufacturing process so that you could identify waste.

The key thing to note about them is that they focus on inputs and outputs. There are some raw materials at the start, which are the initial step to the first process, which does something to the raw materials. This process hands its output to the next step, which does its own thing generating yet another output. And so on, until eventually, you get the finished good. Along the way, you want some metadata about each step, like its costs and the value it adds to the final product.

I'm sitting there in class, and thinking: wait, inputs, outputs, and chains of processes? This is functional programming.

So I started taking notes, but not in English. I start scribbling away in Haskell, prototyping some functional programming ideas that relate to the problems represented by a Value Stream Map. I'm till not too experienced with Haskell, so it's a little cumbersome, but there's a distinct value, to me, in being able to explain ideas in code.

But then, I remember: Haskell is a literate language.

In most languages, you write code and annotate it with natural-language comments to explain what that code does. In most cases, this means that you have to mark your comments with some special character, for example, in C, you'd write something like this:
Take two numbers and add them
int MyFunc(int a, int b) { return a + b; }
The comment is on the line that starts with "/*" and ends when it hits the "*/".

Haskell, by default, takes a similar approach (one line comments start with "--", and multi-line comments are enclosed in "{-" and "-}". But you can tell it, "Hey, be literate." Instead of requiring you to mark your comments, you instead need to mark your code. A literate Haskell program would look something like this:
Take two numbers and add them
> MyFunc a b = a + b
When you're trying to take notes and then illustrate them with code, or when you're writing code in an experimental fashion, this becomes a really good way to sketch out your ideas.

I'm still not blown away by Haskell's dependency on whitespace, but it's got a lot of other features that make it really good for rapid prototyping of logic. I still don't grok "monads", which means non-functional problems (like IO or random numbers) are still a challenge for me, but it's still a really fascinating language. As parallelism gets more important in software design, so will languages like Haskell.