The poet and writer Donald Hall said in his book Writing Well: "Context is All". It was meant to be a guideline for writing, but it also applies to other endeavors.

In particular, I believe it applies to software development where there always seems to be a new methodology or technology promoted that is supposed to solve all of our problems. Of course, it never quite works out that way.

One of the reasons that these ideas fall short of their goals is because "one size fits all" just doesn't work. What's appropriate in the context of a web server isn't going to be appropriate in the context of a low power, resource-limited embedded system.

So the principle of "Context is All" inspired this blog, but the blog won't be limited to software development philosophy - I hope to include more practical information as well.

Monday, July 25, 2011

Legacy Scripting Still King of User Empowerment

Attention has been shifting from legacy Windows scripting languages like VBScript to PowerShell. This is appropriate because PowerShell is, if you excuse the expression, more powerful.

However, there is one area where legacy scripting edges out PowerShell: user empowerment. What I mean by "user empowerment" is the ability for a user to unilaterally control their own computing environment.

For Windows XP and Vista, PowerShell has to be downloaded and installed. This requires Administrator privileges that some users won't have. PowerShell is bundled with Windows 7, but scripting is disabled by default and enabling it also requires Administrator privileges.

Now, in an ideal world, you'd contact your IT department and they'd promptly install PowerShell or enable it for you. In practice, however, there are usually institutional hurdles that make this a difficult and invasive process.

So if you find yourself on a locked-down Windows PC and you want to automate some of your work, consider VBScript or JScript.


Correction: on twitter informed me that you can enable PowerShell scripting without Administrator privileges for the current user. The command to use is: Set-ExecutionPolicy -Scope currentuser -ExecutionPolicy unrestricted

Saturday, April 23, 2011

5 Reasons Why a Republican Presidential Candidate Should Reject Birthism

I'm not a Republican, but I have some advice for Republican Presidential candidates. Make a public statement like this: "President Obama was born in the United States. It's a fact"

Of course, if you've already said the opposite or gave a wishy-washy answer, it's too late for you.

Here's five reasons making such a statement can help elect you:

1 It will separate you from the Pack

For the most part Republican Presidential candidates fall into two categories: Those who openly question Obama's birthplace and those who can't bring themselves to make a clear statement on the matter.

The moment you declare your belief that Obama was born in the US, you immediately become a big story no matter how obscure you were before. The fact that a famous publicity-hound like Trump is saying the opposite will keep you in the news for some time.

2 It will appeal to independent voters

Most independent voters will not vote for a candidate who is afraid to speak an obvious truth for fear of alienating a party or special interest group. You can convince them you are your own man (or woman).

3 It will let you deal with the Tea Party on your own terms

By signaling to the Tea Party that you aren't going to do whatever they want without question, you can court their support from a position of strength. As a Republican, you probably share at least some of the same policy views. The worst case scenario is that some of them might not vote, but there's no danger of them voting for Obama.

4 It will improve the reputation of your party

The Birther movement is making the Republican party look foolish. By rejecting it, you repair some of the damage.

5 It's the right thing to do

This might seem like odd political advice, but in a world of politics where half-truths, fallacious arguments, and deceptive language are the norm, doing the right thing can remind you that you had some good intentions going in. That can strengthen your resolve.

Monday, January 24, 2011

The Truth about the InternetExplorer Object and the WebBrowser Control

Recently I've been developing with VBScript. It's not because I think of it as a cutting-edge technology I need to learn, but rather because at work I'm stuck with a locked-down XP computer without any other programming tools, no internet access and no administrator privileges. Let's just say that software development isn't part of my current job description (There's a back-story here, but that's a story for a different day).

The application we are using at work is browser-based, but the UI (am I supposed to call it Ux now?) is horrible. Since our group is apparently far too low on the totem-pole to get our suggestions implemented, I've been writing scripts to ease our pain. The next step in this endeavor is to automate Internet Explorer and that's where the plot thickens.

There are two related "objects" you can use to automate IE: the InternetExplorer Object and the WebBrowser control. They are both available through Shdocvw.dll and that's where the confusion begins. The InternetExplorer object is an automation interface to IE. The WebBrowser control is an ActiveX control that can be hosted within an application.

MSDN documents both of them in the documentation tree under WebBrowser Control here. This leads some people to believe that the following code creates a WebBrowser control but it doesn't:

