Barklund.org http://www.barklund.org/blog My life with ActionScript and relations Wed, 01 Oct 2008 22:32:52 +0000 http://wordpress.org/?v=2.0.2 en QR codes and Flash on the Beach http://www.barklund.org/blog/2008/10/02/qr-codes-and-flash-on-the-beach/ http://www.barklund.org/blog/2008/10/02/qr-codes-and-flash-on-the-beach/#comments Wed, 01 Oct 2008 22:32:52 +0000 Barklund AS3 http://www.barklund.org/blog/2008/10/02/qr-codes-and-flash-on-the-beach/ Flash on the Beach is just over and the final day had the most impressive (and the single most useful) presentations. The inspirational level this year has been great. The wonderfully beautiful creations by Eric Natzke or Robert Hodgin can take anyones breath away and the generally inspiring nature of Jonathan Harris’ works makes everyone want to do the same (if only we could get similar great ideas).

But Mario Klingemann’s presentation about reading QR codes in Flash was the most (technically) inspiring presentation in my opinion and I could immediately see a bunch of ways in which, I could use this for all different sorts of purposes - in real life advertising and not just for the fun of it. I really feel that I could join this project and make it into a complete library and so far I’ve written him a mail offering my help (and a minor possibility for optimization).

But credits also go to Grant Skinner, as his talk on important things to learn as a new web developer (in Flash in particular) gave me some good inspiration for my own job as head of development with developers of my own needing help and guidelines.

]]> http://www.barklund.org/blog/2008/10/02/qr-codes-and-flash-on-the-beach/feed/ Self-”partially applying” JavaScript functions http://www.barklund.org/blog/2008/02/06/self-partially-applying-javascript-functions/ http://www.barklund.org/blog/2008/02/06/self-partially-applying-javascript-functions/#comments Wed, 06 Feb 2008 20:54:51 +0000 Barklund AS3 JavaScript http://www.barklund.org/blog/2008/02/06/self-partially-applying-javascript-functions/ Was: self-currying JavaScript functions

I read this nice post on self-currying JavaScript functions, and even though the code to me is not optimal (dispite the low line count), it is improperly named, and it depends on the Prototype JavaScript library (which I really don’t like), it is a very nice script and a very nice idea. The trick in this script is using Function.prototype.length. I didn’t know that this property existed, but after digging a bit I’ve realized, that it has been in ECMAScript at least since 3rd edition (which is the latest edition published in 1999), in JavaScript since v1.1, but only made it into ActionScript by ActionScript 3 (which I haven’t study in as much detail as I have with ActionScript 1 and 2 in relation to my book on basic programming in these versions).

In this post I discuss this property and functionality a bit further, and I implement this function for creating self-”partially applying” functions using both no framework, the MochiKit framework and the Prototype framework.

Background

So, what is this property? I have not seen anyone use it before, not in production nor in any of the major JavaScript libraries. It might have been in use by a lot of people several times, but I just haven’t come across it. It has the simple function of returning the number of named arguments, that a given function is originally created with. The function will be called and might work just fine given less or more parameters, but Function.prototype.length is the number of named arguments in the definition. The ECMAScript language specification is kind of vague on the functionality, as it uses the term “usually”:

The value of the length property is usually an integer that indicates the “typical” number of arguments expected by the function. However, the language permits the function to be invoked with some other number of arguments. The behaviour of a function when invoked on a number of arguments other than the number specified by its length property depends on the function. […]

In his post James Coglan uses this property to create what he originally denotes as self-currying functions, but agrees with a commenter, that it is in fact self-”partially applied” functions using the proper terms. I would though go to the extend to say, that the functions are neither curried nor partially applied – their application/evaluation/invocation is just postponed until the correct amount of parameters have been accumulated. If the function was partially applied, the partially applied function would run faster (in theory), as it has been specialized with respect to the already supplied parameters, but this is not the case. The parameters are simply stored until the number of parameters given (potentially across several calls) matches the number of arguments “typically” accepted by the original function.

One of the issues about the implementation by James Coglan that caught my eye, is the use of the prototype chain. Many have an opinion about whether to contaminate the prototype chain or not, but I am of the latter school and really dislike this. Contaminating the global namespace (i.e. window) is thus the only other alternative, but for this a single global object containing all library functions can be created. This is the approach that my preferred library, MochiKit, uses but Prototype (which is way more popular than MochiKit) extends built-in JavaScript objects using the prototype chain. I have thus decided to implement this functionality both in native JavaScript and using MochiKit or Prototype methodologies. Another minor issue with the implementation by Coglan is the use of the activation object to read variables from the inner function. This tends to leak memory (as collected by Quirksmode here), so the general rule of thumb here is to store such values on the function instance and retrieve them from arguments.callee.

