The Semicolon Report ;

PhoneGap is ok with section 3.3.1

2010-04-14T09:31:00.004+02:00

PhoneGap is reported to be compliant with section 3.3.1. So now you can use Javascript to do iPhone and iPad apps. I tried out my iPhone app on the iPad yesterday and it worked fine.

Why the Apple 3.3.1 policy is bad for consumers, economic arguments

2010-04-12T20:28:00.004+02:00

Sorry, I make an exception and talk some politics in this blog. Computer programmers over the world are upset about the new Apple policy 3.3.1, for a background see this Wired article.

The counterarguments are usually from a technical perspective, see for example this post from 37 signals.

I want to give some economic arguments, hopefully that is a language that politicians understand.

Higher costs for consumers argument A.
Claim A1. Apples restriction on allowed programming languages decreases productivity.
Claim A2. This increases the cost of software development.
Claim A3. This will increase the cost of software products.
Claim A4. Consumers will have to pay more for software.

I think claim 2-4 are obvious, given claim 1.
For some scientific support for the claim 1 that not all programming languages have the same productivity, see the the 2000 IEEE paper An Empirical Comparison of Seven Programming Languages(draft PDF)

The following statements summarize the findings of the comparative analysis of 80 implementations of the phonecode program in 7 different languages:
– Designing and writing the program in Perl, Python, Rexx, or Tcl takes no more than half as much time as writing it in C, C++, or Java and the resulting program is only half as long.
– No unambiguous differences in program reliability be- tween the language groups were observed

There are more productive languages than C and C++. I believe Objective-C is similar to these languages, but even if Apple Objective-C is more productive, there can not really argue that there might not ever be another language, language X, that is more productive.

Higher costs for consumers, argument B.
B1. Of the worlds programmers, there are some X percent that know the Apple approved languages, some Z percent that know other languages.
B2. If the Z percent are not allowed to develop software for the iPhone, the supply of programmers are less than Z + X.
B3. Lower supply gives higher prices.
B4. Higher prices for software development, well see claim A2-A4.

Now it would be interesting to see what evidence Jobs have for his claim:

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

I will not be surprised to see the European Union taking actions against Apple soon, not only because of section 3.3.1, but given the iPhone platform and the ways companies are not allowed to compete with the built-in software. Remember EU and Microsoft. Apple: please start to behave like gentlemen.

Using Javascript to do iPhone apps

2010-02-27T15:25:00.002+01:00

Mobile Safari has got native-speed animations, a built in SQL-Lite database for client-side storage, local caching, access to touch events and more. And the great javascript programming language. You can do apps that feel and look like traditional apps, but with direct install from a website rather than through app-store. I recently did a proof of concept for a client that was very impressive. It felt just like a "real" app, with sweeping animations, touch events and more.

Here are some decision points to choose a strategy:

Code an app on the browser:

If you want to do something cheaper and faster.
If you don't want to publish it on app-store.
If you wan't to be able to upgrade it instantaneously.

Code an objective-C application:

If you like to do just as everyone else
If you want to do something in need of really high speed like a 3d game or a face recognition algorithm.
If you appreciate to have a for-profit organziation like Apple approving or disapproving what you have done.

Here are some links for developers that want to try the browser way:

Apple Safari Documentation

Safari Visual Effects Guide

The Touch-Event

A new O'Reilly book about this way to do apps, a very good introduction. It a bit thin on animations and events, so also read the Apple docs.

If you need to get on app-store or access even more native features, there is a project Phonegap that wraps some objective-C around your files. But first take a look at what you can do without it.

Some observations:

Mobile Safari is impressive, but WTF: You can't have scrolling inside a div. I wonder how they came up with the idea to remove that standard feature.

To get a logging facility, on your iPhone go to Settings > Safari > Developer > Debug Console. If you have a good development environment like emacs + flymake + jslint you don't feel the need of a real debugger that much anyway, print statements (logging) is an underrated technique.

Functional object-oriented programming in Javascript

2009-10-28T10:16:00.003+01:00

