2008 January | Building Blocks

31Jan/083

Design Patterns Cheat Sheet

Jason McDonald has created a very well put together design patterns cheat sheet. I thought it would make a nice poster, so I made myself a print resolution version and ordered it through Zazzle. I'm looking forward to hanging it on the wall!

Filed under: design patterns, software architecture 3 Comments

22Jan/081

KitchenSync – open-source Actionscript 3 tweening and timing animation library

Mims Wright has released an open-source animation library for Actionscript 3. This has a lot of promise. From the author:

KitchenSync was designed for developers who want a smart way to handle animation or other time-based functionality with code. Written from the ground up in ActionScript 3.0, KitchenSync relies on smart object-oriented architecture rather than complicated shorthand. It includes a number of features and shortcuts, such as the clone() method, that save effort for developers. KitchenSync makes extensive use of events and informative runtime errors and is quite flexible when it comes to extending the functionality.

This philosophy makes me think that KitchenSync will fit in nicely with pureMVC.

Filed under: actionscript, libraries 1 Comment

21Jan/080

Bram Cohen on what it takes to be a great programmer.

Bram's complete words here.

There are only two coding skills which mostly people who are completely self-taught as a programmer miss out on: proper encapsulation, and unit tests. For proper encapsulation, you should organize your code so that changes which require modifying code in more than one module are as rare as possible, and for unit tests you should write them to be pass/fail so that all unit tests can be run as a comprehensive suite. And now you know everything you need to about those two things. Anyone who is taught the above guidelines, and decides they really want to learn those skills, will with sufficient practice become good at them.

Coding skill is all well and good, and you can't become a great programmer without it, but it's far from everything. I'm decent at raw coding, but I know many people who are better, and some of them are abysmal programmers. I in particular can't deal with being tasked with fixing up spaghetti code. My brain simply locks down and refuses to make any modifications which it isn't convinced will work, which is of course impossible when the source material is an incurably bug-ridden mess.

I've felt this way about my own code with almost everything I've written to date. It has been a struggle for me, to go from an unstructured mess to something other people might be able to look at without throwing up.

It is apparent why people might skip over the 'proper encapsulation and unit tests' while teaching themselves software programming in a non-formal way. They are easily overlooked, and without a grade-book shaped stick hovering over your backside to force that sort of formality, one could easily just slide past these skills and program off the cuff. One of my challenges in learning to program has been to build things properly, to not re-invent the wheel every single time I sit down to make something meaningful in software. My preference is to stand on the shoulders of those that have come before me, and use the collective knowledge of masters, past and present, to expand my understanding and knowledge in appropriate directions. The trick is to do all of this with an open mind. We need to evaluate new ideas and differing opinions without locking onto one particular nerd dogma. I don't know that I will ever be a great programmer, but I will have fun trying.

Here's another interesting piece regarding software education and what it takes to be a great programmer: Who Killed the Software Engineer? (Hint: It Happened in College)

Filed under: OCD, Unit Testing, software architecture No Comments

21Jan/080

Holding a Program in One's Head

A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he's working on. Mathematicians don't answer questions by working them out on paper the way schoolchildren are taught to. They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will.

I was discussing my recent experience with programming dreams, some might say nightmares, with Cliff Hall. He pointed me to this essay from Paul Graham that really nails it. It is so difficult to just shut down after a long period of working on a difficult programming problem. I find myself staying up way to late, because I don't want my brain to lose the trail with mere sleep. Will... sleep... when... dead...

Filed under: OCD, Paul Graham No Comments

21Jan/081

FlexUnit – Some useful examples and tutorials covering unit testing in Flex and Actionscript 3.0

In an effort to build my skills and create applications that are based on a firm foundation, I am implementing unit testing. So far I am completely sold on the concept, and while I'm not quite to the point of full TDD, I can see the benefits immediately with the tighter code and confidence level that accompanies it. Here are some of the useful resources that I came across in my research. They are all centered around FlexUnit, the 'official' unit testing framework for Actionscript 3.