In native JavaScript

First the implementation in native JavaScript. Note the two helper functions, of which the first is needed, as arguments isn’t a real array, and the latter is the general “curry” or “partial” method found in most libraries:

JAVASCRIPT:
  1. function makeArray(a) {
  2.   for (var b = [], i = 0; i < a.length; i++)
  3.     b.push(a[i]);
  4.   return b;
  5. }
  6. function bind(f, a) {
  7.   var g = function() {
  8.     var c = arguments.callee;
  9.     return c._func.apply(
  10.       null,
  11.       c._args.concat(makeArray(arguments))
  12.     );
  13.   }
  14.   g._func = f;
  15.   g._args = a ? makeArray(a) : [];
  16.   return g;
  17. }
  18. function partialize(f, n) {
  19.   var g = function() {
  20.     var c = arguments.callee;
  21.     if (c._len <= arguments.length)
  22.       return c._func.apply(null, arguments);
  23.     return bind(c, arguments);
  24.   }
  25.   g._len = n || f.length;
  26.   g._func = f;
  27.   return g;
  28. }

The above bind-function is not optimal, as re-binding creates an extra layer of function calls which could easily be avoided by reusing the values stored on the function instance, but for this use, the above suffices.

This function can the be utilized exactly like the one by Coglan – except that this partialize function is actually a function, where the toSelfCurrying function by Coglan is a method (available through any function instance):

JAVASCRIPT:
  1. var adder = function(a,b,c) {
  2.   return a + b + c;
  3. };
  4. var add = partialize(adder);
  5. add(1)(2)(3)  // --> 6
  6. add(7,8)(23)  // --> 38

In MochiKit

Implementing this in MochiKit and using the power of the built-in functions (especially bind), this becomes only the last function:

JAVASCRIPT:
  1. function partialize(f, n) {
  2.   var g = function() {
  3.     var c = arguments.callee;
  4.     if (c._len <= arguments.length)
  5.       return c._func.apply(null, arguments);
  6.     return MochiKit.Base.bind(c, arguments);
  7.   }
  8.   g._len = n || f.length;
  9.   g._func = f;
  10.   return g;
  11. }

If keeping with the MochiKit spirit, one would save this function in the MochiKit.Base library and globally if export is active:

JAVASCRIPT:
  1. (function(){
  2. // closure to avoid cluttering window
  3. function partialize(f, n) {
  4.   var g = function() {
  5.     var c = arguments.callee;
  6.     if (c._len <= arguments.length)
  7.       return c._func.apply(null, arguments);
  8.     return MochiKit.Base.bind(c, arguments);
  9.   }
  10.   g._len = n || f.length;
  11.   g._func = f;
  12.   return g;
  13. }
  14. // save in MochiKit.Base:
  15. MochiKit.Base.partialize = partialize;
  16. // if export is active, save on window:
  17. if (MochiKit.__export__) window.partialize = partialize;
  18. })();

In prototype

If you are using Prototype, you probably do not dislike the use of extending built-in classes using the prototype chain, thus the implementation is a slight change of the implementation by Coglan:

JAVASCRIPT:
  1. Function.prototype.toSelfCurrying = function(n) {
  2.   var g = function() {
  3.     var c = arguments.callee;
  4.     if (arguments.length >= c._len)
  5.       return c._func.apply(this, arguments);
  6.     return c.curry.apply(c, arguments);
  7.   };
  8.   g._len = n || this.length;
  9.   g._func = this;
  10.   return g;
  11. };

UPDATE: Fixing typo pointed out by James Coglan.