I have written a tutorial on the best and easiest way to do object-oriented programming in javascript. It is the method described as "functional" by Douglas Crockford in "Javascript the good parts", the chapter on inheritance. All deep thinking was done by Crockford, the only smart thing I have done is to understand to appreciate the ideas. And I have made a new example, and possibly some new arguments for the method. What is funny is that I like this method but not really what Crockford points out as the killer argument for it (real privacy).

Here it is, text, code and demo.

Why feature-sniffing? Sample from an IE8-bug in Dojo

2009-10-22T01:38:00.004+02:00

I am going to give a real-world example of when browser-sniffing fails, and that browser-sniffing is not the same as user-agent sniffing.

Some weeks ago I made a note to myself. Never use native DOM-methods if you have a library at hand. I had discovered an Internet Explorer bug, and noticed that if I had used the dojo.attr code instead of setAttribute it would never have been a problem. But today I discovered that the exact same code that I praised some weeks ago now totally broke on Internet Explorer 8. And it was Dojos fault not Microsofts. I repeat it was not a Microsoft bug. Microsoft actually had fixed a bug.

The reason was browser-sniffing instead of feature-sniffing. The Dojo code checks whether the browser is Internet Explorer, and assumes that it behaves in a certain way if it is. But just because it is is a bug in todays Internet Explorer, it does not need to be in Internet Explorer 9 or 10. The brand name will probably stay. There are two solutions to the problem, one not so good and one good.

Browser-detection

The not very good one is to check on a certain version of the browser that you know about. If you know the bug is in IE6 or IE7 or IE8 you can test for that particular version. But wait, what if they fix the bug? This could be the case for IE8. It is not unthinkable. Then your code would break.

User-agents

An additional question, but less important, is how you detect the browser version. If it is based on an user-agent string you might have additional problems, this string could be set by another browser in some sort of compatiblity-mode, or even changed by the user. When you read about browser sniffing it usually sounds like it is detection based on user-agents that is the main problem. And people respond that only 0.025 percent fakes user-agents anyway so it is no problem. In a way I agree, the main problem is not using user-agents. It is assuming a bug exists without testing for the exact bug, but assuming it exists because we are on a certain browser. Testing for the presence of certain objects (like document.all) and then assuming a certain behaviour can be just as unreliable. What if the bug is fixed in the next service-pack but document.all remains?

Feature-detection

The best way to do it I can think of is to test if the bug exists, not if we are on a certain browser. You can call it feature-detection, or bug-detection. Sure, it might take some extra milliseconds and some coding effort. But I think it is worth it, especially in a general purpose library. And I was just visually inspecting jQuerys support.js, it seems it can be done in a fast way.

Unobtrusive websites

Of course you can use the same way to do accessible website with graceful degradation. Test for features, not browser versions.

Details on the bug

This might not be very interesting, but if you really want to know. Dojo 1.2.3 has a function dojo.attr that fixes some issues with the native setAttribute method. One thing is that when setting the (css) class the attibute is named className for Internet Explorer 6 and 7. But that was fixed in Internet Explorer 8. However, line 1085 in html.js checks for isIE rather than ieLT8 (which would have worked). Here is my bug-report.

Sample bug sniffing

This is the feature sniffing I have used for this bug.

var featureSniffClassNameAttributeIsClass = function () {
    var d = dojo.doc.createElement("div");
    try {
        d.setAttribute("className", "c");
        var h = d.outerHTML;
        // if setting className on a node alters the class, we are on IE6 or 7
        var convertClassToClassName = ! /classname/.exec(h.toLowerCase());
        return convertClassToClassName;
    } catch (e) {
        //probably we are on a non IE browser because an error occurred
        return false;
    }
};

Why don't you upgrade to the latest dojo?

