McArthur GFX

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?