This is almost as compact and just as readable.

]]> http://www.barklund.org/blog/2008/02/06/self-partially-applying-javascript-functions/feed/ Data Structures for Game Development in AS3 http://www.barklund.org/blog/2007/11/08/data-structures-for-game-development-in-as3/ http://www.barklund.org/blog/2007/11/08/data-structures-for-game-development-in-as3/#comments Thu, 08 Nov 2007 15:41:03 +0000 Barklund AS3 Games http://www.barklund.org/blog/2007/11/08/data-structures-for-game-development-in-as3/ This library by polygonal.de looks really nice. I would most definitely be using this for future development.

]]> http://www.barklund.org/blog/2007/11/08/data-structures-for-game-development-in-as3/feed/ Filterable tables – MochiKit-style http://www.barklund.org/blog/2007/09/27/filterable-tables-mochikit-style/ http://www.barklund.org/blog/2007/09/27/filterable-tables-mochikit-style/#comments Wed, 26 Sep 2007 23:08:17 +0000 Barklund JavaScript http://www.barklund.org/blog/2007/09/27/filterable-tables-mochikit-style/ A recent post on the MochiKit mailing list inspired me to have a little more fun with MochiKit, which I use a lot professionally and privately. The task was to see how simply a filtering for tables could be done using MochiKit.

The first task was to identify all the problems of the original script. Then comes setting up the basics, and finally implementing the necessary functionality. And as always MochiKit supplies so many convenient functions, that only the fun part is left. Furthermore this article suggest some simple extensions to the concept of filtering.

Current problems with the existing script include, that the de-highlighter ignores sibling (non-text) nodes of the text node that contained the highlighted term (and removes their markup). That is, if there is a cell like:

<td>here is a <strong>bold</strong> text</td>

Then if we search for is, the script will correctly highlight this word in the text, and the result looks like:

<td>here <span class=”highlight”>is</span> a <strong>bold</strong> text</td>

But if we then de-highlight this highlighted word, all markup from the entire cell (the cell is the direct parent of the text node containing the searched word) will be removed. Thus the resulting cell will look like:

<td>here is a bold text</td>

And this does matter. Because it does not only remove presentational markup like <strong> but (of course) also structural or functional markup like headers or links.

I needed an example table for this, and I used the one html table on the entire net, that I frequent the most – the IMDB top 250. Though I expected the script to be quite heavy, so I only used the top 10 actually for the base example. But later I will show other examples using longer tables for doing different searches.

The script is built around a basic onload-hook putting everything in closure (good for later inclusion in foreign pages) and this function sets up a few utility functions as well as the main hook for all filterable tables (tables including the class filterable). All these filterable tables are prefixed with a form containing a single input field. This input field’s onkeyup-event is then connected to the filtering function. When a key is released in the input field, the search term is extracted, the current highlights are removed, the lines not containing the word are hidden, and the remaining lines are sent through the highlighter. If the search term is empty, all lines are shown without highlights.

The script has many nice displays of how MochiKit really makes programming in JavaScript easier, and less sucky – I especially enjoy this simple function extracting all text nodes beneath a given node (depth-first, children before siblings):

JAVASCRIPT:
  1. // get all text nodes below current
  2. function getTextNodes(node) {
  3.     if (node.nodeType == 3) return [node];
  4.     return reduce(extend, map(arguments.callee, node.childNodes));
  5. }

This simple version of the script can be viewed here.

As mentioned, this isn’t a complete solution. For larger tables, it is very slow. It can be optimized a bit though. First thing is to do the scrapeText(row).toLowerCase() only once per row and store it as an attribute on the node. But for large tables, this isn’t enough. This could be fixed by adding more classes and creating special handling of these. Here I suggest the following two extra classes:

  • filterable-onsubmit
  • filterable-nohighlight

If the first class is given, the filtering will only be applied, when the form is submitted (instead of the input changed, user has to press enter to search) and if the second class is given, the filter will not highlight the search term – only show or hide rows with the given term. These can of course be combined. This can be seen in effect here.

Have fun and feel free to use under the given license.

]]> http://www.barklund.org/blog/2007/09/27/filterable-tables-mochikit-style/feed/ Now introducing: Dexgames http://www.barklund.org/blog/2007/09/11/now-introducing-dexgames/ http://www.barklund.org/blog/2007/09/11/now-introducing-dexgames/#comments Tue, 11 Sep 2007 20:44:44 +0000 Barklund AS3 Games Dexgames http://www.barklund.org/blog/2007/09/11/now-introducing-dexgames/ With a colleague of mine, Morten Reinholdt, I have started to work on a new flash gaming website called Dexgames. Actually we started on the idea several months ago, but now we both have the time to do some more actual work on it.

The concept is very much inspired by many other gaming sites. The ones that I personally have frequented some times are:

Just to name a few.

The site should be completely free, but we might add some google adsense here and there to get the hosting paid this way.

