Gwadanina Rss » JRoller

JRoller (100 unread)

Skip to page: 1 2 3 ... 45

Splitting Java 7

Posted: January 8, 2009, 7:00am CET by Anthony Goubard
Over the last releases Java was still growing up in size. Sun has been fighting it in their different releases with:
- Java Runtime Environment
- Java network installer for Windows
- Pack200
- Java Kernel
As Java 7 will allow module (à la OSGi), they decide to use this feature for Java 7 and modularize Java.
So in the future if you write a module depending on Java, you may have to write
```
module org.netbeans.core.utils {
    require  java.core @ 1.7;
}
```
What does that mean?
- No more classpath
- Faster start-up
- Different profiles for different devices (ME, SE, EE)
More information at the Devoxx presentation on project jigsaw.
Build Your Own Oracle Extended RAC Cluster on Oracle VM and Oracle Enterprise Linux

Posted: January 8, 2009, 2:59am CET by Julian Rivera Pineda

Build Your Own Oracle Extended RAC Cluster on Oracle VM and Oracle Enterprise Linux
Some Thoughts on Testing Search

Posted: January 8, 2009, 2:25am CET by Rob Williams
Search is actually a very interesting case when considering what to test and where. Having just touched this again, from the vantage point of a machine that is crazy fast, we opted for just going straight to some Spring tests that actually look for the real things. The advantage is that you will find out:
1. if the query itself is parseable
2. if the search mechanism can find any results
3. if it found the results you wanted
Typically I like to think of testing as occurring in layers where the first thing to do is unit test the component, and in most cases, mocking things works well here, and there is no need for Spring, so the tests run very fast. In this case, though, what is the component in search? There isn‘t one really. I mean there might be an input form for gathering what the user wants, but that‘s going to be immediately translated into some query syntax and that‘s what we really need to test.

Due to the nightmarish nonsense that attends any attempt to test actual data, in the last round of wanting to test search, the decision was made to avoid testing the actual queries: just write a bunch of unit tests that showed that the query was conforming given the range of possible inputs (e.g., we support searching for things that are in ranges, in lists of possible values, etc., those all have to subscribe to some syntax so that the expression will be parseable, and since we don‘t anticipate having to concern ourselves with the possiblity that JPA will, for instance, suddenly decide not to honor its own syntax, we can kind of pin our own conformance to the specified requirements). This gets you pretty far, surprisingly, but then the actual conformance to the domain model becomes the next question. The simplest way to test this is to actually have the persistence engine parse the query. This is where we cross the Rubicon, no the River Styx.

Why, I keep asking myself, is it such bloody hell to put a database into a state, run a few tests, then restore the prior state? Seriously, if there was a strong counter argument to the facility that we have all sought in using ORM, this would be tops on my list. If this were an object database, we‘d just create a bunch of objects and stuff them in, then rollback or loop the objects and nuke them. I thought I‘d go check the latest spring doc to see what they were saying about transactions not allowing you to easily seed the db before testing. Quite predictably, there‘s just a dismissive gesture ‘unit tests shouldn‘t need data in the db, use a mock.‘ I did find a guy talking about using dbUnit with Spring 2.5. After looking at what looked like a serious Jeremiad, the first comment was to check out a project called Unitils, which actually does look pretty interesting, if seriously ambitious. They did their own mocking, and have support for JPA, and Spring, but have not been able to figure out yet what they do about putting the db into a known state.

The cleanest solution would be a Decorator. The guy who did his own thing I think does something smart: add an annotation to the test that includes the name of a dataset. What I like about that is it is a useful part of the documentation as well, and it keeps all loading/unloading code out of the tests themselves (or their ancestors). Maybe the decorator could be implemented as an aspect. But even with this decoration, the problem is how do we get the seeding scripts. It‘s a hassle making them in dbUnit. This is why the impedance relief coming back just to see if you are getting what you want is especially biting.

The Unitil Project
" title="">Using dbUnit with Spring 2.5
Plugin updates

Posted: January 7, 2009, 9:42pm CET by Andrei Loskutov
I've uploaded four plugin updates today.
Enjoy :-)

P.S.

Earlier this yaer, Bill announced the FindBugs 1.3.7 update. The Eclipse plugin was also updated (check the Bug Explorer), see release notes. I will blog later about new features in the Eclipse plugin, stay tuned...

Separating Concerns: Business Logic Implementations round-up

Posted: January 7, 2009, 9:31pm CET by Daniel Lopez

Separating Concerns: Business Logic Implementations round-up

One of the nice things of using a framework that separates concerns cleanly is that it allows developers to choose different ways of implementing the business logic without affecting other parts of the system, like the presentation logic. That means more freedom to choose.

On the other side, since the introduction of the Java Scripting API in Java 6, executing code in languages other than Java is not only possible but quite easily accomplished. Again, more freedom.

But, as always, with the freedom to choose comes the need to decide, if you know what I mean ;). So, how to decide between one language or another? Well, one of the best ways to do so is to test for yourself, and that's what I did. So, I'm here to share the different implementations I came up with in the various different languages. Note that I'm not an expert in all the languages, so if you find you know how to improve some code, you are more than welcome to send your suggestions.

The basic idea of the test is to write a function that returns a list of items from a database, reachable through a data source, table in the form of an XML document*. The document has to be like this static prototype**, but changing the value of the Impl attribute.

<ITEM_QUERY Type="All" Impl="Static">
        <ITEM
          Code="11111111111111111111111111111111"
          Name="First item"
          Description="Description of first item"/>
        <ITEM
          Code="44444444444444444444444444444444"
          Name="Fourth item"/>
        <ITEM
          Code="22222222222222222222222222222222"
          Name="Second item"
          Description="Description of second item"/>
        <ITEM
          Code="33333333333333333333333333333333"
          Name="Third item"
          Description="Description of third item"/>
</ITEM_QUERY>

Why all of this? Well, I was tired of “hello world” or academic examples that show very little and I wanted to see those languages doing something that my applications do every day: Grab some data from a database and spit it out. So, what different solutions have already been implemented?

Straight JDBC to have the most basic implementation.
Ibatis, one step above the plain JDBC one but still with full control over the SQL code.
Hibernate 3, the famous ORM engine.
JPA (with Hibernate under the hoods), to check the standard API, now that we left EJB entity beans behind.
Dynamic languages accessed through the Java Scripting API: Groovy, JRuby, Jython, PHP, Pnuts.
Compiled Groovy, the same Groovy script but instead of accessed through the API, compiled into a class file and added to the classpath as a regular Java class.
Scala, the functional language that some think it will become the Java successor.

I would divide the implementations in two different categories:

The first one is “the Java way”, were you have different solutions that might be appropriate for different problems, but all within Java. This would include JDBC, Ibatis, Hibernate and JPA and if you want to have a look at the implementations, you should check the different classes at the org.leaf.test package and subpackages at the Fisheye repository.

The core is quite similar in all the versions and, not surprisingly, the main differences lay in how you create the query and how you retrieve the results.

Using plain JDBC: (see the source code of the main file here)

  ResultSet theResultSet = itemsListStatement
  .executeQuery("select * from TTST_ITEM order by ITE_NAME");
  while (theResultSet.next())
  {
  … // results retrieved from ResultSet

Using Ibatis: (see the source code of the main file here)

  // You need to define the corresponding SQL statement for the "selectAllItes" query
  // and the mapping between the resultset and the TstItemBear class in an external
  // XML file
  List items = theSqlMapClient.queryForList("selectAllItes");
  for (Iterator i = items.iterator(); i.hasNext();)
  {
        TtstItemBear theIte = (TtstItemBear) i.next();

Using Hibernate: (see the source code of the main file here)

  // You need to define the mapping between the TstItemBear class and the corresponding
  // table through an external XML file. The SQL sentenced is built for you from the HQL query.
  List items = theSession.createQuery("from TtstItemBear b order by b.iteName").list();
  for (Iterator i = items.iterator(); i.hasNext();)
  {
        TtstItemBear theIte = (TtstItemBear) i.next();

Using JPA: (see the source code of the main file here)

  // You need to define the mapping between the TstItemBear class and the corresponding
  // table through annotations. The SQL sentence is built for you from the JPQL query.
  List items = theEntityManager.createQuery("select i from TtstItemBear i order by i.iteName").getResultList();
  for (Iterator i = items.iterator(); i.hasNext();)
  {
        TtstItemBear theIte = (TtstItemBear) i.next();

The second group would be the “In the JVM but not Java” solutions, and even though it is quite clear from the implementation languages that they are not Java, I mean it in the sense that each language has its own way of doing things, and they don't “feel” like Java. Note again that I don't claim to be an expert in all the languages, so there might be more idiomatic ways of accomplishing the same. If you find that's the case, please enlighten me as learning 9 different ways of doing the same thing took its toll ;). You can see all these implementations in the WEB-INF/scr folder at the Fisheye repository. If you have not played with dynamic languages before, you might find them really interesting.

For example, we can see how the different languages are able to grab the DataSource that is published through JNDI and get a connection. Some are similar to Java, some are different:

Jython (see the full source code here)

  jndiName = "java:comp/env/jdbc/Test"
  factory = System.getProperty("java.naming.factory.initial")
  db = zxJDBC.lookup(jndiName, INITIAL_CONTEXT_FACTORY=factory)

Groovy (see the full source code here)

  Context ctx = new InitialContext();
  DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/Test");
  def sql = new Sql(ds);

Pnuts (see the full source code here)

  jdbc = openJDBC("java:comp/env/jdbc/Test")

PHP/Quercus (see the full source code here)

  $pdo = new PDO("java:comp/env/jdbc/Test");

JavaScript (see the full source code here)

  var ctx = new Packages.javax.naming.InitialContext();
  var ds = ctx.lookup("java:comp/env/jdbc/Test");
  var conn = ds.getConnection();

Scala (see the full source code here)

  val namingContext = new InitialContext()
  val theDataSource: DataSource = 
  namingContext.lookup("java:comp/env/jdbc/Test").asInstanceOf[DataSource]
  …theDataSource.getConnection...

JRuby (see the full source code here)

  ctx = JavaxNaming::InitialContext.new
  ds = ctx.lookup("java:comp/env/jdbc/Test")
  conn = ds.getConnection

You can also see very different approaches on how to loop over query results and how to build the XML. If there was no XML language support or I couldn't find an XML library that could be easily included, I reverted to string concatenation.

Jython (see the full source code here)

  ...
  c = db.cursor(1)
  c.execute("select ITE_CODE,ITE_NAME,ITE_DESCRIPTION from TTST_ITEM ORDER BY ITE_NAME")
  xml = make_query(c.fetchall(), 'All',param['ite_code'],db)
  c.close() 
  …
def make_query(rows, type, ite_code, db):
        return '''<ITEM_QUERY Type="%s" Impl="Jython">
%s
</ITEM_QUERY>
''' % (type,'n'.join([make_item(row) for row in rows]))
  ...

Groovy (see the full source code here)

  def writer = new StringWriter()
  def xml = new MarkupBuilder(writer)
  def groovy = xml.ITEM_QUERY(Type:'All', Impl:'Groovy'){
        sql.eachRow("select * from TTST_ITEM ORDER BY ITE_NAME",
                {
                        itemToXML(builder,it)
                }
        );
  }
  ...
  def itemToXML(builder, item)
  {
        builder.ITEM(Code:item.ite_code, Name:item.ite_name, Description:item.ite_description)
  }

Pnuts (see the full source code here)

  xml = "<ITEM_QUERY Type="All" Impl="Pnuts">"
  for (item : jdbc.query("select * from TTST_ITEM ORDER BY ITE_NAME"))
  {
        xml += "<ITEM Code="" + item.ite_code + "" Name="" + item.ite_name + """
        if(item.ite_description)
        {
                xml += " Description="" + item.ite_description + """
        }
        xml += " />"
  }
  xml += "</ITEM_QUERY>"

PHP/Quercus (see the full source code here)

  …
  $sql = "select * from TTST_ITEM ORDER BY ITE_NAME";
  $xml = '<ITEM_QUERY Type="All" Impl="PHP">';
  foreach ($pdo->query($sql) as $row)
  {
        $xml .= itemToXML($row);
  }
  $xml .= '</ITEM_QUERY>';
  return (string)$xml;
  ...
  function itemToXML($item)
  {
        $itemxml = '<ITEM ';
        $itemxml .= 'Code="'.$item['ITE_CODE'].'" ';
        $itemxml .= 'Name="'.$item['ITE_NAME'].'" ';
        $itemxml .= 'Description="'.$item['ITE_DESCRIPTION'].'" ';
        $itemxml .= '/>';
        return $itemxml;
  }

JavaScript (see the full source code here)

  var allItems = '<ITEM_QUERY Type="All" Impl="JavaScript">'
  …
  var s = conn.createStatement();
  var resultSet = s.executeQuery("select * from TTST_ITEM ORDER BY ITE_NAME");
  while (resultSet.next())
  {
        allItems += itemToXML(resultSet);
  }
  resultSet.close();
  ...
  function itemToXML(theItemRS)
  {
        var theXML = '<ITEM Name="';
        theXML += theItemRS.getString("ite_name");
        theXML += '" Code="';
        theXML += theItemRS.getString("ite_code");
        theXML += '" Description="';
        if(theItemRS.getString("ite_description"))
        {
                theXML += theItemRS.getString("ite_description");
        }
        theXML += '"/>';
        return theXML;
  }

JavaScript with E4X (see the full source code here)

  var allItems = <ITEM_QUERY />
  allItems.@Type = 'All';
  allItems.@Impl = 'JavaScript/E4X';
  ...
  var s = conn.createStatement();
  var resultSet = s.executeQuery("select * from TTST_ITEM ORDER BY ITE_NAME");
  while (resultSet.next())
  {
        allItems.appendChild(itemToXML(resultSet));
  }
  resultSet.close();
  …
  function itemToXML(theItemRS)
  {
        var theItem = <ITEM />;
        theItem.@Code = theItemRS.getString("ite_code");
        theItem.@Name = theItemRS.getString("ite_name");
        if(theItemRS.getString("ite_description"))
        {
                theItem.@Description = theItemRS.getString("ite_description");
        }
        return theItem;
  }

Scala (see the full source code here)

  /**
  * Run some code and close whatever was passed to us
  */
  def run[C <: {def close(): Unit}, T](in: C)(f: C => T): T =
          try {
                          f(in)
                  } finally {
                          in.close()
                  }
  /**
  * Given a connection, run a query and
  */
  def runQuery[T](theConn: Connection, query: String)(f: ResultSet => T): List[T] = {
          run(theConn.createStatement().executeQuery(query)) {
                  theRS =>
                  val ret = new ListBuffer[T]
                  while (theRS.next) ret += f(theRS)
                  ret.toList
          }
  }
  
  def allItems(theDataSource: DataSource, paramMap: java.util.Map[String,Object]): NodeSeq =
  run(theDataSource.getConnection)( theConn =&gt
          runQuery(theConn, "select * from TTST_ITEM ORDER BY ITE_NAME")(
          theRS =>
                <ITEM
                  Code={theRS.getString("ITE_CODE")}
                  Name={theRS.getString("ITE_NAME")}
                  Description={theRS.getString("ITE_DESCRIPTION")}
                  />
          )
  )
  …
<ITEM_QUERY Type="All" Impl="Scala" >
  {allItems(theDataSource,paramMap)}
</ITEM_QUERY>.toString

JRuby (see the full source code here)

  …
  theXML = '<ITEM_QUERY Type="All" Impl="JRuby">'
  s = conn.createStatement
  resultSet = s.executeQuery("select * from TTST_ITEM ORDER BY ITE_NAME")
  while resultSet.next do
        theXML += itemToXML(resultSet)
  end
  ...
  def itemToXML(theItemRS)
        theXML = '<ITEM Description="'
        theXML += theItemRS.getString("ite_description") ? theItemRS.getString("ite_description") : ""
        theXML += '" Name="'
        theXML += theItemRS.getString("ite_name")
        theXML += '" Code="';
        theXML += theItemRS.getString("ite_code")
        theXML += '"/>'
        return theXML
  end

You can see there are styles suitable to everybody. Note that I have not tried to minimise number of lines and I sometimes created methods to encapsulate common behaviour and sometimes not. I did not create all those versions to compare them to one another in a sort of competition, I just wanted to see how it could be done.

After all, I'm quite happy with the results because I've been able to test different approaches and even if using other languages means learning a lot of new things, I didn't want to start all over again, throwing away my whole “bag of tools”. Moreover, changing an implementation language is something much easier to accomplish that changing the whole development process and all the tools involved, as it allows a more steady transition. That also means that if you find unexpected results, you can always go back to the language you are more comfortable with, and that you don't have to be forced to ONE solution for everything. And that's what the JVM and the Scripting API provides.

If you did not have experience with all those languages, I hope this helped a bit by showing something more than the typical "Hello World" :).

I also took the time to do some simple performance tests, and I will be sharing the results as well.

Happy coding!

PS: In case some are interested, I already described the basic architecture that I'm using for the tests in the article “A Dynamic MVC Development Approach Using Java 6 Scripting, Groovy, and WebLEAF”.

*)Why the XML? Because that's what our architecture uses as “lingua franca” between the business logic and the presentation logic, as it allows us to accommodate implementations in PLSQL, Java, Groovy, static XML files for prototyping, etc. I'm sure many of you can think of, and are using, very different architectures without the controversial use of XML, but that's not the topic for the entry.
**)There are some HtmlUnit tests implemented that verify that all implementations indeed return an equivalent XML.

AOL vs Google para DojoToolkit

Posted: January 7, 2009, 9:08pm CET by Alex Fuentes

Hoy en día se han puesto de moda las aplicaciones que extraen recursos desde distintas fuentes y mezclan estos recursos para generar nuevas aplicaciones. Lejos quedaron los tiempos en que todos los componentes de nuestras aplicaciones tenían que estar contenidas en el mismo servidor de aplicaciones. Podríamos estar utilizando Dojo Toolkit y quisiéramos no tener que colocar esta libreria en el war de nuestra aplicacion, una solucion para esto es utilizar un CDN.

Los CDN nos permiten distribuir nuestros componentes y tener un mejor performance para nuestras aplicacion y ademas poder aprovechar las funcioalidades de cache de los browser.

Si estamos utilizando Dojo Toolkit y nuestra aplicación esta conectada a la nube tenemos dos opciones de CDN : AOL y Google.

La pregunta ahora es: ¿ cual seleccionamos ?

Para se desarrollamos una pequeña aplicación que utiliza funcionalidades de Dojo. Ahora con la ayuda de Firebug se determina el tiempo que toma la aplicación en ser desplegada. Request

Los resultados los que muestra la siguiente tabla.

TEST	AOL	GOOGLE
Test1 ( 19 request )	2.84	3.52
Test2 ( 19 request )	2.97	3.25
Test3 ( 19 request )	3.06	4.32
Test4 ( 19 request )	3.06	3.33
Test5 ( 19 request )	2.96	3.43
TOTAL ( 19 request)	2.98	3.57

PD : Las pruebas fueron realizadas sin utilizar las funcionalidades de cache.

Las aplicación utilizada :

[fuentes.alex.googlepages.com]

Mingle server footprint? What the hell?

Posted: January 7, 2009, 8:06pm CET by I. Am. Angry

I have been working on a tomcat application for the last few years and it's on an old server I have, it only has 1gig RAM but the application only seems to want about 50meg.

I thought I would try out Mingle so I dropped it on the box and had a play about with it, almost instantly the box nearly coughed up a lung, I only had 1 project with about 25 tasks so I had a look at task manager to see what was dragging the box down, I nearly fell off my seat, MingleServer.exe - 399 meg. The question has to be asked how the hell can the server pull in 400meg for what is essentially a pretty small web application with 1 user?

The interesting point is that my application is a massive number crunching batch processing, object caching web application. About 50% of the time it's running some kind of process and it's technical demands are about 100 times what mingle needs.

Why me, a lowly consultant can write a highly demanding application in Java that uses 8 times less memory than a simple ruby application written by the so called industry experts must be worrying for Thoughtworks customers and ruby devotees.

If I were Thoughtworks I would remove it from the market, it's embarrassing.
Farewell to Java 7 Closures

Posted: January 7, 2009, 6:40pm CET by Sebastian Kübeck
Seems that the most ambitious change in the Java language since the introduction of Generics, Closures have been postponed to later Java version. That decision must have come as a shock for all contributors working so hard to integrate Closures into Java.
To be honest, after all the complains about the Generics implementation in Java I was rather sceptical that Java should continue the language feature competition with C#. I thought that there were more important issues to solve such as modularization (aka the JAR hell), operator overloading and VM virtualization (multiple logical VMs in one physical process). I was also concerned about the paradigm mix in the language. That could overburden lesser experienced developers. We have been observing this with C++ for the last decades. Long time ago, it was a central goal of the Java makers to have a simple yet powerful language (like C) in contrast to a language with superpowers (C++) that is hard to teach and learn. Java has dropped that with the introduction of Generics and Annotations in Java 5. Things - so I thought - could only get worse if more complex concepts were poured into the language.

As I am curious by nature, I observed the discussions at Artima about the various suggested implementation strategies. Most of those examples made me even more sceptical. Well, until I saw Neal Gafter's presentation...
Closures: A Quick Introduction
It is amazing how "naturally" closures fit into the language. They are more or less a generalization of Java syntax concepts. There is just one new operator to remember, the => operator (in the Ruby community it is called "Hashrocket" but it has a different meaning there). Here is a simple example:
```
void with(InputStream in, {InputStream => void} f) {
    try {
        f.invoke(in);
    } finally {
        try ( in.close(); }
        catch(IOException ex) {}
    }
}
```
Technically, this is a method definition with two parameters. One is a parameter, the second is a function object with a parameter of type InputStream and no return value. As a method, the function would look like this:
```
  void f(InputStream in);
```
In reality it is an object with only one method: invoke. The real magic however happens when you call the method:
```
  StringBuffer content = new StringBuffer();
  with(InputStream in : new FileInputStream("foo.txt")) { 
    byte buffer[] = new byte[4096];
    int l = 0;
    while((l = in.read(buffer)) > 0) {
       content.append(new String(buffer, 0, l));
    }
  }
  System.out.println(content);
```
Note that the block after the with method call is passed as the last argument during the method call. The whole thing looks exactly like the for loop with the colon that was introduced in Java 5. The syntax above is thus a generalization of the concept used in that for loop. Application
In the example above, the construct cares about reliably closing the input stream. That way, you do not longer have to add this ugly catch blocks with closing logic all over the place. Just imagine how much easier JDBC access would be if you hadn't to worry if the statement, the result set and the connection are reliably closed! If you ever had the pleasure to fix hundreds of finally blocks in order to keep the database from leaking connections, you can estimate the trouble you could have saved if you had Closures around. Another, rather aesthetic benefit is the fact that reliably closing resources is just one application of a more general language construct. The thing really rocks once you define your own Internal DSLs as you can impose your own structure in your programs.
Conclusion
With the decision of postponing Closures Java is more or less sitting between two chairs. It left the chair of a simple, easy to learn language but is reluctant to move to the chair of an evolving language that aims to make developers as productive as possible by adding language features. Comparing the options, the current one (between the chairs) is probably the worst. You have the disadvantages of both chairs and can not profit from the benefits of either one.

Anyway, maybe it is time to have a closer look at Scala. Considered the recent development: have you any idea where Java is going (or should go) in the future?
References
- The Java Closure Homepage
- Consensus on Closures Proposal
Thoughts on MacWorld

Posted: January 7, 2009, 6:09pm CET by Rob Williams

On the Steve‘s health front, if the dog barks and the caravan rolls on, yesterday we got our first look at the caravan. On balance, not bad really. The iLife stuff looked interesting, though not revolutionary. The stuff for Keynote was/is a smart move because that thing is poised to really replace Powerpoint. The announcement about the store going DRM-free is good, hopefully will lead to a bit less consternation about where one acquired one‘s songs. But, of course, for me, the most exciting part was the refresh of the 17. (Oh, and I forgot, was disappointed that there was no macmini refresh, even though I kind of didn‘t believe there would be, but more on that.)

On the 17, everything looks good to me. I don't mind the battery not being removable. 8HRs is completely insane. The fact that it can now take 8GBs of RAM is also fantastic, though using the configurator, I was able to figure out that going from 4 to 8 is going to cost you $1200. Finally the fact that there are 2 SSD options (128 and 256) is also great, BUT, there was no mention of whose they would be. I fiddled with the configurator a bit. It wanted to add $900 for a 256. Given that the 320 is worth a hund, that probably means the drive itself is around a grand, so there is a good chance that it's the new MLC that Samsung announced in May. That would be great. If it was, though, Apple is stupid for not using MacWorld as a platform for getting the word out that 2009 is going to be the Year of the SSD (remember Steve‘s Year of HD bit a few back?), and that these new drives are crazy fast. (The Samsung can read at north of 200 and write at better than 100.) Here‘s my last thought on SSD: given the tiny form factor, there must be a way to get 2 of these inside the case. Sure that would make for an expensive machine, but it would also be crazy fast.

My interest in the mac mini was, as previously stated, for running automation software and also having El Gato on it so I can record HD PBS (convinced this will never show up on dish lineups). It would have been a smart idea to refresh this, if for no other reason, the company could show that they could answer the incessant yowling of the press who are trying to cover the story 'What's New for the Depression?' Personally, I want a tiny box, with an Atom processor (or the equivalent from their acquisition (P.A. Semiconductor)), and an SSD that doesn‘t have to even be that fast. Thing could run 24h/d and suck practically no juice. Not this time. Watch for the predictions of mini‘s death to come back again….
JLibs: EventDispatchThread

Posted: January 7, 2009, 4:32pm CET by Santhosh Kumar T

JLibs: EventDispatchThread

Updates to jlibs project:

EventDispatchThread
FEST-Reflect 1.0: Fluent interface for Java Reflection

Posted: January 7, 2009, 12:56pm CET by Alex Ruiz
We are proud to announce that FEST-Reflect 1.0 is out! Version 1.0 is the same as 0.4, with a "1.0" label to express that this is a stable, production-ready version.

FEST-Reflect is a Java library that provides a Fluent Interface-based API that simplifies the usage of Java Reflection, resulting in improved readability and type safety. It supports access to constructors, methods and fields.

You can download the latest release here (file fest-reflect-1.0.zip.) FEST-Reflect requires Java SE 5.0 or later.

Here are some useful links:
Feedback is always appreciated
Am on Progress SOA Blog

Posted: January 7, 2009, 11:22am CET by Ramesh Loganathan

Happy to be blogging on the Progress SOA Blog! :-)