Set objIE = CreateObject("InternetExplorer.Application")

It does, however, create an InternetExplorer object. This distinction is important for a two reasons. First, because the above code will open an instance of the standard IE application which doesn't happen you create a WebBrowser control. And secondly, because the events supported by each is different.

Adding to the confusion, events supported exclusively by the InternetExplorer object aren't supported in the way you might assume. For example, if you set the StatusBar to False in your code, it will hide the Status Bar in your Automated IE instance and will trigger an OnStatusBar event. On the other hand, if you then go to your automated IE window and select "Status Bar" from the "View" menu, it will make the Status Bar visible, but it will not trigger the OnStatusBar event.

Tuesday, December 14, 2010

Do you sell any clocks in this bookstore?

When I was in college I worked in a bookstore. One day a lady came in and asked us if we had any clocks for sale. Today, that question might not be too strange. After all, mega-bookstores like Barnes and Noble and Borders carry a lot of different stuff, but it was an odd question at the time.

I was reminded of that incident today while thinking about job interviews. Why? Hold on.

Imagine a universe where that lady's question was perfectly sensible. In that world, you might enter a traditional book-only bookstore and be greeted by the proprietor who asks you "What kind of product were you looking for?"

I think some interviewers have been to that world.

I selected your company to send my Resume to. I even applied for a particular job you are offering. Why are you asking about what kind of job I want? If I were looking for something you can't offer, I wouldn't be here.

Monday, December 6, 2010

Who says you don't need your MFC books anymore?

I have a problem with my van. The battery connectors are corroded and I don't have the money to have it fixed. (Did I mention that I approach car repair like the stereotypical grandma approaches installing an operating system on her computer?)

Anyway, I needed something heavy to hold the wires to the battery while I started the van, so Jeff Prosise's Programming Windows with MFC came to the rescue. I also have a copy of Jeff's Programming Microsoft .NET, but I hope to have my van repaired before I need it.

Friday, September 17, 2010

What I learned about JavaScript from Douglas Crockford

About a year and half ago, O'Reilly published Douglas Crockford's book: JavaScript: The Good Parts. It's a great book and is particularly useful if you have the opportunity to create new JavaScript code so that you can use the subset of the language that he describes.

One thing the book lacks is a summary of all the good advice in the form of a best practice list. Now, such lists are useful as long as we keep in mind that nearly every "rule" has an exception. Perhaps Crockford deliberately avoided the problems that can come from separating recommendations from their explanation and justification.

Nevertheless, I want to present some of his recommendations as a list that you can apply without necessarily knowing their background. I highly recommend that you consult Crockford's book for more details.

  1. Mitigate JavaScript's default global variables by creating a single global variable that acts as a container for your application.
    code example:

    var THEAPP = {}; = {
    "name": "JavaScript The Good Parts",
    "author: "Douglas Crockford"

  2. When using the Function Invocation Pattern, save a copy of this in a variable (called "that" typically). This will allow an inner function access to the outer function's objects.

  3. JavaScript doesn't have block scope, so declare a function's variables at the top of the function body.

  4. Use the Module Pattern to encapsulate singletons.

  5. Use Cascade to call many methods on the same object in sequence in a single statement. Each method of the Cascade returns the object.

  6. The length property of an array is the largest integer property name in the array plus one. So assigning a smaller value than the current one to the length property truncates the array.

  7. Avoid the for in statement and use the conventional for statement instead.

  8. When to use arrays vs. objects. When the property names are small sequential integers, use an array. If not, use an object.

  9. Regular expressions are best when they are short and simple.

  10. The array.sort, sorts arrays of numbers incorrectly because its default comparison method does a string compare.

  11. Use K&R style braces (put "{" at the end of the line) to avoid a serious language design flaw in JavaScript's return statement.

  12. Don't use an assignment expression in the condition part of an if statement.

  13. Don't allow switch cases to fall through to the next case.

  14. Don't use implied global variables. Any variable used without declaring it, will be global by default.

  15. Avoid using new.

  16. Always provide the radix parameter when using parseInt.

  17. If you intend + to add, make sure that both operands are numbers.

Link to book description: JavaScript: The Good Parts
Link to Douglas Crockford's JavaScript Video