The current titles, that we are thinking about are mostly classical puzzle games like break-out. tetris and the like with different modern twists. But the big plan for the site is the big game, Dex Empire.

What this game is really about, no-one knows yet. But it is to be a combination of a series of games, that the both of us really enjoy:

With this as the basis, this game cannot fail. But it can and will take a very long time to develop – I just hope, that we will actually complete it.

It will end up as some kind of MMORTSRPG – whatever that means.

]]> http://www.barklund.org/blog/2007/09/11/now-introducing-dexgames/feed/ Bibliotekr – a new Danish social book-sharing site http://www.barklund.org/blog/2007/09/04/bibliotekr-%e2%80%93-a-new-danish-social-book-sharing-site/ http://www.barklund.org/blog/2007/09/04/bibliotekr-%e2%80%93-a-new-danish-social-book-sharing-site/#comments Tue, 04 Sep 2007 20:55:24 +0000 Barklund JavaScript Mashup Bibliotekr http://www.barklund.org/blog/2007/09/04/bibliotekr-%e2%80%93-a-new-danish-social-book-sharing-site/ Bibliotekr (a badly hidden pun on Flickr) is an idea crafted by a group of persons trying to create a book-sharing site “competing” with the Danish libraries. And one of the organizers had thrown together a small Hackathon, which I just had to attend.

The Hackathon turned out to be more of a Conceptuathon or Possibilithon, because the concept wasn’t really ready for implementation yet. But we met up 8 persons and discussed our views on the project. Some were developers like me, some were librarians and some just interested parties.

The key points remaining to make the concept ready for alpha-release to the public was how to conceptually identify the lending of a book in a Wordpress post. How does the post change to visualize, that the book has been lent out. This has to be done via some extension to Wordpress. I looked into creating Wordpress plugins – and that seems to be very easy. So when that time comes, I will probably create that.

The second challenge is to display books for lending on a Google Map. This is however quite easy – even applying filters on the sections to show (only sci-fi, only paperback, etc.). The funny thing comes when zooming on the map. Of course the map cannot handle thousands of displayed icons in the same view – the javascript is simply too slow. Thus on different zoom levels, different levels of detail must be applied. The easiest is to switch to zipcode view at a certain zoom-level, and then just count the number of available books in the zipcode and display a single icon for this.

]]> http://www.barklund.org/blog/2007/09/04/bibliotekr-%e2%80%93-a-new-danish-social-book-sharing-site/feed/ Doing a large corporate website the interesting way http://www.barklund.org/blog/2007/08/14/doing-a-large-corporate-website-the-interesting-way/ http://www.barklund.org/blog/2007/08/14/doing-a-large-corporate-website-the-interesting-way/#comments Tue, 14 Aug 2007 10:32:41 +0000 Barklund Play JavaScript HTML Mashup http://www.barklund.org/blog/2007/08/14/doing-a-large-corporate-website-the-interesting-way/ Today we launched a new website for one of the major Danish mortgage provider, Totalkredit. They are known by all Danes due to their tv-ads (produced by TBWA\Copenhagen), that everyone either hates or loves. This is a very big client, and thus they require a very big website. But as they are for the people and tries to communicate directly with the common man, the website need not be corporate, but must be rich with content, easy to use and with many features that will create returning visitors.

Well, all this I did not have much to do with, that concerns the concept department. But concretising, technically verifying and realizing this concept is very much my job. The project has taken many months but it is now finally complete. Or well, such is never complete, but the first version has been launched at least. And this site is (technically) amazing if I should describe it. The amount of JavaScript used is huge and much of it uses MochiKit heavily. The JavaScript is used to enliven the page in a very interesting way.

The whole page works without JavaScript in the classical fashion (clicking links, reloading the whole page with the new page), but with JavaScript enabled, all links are caught and handle via Ajax instead. This technique was introduced to me by Jeremy Keith and his somewhat cute term Hijax. In order to do this, but not combine markup with content, large portions of the HTML (very large in fact) are built in JavaScript. For this need MochiKit.DOM is really handy.

Other features of the site, that makes this a very satisfying job to have completed:

  • It is of course search engine optimized (Hijax preserves this)
  • It uses a very concise, readable markup and works as mentioned without JavaScript (the properties of Progressive Enhancement)
  • The URL is modified on every major page change using fragments in order to allow deep-linking and bookmarking (this is partly self-developed, partly borrowed from SWFAddress)
  • And given the above, that “back” and “forward” buttons of the browser works (unlike many other full-Ajax websites)
  • The site includes Google Maps (you can’t go wrong with that!)
  • The site is tested and optimized for Internet Explorer 6 and 7 as well as Firefox 2 (and friends).