Now that is a good question. I don't know if this bug is fixed yet, maybe it is. But sometimes you don't have an option. We are doing a chat-widget for Lotus Connections. Lotus Connections is a commercial social software for intranets made by IBM. And it does not have a chat. Almost unbelievable. If you are running Lotus Connections and want a chat, of course you do, contact me for more information. Or if you are a systems-integrator and want one to sell. Anyway, widgets for Lotus Connections do not sit in isolated iframes, so your Javascript runs on the actual page. And IBM has decided on the Dojo version, not me. So I don't think I can persuade them to patch it.

Plug for Improved jQuery Flip effect plugin

2009-09-17T14:04:00.005+02:00

I have improved the jQuery Flip Plugin quite a lot. I contributed the updates in july, but there is no release yet. So in case someone wants to use the jquery flip effect plugin, let me plug my version ( zip here)until a new official release is out.

Below are my notes of changes vs 0.5, if you are curious on details.

Enjoy!

Added a testpage fliptest.html to show the bug I fixed. It can also be good to have included in the plugin for future hackers.
Version 0.5 failed fliptest nr 3 with tb and bt on Firefox 3,3.5, Opera 9.64 maybe more. You can see that there is a white border over the text, especially if you run it in the slow mode. This does not look good over an element with a background image.

Solution: Don't pick up transparent from the parent node. Instead add a background-color transparent to the style of the cloned node (it will override background-colors applied from a stylesheet, for example with a class).

This didn't work for IE6. But instead of picking up colors from the parent node, use a special trick for IE6. In order to do that, I added a function isIE6orOlder. Removed getTransparent.

Problem with named colors (like "yellow"), on IE7. I made an acceptHexColors function that forces the use of hex colors.
for "tb" borderLeftColor and borderRight color need not be set to transparent in first or second animation, because it is already set on the start. Also it caused a white background on Firefox, maybe since transparent is a special kind of color.
It was difficult to read a very long line, so it split dirOptions into one line per property.
That made it into 147 lines of setting up the dirOptions. I wanted to simplify it.

Also note, that we set up the four different directions but only one of them is used per call. So there is some unnecessary code being run.

First I split it into four functions, each one returning a dirOption. Then I looked at was common options, in the end it became a few functions in 100 lines, I think you will agree it is more readable and less prone of typing errors.

jslint error missing radix parameter in int_prop.
use of global jQuery variable inside the big wraping. This will make flip not work if using jQuery.noConflict(); And it is totally unnecessary. jQuery is passed in as the $ parameters by the call in the last line of the file. So, in two place around jQuery.extent jQuery.fx.step and jQuery.fn.flip I change jQuery to $.
The cloneId is unnecessary. It is used to get the clone we made, but it is returnde directly when we create it. Instead I made a $clone variable.
The inner function queue(_this,_self) is unnecessary, also the variables _this and _self become just rebindings of my new $clone and $this. So I removed them.

I made the onBefore,onAnimation and onEnd send the $clone and $this as parameters that can be used if you want to. Why? Here is a real world sample.

$me.flip({direction:'tb',
          dontChangeColor: true,
          onBefore:function ($clone) {
              $clone.css({'background-image': "none"});
          },
          onEnd:toggClass});

I added the dontChangeColor settings option. For example, I have an element with no background color. Instead I have a background image, first a bit yellow and then a little grey. I want to use the flip effect, but not change background color. Instead I want to change background image when the flip has finished.
'0px' is the same as 0. Zero is always zero whatever measurement unit.
Added 0.6 and some comments to the ChangeLog.
I can't work with tabs, if you want you can convert it back, 4 chars indentation level.
The compressed (YUICompress) size has decreased from 4903 to 3903 bytes.

Code-writing code in Javascript ;

2009-08-29T14:27:00.003+02:00

When you are coding in Lisp it is perfectly natural to write code that writes code. You make your own language as you go. This is with Lisp macros. I have explained macros in Javascript in another post. You actually can use a similar technique in Javascript, but without macros.

One thing which is very use for code-writing code is to implement a specification of some kind. It can be many kinds of specifications, in this example the spec is a CSV file. That is a comma separated file. You have a list of headers meaning something, and you want to make a program to read this file and access the different rows and columns.

