The function definition in Javascript

I highly recommended Douglas Crockford's book "Javascript:The good parts". In the page 133 of the book, the author mentioned 2 ways of defining a function:

• use function statement,
• use function expression

Their results are exactly the same. For example,
Function statement:

Function expression:

The above two have the exactly same result. they will both define a function foo. But I found there are still one difference: scope.
The function statement is globally scoped, it can be put anywhere in the javascript, and you can call the function before or after it is defined.
For example:

But in function expression is different, the function call statement must be after the function is defined, otherwise the function call will be failed.
For example:

When you think a little deeper, the error of function expression make sense, because the function expression means first declare a variable, then assign it with a function object. Why it failed before the function defined is because the variable is not declared and assigned yet.

So if you use the function expression to define a javascript function, you need to aware this issue.

Learning javascript: understanding prototype property

Prototype in javascript is so important, because javascript implements the object inheritance via prototype delegation. Here I tried to summarize what I found for the javascript property. The examples I used are tested on Firefox Javscript shell .
Please note that in Javascript function is also an object, so here function and function object are interchangeable.

1. Every function object is automatically created with its own prototype property, the prototype property itself is an javascript object.You can add property or functions to the prototype property via function object.
Example:
2. When a object is created by using new keyword, it will get the prototype object from the constructor function;  created object can not access prototype property directly like function object, but it can access the property of the prototype object:
example:

3. When the created object instance read a property of the prototype, which is directly linked to the prototype object of its function constructor; while you want to modify the property, you end up by creating a new property in the object itself, which will not impact the same property name in the original function prototype. I believe javascript in this way implements the OO inheritance and overriding.
Example:

4. The function object prototype property, which itself is an object, its default value contains only one hidden property: constructor, whose value is the same as the function itself.
Example:

Code is constraint

Last week I watched Michael Feathers presentation: Code blindness.This is a great presentation, and it inspired me to think deeper.

Before I think code is important from the programmer's perspective: craftsmanship, and professionalism. But it seems quite far to the managers. They don't know understand it and don't know how to connect this with their daily management.

Today I would try to think from manager's perspective: borrowing the idea from theory of constraints, I will say code is just another constraint, like other constraints manager usually considering: time, budget, people. More specifically code quality will impact developers productivity and on time delivery.

We know that the clean code base will easier to understand, easy to make change, and easy to maintain,but bad code base will hard to understand, hard to change, and hard to maintain, which greatly slow down developer's productivity.To avoid this happens, we have to deliberately keep code lean.

There are two main metaphor to support the clean code:

• Metaphor of technical debt: code base is like technical debt, we have to pay off first by taking effort to refactoring, otherwise it will become harder and harder to change and maintain in future, so refactoring is the interest we pay for the debt.
• Metaphor of software entropy: code base is like entropy, by nature it will gradually go to messy, we have to constantly refactoring and keep our codebase clean.

So we can get the conclusion: code can be asset if it is clean; and can be debt as well if it is messy.

So far we know that code is very important to developer's productivity, it should be consider as a constraint by the manager. But I found many managers are totally unaware of this issue:
They just assume developers are all professional and their code will always good enough;
They only care the schedule, only care something get done, but does not care if the code is well maintained or not.
And since managers unaware or ignore this issue, they might make decisions to make code base even messier, for example,
- they will pressure developer to push them make quick-and-dirty fix, which cause the long term issue;
- They do not care for the code, so they measure the performance only by task been finished, not by how good the code is written, so we can imagine developer will not actively care for the code.

Code is important, but if you unaware or ignore it, then you will not manage it.
If you don't manage it, then you will finally lost the control and then we will get real problems.
When you have the problems, but you don't understand the root cause is code quality, then you probably trying to solve the issue in a wrong way.
I heard so many times from managers said something like "we need to work harder", "we should work more careful", which are totally useless slogans.

Suggestions

1. Manager should aware the code quality's importance, bring the connection between good code quality to developer's productivity and developing schedule.
2. Manager should cover code quality into their daily management, right now there are so many different tools to do code analysis and measurement.
3. Manager should create a culture to encourage software craftsmanship, clean code is a foundation of good software product,  clean code fit nicely the "build quality in" lean principle.

Making developer multitasking is a bad idea

Following is copied from a job description for a mobile software developer from my previous employer QuickPlay Media:

"Well organized with the ability to effectively manage multiple projects simultaneously. Extensive experience in a fast-paced deadline-oriented environment".

When I first look at it, I was really surprised by the word "multiple" and "simultaneously", it is pretty obvious that they requires developers to be able to do multitasking jobs. Today I would like to dig this topic a little bit.

What does "manage multiple projects simultaneously" exactly mean?
- Working project A for 5 minutes, then working on prjoect B another 5 minutes, and project C for another 5 minutes?
- Or when you are working on project A, then interrupt by project B, you have to suspend the project A, then switch to project B;
- Does it mean the developer has more project working simultaneously, the better for his performance review?
- Does multitasking really improve the productivity? get faster delivery?

