I'm just having a look to Fan and it seems quite a cool language, soon more posts on this.

Fan Programming Language: "Portability Write code portable to both the Java VM and the .NET CLR.

Familiar Syntax Java and C# programmers will feel at home with Fan's curly brace syntax.

Concurrency Tackle concurrency with built-in immutability, message passing, and REST oriented transactional memory.

Static and Dynamic Typing Don't like the extremes - take the middle of the road.

Elegant APIs We're quite obsessive about providing all the key features required for a standard library, but with much less surface area than the APIs found in Java or .NET.

Object Oriented Everything is an object.

Mixins Interfaces but with implementation.

Functional Functions and closures are baked in.

Serialization Built-in 'JSON like' serialization syntax makes Fan ideal for declarative programming too.

REST Model data with a unified namespace of resources identified with URIs.

The Green Java Black is now free on JBB, no more need to post questions in order to get the points necessary to have the exam, definitely a good achievement of the community.

Get your green belt for free It's been 4 years now since JBB started and we are proud of what the community has achieved: There are 55 released exams (84 counting beta exams), for a total of 31,210 available questions. Our 39,274 users have taken a combined 240,396 exams during which they gave 2,684,770 answers, 53% of which were correct! Now that we have so much material ready to challenge you, we've decided to make more of it free. Currently, only the two exams needed to get the yellow belt are free. From now on, if you follow a given path, you can take up to 9 exams without any contribution. The pros and cons have been discussed in the following forum thread, feel free to have a look. The next features we are going to focus on are the tools that help moderators do their work. A first step will be to unify question listings, and as usual we've started a thread to welcome all your suggestions.

What is a spike? That question came out at the second Hong Kong Agile meeting, last Wednesday. I was surprised, a spike was something in my base knowledge, something obvious. I think I've learned first the world spike in a programming context rather than spike in any other context.
Probably is not so obvious and makes sense to blog about it.

knowledge spikes

My first spike was quite few years ago, on my first medium size Enterprise project.
The aim of the spikes was to understand a current system, from the database layer to the UI.
It was pain, I still remember it. It took me almost a week, asking help many times, it wasn't an XP project.
At the end of the exercise I was able to understand very well the system, and able to contribute well on the project.
The code produced was checked in. To provide context, knowledge for future joiners in the project. Code that should not run in production.
Basically it was a main class, instantiating all what you need to start up the full system.
I've to say that the codebase was definitely well designed, otherwise doing such an exercise cold be very very diffult.

spikes checked-in?

Conrad, while giving his presentation with Tom on Agile techniques stated that there should be no check in of the code, since that code should never go on production.
I disagree on most cases, there's always a value on the spikes.
The only spikes I would not check in are my personal trials to understand what's going on, crappy code that I would not show us to anybody, so ugly that it doesn't deserve the honor to go on the code repository: One shot spikes.

design sets spikes

On my last project with Pat we tried different design sets (also including technology decisions) for a big problem of redesign/refactor we had.
Also in that case we put the code under version control. Why? For future joiners for instance, these was what we tried, the solution that won it's on the trunk, the failures on a sperate trunk folder, spikes can be a good name right?
I'll take the same approach also starting a new project. Let's pretend I've to start a new java project, an app with a database layer. You can spike the database access with Hibernate, with Ibatis, with EJBS, etc...
It will help you in estimating future stories, in the understanding on how much the chosen solution is testable.

estimations?

A spike should always be estimated, a fixed amount of time can be allocated during an estimation session.
A spike should always achieve a final goal.
If a spike screw completely the estimation throw it away, something is wrong, probably the design, the technology you're trying to use is too complex to play with it, don't insist on.
Throw away but check it in, even if not working, on the spikes trunk! I can't imagine any better documentation for new joiner to justify, to explain, that's why we didn't use EJBs, look at that!
Shall I write tests doing a spike? Why not. If you're trying to find a design I can't imagine anything better that some old good TDD, if you're trying to understand the system you can write a main if you're not familiar with tests or just some tests. A spike can be made of tests.

more on the web...

Take a look also on the definitions on C2.com.
XP.org has his definition as well.

My friend Bruno kicked off, silently few weeks ago the Java Essential project.
What is Java Essential?
It's an open, collaborative book, written in Italian about Java and not only. It will cover topics like TDD, Object Oriented Design and Domain Driven Design, and all the most current/good/trendy frameworks.
It will be written in Italian, for the Italian Java (not only Java really...) community, written by the communities, in fact various good guys from various different Java User Groups and Organizations will write the content.
I've been asked to write the chapter about Domain Driven and since I'm not a good writer I've asked to Floyd Marinescu if I can translate his nice Domain Driven Design Quickly, and he agreed.
Depending on how much it will take and on how much time I'll be able to allocate on this project I'll translate partially the book for Java Essential or the full book, linking it then on InfoQ.
If there's one thing that I care about is to spread around the world what we do and how we do it, last year I had in total four speeches in Rome, Turin, Varese and Bologna, since I'm a bit far from Europe now, that's the best way to continue in that direction :-)

Yes, I still read too much code with switches inside. I hate it. There's still also a "nice" page on the official website of Sun on how to write really nasty code, it's here. I don't wanna infect this blog, so I'm not pasting that example of code here. I paste only a quote, it says:

Deciding whether to use if-then-else statements or a switch statement is sometimes a judgment call.

Yes, indeed. And the judgment call is: "should I write a long list of if then else or maybe think on some kind of polymorphism?" The switch is not an option. Switch smells of poor design, smells of "you dude, writing that code, you don't know what object oriented is!". It's not well testable, it's ugly. The web is plenty of examples on how to refactor from a switch to a decent design, just searching right now, I've found a good one here. There's another one here, with strategies for getting rid of it. So why are you writing still switches? Let me know, we can talk about this and maybe I can help you to quit. Switch off the switches. That's the tip. :-) Hey, this does not allow you to write a long chain of if then else blocks! Think on polymorphism every time you write an if, ask to your pair what he thinks, maybe you can move that responsibility somewhere else, one if is still fine but when you start to have an else... Mhmmm.... I really hope that someone is reading and I'll read less switch stuff...