Pattern matching is the reverse of Object construction, that all it is...

I must say, the Functional Programming side of Scala is a whole new world to me, and the pattern matching mechanism a big a part of it, and I have the intention to deep dive all this.

• Lift creates/destroys an Actor for each Comet request. This rapid creation/destruction of Actors caused memory back-ups, and the existing Actor code seems to be oriented to long running Actors rather than Actors with Object-length lifespans.
• The FJ libraries used for Actor scheduling have problems on multi-core machines and are also a source of memory retention issues.
• Replacing the FJ libraries with a scheduler based on java.util.concurrent exposes race/deadlock conditions related to the fact that some parts of the Actor processing (e.g., testing mailbox items against partial functions while the Actor itself is synchronized)
• The Actors require external threads to function and it's not possible to create external threads in the Google App Engine (making Actor-based functionality including CometActors non-functioning in GAE apps)
• Actors are fragile when exceptions are thrown
• Actors have running and not running states (as compared with objects which can always respond to message sends). In practice, managing the running and not running states is as hard as managing memory in C.
• There are hidden actors associated with each thread which display the above fragility and state management issues
• And as a practical matter, I've got a couple of applications that are going into production over the next few weeks and cannot wait for the various fixes to make it into Scala 2.8 and the hacks and work-arounds that I've done to the 2.7.4 Actor libraries became too complex for my comfort.

Yesterday I was unit testing some code of my work and I started with a top down approach regarding the way I wanted to write the testing code.

Basically I wanted to have a collection of Command objects that would change my input instances (to a Rule Engine) so I could mix and match easily different updates to trigger different rules, at each unit test (lines 9-10).

I also wanted to make several requests to the Rule engine, before validate the results, since a lot of rules are just fired after other ones being fired on previous invocations (lines 12-13).

But what I wanted the most was to easily express the way I would get results from different iterations (using ranges); and summarize elements and apply operations on the resulting sets of data (lines 15-17).

To better understand the assertions above one must know that some arrays of integers, double, Dates are sent back and forth to the Rule Engine, inside the engine the end user sees those array slots as proper named structured data, but at this level, where we poor developers reside they are just arrays, and the class that holds them all is the one called 'Profile', so now I can say that I wanted in the line 17:

• Extract the results from the iterations (or requests) 6 to 10;
• From those iterations work only with the integer array of values, specifically the ones on the position 3;
• Check if the difference between each one of those are of 1;

All those methods in place I could start with their implementation, and bellow is the result (with the omission of some unrelated code ;):

Bellow the 3 container classes, so I could work exactly with the data I needed for each assertion:

public class CommandsResultSet
{
    private List<ComandsOutputIteration> iterations = new LinkedList<ComandsOutputIteration>();

    public ComandsOutputIterationSet iteration(int start, int end)
    {
        ComandsOutputIterationSet set = new ComandsOutputIterationSet();
        for (int i = start; i < end; i++) {
            set.add(iterations.get(i));
        }
        return set;
    }

    public ComandsOutputIteration iteration(int idx)
    {
        return iterations.get(idx);
    }

    public void add([OmittedName1]Output output) {
        iterations.add(new ComandsOutputIteration(output));
    }
}

public class ComandsOutputIterationSet
{
    private List<ComandsOutputIteration> iterations = new LinkedList<ComandsOutputIteration>();

    public IntProfileVarSet intProfileVar(int idx)
    {
        IntProfileVarSet set = new IntProfileVarSet();
        for (ComandsOutputIteration it : iterations) {
            set.add(it.intProfileVar(idx));
        }
        return set;
    }

    public void add(ComandsOutputIteration iteration) { iterations.add(iteration); }
}

public class ComandsOutputIteration  
{
    private [OmittedName1]Output output;

    public ComandsOutputIteration([OmittedName1]Output output) {
        this.output = output;
    }

    public int intProfileVar(int idx) {
        return output.get[OmittedName2]ProfileVariables().getIntegerValues()[idx];
    }
}

public class IntProfileVarSet
{
    private List<Integer> ints = new LinkedList<Integer>();