First post was on the complexity of web services and how much of it is really needed. Do check it out- blogs.progress.com
TDA 2.1 released

Posted: January 7, 2009, 10:39am CET by Ingo Rockel
I just released TDA in version 2.1. This is just a bugfixing release, especially concerning the VisualVM Plugin. In detail in contains the following changes:
- Added last line parsed to the error message if an error occurs during parsing.
- Fixed Issue 22, check for null if diffing dumps.
- Fixed Issue 23, fixed parsing of remote VisualVM Dumps.
- Fixes Issue 24, fixed parsing of monitors in VisualVM Dumps.
- Bugfixing of other small bugs.
The release can be downloaded from the TDA Website in the Download Section. The VisualVM Plugin is available either as download from the Download Section of the website or it will also be available from the VisualVM Plugin Center. Report bugs in the Issue Tracker.
Native Cloud Applications – Major Trend in 2009

Posted: January 7, 2009, 9:22am CET by Nikita Ivanov
It’s this time of the year when we are talking about trends for the new year and I think when it comes to cloud computing one trend that stands boldly above the rest is – Native Cloud Applications. So, what is a native cloud application?
Let’s take a look at what type of applications are currently running on the cloud… You don’t have to look too hard to realize that these are exactly the same applications that have been developed for decade to run either locally or at traditional datacenter:
- Scalability often means crude load balancing over multiple instances of the same application running on several images
- Services provided by cloud providers are rarely used and not taken a full advantage of since they are not readily available during development that happens outside the cloud
- Any work with or deployment on a specific cloud provider means a cloud lock-in that is only compounded by the fact that all current vendors require all-or-nothing approach when it comes to hosting your application
Native Cloud Application overcome these shortcomings. Unlike current applications, the Native Cloud Applications have three distinct characteristics:
1. They are massively parallel, i.e. they are built so that they can scale on a much finer scale on cloud’s on-demand distributed infrastructure – like ability to scale an individual method call in Java code, for example
2. They take full advantage of native services available in the cloud like S3 and SimpleDB from AWS
3. They are developed using a cross-cloud paradigm allowing you to seamlessly develop and run your application across multiple cloud providers utilizing one virtualized cloud spanning your workstation, local co-lo or datacenter and several external cloud providers
To help develop and run Native Cloud Application a new breed of software middleware is required. With the recent release of GridGain 2.1 – Open Cloud Platform last month we’ve started on the road to create a perfect runtime and development platform for Native Cloud Applications. GridGain 3.0 scheduled for Q2-Q3 this year will largely complete our vision of what open cloud platform for Native Cloud Application should be.

