programming channel

Ruby Gotcha of the Day

toby ho — Fri, 26 Dec 2008 19:03:23 -0500

Okay, so in ruby:
>> nil or 'value'
=> "value"
because nil acts as false when used with boolean operators and any other object acts as true. Now let's assign the result to a temp variable a:
>> a = nil or 'value'
=> "value"
>> a
=> nil
Whoa?? Can you guess? In ruby the assignment operator is not special. It acts just like any other operator and does not have a lower precedence than the or operator. Therefore the expression
a = nil
executes first, which evaluates to nil, and assigns the value nil to a, and then the result nil is used in the expression nil or 'value'. Therefore to do what we intended we need to do:
>> a = (nil or 'value')
=> "value"
Wow! That is messed up.

Multiline Strings in Javascript

toby ho — Sun, 21 Dec 2008 20:32:21 -0500

I was looking through the code in facebox.js(a jQuery plugin) and I saw this:
'\
    <div id="facebox" style="display:none;"> \
      <div class="popup"> \
        <table> \
          <tbody> \
            <tr> \
              <td class="tl"/><td class="b"/><td class="tr"/> \
            </tr> \
            <tr> \
              <td class="b"/> \
              <td class="body"> \
                <div class="content"> \
                </div> \
                <div class="footer"> \
                  <a href="#" class="close"> \
                    <img src="/facebox/closelabel.gif" title="close" class="close_image" /> \
                  </a> \
                </div> \
              </td> \
              <td class="b"/> \
            </tr> \
            <tr> \
              <td class="bl"/><td class="b"/><td class="br"/> \
            </tr> \
          </tbody> \
        </table> \
      </div> \
    </div>'

Wow, I am ashamed I didn't know you could do multi-line strings like this earlier!! Although not as nice as multi-line strings in Ruby/Python/Perl, this definitely beats quotes and plus signs.

Compiler should have did-you-mean feature

toby ho — Thu, 18 Dec 2008 14:07:18 -0500

Idea: When you misspell things in your program, the compiler messages should say something like:
Error: Call to a possibly undefined method listChange, did you mean listChanged?

Developing in AIR just got a little suckier

toby ho — Thu, 18 Dec 2008 01:39:29 -0500

I wanted to try putting a javascript console inside an AIR app to aid development. I tried firebug lite, which I've been using a lot to debug IE. When I started up the app and hit F12, the console came up and everything, '1+2' gave 3, so time to rejoice? Not so fast, if you try to type 'window', or 'document', you get this error:
Error: Adobe AIR runtime security violation for JavaScript code in the application security sandbox (eval)

So they sandboxed eval and restricted access the dom and any other api that's available. And it's for... security reasons. What does Adobe have against eval? This sucks!

IE Woes: One

toby ho — Tue, 09 Dec 2008 21:09:28 -0500

Man! Have I been at war with IE lately. I have been holding back a lot of blog posts related to debug IE problems, and I going to start spewing them out now one by one. For the first installment I'll talk about one I encountered these couple of days...

Ever get this IE error?
When you click "Ok", this is what you see:

