McArthur GFX

I kinda like Twitter. It’s a fun place to leave occasional comments. It’s also a great way to find links to interesting information I would normally miss from my feeds. But being a Windows user, I have yet to find that Twitter application that is a joy to use.

I’ve tried out a couple applications, and found each one lacking:

• Tweetdeck
• DestroyTwitter
• Seesmic

There might be a decent application out there that I haven’t found, but these are the most popular ones available to Windows. It almost feels like people only want to make cool stuff for Macs.

In game development, it's very common to want a random number. Maybe you want to determine damage done, if there was a critical, or what slot on the board to insert your piece at. And surprisingly (or perhaps, not), programmers are often looking to make this random number a little less... random.

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

Something a Java programmer learns first is that there is this big, amazing library already built-in to Java, and you can easily use plenty of useful classes by using an import statement. Possibly the first thing you want to do is pop open a box to prompt your name, or say hello, and thus starts this terrible habit:

import javax.swing.*;

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'
	}
});

If you write a lot of Javascript or PHP, there are a couple of habits you might be used to that need to change a bit when you switch over to Python.

1. Accessing a property in a dictionary with a variable
2. Setting properties on objects with a variable
3. Using While with a function call

Recently, there has been a bit of talk about upcoming tablets like the CrunchPad and the iSlate, and whether we need them, how useful they'll be, or ifthey're only use is browsing the web on the toilet. Many people are of the opinion that we don't need one. Or that only gadget enthusiasts would buy it for couch web browsing. Well, I'll go out and say it: Tablets will replace everything.

It's amazing that this decade is finishing off already. Time really does get faster the longer I feel it. Anyways, here's a summary of the activity on this blog for the year.

1. I started the year off with sharing a Privates Mutator for MooTools prior to v1.2.3. 
2. Next, I shared a Drag.Dock class to ...

Read more

As a deadline approaches far faster than you can type, you're required to write some quick-and-dirty code to fulfill those feature requests.

In case you don't know what I'm talking about, this is when there happens to be a flaw in your program's structure. It's an architectural problem: you did properly build the system to elegantly behave in an expected manner. Sometimes, it's a problem from bad planning at the start. In other cases, it comes from scope creep, where features get slipped into a system that previously was not going to have such features.

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.

In a recent pet project, I'm exploring Django. As I'm used to in our PHP framework, I like to extend Models with methods that a model should keep contained, and then I can call multiple times elsewhere in the Controller View in Django (don't start me on the stupidity of the naming scheme). In PHP, it's a bit more straight forward: You can simply write some new functions inside the class. In Django, it was a little more complicated. I explored several different parts that all affect writing methods that should be contained in the Model area of the application.

LAMP is common lingo for web developers. It's an incredibly popular software stack to run dynamic websites. Many hosting companies include the stack for you, already configured and ready to go. But before we get there? That wonderful point where we trust our code to the production server, and then watch something blow up beautifully in a fire-y mess of status codes, fatal errors, and SQLStates. We developers like to test thing before then.

So I'm left wondering, why does setting up a testing environment suck so hard?