Enough talking, here is the site: http://www.totalkredit.dk – “unfortunately” most of the site is in Danish except for a small investor-part.

]]> http://www.barklund.org/blog/2007/08/14/doing-a-large-corporate-website-the-interesting-way/feed/ Adobe AIR Developer Derby! http://www.barklund.org/blog/2007/06/12/adobe-air-developer-derby/ http://www.barklund.org/blog/2007/06/12/adobe-air-developer-derby/#comments Tue, 12 Jun 2007 16:04:11 +0000 Barklund AS3 Mashup http://www.barklund.org/blog/2007/06/12/adobe-air-developer-derby/ Adobe has released a new version of Apollo AIR (yup, that is the new name along with quite a boring logo) and to promote it, they have also announced Adobe AIR Developer Derby – a competition to see who’s best at their new runtime.

The prizes are quite amazing and given the long duration of the development time (deadline is in September), anyone can create some pretty amazing applications. But one things puzzles me about the license, that they require applications to be released under: is attribution-requiring licenses accepted? And what about copyleft-licenses? The official rules are pretty clear on what the license must permit Adobe to use the content for (display, commercial use and derivative use), but does that mean, that if my application is released under say CC-BY-SA-2.5, is that accepted? And what if I include Wikipedia-texts in it (GFDL’ed) and some Flickr-images (under free licenses) will Adobe then be willing to credit me, the main 5 authors of every article from Wikipedia (which is what GFDL requires) as well as the creators of all the Flickr-images that require attribution?

I’ve sent a mail and hope for a positive response. I will keep this entry updated on the matter.

]]> http://www.barklund.org/blog/2007/06/12/adobe-air-developer-derby/feed/ Clients can never be trusted http://www.barklund.org/blog/2007/06/03/clients-can-never-be-trusted/ http://www.barklund.org/blog/2007/06/03/clients-can-never-be-trusted/#comments Sun, 03 Jun 2007 13:05:34 +0000 Barklund Games Flash Platform Security http://www.barklund.org/blog/2007/06/03/clients-can-never-be-trusted/ And for once, I am not talking bad about our company clients, but the clients in a client-server architecture.

Flash memory cheats have always been known to any good flash game hackers and ditto developer, but some still don’t know about them. Thus, as shoemoney recently posted a competition to get the best score in Desktop Tower Defence, “some guy” of course fired up Tsearch and throw a lot of points his way. The result was of course, that he won (even though he cheated), and afterwards he posted a simple guide to do it.

That is why should should always have a server telling you what to do when. More on this topic in the months to come - as I and a friend is developing a brand new game site including high-level security.

]]> http://www.barklund.org/blog/2007/06/03/clients-can-never-be-trusted/feed/ I was just like biking down Park Drive N http://www.barklund.org/blog/2007/05/30/i-was-just-like-biking-down-park-drive-n/ http://www.barklund.org/blog/2007/05/30/i-was-just-like-biking-down-park-drive-n/#comments Wed, 30 May 2007 09:32:37 +0000 Barklund General JavaScript Mashup http://www.barklund.org/blog/2007/05/30/i-was-just-like-biking-down-park-drive-n/ Google Maps Street View is pretty amazing. The detail, the 360 view, the small increments between images. Just see these poor guys driving down Park Drive N. Google is quite amazing. This new street view has mapped 5 cities in the US.

Next, I would expect them to sell these cameras with GPS and have ordinary people drive around with these on their roof. And then once a week, you would sync the camera with Google Maps making sure to only upload good, new, interesting, appropriate photos.

Future advances to this would be local sounds, videos and custom photos - thus competing with sites like Locr.

Update 2007-06-01: The Google Map Street View Team can be seen here, as the truck passes by, Slashdot has an article about privacy issues with street map, and the latter also links to a contest for finding interesting things - of which I especially like the speed limit violation or stopping at the drive-thru. And some images have been removed, like this one once picturing an ongoing police investigation. Here is a top 15 of some of these and other sightings.

Update 2007-06-09: I have found a galaxy visible in bright daylight.

]]> http://www.barklund.org/blog/2007/05/30/i-was-just-like-biking-down-park-drive-n/feed/