Imagine the specification defines customerNr, hairColorId, and so on, in total maybe 53 fields. You want to access these properties in different ways and have some nice solution to keep it all together. Perhaps you want an event system, so other objects can listen to when the hairColorId changes and update something on the screen.

If you are a certain kind of consultant you will want to store the 53 fields in an array and remember the index number of each property. Now if someone inserts a changes the spec you will have to spend a lot of time updating the index numbers. Also it will make it very unreadable, what does theArray[11] really mean? If you are lucky you are the only one that knows and you will be irreplaceable.

I don't want to store it as a JSON type object literal. If we use direct access it makes it difficult to add the event feature, checking the validity of the data and things like this. Access should be through functions.

I don't want the upcoming javascript magic set/get handing of properties. It hides the fact that access is made through a function and makes it difficult to find things that need to be refactored. You can't tell if someclass.customerId is direct access like in the previous section (refactor in my opinion) or a magic setter. The ugly smell has gone, and we need the smell to be able to refactor.

I would want to access this with read/write set/get och what ever you call them, accessor functions. They are a nice spot to throw out events and makes it easy to change the specification. But I don't want to make all these getter and setter functions manually. It makes it error prone and quite difficult to update. And I definitely don't want some magic XML spec outside the file generate the code for me. I want to have control.

I want something like this:


var specification = ['customerId','hairColorId'];
var customer = makeCSVwrapper(specification);
customer.setCustomerId(56);
customer.setHairColorId('blue');
customer.onHairColorIdChange(function () {
   alert("Changed hair: " + customer.getHairColorId());
});
var csv=customer.formatCSV();
sendToServer(csv);

What is the deal?

The whole specification is defined in one line of code. set- and get- functions are created automatically based on the spec.

If a new field is added to the specification we only need to update in one line of code. No editing of setters and getters.

If hairColorId is removed from the specification, we only need to change in one line. And we will spot deprecated code because customer.setHairColorId will now be an error. But if we had direct access as customer.hairColorId = 'blue' this would not cause an error. It would be a bug more difficult to detect.

The risk of typing errors in your setters and getters decrease. The file size decrease. Finally it shows something Javascript can do but most languages can't.

Demo

I have a flashy alert-message based demo and source code you can try.

Code Writing Demo ;

2009-08-29T10:43:00.023+02:00

Code Writing Demo

What is the deal?

The whole specification is defined in one line of code. set- and get- functions are created automatically based on the spec.

If a new field is added to the specification we only need to update in one line of code. No editing of setters and getters.

The risk of typing errors in your setters and getters decrease. The file size decrease. Finally it shows something Javascript can do but most languages can't.

I also have a longer post about this.

Henrik Hjelte / Semicolon report

Click button to try demo:




var makeSetterGetter = function (definitionArray) {



  function each (array,fn) {

      var len = array.length;

      for (var i = 0; i < len; i=i+1) {

          var el = array[i];

          fn(el);

      }

  };



  function capitalize (str) {

      return str.charAt(0).toUpperCase()+str.substring(1);

  }



  function fireEventName (propertyName) {

      return "fire" + capitalize(propertyName) + "Change";

  }



  var self = {

      // You can override these functions for tweaking

      _internalPropertyName : function (propertyName) {

          return propertyName;

      },



      _setParam : function (paramName, value) {

          this[this._internalPropertyName(paramName)] = value;

          var fireFn = this[fireEventName(paramName)];

          fireFn(value);

          return value;

      },



      _getParam : function (paramName) {

          return this[this._internalPropertyName(paramName)];

      },

    

      getDefinitionArray : function () {

          return definitionArray;

      }

  };



  function makeSetterAndGetterMethod (propertyName) {

      var getterName = "get" + capitalize(propertyName);

      var setterName = "set" + capitalize(propertyName);

      self[getterName] = function () {

          return this._getParam(propertyName);

      };

      self[setterName] = function (value) {

          return this._setParam(propertyName,value);

      };

  }



  function makeEventFunction(propertyName) {

      // subscribers is a closure that will be unique for each call to

      // makeEventFunction.

      var subscribers = [];



      var registerSubscriberFn = function (fn) {

          subscribers.push(fn);

      };

      var fireEventFn = function (value) {

          // subscribers is an array of callback functions,

          // call each of them with value and self (optional parameters)

          each(subscribers,function (fn) {

                   fn(value,self);

          });

      };

      var eventSubscribe = "on" + capitalize(propertyName) + "Change";

      var fireEventFnName = fireEventName(propertyName);

      // Add the methods to self.

      // if eventSubscibe is onHairColorIdChange then

      // it will be callable with self.onHairColorIdChange

      self[eventSubscribe] = registerSubscriberFn;

      self[fireEventFnName] = fireEventFn;

  }



  each(definitionArray, makeSetterAndGetterMethod);

  each(definitionArray, makeEventFunction);



  return self;

  // Put the result of calling makeSetterGetter in a variable x

  // You can now call x.setHairColorId which through _setParam

  // calls x.fireHairColorIdChange which is one of the fireEventFn 

  // added that has access to the subscribers array and 

  // can call the callback functions you might have added with 

  // onhairColorIdChange(function (value,obj) {doStuff();});

};