We are working hard on 3.0 release as we speak so stay tuned!
Actor Frameworks Compared

Posted: January 7, 2009, 3:30am CET by Mike Rettig

Sujit Pal published a series of posts about actor models on the jvm. The final post can be found here.

This is the first post I've seen that attempts to implement a single example across frameworks. Overall, Jetlang performs well in comparison to other frameworks. With 1000000 messages, Jetlang completes a second before the nearest competition. Jetlang is currently deployed to several performance critical applications, so the results of Sujit's research are not surprising.

For lower message rates, Jetlang does well, but IMO the numbers aren't very accurate since no attempt is made to warm up the code or the thread pool. Most of the time is spent in initialization.
Top 10 New Organisms of 2008

Posted: January 6, 2009, 10:16pm CET by Julian Rivera Pineda

Top 10 New Organisms of 2008

Top 10 New Organisms of 2008
8 Signs That Apple Customers Are No Longer Special

Posted: January 6, 2009, 9:51pm CET by Julian Rivera Pineda

8 Signs That Apple Customers Are No Longer Special | Gadget Lab from Wired.com

8 Signs That Apple Customers Are No Longer Special
Lecture 9 | Programming Methodology (Stanford University)

Posted: January 6, 2009, 8:39pm CET by Julian Rivera Pineda

