Continuous integration notification, the other way.

My team use Hudson for continuous integration it used to send mail to whoever commit.
Recently our handsome sysadmin decided that this is an abuse of the system so this option was blocked.

As a result i noticed from time to time that the build was broken for some time and i didn't love it very much, I assume no one love it.
I decided to improvise, Hudson  have plugin to gtalk so I created a gmail account for the builder and try this plugin.

Luck was not with me, the builder located in the lab on a private network so the plugin didn't worked.
However, Hudson have an option to send UDP package to a configured address as a result of a job state changed (job start, success or failed). so I configure Hudson to send my Linux machine notification about the build state.

Using Hudson REST API I was able to get all the missing information to send the needed data to the users who committed.
Since my machine connected to the web it was possible to start gtalk conversation quickly I wrote a Java program that send the users gtalk message using smack.
The result was beautiful the builder gtalk user start a conversation with the users that committed and report the build status.

Now for the last part, after I add an image to the gtalk user I was kind of attached to him, I was thinking it would be nice to talk with him from time to time, and then I remembered of my old friends from the university Eliza and Emacs Doctor.

The result is here: builder.webspace@gmail.com 
Here is a sample of our conversation

Just give it a try, open gtalk and chat with builder.webspace@gmail.com .
Barak.

Calling Java applet from Javascript

Hello.

Recently we were busy adding upload media to our webapp, it was required to upload large media files (more then 4G) from client browser to the main site while monitoring the progress. It was required that the user will be able to cancel downloads and have many possibly download running in parallel.

At first we tried to implement this using plupload which is flash client that use multi-part post, the sever side was implemented as Java servlet , this seems to works for small files but fail on large files, in addition memory was not free on some OS.

We next tried native html5 file upload that turn out to suffer with the same sickness, at the same time we noticed that jetty conent-length attibute is of type int and not long, that rules out both html5 upload and the multi part post approach.

Our last try was an FTP applet (based on our in house FTP client) that upload files to a Mina based FTP Server.
That turn out to be really successful, we let the applet handle the file choosing and the FTP to the server while keeping the UI in the Javascript side.
There were 2 things that gave us hard time while developing this applet.

• The first is the security, it turns out that even while the applet is fully signed and allow all security, it can not do that from a thread that was called from Javascript -- Oracle doc has only one short sentence about this property and it took us a while finding it.What we did is use the command pattern, having one thread created from the applet constructor, this threads allow to do all since it does not a thread created for Javascript command execution. A request from Javascript create a command that returns a Future, those commands than inserted into a queue to be processed by the thread created at the applet constructor.This seems to work well. Pay attention that you should not use Java Executors to implement this queue since Java Executors are lazy in its thread creation.
• The second issue related to the fact that embedding Java Applet in a page make the page load un responsive while the Java Plugin is loaded -- so we preferred to load the Applet dynamically the first time that the user try upload, this turn out to be tricky on Firefox on Mac and on IE you need to create a new IFrame for the applet, while in Firefox on Linux and Windows you can load the applet dynamically directly to your page.

The Applet Code code.

What is 'Level out the workload' in software development

Recently I been reading Taiichi Ohno book

Toyota Production System: Beyond Large-Scale Production

A key principles in his book was the principle of leveling out the workload

I have been reading lately lots of books that show how to apply Toyota Production principles to a software development process most of them describe how to map Toyota 7 waste to the software development world.

For example

• Inventory  ~ Partially Done work.
• Extra Processing ~ Extra Process.
• Overproduction ~ Extra Features.
• Transportation ~ Task Switching.
• Waiting   ~ Waiting
• Motion ~ Motion
• Defects ~ Defects

The meaning of leveling out the production in Toyota is to try to make every day the same amount of
each type of product.
For example:

If you have an order of 300 cars of types A and 600 Cars of type B each Cell should assembly
one car of type A than 2 cars of type B and so on.
According to the book leveling out the production help to maintain both machines and employee in good condition, where burst of actions and afterward long periods of doing nothing exhausted both humans and machines.

Another great benefit of leveling out the production is that it allow JIT, when working in JIT
you get every part from the earlier processes exactly when and where you need it, this enable single flow, reduce inventory and find defects early.

Now the question I was thinking of is, how do I level out the workload for software development ?

Software development is creative process unlike car production so maybe there is no good equivalence to leveling out the workload in software development.

My faith is that in software production the your best assets are your employs so leveling the workout can be mapped to:

• Invest and educate your employs.
• Give them feeling that their work is important.
• Provide them with ways to measuring their progress.
• Plan ahead to reduce burst of actions or periods of doing noting.

If you think there are other way of leveling out the production in software development, please let me know.

Testing YUI DND with Selenium

If you happen to write some selenium tests for YUI based page you may notice that sometime selenium DND does not work.
This is because selenium sometime has error when computing the right X,Y of a component when using YUI layout manager.
This problem can be solved easily by overriding selenium JavaScript code that compute X,Y given a locator.

For example getElementPositionTop can be rewrite to something like that:

Selenium.prototype.getElementPositionTop = function(locator) {
    /**
     * Retrieves the vertical position of an element
     *
     * @param locator an element locator pointing to an element OR an element itself
     * @return number of pixels from the edge of the frame.
     */
    var element;
    if ("string" == typeof locator) {
        element = selenium.browserbot.findElement(locator);
    }
    else {
        element = locator;
    }
    var xy = selenium.browserbot.getCurrentWindow().YAHOO.util.Dom.getXY(element);
    return xy[1];
};

All the change should written to a file for example 'user-extensions.js' and selenium should be run with the cmd:


java -jar selenium-server.jar  -userExtensions user-extensions.js

That should solve the issue.

JavaScript applicative Y combinator

Recently I have been working with JavaScript.
Although JavaScript interpreter does not have to be tail call optimized, and I believe most of them are not, JavaScript have closures and functions are first class objects. Hence it is possible to write in JavaScript applicative Y combinator.

In this short text I will start with a simple recursive factorial function written in JavaScript and by modifying it again and again I will transform the code into two methods Y and F such that Y handles the recursion and F handle the factorial logic.
It is worth to mention that once one have those methods, they can be used without naming (anonymously).

Starting with:


var factorial = function(n) {
        if (n === 0) {
            return 1;
        } else {
            return n * factorial(n - 1);
        }
    };

The first change is to create a factorial factory and use it instead the direct call.


var f = function() {
        return function(n) {
            if (n === 0) {
                return 1;
            } else {
                return n *f( )(n - 1);
            }
        };
    };

Now instead of factorial(6) we call f()(6).

Next we change the factory method r to receive one argument, this argument will be always a factorial factory itself.


var f = function(f) {
        return function(n) {
            if (n === 0) {
                return 1;
            } else {
                return n * f(f)(n - 1);
            }
        };
    };

Now the call has changed to something like f(f)(6).
When substituting r’s body with r in the call above we have:

    function(f) {
        return function(n) {
            if (n === 0) {
                return 1;
            } else {
                return n * f(f)(n - 1);
            }
        };
    }
    (function(f) {
        return function(n) {
            if (n === 0) {
                return 1;
            } else {
                return n * f(f)(n - 1);
            }
        };
    })(6)