This idea is totally wrong
In the last 2 years I read a lot books about agile and software craftsmanship, so I am quite confident to say this is totally wrong, it will only make things worst!

Fist it is against human nature. Human is not machine, he is non-linear, a person can only focus on one thing at a time. Interrupt and context switching is very expensive. The book Pragmatic Thinking & learning and  peopleware cover this topic, and explain why managing focus is so important to maintain a higher productivity. and that is the reason why the Pomodoro technique will force you only focus on one task in each 25 minute session. Managing people's focus is the key of improving his productivity.

Second it is against the agile principles and and other proven theories. The goal of agile is to deliver the product as fast as possible, but the interesting thing is the agile trying to reach this goal by limiting the Working-In-Progress items (WIP).  Scrum is trying to limit WIP in one iteration, WIP is called inventory in Lean, which is a waste and should be limited. Limiting WIP is the key concept of Kanban technology. and in theory of constraints also proved that putting to many task in the queue will only slow down the productivity.The reason is pretty obvious, think about this scenario, if you have 3 projects, each will take one week. If you work sequentially, you will deliver one project after 1 week, 2 projects after 2 weeks, and you will get 3 projects after 3 weeks. But if you work simultaneously, you will get any project done until after 3 weeks, but considering the context switch cost, it will take you longer time to finish all 3 projects. So based on Scrum, or Lean/Kanban, or Theory of Contraints,  working simultaneously will not deliver fast, it will only delay the delivery time.

Third is it is a shift burden to from mangers to developers. Managing backlog is manager's responsibility, but requiring developer multitasking means putting some more backlogs into developers. It might looks better for managers, but actually it is bad, since those extra backlogs are either under working or putting into developer's own backlog. This is actually hide the visibility, which is even harder for manager to track the progress. I can feel that the multitasking is a solution which managers are trying to solve too many backlogs, but it is a bad idea, since it only move the backlog from manager layer to developer layer, which making things even worse; the manager should figure out the root cause and find a true solution to increase the burden down rate or increasing the productivity. I like to call this issue is leaky management issue(copied the idea from leaky abstraction from OO design), because it is supposed to be solved in the management layer, but it leaks to the developer layer.

Based on the above analysis, I can feel multitasking will generate following result:
developer will have low productivity, projects will get more delayed, developer have to work harder and over time; since more projects get delayed, so manger put more projects to developer to work simultaneously, then becomes a positive feedback loop, which will make things even worse...

Summary
I feel very sad for my old colleagues, because they are not treated well;  and I feel sorry for my ex-managers, because they are unaware of the basic principle of agile. To make a developer working efficiently, the only thing is trying to make him to work on one thing only. I strongly suggest QuickPlay to remove multitasking in its job requirements, but removing that from managers minds are much harder.

learning clojure: how to compile clojure source code

Currently I am learning clojure now, I focused on the book "The joy of Clojure", but actually I did not enjoy the joy of clojure so far. For me the book is still difficult. As the author mentioned, this book is not for beginner. Most of my time I have to refer on the Clojure API document. Today I want to share my experience on learning chapter 10.2.1, how to compile a clojure source code.

The source code is in page 212, listing 10.3, called DynaFrame.clj:

The author mentioned how to ompile the source code:

 You can compile this namespace by saving it in a directory joy/gui, located on the classpath, in a file named DynaFrame.clj and executing the function (compile 'joy.gui.DynaFrame) in a fresh REPL.

As a clojure beginner, I found it is described not detailed enough, it took me almost a night to figure out how to build it successfully.
After fixing different weird problems, finally I got it working. Here is what I found:

1. Be careful clojure version: at first I use clojure 1.0 to launch the REPL to compile it, but I got Exception to complain not found java.lang. Later I realize the problem is in ^{:static true}, you have to use clojure 1.2 to compile it; if you still want to use clojure 1.0, then use #^{:static true} instead.

2. Use cljr tool, I found it is really handy to add classpath: just run cljr add-classpath <your folder>; run cljr list-classpath will display your classpath.

3. Add source code folder in the classpath
   put DynaFrame.clj under joy/gui, and
   run cljr add-classpath ./

4. Add *compile-path*
   create an directory called "classes", and
   run cljr add-classpath classes/
   Based on the clojure API document:*compile-path* defaults to "classes", the directory must be in the classpath for 'compile' to work.

5. run cljr repl to launch the REPL,  type
    (compile 'joy.gui.DynaFrame)
   and
    (joy.gui.DynaFrame. "1st")

In summary, to compile the clojure code successfully, you need:
 - Add source folder in the classpath;
 - Create and add "classes" folder in the classpath

Developing Blackberry application using NetBeans Plugin - part 2, fixing debug issue

On my previous post, I reviewed the new blackberry Netbeans Plugin. Latre I found Shai also published his post about how to use the new plugin in developing the LWUIT blackberry application.
But I found the new plugin could not debug the blackberry application.

Reason
The reason is if you want to debug your blackberry application, you have to copy all the .debug files into the blackberry simulator folder, include xxx.debug, xxx-1.debug, xxx-2.debug, ... etc. From the generated build-impl.xml script file, we know that blackberry plugin only copied the xxx.debug file and missing all other debug files.

Solution
Add the following targets in the build.xml, which will override the same target in the build-impl.xml:
1.  Update target blackberry-pre-debug, it will copy all the debug files into the simulator folder.

2.   Update target clean-blackberry, it will delete all the files of the application in the simulator folder.

3.  If you want to build BlackBerry CLDC application, you need to add the target create-cod:


The only difference with build MIDlet application is in <arg value="-cldc"/>, by default, the Blackberry plugin already choose MIDlet by using <arg value="-midlet"/>.

Developing Blackberry application using NetBeans Plugin - part 1, first impression

Updates: I got some feedbacks that the download link in Netbeans is not working anymore, I uploaded the plugin binary into my google doc, please try my link if you have problem to download.

Recently when I checked out the latest version of the source code of LWUIT, I realized that LWUIT used a new solution of developing blackberry application - using Netbeans Blackberry plugin. So today I tried to give an review about this new tool.

Plugin Installation
1. go to this link (or my link)to download the blackberry netbeans plugin, save it in your local drive.
2. In your Netbeans IDE, choose Tools - Plugins, click Downloaded tab, press "Add Plugins..." button, choose the downloaded blackberry plugin .nbm file,
3. Restart your Netbeans IDE, the thing is it seems the blackberry plugin has an issue, you can not see it under the Installed tab of the Plugins UI Form. I was confused it at the beginning as well.

Add BlackBerry SDK platforms
The plugin download link (or here)gives some screen shots about how to add blackberry SDK platform into your NetBeans IDE environment, here I just give an rough description, if you are familiar with the steps of adding other J2ME SDK into the NetBeans IDE, you will know it is the exactly the same steps.
Compare this step with the older solution, you will feel how easy it is.

After Adding the BlackBerry SDKs in your NetBeans IDE, you can use the same way as J2ME Mobility package for blackberry development. Really Nice!!! Good job for the author!

Test
To test how the Plugin works, I choose 2 tests, one is for MIDlet and the other is for CLDC application (RIMlet).

Test1 - build an BlackBerry MIDlet application
I imported an JavaME SDK sample application - SunSamples-Demos into my NetBeans IDE, then add another configuration, choose an BlackBerry platform, I just choose JDE 4.5, then everything else is copied from the default configuration.
1. Test Build
Click "Clean and Build", the IDE build successfully and generate .cod file and bunch of .debug files.
So Build test passes.
2. Test Run
When I click "Run", the IDE launches BlackBerry simulator, then I found the several applications (since SunSamples-Demos contains multiple MIDlets), I choose some apps, they work perfectly.
Application Running also passed.
3. Test Debug
I set several break points in the IDE, then I click "Debug", the IDE launches the BlackBerry JDWP application and the blackberry simulator, when choose an application, the application did not stop at a specific break point.
The debug test failed.

Test2 - build an BlackBerry CLDC application
This time I choose a LWUIT blackberry port demo application - LWUITDemoRIM, just check out the LWUIT source code from its SVN, open the LWUITDemoRIM project. If you installed the plugin and added the blackBerry SDK properly, it is very easy to configure the project in the NetBeans.
Here I would like to mention, for native CLDC application, you need to do a little extra work in your build script. Check this link for details: http://forums.netbeans.org/topic24475.html

1. Test Build
Click "Clean and Build", the IDE build successfully and generate .jad file, .cod file and bunch of .debug files. If you open the jad file, it will tell you the application is CLDC application.
So Build test passes.
2. Test Run
When I click "Run", the IDE launches BlackBerry simulator, you will find the familiar LWUIT demo icon, the application works perfectly as I saw before.
So running test passed.
3. Test Debug
When I click "Debug", I saw the same behaviour as the MIDlet application test, the application never stops at the break point.
Debug test failed as well.

Conclusion
Pros:
- The Blackberry Plugin for NetBeans is pretty easy to install and use. The developer will feel it looks pretty same as other J2ME SDK.
- The Build process is really simple and almost same as regular J2ME application, it will convert jar file into blackberry .cod file.
- The IDE can launch Blackberry native simulator and can run the application successfully.
- The plugin built-in support MIDlet build, need a little work for RIMlet.

Cons:
- Debug is not working, after I read the build script, I know why: based on my experience, you need to copy all the .debug files into the simulator folder, but in build-impl.xml, the target "blackberry-pre-debug" only copied 1 .debug file but missing others.  I will post the detailed solution in future.

Next Action
In future, I will continue post my investigation about this plugin, includes:
- How to build the MIDlet and RIMlet
- Dig deeper on how it implement the blackberry build
- How to fix the debug issue