    public boolean incrementedEachTime(int diff) {
        if (ints.size() < 2) {
            throw new RuntimeException("Less than 2 elements! No increment can be verified!");
        }
        return diff(0, 1, diff);
    }

    private boolean diff(int current, int next, int diff) {
        if (ints.get(next) - ints.get(current) == diff) {
            return next + 1 == ints.size() ? true : diff(next, next + 1, diff);
        }
        return false;
    }

    public void add(int intProfileVar) { ints.add(intProfileVar); }
}

This top down approach to design certain operation is most pleasant since you already start exactly where you want to get in the end :-)

*The [OmittedNameX]s where placed to protect the Business of this client.

Sometimes the client can be happy with a simpler functionality than the one he asked for.

If this simpler functionality will make your life easier, like avoiding the break of a good abstraction already in place, it's worth to show alternatives to your system users, after all, they very often don't know for sure exactly what they are asking for.

That's what the presentation bellow describes very well, with a real life example :-)

The code bellow shows how Java annonynous inner classes are just static typed closures, with all verbosity but also all behaviour needed :-)

Back on 2004, Fowler said about closures:

So the first crucial point about closures is that they are a block of code plus the bindings to the environment they came from. This is the formal thing that sets closures apart from function pointers and similar techniques.(Java's anonymous inner classes can access locals - but only if they are final.)

As we can see on lines 10 and 13 our method being sent to the each operation is capable of accessing a local variable (marked as final though). Of course, closures should be much more easy to manually write, that's half of their strengh.

This is again, just to exemplify the concept, even so, anonymous inner classes are extremely handy in the absence of "normal" closures backed up by good syntax sugar.

(*) Extending LinkedList is not encourage, but this is just to make the example simpler

(**) In favour of Java I can say that free IDEs like Eclipse can generate all this verbose code with a few keystrokes (and programmers are more than used to that with their editors, hehe). Hence, leaving us the the best of both worlds, closures but still all the good side of static typing, like safe automated refactorings. And the chances you to be using already a IDE for Java development are rocket high...

(***) Closures are much more pleasant with proper syntax sugar, there's no way do deni it.

I'm sure I'm not the first to blog this but let's go: This simple example shows how we can have the Duck Typing effect using reflection on the Java platform:

Above we are invoking the quack method on two references, one that has the needed implementation and the other which does not have. As expected the second invocation raises an runtime error, as with any dynamic language :-)

Of course this is just a proof of the concept and not what should be a regular practice on development with the Java language. This is just to remember that people very often does not proper recognize the dynamic features of the Java runtime environment.

They are probably less important when programming in the small. Types can be in a spectrum from incredibly useful to extremely annoying. Typically the annoying parts are type definitions that are redundant, which require you to do a lot of (finger) typing. The useful parts are, of course, when types save you from errors, when types give you useful program documentation, when types act as a safety net for safe refactoring.

At the same time I'll not need to maintain this script for months or years, or might never read it again, hence the possibility of powerful automated refactoring (that for instance IntelliJ of Eclipse provide) are not a need, like they are and we already take them for granted on regular systems that we deploy to hundreds/thousands of users.

Automated refactorings are the open gates to the easy and encouraged evolution of software code, and statically declared types are their very foundation.

{title updated}

I was talking to Miguel about the advantages and disadvantages of the CGI way of making web apps, and had in mind the yearly years of it and how alternative solutions like Java Servets proposed a much more sophisticated way to handle the emerging web application needs. Then I stumble upon a @voidspace's blog entry: Is CGI dead? and the argument of simplicity (as I remember Miguel rightfully pointed this also) was put on the table and I don't disagree at all with it. And interesting is to notice that even Java Servlets simplicity (although not as simple as the CGI protocol is) made it the very foundation of several other famous frameworks, which in the end do a lot of the dirty work that software developers used to have.

It's always the tradeoff: with a very simple (but elegant) solution you easy it's adoption, and on its solid base several other layers of software can be built, providing each one more features to the components that will lay on top.