Lecture 9 | Programming Methodology (Stanford University) | Java™ Software Development Videos and Tutorials Directory
SOA is Dead?

Posted: January 6, 2009, 8:20pm CET by Sebastian Kübeck

SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.

writes Anne Thomas Manes in SOA is Dead. Gartner already introduced WOA.
If a term is so easily exchangeable by an others, maybe it did not mean much anyway. As a consequence we do not have to worry remembering the names of its successors ;-)
JLibs: XMLCrawler

Posted: January 6, 2009, 6:47pm CET by Santhosh Kumar T

JLibs: XMLCrawler

Updates to jlibs project:

XMLCrawler
Swing browsers - other interesting DSL Swing projects to follow

Posted: January 6, 2009, 4:21pm CET by Dominique De Vito

I have recently discovered SwingBrowser, an open source project aimed to develop a browser for Swing components, as announced here.

Swing browser is a java application designed to render swing components by downloading/uploading (GET/POST) Swing markup language (SML) documents from a web server.
The SML document looks like html; however instead of html tags it has tags for JPanel, JLabel, JTree, JTable and other components. It also supports layout managers available in AWT/Swing.
[...]
In short it works just like any web browser, except that user and developers work with Swing components.

It looks like, in spirit, close to Sage browser from Don DeCoteau. Kirill Grouchnikov has interviewed Don DeCoteau recently.

Sage has a special markup language (SDF) and associated MIME type (text/x-sdf) that lets it render Swing-based applications, the same way a web browser uses HTML to render documents.

Sage supports also scripting.

Instead of HTML, Sage uses a special CSS-like markup language to describe the application, actions, and interactions. It supports JavaScript, Ruby, Python and a number of other scripting languages for controlling the application and enabling complex interactions. JavaScript is the default scripting language and comes embedded with the engine (via Rhino and BSF 3). Additionally, Sage’s functionality can be augmented via dynamically downloaded Java libraries or OS specific shared libraries (the same way you can download browser plug-ins and ActiveX components).

Just take a look at Sage demos!

