McArthur GFX

I originally setup my Tumblr unsure of what to use it for, so I just added a bunch of feeds to it, like my Twitter, my blog feed, my delicious links, and my github activity. But when I decided to actually use my Tumblr as a real blog, I decided I didn’t want all that junk in here.

For whatever reason, Tumblr doesn’t provide any sort of simple way to clean out a lot (1000+) of posts. The only way to delete posts it to scroll to the post in the dashboard, click the “delete” button, and wait for the POST to be submitted and the page reloaded, which forgets your current scroll position. I wasn’t going to do that 1000 times.

Thankfully, there’s a decent API that lets you easily receive all your posts. The posts have a field set if they had been imported through a feed. And with the dashboard using Prototype, it was a matter of putting together 2 functions to read and delete posts, and then some minor babysitting to make sure to pause when Tumblr would throttle me.

The past couple weeks I’ve been working on a website that, with JavaScript enabled, will never refresh the page. With MooTools, I just needed to manipulate the URL hash and use Request, making it fairly easy to get an Ajax site that works like Facebook. Granted, this has nothing about handling CSS or JavaScript assets for each page. I’m currently handling that myself, and perhaps I’ll share my findings for that another time.

The CSS2 Opacity property doesn't work in the current versions of Internet Explorer - through IE8. However, it has provided a way to achieve similar results with a different method, using IE's filter property.  Javascript frameworks usually work this in for you when you try to set an elements opacity in a cross-browser fashion.

It should come as no surprise that there are bugs that arise from this filter property. One is that the filter doesn't cascade to children that have their position as anything besides static.

This morning Jeff Atwood wrote about Fitts' law and the contrapositive in regards to big, bad eject buttons. The point of his piece was that you shouldn't have buttons with irreversible destructive results be right next to buttons with more frequent use.

I was actually more intrigued by a couple of the commentors when they mentioned a real life example of excellent "eject" button UI: these incredibly important buttons have a safety cap over them.

I’ve started contributing to the MooTools blog, and today my post about all the cool things that the Element module does for us in MooTools.

It’s covers:

• Differences between $ and $$
• How to create a new Element (better-er)
• How $ and toElement interact
• The special properties of the return value of $$

And a code snippet to whet your appetite.

//this would loop through each time at addEvent, addClass, and fade
$$('li a').addEvent('click', function(e) {}).addClass('alertable').fade('in');  

//whereas this will only cause 1 loop
$$('li a').each(function(link)  {
    link.addEvent('click', function(e) {
         alert(this.title);
    });
    link.addClass('alertable');
    link.fade('in');
});

Read the rest at the MooTools blog.

There's a couple ways you can define globally accessible variables in Javascript. And it turns out that in JScript, they actually mean different things (as opposed to all other implementations, where they're the same). This meant my GetClass implementation just plain wouldn't work for Internet Explorer. Well, that's no good, since that's a basic building block of my MooTools MVC framework. Now, I could require all classes be created explicitly, like window.Task, but that makes for a very inflexible pattern. And there's no reasonable way to explain to users why I'm requiring that.

So instead, I delved into JScript to find a way to let me iterate all global variables.

I've updated MGFX.Tabs to have a random slide function. It just uses Math.random, and a slight modifier to insure the random number isn't already the current index. Since I believe in semantic versioning, and this is a feature update (not a bug fix), but not breaking, its should be a new minor version.

var tabs = new MGFX.Tabs($$('.tabs li a'), $$('.tabs .content'));
tabs.random();

We've already learned that to make our Javascript load faster, we should be listening for a domready event instead othe window onload event. However, sometimes, you can actually make too much Javascript reliant on that sacred event. And when you do that, you can get quite the jump or flicker in older browsers.

We use a proprietary text replacement program instead of sIFR or Cufon or anything else out there. We call it Typostream. On one of my recent projects, we had several features of the web-site requiring extra Javascript functionality, along with a good portion of text being replaced. Originally, I had all of this Javascript being executed on DOM ready event, as best practices recommend. However, viewing the site in Internet Explorer revealed some amazingly laggy results.

LOG: Total: 244, Since Last: 244
LOG: Total: 1992, Since Last: 1748

As I continue to work on my MVC implementation in MooTools, I continue to find new hidden features in MooTools. This weekend, I was adding a view method to the controller, as a shortcut to creating a new View and rendering it. One of the arguments is the view file name, but I also wanted some automagic like CakePHP. It'd be great if the view function could determine the file name based on the function that called it.

Here's what I mean:

var ItemsController = new Class({
	view: function(view_name) {
		if(!view_name) {
			//viewname should default to 'controller/method'
		}
	},
	list: function() {
		$(this).grab(this.view()); // 'items/list'
	}
});

Last week saw the release of the MooTools Forge. And that's fantastic news for the MooTools community. If there was ever one thing MooTools lacked compared to jQuery, it was an easy way to find other MooTools code.