Neil Webb has an article on Adobe's Developer Center that covers the basics of getting started with FlexUnit. It is thorough and easy to read. This is probably the best starting off point that I have come across

Theo Hultberg has some valid critiques of the framework, as well as an alternative approach to the 'Temperature Conversion' example that is supplied with the FlexUnit distribution. I found this to be extremely helpful in deciphering FlexUnit and getting it up and running in my project.

Eric Feminella has created a simple API called TestUnitHelper that includes static methods to eliminate some of the tedium involved with creating unit tests with FlexUnit. There is some overlap with some of the points Theo touches on in terms of parsing test methods, but Eric's API is straight forward and gets the job done. Eric is a busy man, be sure to check out the trove of other useful APIs while you are there.

Daniel Rinehart gives a decent explanation of how to handle asynchronous calls in FlexUnit tests in the Flex Cookbook (beta). He also writes up another similar example over on his blog. I'm still not quite there with this concept, but these articles are a step in the right direction.

1/23/08 - I found this page with a huge repository of FlexUnit resources.

Filed under: FlexUnit, Unit Testing, actionscript, flex 1 Comment

15Jan/081

Actionscript string replacement and international currency.

This made me a little nostalgic for the olden days when a vacation to Europe was a remote possibility:

var str:String = "Now only $9.95!";
var price:RegExp = /\$([\d,]+.\d+)+/i;
trace(str.replace(price, usdToEuro));
 
function usdToEuro(matchedSubstring:String,
                    capturedMatch1:String,
                    index:int,
                    str:String):String {
    var usd:String = capturedMatch1;
    usd = usd.replace(",", "");
    var exchangeRate:Number = 0.853690;
    var euro:Number = usd * exchangeRate;
    const euroSymbol:String = String.fromCharCode(8364);
    return euro.toFixed(2) + " " + euroSymbol;
}

Filed under: actionscript, travel 1 Comment

10Jan/080

Maximizing your AIR application programatically – stage.nativeWindow.maximize()

Just be sure to call it in an applicationComplete handler. My attempts to call it from creationComplete were resulting in a null object reference.

1	stage.nativeWindow.maximize()

Filed under: AIR, actionscript No Comments

5Jan/080

Django Authentication from Flex

This method isn't very good, and I would recommend using this instead. This will still work, but I believe it is better to maintain a proper browser session and not do all this monkey work for authentication.

Django 'salts' passwords for added protection. They use SHA1 with a random key applied to further obfuscate the resulting hash. This is a good thing, but it threw me off for a bit. I don't want to send the unencrypted passwords over the wire, so I needed to grab the hash string from Django, break it apart, and reassemble it inside of flex. This did the trick:

private function onGetUsersComplete( re:ResultEvent ):void
{
	var users:Array = re.result as Array;
	var userArray:Array = [];
	for ( var ii:int = 0; ii < users.length; ii++ )
	{
		var user:UserVO = users[ii] as UserVO;
		userArray.push( user );
		trace( users[ii].first_name );
	}
 
	var isValidUser:Boolean = false;
	loginService.removeEventListener(ResultEvent.RESULT, onGetUsersComplete);
	for ( var i:int = 0; i < users.length; i++ )
	{
		if ( users[i].username == this.username )
		{
			currentUser = users[i] as UserVO;
			var salt:String = users[i].password.split('$')[1];
			//django specific password scheme
			password = 'sha1$' + salt + '$' + SHA1.hash( salt + password );
			loginService.verify_credentials( username, password );
			loginService.addEventListener(ResultEvent.RESULT, onVerifyCredentialsResult, false, 0, true );
			isValidUser = true;
		}
	}
 
	if ( !isValidUser )
	{
		sendNotification( ApplicationFacade.LOGIN_FAILED, "Invalid Username" )
	}
}