I had a list of options to give to the user, and a select box would work perfectly. Since DOM methods have burned me in the past, I felt innerHTML was the safer route. It appears, that they both have safety curves like a sine and cosine graph.

The Buggery

Here's what I thought would work of stupendously!

var options = '<option>' + item.options.join('</option><option>') + '</option>';
selectEl.innerHTML = options;

It works in Firefox, Safari, Chrome, etc. Except Internet Explorer. I first noticed in IE7, and so when I went to debug (using IE8's sweeter debugger), I noticed it even breaks in IE8.

It disregards completely the first <option> in the string. Go ahead and try it yourself. Open IE8, press F12, go to Script, and try this super simple task:

var selectEl = document.createElement('select');
selectEl.innerHTML = '<option>this one breaks</option><option>we dont work because the first one is broken</option>';
document.body.appendChild(selectEl);

Solution

It breaks even that. So I resorted to DOM methods to build my select field.

for(var i = 0; i < item.options.length; i++) {
    var option = document.createElement('option');
    option.innerHTML = item.options[i];
    select.appendChild(option); 
}

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

GoogleMaps::geocode

class GoogleMaps {
	
    private static $api_key = 'your_own_api_key';
    
    public static function geocode($address, $format = 'json') {
        
        $data = array(
            'q' => $address,
            'key' => self::$api_key,
            'sensor' => 'false',
            'output' => $format,
            'oe' => 'utf8'
        );
        
        $ch = curl_init();
        
        $get = 'http://maps.google.com/maps/geo?' . http_build_query($data);
        
        //set up endpoint
        curl_setopt($ch, CURLOPT_URL, $get);
        
        //make sure we get the response back
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        
        //setup timeout options
        curl_setopt($ch, CURLOPT_TIMEOUT, '30');
        
        $responseText = curl_exec($ch);
        
        return $responseText;
    }
    
}

Grab your API key, plug it in, and then you can easily geocode an address. Let's take a look at the parameters that we send through curl.

• q - The address query.
• key - Your API key.
• sensor - If the device has GPS capabilities. Set this to false.
• oe - The output encoding. You want utf8.
• output - The output format. Can be json, csv, xml, or kml.

I love working with JSON, since it works so perfectly in Ajax responses, and PHP has the super easy json_decode function, making it much easier to use than XML. I'll show you an example of the response you would receive in JSON:

{
    "name": "1600 Amphitheatre Parkway, Mountain View, CA",
    "Status": {
        "code": 200,
        "request": "geocode"
    },
    "Placemark": [{
        "id": "p1",
        "address": "1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA",
        "AddressDetails": {
            "Country":{
                "CountryNameCode": "US",
                "CountryName": "USA",
                "AdministrativeArea":{
                    "AdministrativeAreaName": "CA",
                    "Locality":{
                        "LocalityName": "Mountain View",
                        "Thoroughfare":{
                            "ThoroughfareName": "1600 Amphitheatre Pkwy"
                        },
                        "PostalCode":{
                            "PostalCodeNumber": "94043"
                        }
                    }
                }
            },
            "Accuracy": 8
        },
        "Point": {
          "coordinates": [ -122.0841430, 37.4219720, 0 ]
        }
    }] 
}

Makes for easily grabbing of the longitude and latitude with $response->Placemark[0]->Point->coordinates.

If you're trying to get the address back out of the request, maybe to get the official, properly formatted address, you might hit a few quirks. Such as, some places will have a SubAdministrativeArea, and others won't. The addresses that do have that (such as a county), the LocalArea object will be inside. With a bit of wiggling, you'll get it.

Be sure to check out Google Code for more info on the geocoding services.

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

Prototype

Element.addMethods({
	fadeAndRemove: function(element, duration) {
		element = $(element);
		duration = duration || 0.6;
		element.fade({
			duration:duration,
			afterFinish: function(e) {
				element.remove();
			}
		});
		return element;
	}
});

MooTools

Element.implement({
	fadeAndDestroy: function(duration) {
		duration = duration || 600;
		this.set('tween', {
			duration: duration,
			onComplete: this.destroy.bind(this)
		});
		this.fade('out');
	}
});

The big differences in the two versions, is that Prototype's base time unit in the animations is the second, and MooTools uses the millisecond. And that Prototype calls element removal remove, and MooTools calls it destroy. Also be sure to use the proper way to extend Classes, addMethods or implement.

You'd proceed to use this combo function like so:

$('elem').fadeAndDestroy();

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

In our heads, it's quite easy to do Date math. Moving forward a week requires just adding 7 days. How would you do that with a Javascript Date? Programming languages usually try to make working with Dates as logical as it is to do in our heads. So I a little surprised at an irregularity in using Dates in my math.

Though to be fair, it seems I could blame it on Javascript's decision to make the addition operator and concatenation operator the same symbol. I only did some quick, sloppy tests in Firefox 3.5 and Chrome 3.

Adding to Dates

I first wanted to move a date forward a week, so I thought that perhaps I could add 7 days worth of milliseconds to the date to get next week. Go ahead and try it:

new Date() + (1000 * 60 * 60 * 24 * 7)

The value is a string: "Fri Sep 18 2009 16:37:01 GMT-0700 (Pacific Daylight Time)604800000". Yup, there it is! Our week's worth of milliseconds, attached on the end of a Date string. It would seem that Javascript decides that the Date should be evaluated as a string instead of a number at that point.

How To Add

In order to add to Dates, I had to create a new Date, using the value returned from getTimeand adding milliseconds to it, and using that new (humongous) number in the constructor.

var nextWeek = new Date(today.getTime() + 1000 * 60 * 60 * 24 * 7);

Also to keep in mind here, is that unlike in, say, PHP where you provide seconds to the date function, in Javascript, you must provide milliseconds, hence the extra 1000 in there.

Subtracting from Dates

Now, until I remembered that + means to different operations in Javascript, I was rather shocked that I could easily subtract from Dates, but not add.

new Date() - (1000 * 60 * 60 * 24 * 7)

Result is a number:1252714884521.This does the proper math, but not everything I had hoped and dreamed for. No matter, receiving a number is certainly a result I could expect, as opposed to the string joining from addition.

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

In PHP

$dayOfWeek = date('w', $date);
$secondsInDay = 60 * 60 * 24;
$sunday = date('Y-m-d', $date - ($dayOfWeek * $secondsInDay));
$saturday = date('Y-m-d', $date + ((6 - $dayOfWeek) * $secondsInDay));

$entries = TimeEntry::find(array(
	'timestamp =<' => $saturday,
	'timestamp >=' => $sunday
));

In English

First off, PHP's date method can be given a parameter to return the numerical day of the week. So, if $date were today, we'd be storing 4 (Sunday is 0). Now, with just a little bit of math, we can subtract the number of days to get Sunday, and add the difference to get Saturday.

That last bit is a data model searching for all entries between those dates.

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

In Javascript, depending on the browser, getting the value from inputs, especially when I expect to get a number value, can often times be a number in string format. And in those situations, I don't care . If I'm looking for someone to be 21, I don't care if they claim to be 21, or '21'. They both work for me.

My options are to use a nice, simple equal operator, or do something more verbose , harder to read , and suckier to write , to make sure I use the identity operator.

I'll do it this way:

if(elem.value == 21) {
	//enter bar.
}

So I don't have to write this sillyness:

if(elem.value === 21 || elem.value === '21') {
 
}//or
if(parseInt(elem.value, 10) === 21) {
 
}

Alternatively, I could write some method in PHP that manipulates a string of input. Before I do anything to it, I'm going to verify it's something I can manipulate. If it's null, or false, or an empty string, or zero, I don't much care. All those things should rejected. There's no need to use some sort of identity operator when I can safely say that anything falsy is no good to me .

function echoProperName($str = null) {
	if($str != null) {
		echo ucwords($str);
	}
}

I recognize I don't even need to use comparison operators at all in this example, yet this very usage I have seen flamed for not using the identity operator. Ridiculous. It doesn't fit here.

Programming languages give us loads of expressive tools, but by some sort of "convention", we get told not to use many of them. You can smash your thumb with any tool . No need to tell me not to use '==' or '++' or some such because some people have hurt themselves with it.

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

Private vs Protected

The difference between private and protected variables in most languages is that private can only be used in the same class. Protected is similar, but it can also be used from a class that extends the base class. Private properties are off limits to children.

Engines must Start before Running

When writing your classes, you can specify methods that should be protected by building the function in a similar way you bind functions:

var Engine = new Class({
	initialize: function() {
	
	},
	start: function() {
		//... starting magic ...
		this.rotate();
	},
	rotate: function() {
		var rotate = true;
	}.protect();
});

See that .protect() on there? That function is now protected. Which means, that only other internal methods can call that function. If we instantiate a new Engine, we can't tell it to run ourselves. We can only tell it to start, and the engine will do all its starting magic before making it run. Capiche?

Now, when you're designing your classes, keep in mind the API you want to present the class' users. Several MooTools classes only share a couple methods for public use, and many other functions are written for internal use only. With protect, you can make sure none of those methods are relied upon , or possibly called before another method that is supposed to be called first .

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

Certainly, as Michael Braude says, the barrier to web development is incredibly low. HTML can be learned in a couple hours.  A couple more and you can make something "just work" in Javascript. As a web programmer, I never have to worry about 3D rendering, rarely do I ever have to care about threading, writing to disk is taken care of for me by SQL.  The problems we're trying to solve usually aren't so astronomical to need an ingenious algorithm designed.

Instead, much of the work is on the user interface.  The problems we solve is usually how to do make it simpler. It must work for general internet users.  They must be able to use it easily. Our research and thinking must be more on human psychology and people's attempts to use our software.  We don't have the luxury of assuming our software will be used by another nerdy programmer willing to bang away on a command line all night long.

Not Smart Enough

I don't mean to single Michael out (his post does have a bit of sense to it), but it's the most recent statement I've seen of this large view people seem to have towards web developers:

The reason most people want to program for the web is that they’re not smart enough to do anything else.  They don’t understand compilers, concurrency, 3D or class inheritance.  They haven’t got a clue why I’d use an interface or an abstract class.  They don’t understand: virtual methods, pointers, references, garbage collection, finalizers, pass-by-reference vs. pass-by-value, virtual C++ destructors, or the differences between C# structs and classes.  They also know nothing about process.  Waterfall?  Spiral?  Agile?  Forget it.

So, can "not smart web programmers" understand this archaic desktop vocabulary?  Of course.  Compilers are used in 2 of the major development stacks (Java and .NET), we use class inheritance, interfaces, and abstraction all throughout MVC.  And yes, several of us actually understand how it all works.  References, garbage collection, pointers, of course!  Many of us use all of this wizardry in building our web applications.  At least, those that would actually call themselves programmers.

The fact is, most of us professional web programmers came from desktop programming.  We've worked for desktops, now we're targeting the web.  And we'll likely continue to go back and forth, until most everything has moved to the web.

Why The Hating

I've already said web-sites can be easily made.  HTML is easy! So, sure, people will get involved who don't know any better.  But that's not unique to the web.  The same problem was around before web applications existed.  Back then, you'd get people who take a look at BASIC, learn how to store variables, print to the screen, accept input, and write GOTOs.  And their programs sucked, too.

Where ever people have the power to build something, people will architect crap . Whatever comes after the web, where great and exciting things are going on, people will make crap there too. Apart from all the crap, though, there are talented programmers writing excellent applications using good design and principles.

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

Some practical uses can be found, such as the domready event that the document fires, or extending the click event to always change your cursor. I want to touch on this interface though, to show how you might solve my problem I mentioned 2 weeks ago: looking for events that would only fire once.

This is only useful for Element Events. I haven't researched doing this with an event from a class. That will probably use the same principle. But let's move on!

Element.Events

When you add an event to Element.Events , you specify an object with up to 4 properties:

• base : A DOM Event that is needed to trigger this. For instance, a doubleclick event would use click as it's base.
• condition : a function the returns a boolean for whether the event should fire. Our same example, doubleclick, would time the interval between clicks and return true if the time difference was small enough.
• onAdd: a function that gets called whenever you subscribe to the event somewhere else ( someEl.addEvent('doubleclick', ... ) ).
• onRemove : a function the gets called when you called removeEvent

With this in mind, we will consolidate the process of keeping track of one-time events in our custom event.

oneClick

Attach a listener, determine if the event has already fired, and if so, execute the listener immediately.

I couldn't come up with an excellent custom event, so we'll pretend that I might have an element that can clicked once, and only once, no matter what. Let's implement oneClick.

Every time I subscribe to oneClick , we'll check a property to see if it's fired before, and if so, execute our new listener then and there. If not, continue as normal. Then, when the event does fire, we will set a property that the event has fired in the condition, and after that, make our condition return false, so that the base event never makes our custom event trigger more than once.

 
Element.Events.oneClick = {
	base: 'click',
	condition: function(event) {
		var fire = !this._oneClicked;
		this._oneClicked = true;		
		return fire;
	},
	onAdd: function(fn) {
		if(this._oneClicked) {
			fn.call(this);
		}
	}
};

Now, we can listen on an element for oneClick, and listen for it somewhere else, perhaps later. Who cares. I can feel assured that this event will happen only once. And all new listeners that might have depended on my element being clicked (like a Start button) will work too!

$('startButton').addEvent('oneClick', function() {
	Timer.start();
});
 
// ... else where
$('startButton').addEvent('oneClick', function() {
	Toolbar.show();
});

One Limitation

So far, the one limitation I found, was that you had to not need the actualy Event object in your listener. As in, you can't check the event.target , or mouse x and y coordinates from the event. This is because from the onAdd method, we don't have access to a native event, since one hasn't actually fired. I found this trying to call e.stop() in my testing script. This doesn't bother me much, but be warned.

Implementing this for Elements was easier than for Classes, because of MooTools custom element events system that already exists. I have an actual need for the Class events to be one-time, but found this out along the way. Do you have a use for this?

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.

MooTools gives this power directly to every String!

String.prototype.substitute

Substitute lets you write a string, declaring delimiters where you would like variables to belong. So we can write:

var example = 'My name is {name}.  I love {passion}';

Now, all we have to do is use an object with those properties set, and call the substitute function, and it will do all the replace magic for us.

var obj = { name: 'Sean', passion: 'programming' };
var subbed = example.substitute(obj);
alert(subbed); //My name is Sean. I love programming';

Now, I said we can use this awesome power for a simple template usage. See where this is going?

A Simple Template View

My view has more going on than this, but I'll remove the rest so you can see simply the templating part that is going on.  It's very easy to use, indeed!

var View = new Class({
    
    template: '<a href="/task/view/{id}">{name}</a>',
    
    render: function(data) {
        var template = this.template.substitute(data);
        return new Element('div',{html: template}).getFirst();
    }
    
});
 
var firstTask = {
    id: 1,
    name:'Write Subsitute Article'
};
var taskView = new View();
document.grab(taskView.render(firstTask));

By defining the template in a string, we just write out the html for an anchor tag of my view.  We make a new View, make an object, and tell the view to render using the object. The last part is simply turning the string into HTML by inserting it into a div, and then grabbing the element back out.

Follow me on Twitter

I have little spurts of ingenuity on Twitter, follow me: @seanmonstar.