Archive for the ‘Programming’ Category

Not Quite Murphy’s Law…

Friday, March 24th, 2006

Is there a name for the phenomenon described below?

  1. One has a problem developing or building something for some long period of time.
  2. In frustration makes a post to a newsgroup or other source of public support.
  3. A very short period of time later figures it out on his or her own.

It can’t be murphy’s law, because something went right for once. Or is it just something going wrong in a twisted, different way?

I was working through some tutorials for Macromedia/Adobe flex today, and was having some strange problems with the second tutorial (build a calculator) and not more than 30 minutes after posting to a yahoo group “flexbuilders”, I find the faulty configuration responsible.

Together at Last

Wednesday, March 15th, 2006

I was wrong all this time – here I was thinking that problems were either intermittent or reproducible, but apparently some particularly talented people write software with problems that are both. Thank heavens this support tool lets people report this interesting class of problems!

reproducible-or-intermittant.PNG

You can’t make this stuff up!

Adventures In ActionScript

Friday, March 10th, 2006

Once again, post work nap out of the way, I resumed doing my homework project and learning flash in the process. It seems (like most things) there are many different ways to use flash. On one extreme you can use the timeline along with automagic tweening functionality and very minimal scripts to lash things together, or you can go to the other extreme and use it as a visual programming environment, using object-oriented (well as OO as JS/AS get) externally defined scripts for everything. Being a programmer, I chose the latter.

One of the problem’s I’ve had is resolving fields in the various namespaces, particularly finding one “movieclip” from another. Its odd that everything useful has to be a movieclip or a button, and that you can only apply certain graphic filters to those type of objects. Back to the namespace issue – now that I seem to be able to properly find objects from one another, I encountered the problem that function objects in JS/AS don’t know what object instances they’re associated with like they would in Python. So setting a button’s event handler to call one of the functions in either approach below won’t work: (I wish I new why the editor in WordPress is effectively double spacing the text below by inserting break tags)


/* approach one :
* fails because doSomething will not be bound to this instance
*/
this.myButton.onRollOver = this.doSomething;
/* approach two:
* fails because this is not pointing to the right thing when it is executed
*/
this.myButton.onRollOver = function() { this.doSomething(); };

At this point I picked my roommate Phil’s brain because he’s always crawling around the obscure guts of languages like this, and found out some of these strange consequences of Javascript not really being OO – that the this pointer sucks and the above facts about the capabilities of function references.

Big thanks to him for pointing out this simple way to fix the problem using a closure:


var a = this;
this.myButton.onRollOver = function() { a.doSomething(); };

And for reminding me that you can do something like MochiKit does in their bind function to make “real” function pointers that know what instance they belong to (in a really stripped down form below)


class BindUtil {
static function bind(obj,func,args) {
return function() {
if (args != 'undefined')
func.apply(obj,args);
else
func.apply(obj);
};
}
}

Because that function makes it possible to pass arguments, one can easily define one handler to use for various buttons inline like this:


this.tempMinusBtn.onPress = BindUtil.bind(this,this.changeTemp,[-1]);
this.tempPlusBtn.onPress = BindUtil.bind(this,this.changeTemp,[1]);

So I’ve got one working dialog for my prototype due on Tuesday, but this is more functional that a lot of the rest will be. Its a screen from a inflight entertainment system we’re prototyping. The screen linked below is the climate control dialog that will fly in from the side to adjust temperature etc. The close button does nothing.

Flash Demo (Requires Flash Player 8 )

Only now do I notice that the control areas aren’t centered. I guess I’ll fix that later.

My First Flash App

Monday, March 6th, 2006

So I’m learning Macromedia Flash at long last, because I have a prototype due in a week. From the looks of my first little flash app, I have a long way to go.

Mouseover those labeled buttons at the top. I dare you.

Update: Kristi says the red ball doesn’t work for her. It works for me, so I dunno.

Interesting Java Snippet

Saturday, February 18th, 2006

I was at an interview yesterday and got something like this snippet as a test.

Apologies for the lack of tabs, whatever I try to put them in, wordpress defeats me.
public class ExceptionTest {
public String method1(){
try {
return method2();
}
catch (Exception e) {
return "method 1";
}
}
public String method2() throws Exception {
try {
throw new Exception();
}
finally {
return "method 2";
}
}
public static void main(String [] argz) {
ExceptionTest et = new ExceptionTest();
System.out.println(et.method1());
}
}

I was asked if I thought the finally block in method2 would execute before the catch in method1? So I puzzle over that for a while, trying to determine how the stack would unroll, particularly in light of the finally block returning a value. I think my guess was pretty good.

I went ahead and tested it to see what actually did happen, and it turns out that returning from a finally block as in this example generates a compiler warning, and gleefully prevents the catch block from even executing, resulting in the program printing out “method2″. If the return is removed from the finally block, finally still executes before the catch block, as expected so that it can clean up the local state of that stack frame, and the program prints out “method1″.