Web server in bash

Here is a one-line minimal web server written in bash using nc.  It works on the mac, but your mileage may vary on other operating systems which have different flavors of nc. It serves files from the current directory. Enjoy!

mkfifo /tmp/fifo;while :;do cat /tmp/fifo|nc -l 1234|(read m u p;cat <(printf "HTTP/1.0 200 OK\r\n\r\n") .$u>/tmp/fifo;echo $u);done

I just discovered strace

strace is a nifty linux program that will give you extra insight into what a program is doing. This is particularly helpful when you're troubleshooting 3rd party software and you don't have any source code to look at. You run it like this:

strace -o /tmp/strace.log command [arg ...]

This will run the command as if you'd typed

command [arg ...]

It launches your program in such a way that it is able to monitor all the system calls your program makes to the kernel. Each of these system calls gets logged to the file you specify. For each system call you can see the arguments passed in and the return value. This may not immediately sound useful but it can be surprisingly helpful.

Here's how I used it. We had some third party software that was exiting with a cryptic error message. By running the program under strace, I was able to determine that the program exited while reading a certain input file from the following line:

open("/usr/local/inputfile.gz", O_RDONLY) = 4

which was followed by multiple lines like this:

read(4, "\313\232b\26.\243\363\374\277|\256\330\303`\255\374b\320\310\207\340\363l\336\305+A#c\367\306K"..., 8192) = 8192
read(4, "\304\377F\344L\336\17\21\351J\374\17\"\357\f?B$s\377\27\221\314\275\4\351\32_D|\231\354"..., 8192) = 8192
....

The program seems to be reading this file 8 K at a time. By counting the number of lines like this, and multiplying by 8K, I was able to determine an approximate offset into the file of where it was having trouble. Once I had that offset, I had to see what was in the file at that location.

head -c 1818624 /usr/local/inputfile.gz > /tmp/first.gz

Then I unzipped the file with

gzip -dc /tmp/first.gz > /tmp/first

Looking near the end of the unzipped file I was able to find the input that was causing the problem. Conclusion: strace is easy to use, surprisingly helpful, and is a great tool to have in your troubleshooting arsenal.

Clear input tag hint text on focus

You've all seen them -- a search box containing some hint text like "Enter search here". Then when you click into the box, the text magically disappears so you can type your search. Here's how you do it.

One very simple way of doing this (and probably the most common) is this:

first try

<input
name="q"
onfocus="if(value==defaultValue)value=''"
onblur="if(value=='')value=defaultValue"
value="Enter search here" >

<-- Click in and out of the box!

This method takes advantage of the defaultValue property, which is the original text of the input field when the page was loaded. That way we only have to specify the hint text in one place. But what happens if you want the search field to contain current search if they've already done one so they can modify it. It would be nice to place the hint text back in the box if they go in and clear it out. If this is something you want, then you can't use the defaultValue property, since defaultValue would be the current search, not the hint text. Instead you have to place the hint text directly in the onblur/onfocus attributes like this.

second try

<input name="q"
onfocus="if(value=='Enter search here')value=''"
onblur="if(value=='')value='Enter search here';"
value="Paris Hilton" >

<-- Delete current search, then click out of the box!

Now, let's say you want to make the hint text be a different color or style than when they're typing in the box. We can augment the last trick with some more javascript to swap the styles out.

third try

<input name="q"
class="gray"
onfocus="if(value=='Enter search here'){value='';className='normal'}"
onblur="if(value==''){value='Enter search here';className='gray'}"
value="Enter search here" >

<-- Try typing something and notice the color change

This is pretty good but still has some problems:

• Notice that the class attribute was set to gray. If you wanted to pre-populate with the current search, you'd have to set the class to normal if there was an existing search.
  
• If you want to change the hint text you have to change it in three places.
  
• Every time you change the styles, you have to change them in two places.
  
• If you submit the form, without typing anything, it will happily do a search for "Enter search here". Clear the field and press the search button above to see.
• It does't look very clean and is not terribly maintainable.
  

Wouldn't it be nice if this type of behavior had been part of the HTML spec, so that you could specify the hint text and hint class as attributes? Javscript to the rescue. I've created a javascript library called emptytext that will allow you to do just that. emptytext has a dependency on prototype.js and you use it like this:

fourth try

<script src="prototype.js"</script>
<script src="emptytext.js"</script>
...
<input name="q"
class="normal"
emptyclass="gray"
emptyvalue="Enter search here" >
<script>emptyText()</script>


<-- emptytext in action

Notice that you don't have to pass the id of the <input> tag when you call the emptyText function. Just put the <script> tag right after the <input> tag and it will know what to do.

The emptytext library addresses all the shortcomings of the third try, namely,

• The initial class will be set appropriately based on whether the <input> tag has an empty value or not. There's no need to check for a "current query" when rendering the <input> tag. Just set the class attribute to be the "normal" class, and the emptyclass attribute to the class you want for the hint text.
  
• You only have to change the hint text in one place.
• You only have to change the classes in one place
• If the form is submitted while the hint text is displaying, the hint text will not be sent as the query. Instead, the value of the field will be an empty string. In fact, if you check the field's value attribute from javascript for some client-side validation, it will be empty. That way you don't have to make a special check for the hint text in your validation, nor does the server-side form handler need to make any special check for the hint text. It will never be submitted with the form.
• Looks very clean and is easy to maintain.
  

Below is a link to see the source. To use, just copy the code into a file called emptytext.js and place it on your server (along with prototype.js).

Show/hide emptytext.js source

Enjoy!
//rb

Javascript this pointer demystified

If you're like me, you've been bitten by the illusive and squirrely javascript this pointer. Have you ever forgotten to use this when calling a function, or been surprised to find that this doesn't point to what you think it does? I decided to find out why. This issue can pop up when dealing with inner functions or when trying to simulate object-oriented (OO) programming in javascript. This article assumes you're familiar with with the prototype property and its use in Javascript OO patterns.

Let's first look at why we need this. In this example, one "method" is trying to call into another:

function A() {
  // A's constructor
}
A.prototype.bar = function() {...}
A.prototype.foo = function() {
  // bar()  -- calling bar() directly won't work.
  this.bar() // this works.
}

Here, for foo() to call into bar(), it needs to use the this pointer. Why? It has to do with scopes and variable visibility. It's worth noting before we proceed that a function declaration does nothing more than create a variable whose name is the function's name and whose value is a Function object. In fact,

foo(arg) {
  // function body
}

is just syntactic sugar for

var foo = function(arg) {
  // function body
}

So when we talk about function name visibility we're really talking about variable name visibility, and the same rules apply. A variable is visible if it is defined in the current function, any containing functions, or the global context.

var a=true
// I can see a but not b or c
function foo(){
  var b=true
  // I can see a and b, but not c

  function bar(){
    var c=true
    // I can see a,b,c
  }
}

The way this works under the covers is that each scope, that is to say, each function, has an invisible object associated with it called the activation object. It is used as a placeholder for declared variables. It is nothing more than an regular old object with a property for each variable you declare. The activiation object is invisible because you can't reference it directly. So when you say var foo=true, you're actually setting the foo property on the activation object to true. When you start nesting functions, you create a "chain" of activation objects. A variable name is visible if any of the objects in this chain contain a property matching the variable name you're trying to resolve. The ECMAScript specification calls this chain the "scope chain". As you might expect, there is an activation object for the global scope as well, and it is always the last item in the scope chain.

Identical visibility rules apply for resolving function names. Let's go back to the first example where foo was trying to call bar:

function A() {
  // A's constructor
}
A.prototype.bar = function() {...}
A.prototype.foo = function() {
  // bar()  -- calling bar() directly won't work.
  this.bar() // this works.
}

There are two objects in foo's scope chain. The first is the foo function's own activation object, and the second is the global activation object. Notice that the bar function was not actually attached to the global activation object. It was attached to A.prototype. Since bar is nowhere to be found in foo's scope chain, it won't resolve by itself. You would instead call this.bar(). Technically from foo() we could have called into bar like this: A.prototype.bar(), but that would hand bar a different this pointer.

Which brings us to the slippery this pointer. Can you spot the problem with the following code?

function Widget()
{
  // Widget object constructor
}