function demo() {

  function map (array,fn) {

      var result = [];

      var len = array.length;

      for (var i = 0; i < len; i=i+1) {

          var el = array[i];

          result.push(fn(el));

      }

      return result;

  };



  var specification = ['customerId','hairColorId'];

  var customer = makeSetterGetter(specification);



  customer.onHairColorIdChange(function (value,object) {

      alert("3.Customer id "+ object.getCustomerId() +

            " has new haircolor " + value);

  });



  customer.onCustomerIdChange(function () {

      // This is ugly, but you can also access properties

      // directly. This way I know no events will be triggered.

      customer.hairColorId='DONT KNOW';

  });

  alert("1.Customer starts with undefined color: " + customer.getHairColorId());

  customer.setCustomerId(10);

  alert("2.Secretly it has been set to don't know: " + customer.getHairColorId());

  customer.setHairColorId('blue');



  customer.commaSeparated = function () {

      var self = this;

      return map(this.getDefinitionArray(), function(paramName) {

                     return self._getParam(paramName);

                 }).join(',');

  };



  alert("4.Send this to the server:" + customer.commaSeparated());

};

Lisp macros explained in Javascript

2009-06-24T17:35:00.009+02:00

My two favourite programming languages are Common Lisp and Javascript.

I want to explain some of the features of Lisp in a syntax that is understandable to everyone. Of course everyone does not understand Javascript, but this example is simple and understandable also to C and Java coders.

The story

One day you see that you have a lot of small fragments in your code looking more or less like this:

if (someFunction(blaha)) {
   doSomeThingWith(someFunction(blaha))
   log("I did something with", someFunction(blaha));
};

You make a temporary variable to avoid running someFunction three times.

var temp=someFunction(blaha);
if (temp) {
   doSomeThingWith(temp);
   log("I did something with", temp);
};

You have now done this 2344 times in your career and at 34 places in your current project. SomeFunction takes 9999 ms. It smells. How long will it take until you want to refactor it?

In Javascript you can create new functions, but not syntactical constructs. And I can't really see how you would make a function to improve on this. But it would be cool if we could invent our own statements. What about this idea: An if statement that makes an automatic temporary variable that you can use later?

ifTemp (someFunction(blaha)) {
   doSomeThingWith(temp);
   log("I did something with", temp);
}

ifTemp would create a temp variable behind the scenes, put the result of someFunction in it and you could then refer to temp in the if clause. Now, if we are to hardcode the name of the variable, I would rather choose "it" instead of "temp". It makes the code almost poethic when read out loud.

ifit (someFunction(blaha)) {
   doSomeThingWith(it);
   log("I did something with", it);
}

I don't know who was the first to invent this, but I got the idea from Paul Graham and his book OnLisp. He calls this if-construct anaphoric if, as all we scholars instantly recognize from Greek rethorics. We could call this statement aif (a for anapahoric) instead of ifit.