1970 - Guy Steele and Gerald Sussman create Scheme. Their work leads to a series of "Lambda the Ultimate" papers culminating in "Lambda the Ultimate Kitchen Utensil." This paper becomes the basis for a long running, but ultimately unsuccessful run of late night infomercials. Lambdas are relegated to relative obscurity until Java makes them popular by not having them.

1987 - Larry Wall falls asleep and hits Larry Wall's forehead on the keyboard. Upon waking Larry Wall decides that the string of characters on Larry Wall's monitor isn't random but an example program in a programming language that God wants His prophet, Larry Wall, to design. Perl is born.

:D

The Fink project wants to bring the full world of Unix Open Source software to Darwin and Mac OS X. We modify Unix software so that it compiles and runs on Mac OS X ("port" it) and make it available for download as a coherent distribution. Fink uses Debian tools like dpkg and apt-get to provide powerful binary package management. You can choose whether you want to download precompiled binary packages or build everything from source. Read more...

In days of old in 2.6.29, netfilter did locketh using a 
lock of the reader kind when doing its table business, and do
a writer when with pen in hand like a overworked accountant
did replace the tables. This sucketh and caused the single
lock to fly back and forth like a poor errant boy.

But then netfilter was blessed with RCU and the performance
was divine, but alas there were those that suffered for
trying to replace their many rules one at a time.

So now RCU must be vanquished from the scene, and better
chastity belts be placed upon this valuable asset most dear.
The locks that were but one are now replaced by one per suitor.

The repair was made after much discussion involving
Eric the wise, and Linus the foul. With flowers springing
up amid the thorns some peace has finally prevailed and
all is soothed. This patch and purple prose was penned by
in honor of "Talk like Shakespeare" day.

Signed-off-by: Stephen Hemminger 

IBM sells Hardware, an Operating System (AIX), a Database (DB2), JEE Application Server (Websphere family), a Java IDE (Based on Eclipse) a their own Java SE implementation (J9).

Sun idem: Solaris (SO), MySQL (DB), Glassfish (JEE Stack), Netbeans (Java IDE & Application Platform) and the Hotspot.

Oracle on the other side (AFAIK) doesn't sell Hardware, nor a Operating System, has Java IDE that was very late in terms of modern IDE features and also did not have a implementation of the Java SE.

That said, I think the market has more to earn with Oracle buying Sun than IBM, so we don't simply loose a whole family of great products into what could be a bizarre corporate merge of them.

I just hope I'm right.

"[The acquisition] isolates IBM straight away because IBM didn't buy Sun. Two weeks ago IBM could have dominated nearly two-thirds of the Unix market and this week they'll be lucky to dominate a third of it. IBM missed the boat here. I think Solaris is a real threat here for IBM," Gartner's Dawson said.

Research firm Technology Business Research (TBR) said in a note: "Oracle may spin off or sell off some parts of Sun’s hardware and software business following the acquisition. Likely purchasers of Sun's hardware business include Fujitsu, EMC, Dell and HP."

Ovum's Mitchell said: "The market's really condensing into four large players at the moment - IBM, HP, Microsoft and Oracle, after this acquisition, are really the largest around. It's moving [Oracle] into that category."

I have sent this by email to some friends last week and got very interesting replies, I guess I should have posted it here from the start :-)

1. Web Designer never has to touch Java code;
2. Create multiple "Web Skins" for a application;
3. Change Look and Feel;
4. Change Layout on a given Web Page;
5. Change Flow among Web Pages;
6. Move *existing* data elements from one page to another;
7. Integrate with various backend infrastructures;
8. Reuse components;
9. Perform internationalization (i18n) of a web application;
10. Keep the API small and to the point;
11. Ability to learn WebWork fast, by making all the fancier features optional;
12. Allow the developer to choose how to implement as much as possible, while providing default implementations that work well in most cases [1];

I'm not sure if the order on the list above reflects the priority but if so I would strongly use the items from 8 until 12 as the first top one priorities:

1. Reuse components;
2. Keep the API small and to the point;
3. Ability to learn <YOUR FRAMEWORK/API NAME HERE> fast, by making all the fancier features optional;
4. Allow the developer to choose how to implement as much as possible, while providing default implementations that work well in most cases [1];
5. Perform internationalization (i18n) of a web application;

An the last item is for certain one of the main strengths of the Springframework, as well as the terrific usage of Object Oriented advantages as Polymorphism.

I stumble upon this WebWork article because a tool I'm using for the past months makes some use of it :)

• Ballmer: Linux Bigger Competitor than Apple;
• Apple released the first beta release of Safari 4.

Ruby and JRuby still generate a lot of enthusiasm. More and more Ruby programmers are looking at JRuby as their Ruby projects mature — when they move into heavier loads, larger systems, more cores, more processors. Most significantly, as Ruby development branches out into larger enterprises where deployment on Java servers is important, JRuby is seen as the solution.

A less obvious advantage to JRuby is that it may already be a better Ruby implementation. Certainly that's where it's headed — faster, better use of memory, better use of resources. Many Ruby programmers are starting to see these advantages.

So, people are beginning to understand that whether it's based on Java or the standard implementation, JRuby is better at handling resources, better at taking advantage of multi-core processors, and so on. This is the impetus for people to try JRuby, and to stay with it once they've tried it.

On the last days I decided to put on my radar more readings about software development methodologies, more specifically Scrum, as my friend Serodio told about a course he's planning to attend.

Looking for a good comparison between RUP and Scrum I quickly found this small blog entry with the experience Dennis var der Stelt.

The post is pretty old (from our industry point of view at least ;) but nevertheless interesting:

I have the feeling Agile development can better understand and react to what the customers needs, not what he thinks he wants. That comes to show in this funny picture of a swing.
It's funny to see how everyone within a project has (or can have) a different view on the swing. I think it's hard to get the same swing in every picture.
...
To get the same picture in how a customer explains it and what a customer really needed, you need good iterations and a lot of communication. For some reason, I have the feeling communication in RUP is more through documents where as in Agile it's face to face communication between the customer and the entire team. And I think that's an important difference.

When you see that a project like Apache Wicket uses Maven, you can assume that you'll be able to check it out from source and build it with mvn install without much hassle.

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Wicket Parent ......................................... SUCCESS [1:07.896s]
[INFO] Wicket ................................................ SUCCESS [2:44.671s]
[INFO] Wicket Date/Time ...................................... SUCCESS [15.380s]
[INFO] Wicket Extensions ..................................... SUCCESS [12.289s]
[INFO] Wicket IoC common code ................................ SUCCESS [9.690s]
[INFO] Wicket Spring Integration ............................. SUCCESS [16.648s]
[INFO] Wicket Velocity ....................................... SUCCESS [3.336s]
[INFO] Wicket Auth Roles ..................................... SUCCESS [4.665s]
[INFO] Wicket Guice Integration .............................. SUCCESS [8.259s]
[INFO] Wicket JMX ............................................ SUCCESS [2.217s]
[INFO] Wicket Objects Sizeof Agent ........................... SUCCESS [1.063s]
[INFO] Wicket Examples ....................................... SUCCESS [1:39.868s]
[INFO] Wicket Quickstart Archetype ........................... SUCCESS [37.774s]
[INFO] Wicket Thread Test .................................... SUCCESS [10.396s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 minutes 39 seconds
[INFO] Finished at: Wed Oct 22 22:35:52 BRST 2008
[INFO] Final Memory: 29M/63M
[INFO] ------------------------------------------------------------------------

It simply worked :)

Tail Recursion is a specialized type of recursion where there is a guarantee that nothing is left to execute in the function after a recursive call. In other words, the function returns the result of a recursive call.

If there is no additional instructions to execute, then there is no need to store the instruction pointer on the stack, since the only thing left to do once the recursive call exits is restore the stack. So rather than needlessly modifying the stack, tail calls use a GOTO statement for the recursion. And once the recursion eventually succeeds the function will return to the original instruction pointer location.

He also uses F# to write the sample code: A succinct, type-inferred, expressive, efficient functional and object-oriented language for the .NET platform.