Almost everyone else has posted a note about the meetup last night (Anita, Jack, Dennis, and Ram – but not Alex), so I’m a bit behind. We somehow manage to spend little of our time talking about blogging at these meetups but we still enjoy ourselves immensely. I’m disappointed that Anita (and Jack, I presume, though I didn’t get a chance to ask him) hasn’t been following Battlestar Galactica this season. The other folks I usually talk to about the show are still catching up from the first half of the season. I would love to know what they think about the Baltar-Six developments in the past few episodes.

Dennis — a.k.a. Orcmid — dropped by and left a comment this morning. He asked whether I had tried compiled JavaScript in .NET or not.

In the case of my strong typing epiphany, I wasn’t writing a script from scratch. Instead, I was modifying an existing script. Basically, I was changing it from doing a set of things once to doing that set of things multiple times, but with slight variations in the options. There was a bit of new logic in the program, but it was mostly refactoring. And it was the refactoring that got tough without strong typing as I converted repeating blocks of inline code into functions and corrected assumptions the original author had made (but that no longer were true). I had to change the scope of variables, create parameters, and document each new function. There were a lot of opportunities for typos.

One of the cardinal rules of modern programming is never to copy and paste. If you have two or more blocks of code that are identical, or even nearly identical, a subroutine should be made and then that subroutine called in place of the inline blocks of code. The reasoning is this: if the logic is duplicated in the code, if that logic is ever changed, it may not get picked up in all the places.

For example, pretend this pseudocode is a meaningful program:

if something equals "a" then
    doFunctionOne(using "a")
    doFunctionTwo(using "a")
    doFunctionThree(using "a")
if something equals "b" then
    doFunctionOne(using "b")
    doFunctionTwo(using "b")
    doFunctionThree(using "b")

There’s an example of copy-and-pasted code. It could easily be turned into a subroutine:

subroutine doFunctions(parameter)
    doFunctionOne(parameter)
    doFunctionTwo(parameter)
    doFunctionThree(parameter)

And then the main part of the program would look like:

if something equals "a" then
    doFunctions("a")
if something equals "b" then
    doFunctions("b")

Or even simpler, in this trivial example:

doFunctions("a")
doFunctions("b")

Imagine this kind of change, but across several hundred lines of script code.

Getting back to Dennis’s question: I have done some things with JScript.NET, but it wouldn’t have helped here because I was modifying existing code rather than starting from scratch and I needed to work within the already-established parameters.

If I have to touch this bit of code again, for anything more than the most-trivial change, I’ll most likely invest the time to convert it to managed code. It will save me — or whoever comes along after me to maintain it — more time than I’ll spend doing the conversion.

Now, another question that the devil’s advocate in me has been asking: when is copy-and-paste better than factoring code into subroutines? Let’s forget about one-off, throw-away code. For stuff that’s meant to last and be maintained, are there any situations where copy-and-paste is preferable? Perhaps I will address that in the future or, even better, maybe some of you will provide answers in the comments.

Update: I’ve got to do something to remind myself to insert the tags on the posts before posting. I need to figure out how to hook Blogjet to remind me.

Tags: meetup, programming, refactoring
del.icio.us tags: meetup, programming, refactoring

Version 2.6 of Paint.NET was released a few days ago. It’s not a replacement for Photoshop — nor is it meant to be — but it’s a quick little tool, it’s free, and it’s written in managed code and the full source is available.

When I embed screenshots on a page, I like to surround them with a black border to make them look a bit better. I’ll often do that just with CSS, but many of the RSS readers don’t display the full style info. So that means I need to put the border in the picture itself.

Here’s how to do that in Paint.NET.

We’ll start with figure 1, pulled from the Paint.NET user interface itself.

Figure 1: Starting example

I deliberately captured a bit of the background of the Paint.NET window and included the cursor. Unfortunately, Paint.NET puts its own black border around the picture so it already looks pretty good. So here it as it would appear in the page without a border:

Figure 2: Example with no border

And here it is with a border:

Figure 3: Example with border

Much nicer, hmm?

To do this, you need to set the background color to black and then expand the canvas size by one pixel on each side.

Paint.NET uses a tool palette very similar to that used for years in Adobe’s products. At the bottom is the color selector, with the overlapping rectangles for the foreground and the background colors, and the little arrow that swaps the colors. Make sure the colors are set to the default black and white (by clicking the mini-overlapping-rectangles icon) and then swapping colors using the double-arrowed tool. I’ve circled it in red in figure 4 below.

Figure 4: Tool palette

Next, from the Image menu, choose Canvas Size… You can also use the keyboard shortcut Shift-Ctrl-R.

Figure 5: Image menu

By default, the Canvas Size menu will look like figure 6.

Figure 6: Canvas size dialog with default settings