Good opportunities to foster Swing programming?

It sounds to me as interesting projects. And there are other similar initiatives like SwiXML or JAXX.

These are pretty interesting attempts to simplify Swing programming. To be more precise, these are DSL proposals for Swing programming; SwingBrowser uses an XML-based language, while Sage browser uses a special CSS-like markup language.

It looks like a good idea to foster Swing programming, as people are more familiar with a declaration style for UI definition, like (X)HTML, and scripting, like for web development.

Well, DSL UI programming in on the air!

Flex, a successful UI programming, is based also on a DSL UI programming; indeed, MXML, an XML-based markup language, offers a way to build and lay out graphic user interfaces. Interactivity is achieved through the use of ActionScript, the core language of Flash Player that is based on the ECMAScript standard.

JavaFX is also based on a DSL UI programming. And I just wish it could be proposed outside JavaFX as a Swing DSL to foster Swing use and programming.

Interesting comments of my previous post mention DSL capabilities of Scala and Groovy.

And?

Well, in a somewhat "perfect" world, I would prefer that the Swing DSL inside JavaFX could be extracted and proposed to regular Swing developers.

While competition is better, the projects listed above look quite interesting to keep an eye on (just see Flex example or Sage demos), as following the DSL way. An interesting fact about competition is that those solutions follow different ways: XML-based language versus other language, scripting or not, browser way or not, etc.

In the end, DSL way, that I have more or less recently met for UI programming, appears to me as interesting while keeping Swing foundation, but simplifying UI programming.
JFreeChart / Bordeaux Java User Group

Posted: January 6, 2009, 3:35pm CET by David Gilbert

On Thursday night (January 8) I'll be making a short presentation about JFreeChart to the Bordeaux Java User Group. If you are in the area, register and come along.

My French is nowhere near good enough (yet) so the presentation will be in English, but I'm trying to at least write the slides in French. And I'm planning to work through a live demo in code, so it doesn't really matter what language you speak, as long as it is Java!
JFreeChart 1.0.12

Posted: January 6, 2009, 3:20pm CET by David Gilbert

A new version of JFreeChart was released on the last day of 2008, but I didn't have time to announce it until now. The sample chart below highlights a couple of features that made it into this release. First, the axes have support for minor tick marks (a long outstanding feature request that has at last been implemented). And second, despite JFreeChart having supported multiple axes and datasets since I can't remember how long ago now, it hasn't been so easy to add *duplicate* axes for a single dataset. That's been dealt with too.

As usual the release contains a number of bug fixes and other small changes. Refer to the NEWS file and ChangeLog for details.

Happy New Year to everyone!
Book Review: Swing Extreme Testing

Posted: January 6, 2009, 2:48pm CET by Alex Ruiz
Automated testing of user interfaces (UIs) is not an easy task. Since I've been involved with this difficult, yet fascinating topic for some time now, I'm very excited (and grateful) to review the book "Swing Extreme Testing."