An anaphoric if-macro in Javascript

Disclaimer: Don't try this at home. It won't work. This is just an example for how we probably would go about to do it, if it was possible.

macro.defineMacro("ifit",function() {
   macro.defineSyntax("ifit",
     macro.expression,
     macro.block,
     macro.startOptional,
     "else", macro.block);
   macro.defineExpander(function (context) {
      var testExpression=context.getExpression();
      context.moveForward();
      var block=context.getBlock();

      context.addStatement("var it=",textExpression);
      context.addStatement("if (it) ",block);

      // Handle else part
      context.moveForward();
      if (context.hasMore) {
          context.skipForward("else");
          var elseBlock=context.getBlock();
          context.addStatement("else",elseBlock);
      };
   });
};

In theory we could make something like this, parsing js files on the server, expanding macros and creating new js files to be loaded by the browser. But I won't do it. If I wanted to I would use a Lisp-like dialect instead (like Parenscript).

Translating the Javascript to Lisp

Lisp statements have a simple syntax. The whole statement is surrounded by a pair of parenthes.

In semicolon based languages:

someFunction(someValue,someOtherValue);

In Lisp:

(someFunction someValue someOtherValue)

Exactly the same number of parenthes by the way, and one less meaningless semicolon.

Javascript:

ifit (someFunction(blaha)) {
   doSomeThingWith(it);
   log("I did something with", it);
}

Translated to Lisp:

(whenit (someFunction blaha)
   (doSomeThingWith it)
   (log "I did something with" it))

"When" in Lisp is an "if" with no "else" clause. There is also an if-statement, but if we are to use it we need to put "doSomething" and "log" into a block (otherwise it thinks the log-statement is the else clause). A block in Lisp is actually a function called "progn". Progn means execute statements in order and use the last value as value.

(ifit (someFunction blaha)
   (progn
     (doSomeThingWith it)
     (log "I did something with" it)))

Defining a variable in Lisp is a statement "let" that takes a list of variables and value pairs as the first parameter, and then any number of statements where the variable is visible.

The thing we looked at first was this piece of Javascript:

var temp=someFunction(blaha);
if (temp) {
   doSomeThingWith(temp);
   log("I did something with", temp);
};

Translated to Lisp:

(let ((temp (someFunction blaha)))
   (if temp
     (progn
       (doSomeThingWith temp)
       (log "I did something with" temp))))

An anaphoric macro in Lisp

Lisp macros are defined with defmacro. It is evaluated at compile time, and simply returns a Lisp statement. You get pieces of source-code as input parameters. These parameters are not evaluated. The macro can do things witht the source code it gets in and should return some new source code as output. Since Lisp has such a simple uniform syntax, creating and inspecting source code is not a difficult task.

(defmacro ifit (testForm thenForm elseForm)
   (let ((srcCode "(let ((temp EXPRESSION))
                      (if temp THEN ELSE"))
      (replace srcCode "EXPRESSION" testForm)
      (replace srcCode "THEN" thenForm)
      (replace srcCode "ELSE" elseForm)
      (return srcCode))))))

To be truthful, actually the real world syntax it is even shorter and prettier using the backquote and comma subsitution mechanism. Notice that this is quite a bit shorter than the fake Javascript macro earlier.

(defmacro ifit (testForm thenForm elseForm)
  `(let ((it ,testForm))
     (if it ,thenForm ,elseForm)))

What is the deal?

Macros can be used for a lot of things. From small utilities like these to advanced embedded languages. Offloading lengthy calculations to compile time (Substitute "compile time" to on the "the server" for Javascript). Everything that Java uses "Annotations" for, but with more flexibility. If you get bored with Javascript, i suggest you take a look at Lisp. I recommend the book Practical Common Lisp as a good start. Some other great things about (Common) Lisp is a fresh view of object-orientation and unique exception-handling with restarts.

Disclaimer

I have made Lisp a little more mainstream in these examples in order to arguable make it easier to grasp. I would not call this simplification. On the contrary. Some would call it obfuscating.