Ouch! Can this be any more catastrophic?(Yeah, that's my Chandler impression.)

According to this forum post, this happens if you have script tags in your document that's modifying other parts of the dom before the document finishes loading. Umm, okay, but I still had a hard time finding out the exact point this caused the problem. I used the comment-out-code-and-see-if-it-still-breaks-binary-search methodology, and came up with some work arounds which involved delaying the execution of some setup code. But, this catastrophic error came back to haunt be time and time again. Clearly I didn't find the root cause of this error or I wouldn't be committing it repeatedly.

But finally, I found it(I think, well at least one of the root causes). I am using firebug lite in development, which creates iframes and panels in the pages that pops out and in just like firebug. When you call console.log with firebug lite, guess what happens? Yeah, it modifies the console output window - a part of the dom that is outside of where the script tag is. Got rid of those console.log statements and fixed it.

In conclusion, do not do what I did!

IE getElementById looks up "name"

toby ho — Tue, 09 Dec 2008 16:29:00 -0500

IE, are you kidding me?

dissecting the prototype chaining

toby ho — Mon, 08 Dec 2008 14:36:17 -0500

I realized when I was trying to explain the prototype chain to my wife the other day that I didn't get it completely. So I went back to the drawing board and this is the example that I came up with:

function inherit(parent){
    var obj = function(){};
    obj.prototype = parent;
    return new obj();
}

toby = {};
toby.name = 'Toby';
toby.age = 27;
toby.eyeColor = 'brown';
toby.hairColor = 'dark';

console.log(toby);
// Object name=Toby age=27 eyeColor=brown hairColor=dark

emma = inherit(toby);
emma.name = 'Emma';
emma.age = 1

console.log(emma);
// Object name=Emma age=1 eyeColor=brown hairColor=dark

console.log("Toby is Emma's parent: " + (emma.__proto__ == toby));
// true

Y Combinator

toby ho — Thu, 27 Nov 2008 10:29:36 -0500

This is a great article on the Y-Combinator. It talks in laymans terms. I understand now what it does and why it is useful. However, I still have no clue how the code for the Y-Combinator works.

Great Break Down Of th e Coolist Languages

toby ho — Wed, 26 Nov 2008 23:47:33 -0500

This is a great great read.

Making Flex Suck Less

toby ho — Wed, 26 Nov 2008 20:47:25 -0500

This is a follow up to my last Flex post. As I am learning more about Flex I have learned ways to address all 3 of the items in the cons list.

Develop feedback - not as instant. I mentioned that Flex has a compile step in the development process, this cannot be fixed. But the lack of an interactive console can be addressed by using the Javascript bridge, with which you can use Firebug to script your Flex app. There are inevitably some limitations, of course(like, I don't think you can pass functions to and from Flex land; and you can't modify the existing code), but by and large it is extremely useful. The scripting ability alleviates the slower feedback problem even though it does not eliminate it.
Mandatory Static Typing. I misspoke on this one. Actually the static typing isn't mandatory at all. I mistook the warnings from the compiler to be errors. You have the option of turning off the warnings. Now I can eliminate a lot of what I dim the unnecessary type declarations from my code. However, I will not remove type declarations entirely, because I believe static type checking IS immensely useful for situations where 1) it takes some time for the program to start up, and 2) it takes some user navigation actions to get to the place you want to test. The type checker will catch a class of stupid errors, which if you encounter only after waiting and performing a series of mouse clicks and key presses, can make you irritated quickly. My rule of thumb for type declaration in ActionScript is: 1) declare function input and output types; 2) declare global variable types; 3) local variables may or may not be declared, depending on the situation(if the variable is used extensively in the function, then declare); 4) do not declare if the type is void(i.e. nothing). I've never really worked with a language that has optional type checking, this is fresh! The browsers in the future will have this too in Ecmascript 4. Another language that has this is Groovy, and I heard C# is adding this too, how exciting! I SOOO admire Anders Hejlsberg. (after seeing the video it seems it's more like a bridge to scripting languages/libraries)
As for the mx: prefix, I've already figured out how to do without it. So you can write <Panel ...> rather than <mx:Panel...>

In conclusion, Flex is actually an even better development environment than I gave it credit for last time.

FLEX: first impressions

toby ho — Thu, 20 Nov 2008 18:51:45 -0500

At work I am required to write a web UI that has a rich-desktop kind of interface. Without getting into too much details, it's layout will look a bit like an older email application(e.g. outlook, the older versions). It also need to have drag-n-drop capabilities. I whipped up a prototype of the UI using prototype and scriptaculous, since that's what I've been getting fluent with. A couple of things about my prototype made me decide to give Flex a try.

No draggable divider. The draggable divider - although not essential - is something that seasoned computer users have learned to expect when you give them interfaces that have multiple panels jammed onto one screen. Scriptaculous didn't have an draggable divider widget. YUI and ExtJS did, and I am not against learing a new library. But I get the vibe that their implementations might not be rock solid.
Buggy drag-n-drop libary. Scriptaculous comes with a drag-n-drop library. I've used it in multiple occations. It's also been buggy for me on multiple occations. A lot of the bugs are attributed to differences in browsers.

I decided that I was tired of chasing down cross browser bugs, which will only grow exponentially the more complex my UI gets. Therefore, Flex could really be the answer to these problems.

I am probably 60% done with my port of the UI prototype from Javascript/prototype/scriptaculous to Flex. I am happy with it for the most part. Here are my first impressions of Flex. First the pros:

Programming in Flex is suprisingly similar to programming in HTML/javascript/CSS. (Well, not as suprising as it could have been since I've heard Charles Lowe say the same on DrunkAndRetired.com podcast). You write a mxml file, which is like your markup - in place of your HTML; you write ActionScript inplace of Javascript; and there's a css 3 compliant stylesheet you can use to style the UI.
Flex has a rich UI component model that similar to many of the desktop UI toolkits(Swing, GTK, MFC, etc), which is a departure from the HTML/Javascript model. This is a plus because you get a lot of widgets you can use out of the box with very little code. Using third party Javascript widgets is usually more involved.
ActionScript is not much different from Javascript, so people literate in Javascript should pick it up easily. The only significant difference I've noticed so far is the type declaration syntax - ActionScript is statically typed. I believe ActionScript is compatible with a newer version of Ecmascript which has optional type declaration for variables and parameters. Type declaration in ActionScript(as far I can tell) is required on function parameters and global variables(errors out if you leave it), and optional on local variables(warns you if you leave it).
Yes, you have to write XML, but it's not that bad. I have expressed my hatred for making programmers read and write XML by hand in the past. It's inhumane! Flex makes you do that. Yes. But! It's used in a way that's not as bad as some other ways in which XML have been used(build scripts, web configuration, for example). In Flex, XML is used for Markup (wow! a markup language used for markup? what a concept?). The XML declaratively defines the UI(such as in HTML), which, I my opinion, is the way UI's ought to be written, and not in a procedure way(such as in Swing).
Flex components look good by default. For HTML/CSS you always have to design your own theme - even if you just want it to look half way decent. No such BS in Flex. Flex components look good out of the box(no CSS tweaks or includes required), because of this I believe you can prototype Flex UIs faster.
A Flex app runs exactly the same on any browser it supports. This was the main sell for me. Nothing more needs to be said.

Now the cons:

Develop feedback - not as instant. Developer feedback loop is slower because of the compile step. ActionScript is a compiled language, and you need to compile your Flex programing to get a SWF file. Also, in Flex 3, they took away the eval() function(why oh why???). This means you cannot create an interactive shell in Flex like Firebug or the python shell.
Mandatory Static typing. Although I have nothing against static typing in general. I don't like mandatory static typing(such as exists in Java, C#, C++). Haskell is a staticly typed language, it verifies all your types for you, and yet it doesn't require you to specify the types of all you variables and parameters because it can infer them all for you. I like that. This is not a big issue for me, it's just not as kosher as Javascript in this respect.
~~It's annoying that you have to write mx: to begin all Flex component tags in the mxml spec. No such BS in HTML. I tried a hack to do without it, it didn't work so well.~~
Update: Looks like I have gotten rid of the mx: problem. I guess I showed them ;)

Overall, the pros are worth more than the cons. Linguistically, I prefer Javascript to ActionScript and HTML to MXML, so it's not going to Change My Life(TM). But the UI component model and cross browser compatibility greatly outweigh those nags.

Radio button change event firing

toby ho — Mon, 10 Nov 2008 10:54:29 -0500

If you register the change event for a radio button, they fire at different times between IE and FF. FF fires the event immediately when you click on the radio button to change its value. IE does not, it fires changed only when you blur the element.