http://studiokoi.com/blog/index/ en StudioKoi.com Copyright 2010 2010-02-15T00:58:24+00:00 http://studiokoi.com/blog/comments/hope_this_works/ http://studiokoi.com/blog/comments/hope_this_works/#When:00:58:24Z Just testing 2010-02-15T00:58:24+00:00 http://studiokoi.com/blog/comments/simple_argument_defaults_in_javascript/ http://studiokoi.com/blog/comments/simple_argument_defaults_in_javascript/#When:03:52:00Z In many other interpreted programming languages like: Python, PHP, ActionScript 3.0, etc., you can have defaults to arguments that do not get passed to functions. In the three afore mentioned languages, it's as easy as saying arg = 'default' inline in the function definition. This however is not available in the JavaScript interpreter. (It might be in ECMAScript 5, though.) But that can easily be remedied with a simple helper function. I have met other programmers that find it ridiculous that you have to create features in JavaScript that are built into other languages. They use that to put down JavaScript and call it a terrible language. However, I think thats part of what makes JavaScript so great. JavaScript, though not as powerful in features as some other languages, offers enough flexibility and expressiveness that you can create what you feel that you are missing. Lets take a look at the problem and see how easy we can remedy it. First, look at a basic function that is about the same in most C based languages: function foo(arg1, arg2){ return arg2;}foo('one', 'two'); // returns 'two'foo('one'); // Error thrown In the above example, you MUST have a second argument passed to the function, or you get an error. Some people remedy that like so: function foo(arg1, arg2){ //check for defaults var arg1 = arg1 || "one"; var arg2 = arg2 || "two"; return arg2;}foo('one', 'also two'); // returns 'also two'foo('one'); // returns 'two' The above works ok, but is a little cumbersome. The logical or operator or '||' (double pipe) in JavaScript returns the first item if it is truthy, or the second item no matter what. Usually, you'll only see that in if statement blocks, but this idiom works well as an either or return value and is used such. NOTE: This idiom would not work well with any value passed that is falsey: A blank string, an integer 0, boolean false, etc., because it returns the second item when the first argument is a falsey value and not just undefined or null. The above fix is lousy, though, because it becomes a mess when you have more than one optional argument. Take the following example that uses an object literal as the only argument and allows for passing only the arguments you want to send: function foo(args){ //check for defaults args.arg1 = args.arg1 || "one"; args.arg2 = args.arg2 || "two"; args.arg3 = args.arg3 || "three"; return args.arg2;}foo({"arg2":"also two"}); // returns 'also two'foo({"arg1":"also one"}); // returns 'two' The above works a little better because it allows you to pass only the arguments you want without having to null out others. It still presents ugly default checking and the same issues with falsey statements. We can use the same idea, but implement it far better with a simple function that will take a set of defaults and replace passed items over it and return the a useable object with all defaults and arguments in one. function defaults(def, arg){ for(var i in arg) { def[i] = arg[i]; } return def;} The above code takes exactly two arguments, the first being an object with the default 'name:value' pairs for your arguments. The second one is the argument object actually passed to the defaults function. The second object is iterated over and all of its values are placed over the default ones and the default object is returned. This will give a useable object with defaults in place and actual passed arguments where presented. How it actually works can be displayed as such: Defaults Object Arguments Object Resulting Object "one" (nothing passed) "one" "two" "also two" "also two" "three" (nothing passed) "three" Lets see it in action: function foo(args){ args = defaults({ arg1 :"one", arg2 :"two", arg3 :"three" }, args); return args.arg2;}foo({"arg2":"also two"}); // returns 'also two'foo({"arg1":"also one"}); // returns 'two' The default arguments are much less cluttered and were properly applied to items missing from the passed args object. Armed with our new defaults function and knowledge of how to use a single object to send all arguments, we can now safely send only select arguments, falsey or not, and have default arguments take care of the rest. Enjoy! JavaScript 2009-09-27T03:52:00+00:00 http://studiokoi.com/blog/comments/i_won_frank_peaks_twitter_contest/ http://studiokoi.com/blog/comments/i_won_frank_peaks_twitter_contest/#When:06:18:00Z If you like art at all and you don't already follow Frank Peak on twitter, or visit his website, I would highly recommend it. He periodically has "Almost Daily Drawings" that are his random doodles and concept drawings. His portfolio is also very, VERY good. Frank is a very skilled illustrator and 3D artist who recently held a contest on Twitter for people who would retweet him. I was one of the fortunate winners of the contest. Included in the package was a SWEET envelope that Frank personalized for each winner with random (and rather cute) artwork. Inside the package was a button pack with buttons by Royal Buttons Custom Buttons. There was also an unbent copy of the package art, and a sweet random drawing on nice card stock with a personal note from Frank, thanking the winner for participation. Frank said he would also have some future contests, so even though this one is over, there could be some stuff up for grabs later. News 2009-09-09T06:18:00+00:00 http://studiokoi.com/blog/comments/dont_miss_the_appcelerator_titanium_launch_party/ http://studiokoi.com/blog/comments/dont_miss_the_appcelerator_titanium_launch_party/#When:19:40:00Z On Tuesday June 9th, the Appcelerator team will be throwing a product launch party at Apple’s World Wide Developer Conference to toast the arrival of Titanium Beta. If you are going to be at the WWDC head over to Jillian’s in San Francisco between 6 and 9 p.m. where they will unveil Titanium Beta. I wish I could be there myself, but flying out to San Fran on a Tuesday is a tall order. Check it out for yourself and be sure to go if you are there. Celebrate the arrival of Titanium Beta News 2009-06-05T19:40:00+00:00 http://studiokoi.com/blog/comments/please_update_your_rss_and_atom_feeds_to_the_code_blog/ http://studiokoi.com/blog/comments/please_update_your_rss_and_atom_feeds_to_the_code_blog/#When:06:06:00Z Please update your RSS and ATOM feeds to this site. I recently discovered a small error with my back-end code that was allowing erroneous links to appear for my RSS and ATOM feeds. These bad links will work until the end of the summer at which time I will remove them and only be updating the proper links. Update your ATOM feed to the Code Blog. Update your RSS feed to the Code Blog. News 2009-04-20T06:06:00+00:00 http://studiokoi.com/blog/comments/adobe_air_app_jslint_air/ http://studiokoi.com/blog/comments/adobe_air_app_jslint_air/#When:07:33:00Z In attempts to make my JavaScript applications better, I frequently use Douglas Crockford's JavaScript verifier application JSLint. If you have never used JSLint, I would advise reviewing the background on JSLint In order to use it more easily and efficiently on local files, I took the JSLint JS file and ported it to an Adobe AIR application for the desktop. You can import the file from your desktop or paste the code in directly. In a future edition, I will add drag and drop ability to JS files. I used jQuery UI for the app UI and plan to eventually add skin choices to the options menu base on jQuery UI default skins. The app will auto update, so you will be able to see new features as soon as I add them if you accept the updates. Check out the Interface Preview, and give the app a try. Please leave all comments and bug issues as comments in this thread. Enjoy! _DEFER.flash['flash_1_jslintair'] = { "swfurl":"/images/AIRInstallBadge.swf", "width" : "215", "height": "180", "params":{ "wmode": "transparent" }, "vars":{ "appname" : "JSLint AIR", "appid" : "JSLintAIR", "appurl" : "http://software.studiokoi.com/applications/jslintair/jslint.air", "airversion": "1.5", "image" : "http://software.studiokoi.com/applications/jslintair/badge_jslintair.jpg" }, "attr": {} }; AIR 2009-04-16T07:33:00+00:00 http://studiokoi.com/blog/comments/execution_order_of_functions_and_variables_in_javascript_and_actionscript/ http://studiokoi.com/blog/comments/execution_order_of_functions_and_variables_in_javascript_and_actionscript/#When:07:17:00Z Many newcomers to web development may not be used to how web implementations of JavaScript execute. Namely, in what order it executes. This can be the source of many errors that are difficult to pinpoint if you aren't experienced with it. I think this also affects people who are very experienced with other programming languages and fosters a lot of undeserved hate towards ActionScript and JavaScript. (It's important to note that not all implementations of JavaScript are the same, and that some may in fact defer from what is said below. This article concerns browser and Flash based ECMAScript.) The thing to understand about JavaScript is that it isn't compiled for the most part. (This is not exactly true for ActionScript because of the introduction of classes in ActionScript 2.0, however, the runtime script remains the same. You might argue that it compiles into a *.swf file, but in reality, that is the combination of everything that has to do with the Flash file. The ActionScript still remains live.) It's good that it isn't compiled though, because this allows for much more dynamic, expressive coding. So, if it isn't compiled, how does it work? Browser-based JavaScript code is all executed at first calling, nothing is compiled or cached in a scope until it is called (except AS2 & AS3 classes). It works this way because, with the exception of basic, immutable variable types: strings, booleans, numbers, and 'undefined', every variable in JavaScript is an object. This includes 'null' and functions ('null' is technically a basic variable, but is reported as an object in JavaScript). Since functions are objects, this means their value in memory is also like an object and names are only assigned by reference. Lets see how this works: //bob first initializationfunction bob(){ alert('bob');} //set jan to bob via referencevar jan = bob; //set bob to another functionfunction bob(){ alert('newbob');} jan(); //alerts 'bob'bob(); //alerts 'newbob' This where things can be very confusing to people who are used to other languages where functions are just functions and can only be written once to a variable name at compile time. In order to understand better, let's write the same code again with anonymous functions: //bob first initializationvar bob = function(){ alert('bob');}; //set jan to bob via referencevar jan = bob; //set bob to another functionbob = function(){ alert('newbob');}; jan(); //alerts 'bob'bob(); //alerts 'newbob' This is how functions are actually assigned in JavaScript. The traditional C style that was seen in the previous example is translated at runtime into something like the above. So, when you code JavaScript, imagine instead that all functions are really variable pointers to anonymous functions in memory. (ActionScript 3.0 in strict mode attempts to stop this sort of behavior by warning you when your code tries to overwrite variables that have already been set. While this is good for heavier languages, I think it is moving away from what makes ECMAScript really dynamic in the first place.) At this point, you might be asking: "Why is all this important to the execution order of JavaScript?". This gives you background as to why JavaScript doesn't execute anything until runtime. In light of this, there is one thing JavaScript does to speed things up that is VERY important to understanding its execution order: JavaScript caches declared functions before any other variables, after this, it goes back to the top of the scope and runs variable definitions and functions calls in the order that they appear. This is where the confusion begins for the uninitiated. Let's say for example that you have a function that returns a value from a passed variable. You might want to assign a variable to the result of that function like so: var newNumber = secondPower(5); //25 //first definition of functionfunction secondPower(n){ return n * n;} This works because the function was cached before the variable was assigned. However, doing things this way in your own code is a TERRIBLE idea because it can cause more problems than it solves. Lets look at an example of where this might fail. Remember our previous example where we assigned the anonymous function to a variable name? While in that example, it worked perfectly, it actually causes a strange thing to happen to execution order: var newNumber = secondPower(5); //error, secondPower is not defined yet //some parsers would not even get this far due to the above error//thrown errors in ECMAScript halt the execution scope they are invar secondPower = function(n){ return n * n;}; var newNumber2 = secondPower(5); //25 This error happens because when the parser came through, it cached the anonymous function before anything else, but not the variable name assignment to the anonymous function. Therefore, when we called 'secondPower', it had not been assigned yet and the first calling was undefined and possibly threw an error. It is important to remember that the bad thing that happened here was not the fact that we assigned a variable name to an anonymous function in place of the classic C way to declare a function, but rather the bad idiom of calling a function before it is assigned. Anonymous functions offer huge benefits to ECMAScript and are not inherently bad. Other problems can arise from calling functions before they are declared even if the function is written in the classic style. Perhaps the function we use for variable assignment requires an outside variable to function properly. This would cause an error if the function was called before the assignment of the dependent variable took place: var newNumber = multiplyNumber(5);//multiple is not defined yet, incorrect result with possible error  var multiple = 2; //this is cached and available before all other variablesfunction multiplyNumber(n){ return n * multiple;} As we can see here, an error would occur in our variable assignment because even though the function was properly cached, its dependent was not assigned yet and the function could not execute properly. So, knowing this, what should you do to avoid these errors? Here is a quick list to help you when writing your code: Never call a function before it is declared Declare all variables in a execution scope as soon as possible Only assign variables to a function result after all functions and other variables have been declared Just to reiterate, let's look at how a good code setup should be writen: //declare all variables as soon as possiblevar newNumber, multiple = 2; //declare all functions before calling themfunction multiplyNumber(n){ return n * multiple;} //finally, set variable values that require function resultsnewNumber = multiplyNumber(5); //10 Declaring your variables and functions in this way will allow you to use more expressive methods to set functions and will most importantly avoid errors. For some further reading, check out Douglas Crockford's recommendations on JavaScript coding conventions. While I mostly mentioned JavaScript in this Article, the majority of these principles and Douglas Crockford's suggestions apply to ActionScript as well. JavaScript 2009-04-13T07:17:00+00:00 http://studiokoi.com/blog/comments/typechecking_arrays_in_javascript/ http://studiokoi.com/blog/comments/typechecking_arrays_in_javascript/#When:08:06:00Z In JavaScript the typeof operator reports an array as 'object'. While this is technically correct (an array in JavaScript is really just a specialized object), it's a pain in the neck when you are type checking a variable. There are a number of ways to identify an array in JavaScript. Checking for properties of an array isn't totally accurate because you can add any named member to an object to imitate an array. Checking for 'instanceof Array' works most of the time but could be tricky in some implementations of JavaScript. Mark Miller of Google gives us a solution that is standard to the ECMAScript documentation: Object.prototype.toString.apply(value) === '[object Array]'; What this essentially does is take the standard Object method "toString" and applies it to the passed argument (which is your array you are checking). This makes sure that it reports itself according to standard, which all real arrays should. We can implement it in an easy checking function that returns a boolean: function isArray(a){ return Object.prototype.toString.apply(a) === '[object Array]';} Props to Douglas Crockford because I read about this on his blog. There is also some further discussion there on using this method and i recommend reading it. As a bonus of sorts, this also works in ActionScript 2.0 and ActionScript 3.0. JavaScript 2009-01-10T08:06:00+00:00 http://studiokoi.com/blog/comments/javascript_errors_testing_for_the_existence_of_functions_in_javascript/ http://studiokoi.com/blog/comments/javascript_errors_testing_for_the_existence_of_functions_in_javascript/#When:22:38:00Z When using multiple JavaScript libraries, it is inevitable that one JavaScript file will need to call functions named in other libraries. This is necessary but can cause issues if all of the libraries aren't present. Error handling with JavaScript is somewhat lackluster. With this in mind, you should do your best to catch and handle errors and avoid sending them to the end-user. In order to prevent errors and allow for scalability, you should test for functions that aren't present in the script where you are calling them. Lets say for example that you have downloaded a JavaScript library named "bob.js" and it contains just a main function named "bob". To keep things clean, you might load this file separately. (Of course this is a bit unrealistic, no one would make a separate file for one function, but for the sake of example, bear with me.) Your loading code might look like this: <script type="text/javascript" src="bob.js"></script><script type="text/javascript" src="mycode.js"></script> So, correctly, we have loaded the "bob" library first and our code second. For the sake of example and understanding, lets suppose that the "bob" function just returns a simple math result. It isn't important what the bob function does, but it might be easier for some to understand if we had a real example: //bob.jsfunction bob(n){ return n * n;} Now this takes us to our real example. Given that we have the function "bob" in another file, we want to use it in our own code, "mycode.js". When the page loads, we want to add a div tag with some text that has a number in it. We are going to use the "bob" function to return the number to the power of 2 and write it: //mycode.jswindow.onload = function(){ //the starting number var oldNum = 43; //make the number we are going to write var newNum = bob(oldNum);  //set the body tag to a variable var body = document.getElementsByTagName('body')[0]; //make the div container var myDiv = document.createElement('div'); //create the text container var myText = document.createTextNode(newNum); //add the text to the div myDiv.appendChild(myText); //add the div to the body body.appendChild(myDiv);} While the above code could be written quite a bit smaller, it works well and it is plain what is happening. You run into an issue however when the "bob.js" file isnt present. When you run into an error in JavaScript, it usually kills the chain the function or event is called in. So in the above instance, as soon as it hit the second variable, and the bob code wasn't present, the code would simply halt on error and nothing would display on screen, potentially breaking many other things in the process. This brings the issue of error handling and function testing. One of the tools that we do have in JavaScript is the try/catch(/finally) statement. It is very handy for areas of code that can be error prone or have outside influence on the application. We could fix our example by adding a try/catch statement that would have a backup variable in case the "bob.js" isn't present: //mycode.jswindow.onload = function(){ //the starting number var oldNum = 43; //make the number we are going to write try { //works if bob is present var newNum = bob(oldNum); } catch(e) { //catches the error if bob is missing and provides an alternative var newNum = oldNum; }  //..etc} This will effectively remove the chance for error if "bob.js" isn't present. However, the try/catch statement takes a bit of a performance hit due to all it is designed to do. When simply testing for functions, I feel it is a bit verbose. My personal preference is just to test for the existence of the function before I attempt to call it. This way you don't spend the CPU time calling the function, getting the failure, sending the error, catching the error, then running the error block. When testing for a function, it's usually best to make sure it is actually a function rather than simply checking for it to be not undefined. This is doubly important in situations where you are using multiple libraries or working with a lot of people on the same file. Your code and their code could have the same name for two different types of objects. JavaScript has no overwrite protection even on its own built in functions unless specific platforms add it in, therefor you must take it upon yourself to check. Checking for the existence of functions can be done easily using the typeof operator in JavaScript. Many times, I code that simply checks for "undefined" or not, then lets the code run. As mentioned above, this still leaves some potential for errors in your code. Granted, there will always be margin for error, but the goal is to make habits that minimize it and help you the real issues. Therefore I think it is better to make sure your function is actually a function. The same code we used with the try/catch statement can be written similarly with the typeof checking: //mycode.jswindow.onload = function(){ //the starting number var oldNum = 43; //make the number we are going to write if(typeof bob === "function") { //works if bob is present and is a function var newNum = bob(oldNum); } else { //if bob is not present, provides an alternative var newNum = oldNum; }  //..etc} This has better performance than the try/catch statement and gives you a better idea where an error could be if it occurs. However, we could write this even shorter to make the code a little cleaner using a ternary operator: //mycode.jswindow.onload = function(){ //the starting number var oldNum = 43; //make the number we are going to write //if bob is present and is a function, make number //if bob is not present, provides an alternative var newNum = (typeof bob === "function")? bob(oldNum) : oldNum;  //..etc} One last thing to mention when using typeof. It will throw an error if you are testing for a function inside of a nonexistent parent. So, say "bob" is an object, with a subobject "math", with a method called "double". If we test for "bob.math.double" and "bob" doesn't exist, JavaScript will throw an error with the typeof operator. To avoid such errors you could test for each segment of the method's parent chain before testing for the method itself: //mycode.jswindow.onload = function(){ //the starting number var oldNum = 43; //make the number we are going to write if(typeof bob === "object" && typeof bob.math === "object" && typeof bob.math.double === "function") { //works if bob is present and is a function var newNum = bob.math.double(oldNum); } else { //if bob is not present, provides an alternative var newNum = oldNum; }  //..etc} This seems a lot longer given the possibilities of nested objects, but doing it this way also prevents the issue of same-named objects clobbering each other and sneaking in to create errors. If you are really confident with your code and have no outside workers/code coming in, you could skip the middle statements and just test for the parent object. There we have it. This method of function existence checking has saved me lots of time and has created some interesting idioms for projects where external code may or may not be present. Enjoy! JavaScript 2008-12-29T22:38:00+00:00 http://studiokoi.com/blog/comments/all_comments_on_the_code_blog_now_require_moderater_approval/ http://studiokoi.com/blog/comments/all_comments_on_the_code_blog_now_require_moderater_approval/#When:02:46:00Z Unfortunately, the griefers of The Internet, comment spammers, have made it necessary to take the precaution of requiring all comments made on this site to be moderated. This means that any comments posts you see will not be imeadiately visible until moderator approves it. I apologize for the inconvenience, but the spam just isnt good for anyone, and this is the only way I can keep up with it. On a side note: I realize I haven't posted in a while, but a lot of things have been happening in my home life recently. However, I do have some posts in the pipeline, so subscribe to the RSS feed and keep checking back. Thanks to all the readers for your support. News 2008-12-11T02:46:00+00:00