Link Details

Finally an article about GridGain that has a real life scenario and code.

Common Kiril.

There are many of articles on GridGain that have real life scenarios and code. Here are a few examples (there are many more):
http://www.dzone.com/links/load_balance_on_the_grid_one_interface_with_one_m.html
http://www.dzone.com/links/say_hello_world_to_the_grid.html
http://www.dzone.com/links/jxinsight_55ea8_gridgain_diagnostics_probes.html
http://www.dzone.com/links/an_ondemand_grid_with_gridgain_and_ec2.html

There are many interesting blogs without coding examples, but explaining useful grid computing features and concepts as well.

We are still waiting for you to try it out ;-)

And there are many articles that have little or no substance to them and are only voted up by GridGain project members. As you know, there have been repeated complaints about this practice. For me, it represents bad judgment and I causes me to wonder if that bad judgment extends to GridGain technical decisions.

I agree with Krill that this article had some potentially useful information in it. However, there are more straightforward ways to speed up slow unit tests. For example, see

http://www.artima.com/weblogs/viewpost.jsp?thread=126923

I was on a team that used the techniques described in that post and were able to run about 4000 unit tests in 15 seconds on a single core x86 without the additional complexity of a grid computing architecture just to run unit tests.

Say business tests. Those article is right saying that "test is not the unit test if ... ". But what about thousands business tests that need DB connection, network communication and so on.
The need to be automated as well. And in this case they won't take 15 sec :)) but 15 hours if you are lucky enough.

As for voting, man I have never seen 20 or even 15 people in our company :)) You are not right. IMHO these are the people who use us :)

> As for voting, man I have never seen 20 or even 15 people in our company :))
> You are not right. IMHO these are the people who use us :)

This is exactly right. Good content will get voted up by the users (real and potential). Good content doesn't need to be submitted by the article author, and good content doesn't need to be "mob-linked" by the project members. I suggested once a simple experiment - instead of doing the above, wait a day or two and see if anybody deems the blog entry valuable / interesting enough to post it and vote it up. That would be an indicator of real interest.

Kiril,

What I noticed is that in many cases people who complain about this (not you) work for our commercial competitors.

Sticking to your argument "Good content will get voted up by the users" really tells me that 90%+ of GridGain blogs is "Good Content".

Since we had a combination of different types of tests we didn't need 15 hours of "business tests". You're correct that integration tests didn't run in 15 seconds, but we did run a few thousand of them in less than 10 minutes. It's common for developers to write tests against a database that don't really need the database. For example, if a project is using ORM many tests can be written against the entity classes without requiring those entities to be loaded from a database for the test. I've worked with teams where we increased the the speed of their test suites by 10x or more just by using good testing techniques. From what I've seen, many developers just assume that that their tests must run slowly and don't think about how to increase their speed. Using grid computing in this case is treating the symptoms rather than the root cause of the problem.

Hi joecoder,

How about a real name and the company you work for? Hard to have a thoughtful conversation with a guy that hides behind a made up nick.

I'm not sure why knowing my name and company will make thoughtful conversation easier. However, I'm not a competitor. Actually, I'm a potential GridGain user. When I have a specific need for grid computing, I'll still consider using GridGain despite the dubious marketing techniques.