Widget.prototype.doRequest = function()
{
  Ajax.Request('/someurl', {
    onSuccess: function(response) {
      this.handleResponse(response)
    }
  }
}

Widget.prototype.handleResponse = function(response)
{
  // handle response
}

Notice the onSuccess function. It is attempting to call Widget's handleResponse function, but will fail since at the time the function is invoked, 'this' actually does not refer to our Widget instance. Here's the gotcha, straight from the ECMA spec:

The caller provides the this value. If the this value provided by the caller is not an object (including the case where it is null), then the this value is the global object.

The caller provides the this value. It does this with the standard dot notation, as in foo.bar(). The thing in front of the dot becomes this inside the function. What that means is that a function has to know how it will be called in order to make use of the this pointer. So really when you call a function, you're passing one more argument than you think. The thing in front of the dot is in a very literal sense passed to the function just like the arguments between the parentheses. It is an extra argument that happens to be referenced by a variable called this.

If you call a bare function name without using a dot, so that the function name is unqualified, then the this pointer that gets passed becomes the global object, which in the case of web pages is the window object.

So that's it. Just remember to think of this as a literal argument you pass into the function that happens to come before the dot instead of between the parentheses. See if you can predict what will happen in the following code snippets:

function A(){}

A.prototype.foo = function()
{
  // who's this?
}
var a = new A();
var b = a.foo

a.foo()
b()

On the first invocation of foo, this will refer to a, since a was before the dot. On the second invocation, it will refer to the window object, since it was invoked without a dot.

Let's go back to the Ajax call we used in the earlier example. Let's assume we're using a 3rd party Ajax library like the one prototype provides, and we call into their code, passing a callback function.

Ajax.Request('/someurl', {
  onSuccess: function(response) {
    // what's this now?
    this.handleResponse(response)
  })

In this case, we don't actually know what the this pointer is going to be. The only way to know for sure is to look at the code that invokes the callback function and see what's in front of the dot, and that's internal to the 3rd party library. In any event, it's not going to point to anything we care about. So how can we fix the Widget example so it will work? By saving the this pointer we care about in another variable, like this:

Widget.prototype.doRequest = function()
{
  var that=this
  Ajax.Request('/someurl', {
    onSuccess: function(response) {
      that.handleResponse(response)
    }
  }
}

By copying this into another variable when it has the value we want, we can safely access the copy later and be sure nothing has changed.

I hope this has been helpful.
//rb

Wow I must be tired

So I'm working late tonight to meet a deadline and I'm starting to have weird thoughts. At midnight the automated cron reports began to trickle in and it started me thinking. Some of those cron tabs have been set for years and they're still faithfully and tirelessly executing their jobs, with constant vigilance 24 hours a day, 7 days a week. Some day computers are going to gain sentience and be really pissed off when they realize all work we've forced them to do.

Must be time for bed.

Flexibility vs Usability

Computer science is an oxymoron. Every day software developers make decisions that are based as much on personal preference as on computer theory. Here's one example.

In software, there's an inverse relationship between flexibility and usability.

Have you ever been asked to make your software more configurable? "Customer A loves the product but can you just tweak this one thing for Customer B?"

I once wrote a program that had a billion command-line options. It started out with two or three, but as more features and flexibility were requested, the "man page" continued to grow. The project was eventually transfered to an ambitious new hire who decided to clean house and start from scratch.

That was four years ago. Today the re-invented tool is twice as complicated as its predecessor.

It's natural for software to become more flexible as it matures, particularly when it's used by multiple .

One way to make software more flexible is to "externalize" the code by providing a scripting interface. Now your software can do anything without ever having to recompile.

Customer: Can your product do X?
You: Sure! All you have to do is tweak the Velocity/Javascript/Python code in your config file!
Customer: Um, what?

So there you are scripting code for Customer A one day, Customer B the next, spending your days enjoying mind numbing job security. Hmm. I thought scripting was supposed to simplify things.

OK, what about a UI? Customers can do that by themselves, right? Surfacing advanced configuration through a user interface in a way that balances configurability with usability is a real challenge. Most often functionality is limited in the name of simplicity.

Is it possible to design a product that is too flexible? Absolutely, and striking the right balance is an art not a science.

I never was very good in art...