A friend of mine has recently called Google Wave a simple chat app with no innovation whatsoever, well this are my first impressions about it (after reading and even using it! hehe):

A Google Wave is a centralized document (in opposition to the emails) that can be 
    • edited simultaneously with several invitees, 
        • using formatted text, images, videos, maps 
            • (even small applications can be embedded).
    • this content can have attached to it a conversation between the guests
        • where each reply can be edited:
            • using formatted text, images, videos, maps 
                • (even small applications can be embedded);
                • (and Google Gadgets have a safe home here too).
        • using a standard reply or from the middle of the content;
        
    • The Wave updates are shown live to all invitees, as they type.
    
    • The History of all updates is save so late comers can be sent "There and Back Again..." to the future :-)
    
    • You can attach files, save searches, organize your Waves with tags and folders;
    
    • Wave content understands youtube links, google maps 
       and I hope more text formatting tools in the future :-) 
       (just a bit more...)
    
    • The user interface is very clean, drag & drop friendly, you minimize and restore every box, etc.
    
    • They have defined an open protocol so every one can create Wave Servers (Like private corporate ones) 
       so they can compete with corporate email servers with a much more sophisticated and rich communication medium.
    
    • They also have this Robots concept, where a software component can be installed and receive all updates from an Wave 
       and act upon it (e.g. updating the Wave) like any other guest, in fact, in term of UI they are just another guest.
        • There's the Robot Rosy (a demo here) that can translate regular conversations and even based on their context! 
            • Like in a conversation about Brazil's current president do not translate his name to 'Squid'.  
    
That's why Google Wave (and the next private Wave servers) seems very promising to me.
        

I also recommend these very informative videos:

• What is Google Wave?;
• Google Wave: 15 features;
• Google Wave: Rosy

Today I've started a Wave with some of my friends to discuss the recently revealed google programming language called Go.

it generated C code as its output

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing. Finally, it is intended to be fast: it should take at most a few seconds to build a large executable on a single computer. To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection; rigid dependency specification; and so on. These cannot be addressed well by libraries or tools; a new language was called for.

... there is no type hierarchy: types just are, they don't have to announce their relationships ...

Why do garbage collection? Won't it be too expensive? ... The current implementation is a plain mark-and-sweep

Of course, implementing garbage collection in a concurrent environment is itself a challenge, but meeting it once rather than in every program helps everyone.

Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing)

Why is there no type inheritance? there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

One of the most successful models for providing high-level linguistic support for concurrency comes from Hoare's Communicating Sequential Processes, or CSP. Occam and Erlang are two well known languages that stem from CSP. Go's concurrency primitives derive from a different part of the family tree whose main contribution is the powerful notion of channels as first class objects.

What’s a systems programming language? It’s the kind of language you use when writing a new OS. Or a device driver. Or an I/O stack. Or a piece of networking middleware. Or a very fast web server.

Are we facing the beginning of the end of the C++{0x} era? And did Language D has lost momentum?

I've uploaded the HTML Lua Reference Manual into Google Docs and it used styles for several tags like the h1, h2, h3, etc title ones! Awesome! :)

Story: Today I helped on technical aspect of an interview at my job; At a certain point this guy brought to the conversation the Lua programming language. I decided to take a peek and maybe print at the last version of the Lua manual which I never saw again in the last years. The manual is available in a single HTML which is far from being the best printable format, so I decided to convert it to ODF first. I've always being a fan of the sophisticated JS Applications that Google Docs family is, since the beginning when their word processing didn't have a wrap text feature ;-) So after copy & pasting not working well on OpenOffice Writer I gave a shot at Google Docs upload feature, to my surprise the resulting document even being not perfect was created using styles for certain HTML tags, something tremendously helpful for medium to big texts!

I'm finally using twitter lists (and also finally back to my blog) in order to find some order from the chaos originated from so many different tweets of people I follow :-)

My Twitter lists:

• @bpfurtado/style
• @bpfurtado/software
• @bpfurtado/humor
• @bpfurtado/util
• @bpfurtado/gurus
• @bpfurtado/friends

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 :)