Posted by Jonathan Dodds on May 16, 2007 at 09:50 PM in Mac OS X, Note To Self, Quick and Dirty | Permalink | Comments (0) | TrackBack (0)
I added a new category: ‘Quick and Dirty’. Quick and dirty posts have a specific technical focus. They may be about a bug, an issue, a tip, or a technique. I went back and added the category to about 16 existing posts. New quick and dirty posts will generally be short: quick to read; quick to write. They’ll be ‘dirty’ in the sense that the posts won’t be intended to be rigorously comprehensive. Sometimes it’s more valuable to be immediate than to be scholarly.
Posted by Jonathan Dodds on March 10, 2007 at 03:03 PM in Quick and Dirty | Permalink | Comments (0) | TrackBack (0)
It’s hugely convenient to be able to pop open a command shell (aka “Command Prompt”) in a given directory from the Windows Explorer. The Registry can be manually edited to add context menu commands and there is a Microsoft Knowledge Base article that describes one such approach but the PowerToys collection includes an “Open Command Window Here” item that’s a little more complete. The PowerToy adds shell commands for directories and drives.
Link: How to start a command prompt in a folder in Windows Server 2003, Windows XP, and Windows 2000.
Link: Microsoft PowerToys for Windows XP.
Apparently Vista includes an “Open Command Window Here” command but only on a Shift-Right-Click in the Explorer’s right hand pane.
Incidentally I always need to change the factory defaults for the Command Prompt. I have no great sentiment for monochrome displays and can’t see any sense to using white characters on a black background. I also change the font from ‘Raster’ to ‘Lucida Console’, enable ‘Quick Edit Mode’, increase the command history, increase the height of the screen buffer, and increase the height of the window.
Posted by Jonathan Dodds on February 20, 2007 at 11:17 PM in Note To Self, Quick and Dirty, Web/Tech, Windows | Permalink | Comments (0) | TrackBack (0)
Installing Internet Explorer 6.0 apparently doesn't update the scripting engines. The JScript (JavaScript) and VBScript scripting engines are separate components from the Microsoft browser but unlike some other components that IE depends on, the scripting engines don't appear to be updated by the IE installer.
A while back, after a new release, some users started receiving script errors from a certain web application. The users who were having issues all had Internet Explorer 6.0 running on Windows 2000. Windows 2000 shipped with IE 5.01 and version 5.1 of the scripting engines. A service pack probably updated these installations to IE 6.0. It would seem reasonable to expect that the scripting engines would have been updated to v5.6 but they were not. The scripting engines remained at v5.1.
A few notable features added after JScript v5.1 include:
Specifically the errors the users were seeing were caused by the use of push() and undefined.
To resolve the issues code like
vec.push(foo);
was rewritten as
vec[vec.length] = foo;
and code like
if (foo != undefined)
was rewritten as
if (typeof(foo) != 'undefined')
.
An installer for the v5.6 scripting engines can be downloaded from Microsoft's web site.
Posted by Jonathan Dodds on June 08, 2006 at 06:37 PM in JavaScript, Quick and Dirty, Web/Tech, Windows | Permalink | Comments (0) | TrackBack (0)
Here’s a word: expando. Here’s a sentence using the word: JavaScript has expando objects.
Expando sounds like a silly made-up word. And it might be. But it’s also an actual word in Latin. It means ‘to spread out.’ The Latin meaning is almost appropriate for JavaScript. Objects in JavaScript are expando objects because properties can be dynamically added (expanding the object) and removed.
var obj = new Object();
// add a property
obj.foo = 'bar';
// remove a property
delete obj.foo;
Since functions in JavaScript are first class objects, properties can be added to functions. A function can be made state-ful by setting a property. In the example below a function named process sets an error property on itself:
function process(input)
{
process.error = 0;
...
if (...)
{
process.error = 1;
}
return output;
}
If the process function has never been run, process.error will be undefined.
if (typeof(process.error) != 'undefined')
{
// test for an error
...
In newer versions of JavaScript this test could be written more directly as (process.error != undefined)
but using the typeof operator is more portable.
The undefined state could be eliminated by initializing the property outside the function:
var process = function(input) { ... };
process.error = 0;
Are state-ful functions a good practice? It would be problematic if the function can be called again before the previous state has been handled so, in general, keeping state in a function should probably be avoided.
Yes, I just said don’t do the thing I just showed how to do.
Instead of creating state within the function, the function can return a tuple. (Like expando, tuple has a Latin etymology. Did you think you would be learning so much Latin from a blog post on JavaScript?) Tuple is a term used in set theory and by extension the relational database model but in terms of functional programming a tuple is an object that holds several other objects.
A tuple could be implemented as an Array. Using an array would require knowing the position in the array of each specific datum. Depending on positional information is brittle especially for large sets. A better way is an implementation that supports named datums. With named datums the order is irrelevant and the code is more literate.
Here’s the process function modified to use an ad-hoc tuple:
function process(input)
{
var tuple = new Object();
tuple.output = null;
tuple.error = 0;
...
if (...)
{
tuple.error = 1;
}
return tuple;
}
Using the object literal syntax the tuple object and its properties can be created in one line instead of three:
var tuple = {output: null, error: 0};
Finally the returned tuple result could be handled as follows:
var result = process(in);
if (result.error == 0)
{
// do something with result.output
...
}
Related Posts:
JavaScript Closures
Posted by Jonathan Dodds on June 01, 2006 at 11:47 PM in JavaScript, Programming, Quick and Dirty, Web/Tech | Permalink | Comments (0) | TrackBack (0)
From the backup brain department:
When I need a connection string or a DSN, a UDL file is a handy way to quickly and accurately generate it. But I can never remember the UDL file extension when I need it.
Link: Creating and Configuring Universal Data Link (.udl) Files.
Posted by Jonathan Dodds on May 19, 2006 at 07:00 PM in Microsoft, Note To Self, Programming, Quick and Dirty, Windows | Permalink | Comments (0) | TrackBack (0)
There are times when it’s useful to throw a token parameter on a URL and have the receiving page test for the existence of the parameter. For example:
/website/page.aspx?foo
What’s significant is whether the token exists or not. It doesn’t need to have a value.
When I tried to use this trick in an ASP.NET 2.0 based application I found an issue. I expected to be able to test something like:
if (Request.QueryString["foo"] != null)
Parameters have the form <name>=<value> and I expected “foo” to be taken as a name with no value. But “foo” wasn’t a key in the QueryString collection. “foo” was interpreted as a value and the key was null.
That’s not very useful.
And I don’t recall any other web development environment behaving that way. I quickly tested against JSP and ‘classic’ ASP. Sure enough. In JSP/ASP “foo” is interpreted as a name with a null or empty value.
So how to test for “foo” in ASP.NET? I didn’t want to iterate the whole QueryString collection. That would be wasteful. I didn’t want to depend on an index position. Depending on fixed positions is brittle and counter to the whole point of using name/value pairs.
My solution? I changed my URL to
/website/page.aspx?foo=
Posted by Jonathan Dodds on May 04, 2006 at 06:01 PM in ASP, ASP.NET, Java, Quick and Dirty, Web/Tech, Windows | Permalink | Comments (0) | TrackBack (0)
POSTing to an ASP? ASP’s Request.Form requires application/x-www-form-urlencoded.
If you’re writing a web client of some sort that is trying to push data at an ASP based page via a POST request, you need to set up your HTTP headers correctly. To get ASP to parse the request body into the Request.Form collection the content-type must be “application/x-www-form-urlencoded” and the content-length must be set.
“application/x-www-form-urlencoded” is the default value for the HTML <form> element’s enctype attribute.
Posted by Jonathan Dodds on April 25, 2006 at 10:45 PM in ASP, Programming, Quick and Dirty, Web/Tech, Windows | Permalink | Comments (0) | TrackBack (0)
printf() debugging is the practice of inserting ad-hoc calls to printf() (or an equivalent) in an effort to see the code path and/or the changes in variable state. printf() debugging isn’t pretty but even when sophisticated logging and diagnostics are available it can still have a place as a useful technique.
I’ve seen debugging techniques for web applications where diagnostic information is cached and then displayed by writing it out as formatted HTML at the end of the page or setting it as the value of a textarea element or something similar.
But there’s a simpler, less obtrusive way.
Instead of building or borrowing the plumbing to cache the diagnostics and messing up the appearance of the page with stuff that doesn’t belong, generate inline HTML comments.
Sure. It’s an extra step to choose ‘View Source’ to see the comments. But it’s not really an inconvenience. And there’s no harm in leaving in comments that don’t contain sensitive information. They might just prove to be invaluable when used to support in-the-field troubleshooting.
Posted by Jonathan Dodds on April 24, 2006 at 10:02 PM in Programming, Quick and Dirty, Web/Tech | Permalink | Comments (0) | TrackBack (0)
Sometimes it’s useful to be able to quickly add or remove a section of code. Some languages have preprocessors that can help but here’s a ‘stupid’ comment trick to achieve the same.
C-style syntax languages (e.g. C, C++, Java, JavaScript, C#) support single line comments with ‘//’ and block comments with a ‘/*’ and ‘*/’ pair. The trick is that single line comments can be used to comment out block comments.
So here’s a commented out code block:
/*
var lorem = 'ipsum';
...
//*/
Note the ‘//’ for a single line comment in front of the block comment terminator. The block can be uncommented with a single keystroke, by adding a ‘/’ before the block start.
//*
var lorem = 'ipsum';
...
//*/
Posted by Jonathan Dodds on March 26, 2006 at 10:13 PM in C#, C/C++, Java, JavaScript, Programming, Quick and Dirty | Permalink | Comments (0) | TrackBack (0)