We’re going to add a pixel on each side, so that means increasing the width and the height by two pixels. But that’s not quite it. Notice the Anchor section in the bottom of the window? That says where to put the existing canvas relative to the changes. If it’s in the top left, then any size increases will only appear on the right and the bottom — not what we want. Here’s the dialog box after making the changes:

Figure 7: Canvas size dialog after changes

And here’s what it will look like in Paint.NET after the change:

Figure 8: Example after adding the border

It looks thick inside Paint.NET, but remember that it already applies its own 1-pixel black border.

Save your changes, and you’re done.

Tags: Paint.NET, digitaldarkroom, tips, hints
del.icio.us tags: Paint.NET, digitaldarkroom, tips, hints

It has nothing to do with skills at the keyboard, but with programming languages and environments. For the first time ever, while working on a small, self-contained script, I missed having static typing and a compiler to help verify what I was doing. I almost fell off my chair when I realized it.

Let’s back up and I’ll try to explain what this is about. As usual, I’ll ignore all kinds of details to try to get the idea across.

There are lots of different ways of classifying programming languages. One distinction that has always been relevant to me is that between scripting and compiled languages. Scripting languages (and here I’m including things like Perl, VBScript, and PHP) lack two features that, in my simple classification scheme, belong to compiled languages: strongly typed variables and, of course, compilation.

But that lack of features is, to me, a good thing. When trying to write a quick program, strong typing and compilation get in the way. Strong typing requires you to be careful about the way you use data and variables in your program — the way you handle things like numbers or text. Spending time to get that right can slow you down. Compilation is an extra step in the process. With a scripting language, you just write the code and then run it. But with a compiled language, you have to write the code, then compile it, then run it. That compilation step may only take a few seconds, but when you’re doing it dozens of times while building the program, it adds up. Edit-compile-run is a noticeable difference between Edit-run.

I have never doubted the value of strong typing, or static typing and type safety, anyway, in large programs with multiple people collaborating on it. There’s tremendous value in the structure those systems impose.

But until today I had never wanted those features/burdens when working on scripts. The script I’m working with is about 500 lines and was written several months ago. Now that we’re working on the next version of our product, the assumptions that were made when the script was first written are no longer valid — it needs to handle more possibilities.

So I’m reworking the script to handle these possibilities. And the logic of what I’m doing — the actual purpose of the script — is very simple. But there are enough variables and subroutines, and they’re used enough places, that there are plenty of opportunities to make mistakes, often just with a typo. Maybe the variable is abcVariable and the first five times I type it correctly, but the sixth time I type abVariable. With a compiled language, the error would be flagged before the program could run. But in a scripting language, I can’t know that the error exists until I run the program. You may have heard the terms compile time and run time. This is the distinction.

In this case, the script takes a few minutes to complete its work and restoring the system to its previous state (so that I could try the script again) takes a few more minutes. To make things even more dangerous, the script copies and deletes files. If I make a mistake in some of that code, I could erase a whole lot more than I intended. And it’s no fun restoring from backup.

So, working in the scripting language, I have had to pull bits and pieces out as I make changes and put them into another script, write a bit of code to run those bits and pieces, and test things piecemeal as I go.

This is the first time that I’ve been handling a scripting task where I would have been faster with a compiled language. It’s pretty darned surprising to me.

And, please, all you fans of Ruby or Python, don’t tell me I’m an idiot because your language could solve these problems. If I had the luxury of using Ruby or Python — or even taking the time to rewrite the script in a compiled language — I would. But we have a budget and I can’t spend enough of it on this to rewrite it.

Tags: development, strongtyping, scripting, compiled
del.icio.us tags: development, strongtyping, scripting, compiled

What are you giving up for Lent? Me? I’m giving up impatience.

I know this is supposed to be a season of penance rather than an indulgence in self-improvement. But then I’m not Catholic and impatience must be one of my pleasures since I’ve indulged in it for so long.

I don’t like to wait in line — not at the grocery store, not at a restaurant, not at the border. I’m frustrated by people driving below the speed limit and the time it takes to pass all the security checks when making a RAS connection at work.

I’ve been trying a thought experiment the past few days and I have been surprised by the results. Every time I feel impatient or sense myself rushing, I ask, “Why are you impatient? What’s the value of hurrying?” There are some valid answers to those questions — diarrhea or free Krispy Kreme donuts among them — but mostly there is no good reason. What am I missing if I don’t make the traffic light? Especially what am I missing if Dawn and Maya are in the car with me? So all the tables are full. That’s just an opportunity to study the restaurant’s decor or watch people come and go.

Most of all, though, I value grace, dignity, and kindness — not characteristics usually associated with impatience and rushing about.

It’s going to take a lot of practice and a lot of discipline, but I hope to emerge a better person. And isn’t that really the spirit of Lent?

Tags: Lent, impatience
del.icio.us tags: Lent, impatience