I love closures. They are an excellent tool any Javascript programmer should have in his tool set. They let you do fantastic things, and are the way things like the Module Pattern are possible. But they can also be tricky. I'll show you a couple ways they've managed to fool me, so that you can be aware of them when you use them in your programs.

Quite a while ago, I released a simple-to-use MooTools tabs class, and it continues to be one of the most frequented posts on the site. With so many people obviously desiring a MooTools tabs plugin, I've added a few new features to the plugin, as well as moved it to Github for inclusion in the future MooTools Forge.

I just wanted to document this rather frustrating bug here, so I can look it up later, and hopefully help anyone else who is running into something similar. This bug involves select tags, specifically setting their innerHTML property.

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.

One of my favorite methods that I use constantly in various interfaces combines fading and removing of an element. It could be a table row, or list item, or a div, but often times when I wanted to remove something, I'd like it to remove with a fade. And not always wanting to write to listen for the complete event and then remove the element. So I'll show the original I use in Prototype, and then a port to MooTools.

Dates are a peculiar type of data that we have to work with. In some sense, they aren't a number, but instead are a combination of month, day, and year. But at the same time, in most programming languages, they are fundamentally a number: the number of seconds since the Unix epoch.

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.

In two languages that I use often (PHP and Javascript), there's 2 different equality operators when comparing values. It's become quite common to see places expressly tell you that you should only ever use one of them. That the other is evil. People see this, and then point fingers whenever you use 2 equal signs instead of 3. Here's perfectly valid reasons to use equal operator (==) instead of identity(===).

I've talked previously about getting private variables and methods in your classes , but doing so was always kind of hacky.  In Javascript, elements don't have a native way to hide properties.  So we have to come up with creative ways like using closures .  In MooTools 1.2.3, we have a way to protect class methods.

MooTools lets you listen to events from 2 mediums: Elements and Classes. From classes, you can fire any event you want, and listen for it elsewhere. But with Elements, events are usually tied towards native DOM events. MooTools gives you the ability to define custom events for elements, by adding an entry to Element.Events .

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

As I continue to flesh out my MooTools MVC framework, I found a neat way to implement a templating system, using only what MooTools gives me. The goal of templating systems is to allow you to write in your target format (usually HTML), and denote where variables should be tied in.

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

...