The next transformation is reverse eta conversion (η-conversion)
 f(f)(n) => function(a){ return  f(f)a}(n), this delays the computation of f(f(n)  and prevent infinite  loop because of the evaluation order in applicative order.


    function(f) {
        return function(n) {
            if (n === 0) {
                return 1;
            } else {
                return n * ((function(a) {
                    return f(f)(a);
                })(n - 1));
            }
        };
    }
    (function(f) {
        return function(n) {
            if (n === 0) {
                return 1;
            } else {
                return n * ((function(a) {
                    return f(f)(a);
                })(n - 1));
            }
        };
    })(6);

Now (function(a) {

                    return f(f)(a);

                })

can be extracted out we will do that by wrapping everything in a new function call with param r and passing it the expression  (function(a) {

                    return f(f)(a);

                })

To the function

    function(f) {

        return function(r) {

            return function(n) {

                if (n === 0) {

                    return 1;

                } else {

                    return n * r(n - 1);

                }

            };

        }(function(a) {

            return f(f)(a);

        });

    }

    (function(f) {

        return (function(r) {

            return function(n) {

                if (n === 0) {

                    return 1;

                } else {

                    return n * r(n - 1);

                }

            };

        })(function(a) {

            return f(f)(a);

        });

    })

Now we do the same with the pink expression and have:

function(m) {

        return function(f) {

            return m(function(a) {

                return f(f)(a);

            });

        }(function(f) {

            return m(function(a) {

                return f(f)(a);

            });

        })(function(r) {

            return function(n) {

                if (n === 0) {

                    return 1;

                } else {

                    return n * r(n - 1);

                }

            };

        });

Hence we have 2 functions

var y = function(m) {

        return function(f) {

            return m(function(a) {

                return f(f)(a);

            });

        }(function(f) {

            return m(function(a) {

                return f(f)(a);

            });

        });

and:

var fact = function(r) {

            return function(n) {

                if (n === 0) {

                    return 1;

                } else {

                    return n * r(n - 1);

                }

            };

        }

and 

y(fact)(6) => 720

How to convert user stories to tasks

Every Agile team needs to convert, as part of its work, user stories to lists of tasks.

• User stories are stories that describe how the user wants to act on the system and what happens as a result. Implementing a user story can span over many days for the whole team. However, it is preferred to narrow a user story if its estimation exceeds the agile iteration time.
• Tasks on the other hand, are coding + testing missions for one programmer (could be two in cases where pair-programming policy is used by the team). They normally do not exceed one day of work. 

During the iteration planning time it is the team’s responsibility to convert the list of the user stories given by the product owner, to lists of tasks. This is done for the following benefits:

• By splitting user stories to smaller tasks the team is forced to discus implementation issues and to understand better what is needed, and agree how it should be implemented.
• It is much easier to estimate a small task than the whole user story.
• It is possible to track the progress of the team when the team members work on day or less long tasks, this can help the team coach to see and handle problems soon.

Now the question is how does one split the user stories to tasks?

In my team we are working on software that spans over modules. We have a database, business logic servers and a client application.
Most of the user stories involve coding in all modules. Thus, at first, we used to split the user stories with respect to those modules, each user stories became 3 tasks -- database, business logic and client.

It seems natural doesn't it?
Well apparently it is not. Although the team shares the same room, we spent much time on integration. And most of the time, even after all of the user stories tasks were done, the user story itself was not done yet.

Recently we started to create tasks by functionality instead of modules, with this method each task implements part of the functionality required by the user story (maybe even simplified one) but it spans over all modules.
At start it seemed like we are doing more work (instead of working on the database until all work is completed, we now implement in iterations), but this is not true, working like that has a lot of benefits.

Among these benefits are:

• Less integration issues.
• System tests can be a part of the task (Done definition).
• Testing can start earlier.
• If the user story is not finished by the end of the iteration, some times it is still possible to ship 

the part that is done.

In my opinion, what frightens teams from working like that is the fear that newer tasks will create regressions in early tasks.

I see this fear as another benefit since it forces you to write good system tests for each task and insist on the done definition.

Bugs free software development

This is the holy grail of the software industry, how can we write bugs free software.
Surely there is not such thing, what we can do is improve the development process toward this goal.
My assumption is that programmers will always create bugs as they develop, so I will focus on the safety harness - testing.

We can divide the test into 2 categories:

• Automatic tests,
• Human tests.

First let's look at automatic tests; there are 2 kinds of them:

System tests -- tests that check the whole system by performing user stories as defined in the spec.

• Pros
• System tests are important because they tests/use the system like real users do .For example system tests run on top of setup installation using the real database and other 3rd party components.
• It is very easy to design good set of system tests, you just have to follow the user stories that the system should support.
• One big advantage of system tests are that they are not tied to implementation of specific module, for example you can change the underline algorithm since the user story stay the same the test remain correct.  
• Cons
• System tests takes time to run and hard to understand where things go wrong when failed, so in most of the cases the tests infrastructure should be accompanied by report infrastructure.
• It can be technically very hard to prepare the infrastructure required for for system tests because of the dependencies of 3rd party components.

And unit tests -- tests that written by programmer to test a piece of code before or after writing this piece of code.

• Pros

• Unit test are run fast and can be part of the compilation process on the developer machine, so bugs are caught and fix on the spot.
• Since it run fast it is possible to cover in some case all the input and the output for a given piece of code and this is very nice.
• Unit test are very easy to fix when fails.
• Unit tests in general create better code because it force the programmer to think of interface and use its piece of code on the spot.
• Cons
• Unit tests are highly dependent on the code they tests, you can not change algorithm without rewrite the tests.
• Good set of unit tests are very hard to write, it is an art.

A good software development process should rely both on unit tests and on system tests as part of the development process.
The first line of defense should be the unit tests, while the system test should be used to verify that the old user stories still working.

What about human tests?
First it is clear that there should be phase of human tests in or after the development process
this is because automatic tests will never give you 100% cover in nontrivial software.

I myself think that it is better to push the human tests as early as possible in the development process because:

• That way you always know where you stand.
• The more early you find bug, the easier it to fix it.

The real difficulty in this case where the team contains programmers and testers is how to make the testers citizens with equal rights.