I enjoyed reading it. The book is well-written, interesting and useful. It covers Swing testing in great detail, with pretty good examples that are easy to follow. I agree with most of their UI-testing techniques, also I disagree with some of the more general topics:
What I agree with
- The book starts with an introduction to automated testing in general, covering why we don't test our software and why we should do it.
- The authors encourage readers to test their code and redesign complex classes to make them testable.
- This is one of the few publications that stresses the importance of accessing UI components in the event dispatch thread (EDT,) even in tests.
- The authors chose to create their own UI testing tool, Cyborg. Like most UI-testing tools, Cyborg is capable of simulating user input using the AWT Robot and verifying the state of UI components. Although the code examples using Cyborg are a little bit too long, they are also easy to understand.
- This is, in my opinion, the most important aspect of this book: the authors not only describe the tools they are using, they also share their experiences testing complex, real-world Swing applications (e.g. what worked for them and what didn't.).
What I'm not sure about
- Although the book points out the importance of accessing UI components in the EDT, I'm not sure their implementation, which involves calling the method invokeAndWait (in javax.swing.SwingUtilities,) is completely correct. We tried a similar approach in FEST, and we ended up with horrible OutOfMemoryErrors. We fixed it with a thread synchronization mechanism using invokeLater and java.util.concurrent.CountDownLatch (details here.)
What I disagree with
- The authors suggest that is impossible to create software using a test-first approach. Their main reason is that by writing the test first, we will have a test that doesn't compile. In my opinion, this is not correct. I've been writing software using a test-first approach for several years now. Yes, at some point we will have a test that doesn't compile, but that is part of the process.
- The authors propose to have test classes in the same root folder as the source code, with the same package name with ".test" added at the end. For example, tests for classes in the package org.mypackage will be stored in the package org.mypackage.test. Although this can be a controversial topic, I prefer to have source code and test code code in the same packages but different source trees. The main advantage (IMHO) is the ability to test classes and methods that are package-protected.
- Because of the point mentioned above, the authors suggest using reflection to test package-protected classes.
- Instead of using one of the well-known testing frameworks (TestNG or JUnit,) the authors created their own testing framework: Grand Test Auto. I don't understand why. Grand Test Auto:
  1. uses naming conventions similar to JUnit 3 to identify test methods, and no annotation support (it feels like going backwards)
  2. it's a command line tool, no IDE support
- The authors promote 'design by contract' (DbC) using Javadoc comments, because, according to them, using JDK 1.4 assert requires discipline to "check that comments accurately reflect the checks that are being done." I completely disagree. Javadoc comments for DbC do not have IDE support and are not type safe, therefore they can potentially be a maintenance nightmare. In addition, I haven't found a DbC tool that allows me to have the checks and the source code in the same file while keeping type safety.
- The book covers database testing using a object-oriented database. I found that pretty interesting since many publications cover how to test relational databases only. What I disagree with is the authors' vision of a unified way to access data, regardless of the underlying storage technology. I have found that the design of the data access layer depends on many factors, such as the database itself and how it is being accessed.
Conclusion
"Swing Extreme Testing" is an interesting book. I like and agree with many of the ideas related to Swing testing. Unfortunately, I disagree with many of the remaining concepts covering automated testing in general. I would recommend to read a book about general automated testing first, and then move on to the chapters that focus on Swing testing in this book.

Many thanks to the PACKT Publishing for this great opportunity.
Cloud Cafe Podcast: "GridGain A Grid in a Cloud"

Posted: January 6, 2009, 8:24am CET by Nikita Ivanov

We at GridGain took some time off the blogging for the Christmas and New Year holidays but things were working in rather overdrive mode here. We’ve released our latest version and crystallized our direction for major 3.0 release coming in the mid-2009.
We’ll be blogging and announcing all these exciting news in the coming days and weeks – but today I would like to point to a great blog by John Willis. He’s got very interesting podcast collection in his CloudCafe and the latest one is with your humble correspondent about GridGain.

Take a listen and enjoy it!
Java 6 update 12 on its way

Posted: January 6, 2009, 7:00am CET by Anthony Goubard
After pushing the Java 6 update 11, Sun is working on Java 6 update 12.
This update will not only contain bug fixes but also new features including:
- 64 bits applets plug-in
- Support for Windows 2008
- Better support of heavy weight/light weight component mixing, probably meaning that JMenu will appear above native components.
Early builds are available here
Scala is dynamic

Posted: January 6, 2009, 5:59am CET by Vaclav Pech
I'm constantly getting impressed by the new languages available on JVM. This time it is Scala and its implicit conversions that gained my attention. Those familiar with Groovy know about the expando metaclass and the dynamism it allows. With Groovy you can easily extend a class with a new method by adding the method to the metaclass.
```
String.metaClass.myNewMethod = {int param1, int param2 ->

   // do something With param1 and param2

}
```
Which allows us to call the method:
```
"Groovy is dynamic!".myNewMethod(10, 20)
```
Although Scala is a statically typed language, it can be amazingly dynamic. In the small code example below I'll enhance the String class with a new method just like I did in Groovy.
First we need a trait (interface) defining the new method:
```
trait EnhancedString {

  def myNewMethod(param1:Int, param2:Int):String

}
```
Second we define an implicit conversion method, which the compiler will use whenever it is not able to satisfy a method call on the String class. The Scala compiler will replace the String with an EnhancedString and the myNewMethod() definition specified here will suddenly become available.
```
  implicit def stringEnhancer(s: String) =

    new EnhancedString {

      override def myNewMethod(param1:Int, param2:Int) = //do something With param1 and param2

    }
```
It is definitely a bit more involved compared to the Groovy example, since we need to make sure the types are correct. On the other hand, the compiler can ensure that we're calling an existing method and have the parameter types right.
```
    println("Scala is dynamic too!".myNewMethod(10, 20))
```
I find Scala to be a very inspiring language.
El-Menoufiya and NetBeans IDE

Posted: January 6, 2009, 4:30am CET by Julian Rivera Pineda

Geertjan's Blog : Weblog

El-Menoufiya and NetBeans IDE
Java 7 - Null-default and Null-safe operators

Posted: January 6, 2009, 1:57am CET by Stephen Colebourne
The most popular small language change request is better handling of nulls. As a result, I've updated my null-handling proposal.
Enhanced null-handling
The votes from Devoxx and JavaEdge were clear. Ordinary developers find handling nulls to be a pain and they would like to see language change to address it. At JavaEdge in particular almost a third of the first preferences and two thirds of the top four preferences went to null-handling.

I blogged my original thoughts two years ago. The updated null-default and null-safe invocation proposal is now available (v0.2).

The proposal covers two new operators, which follow Groovy for syntax (and thus consistency).

The null-default operator ?: returns the LHS unless that is null in which case it returns the RHS:
```
  // today
  String str = getStringMayBeNull();
  str = (str != null ? str : "");
  
  // with null-default operator
  String str = getStringMayBeNull() ?: "";
```
The null-default operator also works particularly well with auto-unboxing.
```
  Integer value = getIntegerMayBeNull();
  int val = value ?: -1;
```
In fact, I hope that tools (IDEs and static analysis) would combine to effectively make the null-default operator mandatory when unsafe unboxing is occuring.

The null-safe operator ?. is an alternative form of method/field invocation. If the LHS is null, then the result of the whole method/field invocation is null:
```
  // today
  String result = null;
  Foo foo = getFooMayBeNull();
  if (foo != null) {
    Bar bar = foo.getBarMayBeNull();
    if (bar != null) {
      result = bar.getResult();
    }
  }
  
  // with null-safe operator
  String result = getFooMayBeNull()?.getBarMayBeNull()?.getResult();
```
There is an interesting case if the last segment of the field/method expression returns a primitive. However, this can be handled by combining the two new operators (hence why its one proposal):
```
  // today
  int dotIndex = -1;
  if (str != null) {
    dotIndex = str.indexOf(".");
  }
  
  // with null-safe and null-default operators
  int dotIndex = str?.indexOf(".") ?: -1;
```
I considered mandating this when a primitive occurs, but it would have undesirable side effects, so this is one best left to the tools to handle.

More details on all of this in the proposal.
Summary
Nulls remain a pain in Java. There simply isn't enough language support for this most common task. Every day, developers write logic to check and handle nulls and this obscures the meaning of the real code. And every day production systems go down due to NullPointerExceptions that weren't caught. This proposal provides a simple enhancement to Java that tackles the heart of the null issue.

Opinions welcome.
GMaps4JSF 1.1.1 is released

Posted: January 6, 2009, 1:13am CET by Hazem Ahmed Saleh

GMaps4JSF aims at integrating Google maps with JSF. JSF users will be also able to construct complex StreetViewPanoramas and Maps with just few JSF tags.

GMaps4JSF is one of the JSF Mashups libraries that enables JSF users to build web 2.0 mashup applications in JSF easily.

GMaps4JSF provides JSF tags that make it easy to:
* Create the map using (latitude and longitude) or (address).
* Add marker(s) to the map.
* Add information text(s) to the map or to the marker.
* Add control(s) to the map.
* Create event listener(s) on the map objects.
* Draw polyline(s) on the map.
* Draw polygon(s) on the map.
* Add groundOverlay(s) on the map.
* Perform different operations on the map like zooming in and out, switching between map types, ...etc.
* Create a Streetview Panorama and integrate it simply with the map.

GMaps4JSF supports Facelets and portlets as well.

What is new in GMaps4JSF 1.1.1:
* Adding the icon component to simplify the marker image customization.
* Allowing adding notes to the marker component, and adding the (showInformationEvent) attribute to the marker component.
* Direct Facelets support.
* Enable adding events to the HTMLInformationWindow component using the eventListener component.
* Adding (address) attribute to the streetViewPanorama component.
* Adding (address) attribute to the marker component.
* Facelets support.
* Solving 1.1.0 defects.

The Demo:
[mashups.s43.eatj.com]

The library main page:
[code.google.com]

The tag library documentation page:
[code.google.com]

The quickstart of "How to use the library":
[code.google.com]
FEST-Swing 1.0rc2: Fluent interface for testing Swing GUIs

Posted: January 5, 2009, 4:21pm CET by Alex Ruiz
We are proud to announce the release of FEST-Swing 1.0-RC2. This is the last release before 1.0 (to be released in mid-January.)

FEST-Swing is a Java library that provides a fluent interface for functional Swing GUI testing. This library provides an easy-to-use API that makes creation and maintenance of GUI tests easy.

Changelog:
1. Fixed issue 139: Component-less click method. Many thanks to Viet Nguyen.
2. Fixed issue 213: ScreenshotTaker takes non-reproduceable screenshots across consecutive tests. Many thanks to Jean-Francois Poilpret.
3. Fixed issue 247: Tests failing in EDT don't provide relevant information. Many thanks to Juhos Csaba-Zsolt.
4. Fixed issue 251: JTableTextComponentEditorCellWriter regression. Many thanks to Juhos Csaba-Zsolt.
5. Fixed issue 257: Generic extension of GenericTypeMatcher doesn't work as expected. Many thanks to Juhos Csaba-Zsolt.
6. Fixed issue 268: pom.xml in fest-swing-testng shows TestNG as "test"-scoped dependency. Many thanks to Jean-Francois Poilpret.
7. Fixed issue 270: Feature request - mouse wheel support. Many thanks to Slava Gurilev.
8. Fixed issue 271: Rename RobotFixture to BasicRobot.
9. Fixed issue 273: Remove AWT Mode.
10. Fixed issue 274: Remove unused/deprecated methods in Robot.
For more details about new, updated or removed classes, please read the change report.
FEST-Swing can be downloaded here (file fest-swing-1.0rc2.zip.) FEST requires Java SE 5.0 or later.

Here are some useful links:
Feedback is always appreciated
Flash games: threaded or single execution loop

Posted: January 5, 2009, 1:27pm CET by Jez Nicholson

Whilst writing a Flash mini-game the discussion came up whether the objects themselves should manage their proximity checking, etc. or whether there should be a single game execution loop that steps through a container of game characters. I'm making a note here because I am going for Inbox Zero and am about to delete the emails about it.

Me being a Java Dev, I tried an object-based approach first and it all ran really slowly. I'm not sure how good Flash (as in Actionscript 3.0) is at multi-threading, but my guess is nothing like as good as Java, so we tried the single "game loop" approach. This has the added benefit of being simple to pause the game and/or look at the current game state. I guess that the problem then becomes more about efficiently handling stepping through a set of objects giving them their 'turn'. It all takes me back to mainframe days of round-robin and priority scheduling.

The single game loop seems fairly effective for small-ish numbers of objects, so maybe it is sensible to just accept that and use it. I know that there are other schemes based on splitting the screen into cells and only checking for collisions between close objects (to me, this sounds like a database index). [lab.polygonal.de]

Another area to investigate later would be more efficient containers e.g. [code.google.com] and plenty of good examples here: [lab.polygonal.de]

Behaviour Driven Development meets Finite State Machine

Posted: January 5, 2009, 8:00am CET by Sebastian Kübeck

In a recent article, Robert C. Martin (aka Uncle Bob) talks about similarities between Behaviour Driven Development and Finite State Machine rules. That leads to some interesting conclusions which I want to share with you. Behaviour Driven Development

In short, Behaviour Driven Development(BDD) is a variation of Test Driven development(TDD) coined by Dan North. Dan North had problems teaching programmers TDD. The permanent question was "How should I test something that doesn't exist?". As a result, he suggested expressing upfront tests as "micro requirements" and wrote a tool that programmers could use to express those requirements in a more natural way. The requirements follow a simple pattern: Given/When/Then.

For example:

  GIVEN an employee named Bob making $12 per hour.
  WHEN Bob works 40 hours in one week;
  THEN Bob will be paid $480 on Friday evening.

Finite State Machines For Bob, that pattern sounded somewhat familiar. He could find out why until he remembered that he was defining Finite State Machine (FSM) rules that way for decades.

The following example shows the same rule set as BDD requirements and FSM rules. Just cover one of the table headers:

BDD:	GIVEN	WHEN	THEN

FSM:	Current State	Event	New State	Action
&nbsp	LOCKED	COIN	UNLOCKED	Unlock
LOCKED	PASS

Gwadanina Rss » JRoller

Feeds

JRoller (100 unread)

Posted: January 8, 2009, 7:00am CET by Anthony Goubard

Posted: January 8, 2009, 2:59am CET by Julian Rivera Pineda

Posted: January 8, 2009, 2:25am CET by Rob Williams

Posted: January 7, 2009, 9:42pm CET by Andrei Loskutov

Posted: January 7, 2009, 9:31pm CET by Daniel Lopez

Posted: January 7, 2009, 9:08pm CET by Alex Fuentes

Posted: January 7, 2009, 8:06pm CET by I. Am. Angry

Posted: January 7, 2009, 6:40pm CET by Sebastian Kübeck

Posted: January 7, 2009, 6:09pm CET by Rob Williams

Posted: January 7, 2009, 4:32pm CET by Santhosh Kumar T

Posted: January 7, 2009, 12:56pm CET by Alex Ruiz

Posted: January 7, 2009, 11:22am CET by Ramesh Loganathan

Posted: January 7, 2009, 10:39am CET by Ingo Rockel

Posted: January 7, 2009, 9:22am CET by Nikita Ivanov

Posted: January 7, 2009, 3:30am CET by Mike Rettig

Posted: January 6, 2009, 10:16pm CET by Julian Rivera Pineda

Posted: January 6, 2009, 9:51pm CET by Julian Rivera Pineda

Posted: January 6, 2009, 8:39pm CET by Julian Rivera Pineda

Posted: January 6, 2009, 8:20pm CET by Sebastian Kübeck

Posted: January 6, 2009, 6:47pm CET by Santhosh Kumar T

Posted: January 6, 2009, 4:21pm CET by Dominique De Vito

Posted: January 6, 2009, 3:35pm CET by David Gilbert

Posted: January 6, 2009, 3:20pm CET by David Gilbert

Posted: January 6, 2009, 2:48pm CET by Alex Ruiz

Posted: January 6, 2009, 8:24am CET by Nikita Ivanov

Posted: January 6, 2009, 7:00am CET by Anthony Goubard

Posted: January 6, 2009, 5:59am CET by Vaclav Pech

Posted: January 6, 2009, 4:30am CET by Julian Rivera Pineda

Posted: January 6, 2009, 1:57am CET by Stephen Colebourne

Posted: January 6, 2009, 1:13am CET by Hazem Ahmed Saleh

Posted: January 5, 2009, 4:21pm CET by Alex Ruiz

Posted: January 5, 2009, 1:27pm CET by Jez Nicholson

Posted: January 5, 2009, 8:00am CET by Sebastian Kübeck