Batch programming is certainly very easy to understand and write. You order a todo list and give it to the compiler/interpreter. It's what's usually taught first when you learn to program, and even in some server-side languages, you batch program (PHP doesn't have events at all, for instance). However, persitance applications that live on the desktop (and perhaps Ajax applications with minimal page refreshes) rely on event-driven programming. You set up a user interface, and then wait for the user to do something to that interface, and then respond to the event.

This is all well and great. But I've hit a problem a couple times recently as I create more desktop applications. I thought this would be easy to find, since I've hit the problem often and early. But I haven't, so I'll have to solve it myself. Sometimes, a component might have a one-time event that you need to listen to, and you don't know if that event has fired or not.

In Javascript, the this keyword can be a tricky thing. It's trickiness comes from how functions behave differently depending on how you call them. What? You can call them differently? Yep! There's 4 major invocation patterns for a function, so let's see how each works, and how they handle this.

1. Method Invocation
2. Function Invocation
3. Constructor Invocation
4. Apply Invocation

Basically, if you don't know what happens when you have multiple variables pointing to the same Object or Array, then check out this quick and dirty article and read the first half or so. Or if you don't want to bother, I'll give you a snippet to paste into Firebug.

var a = ['one','b',3,false];

var b = a;

a[1] = 'BEEEE';

console.log(b[1]);

Have you ever wanted to get the class name of an object, maybe to check what instance it is of, or maybe to use the name for something? I was in need of exactly that, so I set out to do so last night. I started by asking Stack Overflow , and no one gave me an answer, so I pondered about it a bit. I started paying attention to the Hash object.

I knew that inside a class function, this.constructor would reveal the function that makes new intances of that class. But that function is anonymous, so I couldn't ask for the Function.name property. But! But, if I have a value, I can check an object for the key of that value.

Just a quickie: I was browsing the new Class script of Mootools 1.2.2 , to learn about all the changes (which are quite awesome), and I hope to rework my Privates Mutator real soon to work with the new way of things. I noticed this immediately:

if (params instanceof Function) params = {initialize: params};

I didn't have the priviledge of using SWFObject or the likes.  I just needed to create a movie in a modal-like window that depended on the page you were on. So, taking a list of properties and params, I proceed to use the DOM methods to build my Object and Param tags. Well, Prototype 's Element methods, actually. It worked in Firefox, and partially in Safari / Chrome, and none at all in Internet Explorer 7.

With the release of Firefox 3, we find all major browsers now support a single interface (mostly) for allowing the Browser to do all of our Rich Text editting needs. This allows us to set a single property, contentEditable, and then that element accepts rich text processing. No more loading in an iframe, having document.domain issues, and having little control over the style of the iframe. This, however, does mean Firefox 2 and below are excluded from the party.

I probably spend more time writing PHP than I do Javascript (I'd like to reverse that but oh well). Well, PHP has so many functions, I'm constantly going to something like http://php.net/substr_replace to simply remember how a function works. It's not a long process, but it involves opening a new tab (Control + T), selecting the address bar (Control + D), typing php.net/substr_replace, and then loading the page.

To learn the basics of a Ubiquity command, I made it so all I have to do is open Ubiquity (Control + Space) and then type:

php substr_replace

Earlier this week I posed a simple programming question on how to determine if a string is a palindrome .  That was the first interview question I've recieved in my career, and wanted to share it.  Now I'll share my answer that I gave back then.

Interviewing as a programmer is always kinda fun (in my opinion).  The developers already at the company get to ask you fun challenges to solve (and what programmer doesn't like to solve problems).  I just rememebered one of the first questions I'd been asked on an interview, and I wanted to write a post on how to solve the problem.  But then I felt it might be nice to get others trying first.  So I'll offer the question, and then I'll offer my own answer in a couple days.

I've been working on a RTE using Mootools, and I wanted the toolbar to draggable. I always like it when I can drag something to the edge and it will dock itself. So, I extended Drag.Move to allow docking: Drag.Dock. With this class, which requires Drag and Drag.Move from the Mootools More, the draggable elements can now be docked to any side of the window.

After a good read though Javascript: The Good Parts , and the start of a rather large class that I'll be writing in my spare time, I thought of how I could setup private variables in a Mootools class.  YUI's Module pattern is an easy way to make some private variables, but it needed to fit into the Mootools Class pattern.  So I merged the two ideas, and created a Class Mutator, that lets you define a Privates object, and you get private variables!

If you use a library that mimics classical inheritance into Javascript, like Prototype or Mootools, then you use the new Element() expression aplenty. It feels far nice to do it all in one constructor-like call, then using document.createElement , and then node.setAttribute and so forth a bunch of times. But I'm not going to argue which is more proper. Instead, what I've found is an annoying inconsistency with Internet Explorer 7 (probably 6 as well, but I didn't bother to check the obvious) when specifying the onclick attribute .

Apparently, Aaron Newton and Valerio have released a mooBugger bookmarklet that you can save at a bookmark in one of your other browsers (Internet Explorer, Safari, et al).  This bookmark can then be clicked from any site, and it will load and run javascript on that page and build a close clone of Firebug .

Programming languages with C-style syntax all have logical operators for AND, OR, and NOT.  They are &&, ||, and !, respectively.  In Javascript, the way the languages determines logical operations and the values Javascript treats as true or false lead to people using the AND and OR operators for guard and default situations .  Let me explain.

The guys over at Ajaxian pointed out this neat little tutorial on using Javascript's Canvas.

I wrote a simple script to pop-up a modal-like element when clicking on an “Add” button on the page. I wanted to insert the element into the DOM on first click, and on subsequent clicks, simply reset the form. A bug popped up in IE7 (surprise) that prevented me from checking if I had inserted the element already.

I got to play around a little bit with YUI’s (I pronounce it yoo-ey) Rich Text Editor as I implemented a low-level CMS for one of my current projects. I’ve used TinyMCE a-plenty, and wanted to check out YUI’s implementation because theoretically YUI is far easier to extend. One thing that tripped me up was the styling, which in retrospect I should have noticed, but it irked me, so I solved it in my lazy efficient programmer fashion.

Last week, I released a pluggable Slideshow type Mootools class . I had written that class a while back, and since then had extended its functionality to allow me easily make tabs on any page. I wanted my tabs to have the ability to auto-switch if I wanted, so extending my Rotater class made perfect sense.

I’d like to release my first public class written for the Mootools framework. I call it the Rotater class, and its purpose is for those slideshow elements on pages, but without the need for controls. Most likely used for a splash-y area that should loop infinitely through images or content.

Javascript lets us run program logic on the client-side, meaning we can change HTML Elements dynamically based on some logic without reloading the page with a new server call. This logic is run by Events that are launched from User Interaction. A common way of doing so is adding inline Javascript events , but I’d like to erradicate this scourge from the web.

Steve Webster recently wrote an article about how horribly standards-stupid SproutCore (the Javascript framework Apple used to make MobileMe) is. He kind of has the right mind-set, in that Javascript should be a progressive enhancement to web-sites, and they should still function properly without i...

Read more

Mootools released version 1.2 a couple months ago. And it rocks. I find developing in Mootools to simple, and actually fun (go ahead, slap me with the geek word). I’ve been writing a few classes in my day office, and have found some rockin’ resources for leaning Mootools.

I have the most f...

Read more