Will revisit and republish some of those posts here, to revisit my thoughts at that time will start from December 2006.

Getting Agile with Scrum

Leading a Self Organizing Team

Agile estimating

Advanced Topics in Agile Planning

Scaling Agile to work with a Distributed Team

User Stories for Agile Requirements

public void shouldHaveFirstTransitivePropertyOfInequality() {
		assertTrue(valueUnderTest.compareTo(valueExpectedToBeBiggerThanExpected) < 0);
		assertTrue(valueExpectedToBeBiggerThanExpected.compareTo(anotherValueExpectedToBeEvenBiggerThanExpected) < 0);
		assertTrue(valueUnderTest.compareTo(anotherValueExpectedToBeEvenBiggerThanExpected) < 0);
	}

Full sentences in the method names. Yeah, it specifies the expected behaviour of the unit under test, but the question is about readability now.

I tried to remove the camel case to see if the readability improves, and also because I’m not a Lazzy Programmer

public void should_have_first_transitive_property_of_inequality() {
	assertTrue(value_under_test.compareTo(value_expected_to_be_bigger) < 0);
	assertTrue(value_expected_to_be_bigger.compareTo(value_expected_to_be_even_bigger) < 0);
	assertTrue(value_under_test.compareTo(value_expected_to_be_even_bigger) < 0);
}

I’m feeling good with the readability improvement, so I will drop Camel Case in my BDD exercises.

One concern I had, when started this BDD exercise, was about the length of the name for objects, fields and methods. Yes, it may look a little odd at first (ohh, the guilty of breaking conventions!!), but like everything else in life, also this code may turn to be better than what I have today. My goal is to improve readability and not follow a convention.

The video is from Dave Astels (http://techblog.daveastels.com/) and is here: http://www.youtube.com/watch?v=XOkHh8zF33o

From http://www.javapractices.com/topic/TopicAction.do?Id=17

This can be interpreted as “It’s not a good idea to use inheritance in, for example, JPA Entities. It’s better to use composition”.  I tend to agree. Deep hierarchies of JPA entities,  can be a daunting task to understand, maintain and extends. Having small hierarchies, I think it’s ok. If a JPA model, most of the time models real world concepts, and if real world concepts are better described in terms of composition, instead of inheritance, why complicate things? Take the typical Car exercise, would you model most of your car using inheritance or composition?

But if  you’re  modelling your JPA entities with object oriented principles , not caring about the mapping stuff, for now, everything that you will need to store in a DB are value types, like Integer, Long, String, byte[], or some composition of these and other value types, so there’s no point to inherit just to add values to an object, it’s better to create a new value type that represents the concept.

Just use the maven plugin to try with your maven projects and see the results.

There are other tools for mutation Testing with Java and JUnit, but did not try:

http://jester.sourceforge.net/
http://jmute.sourceforge.net/
http://jumble.sourceforge.net/

You can see the exercise here

I also have the presentation in PDF stored in google drive. Find it here.

If you have any feedback/comments or whatever, comment this post.

The presentation is here:

If you prefer the PDF, you can view it here: http://bit.ly/Ip7UYl

The exercise can be downloaded/viewed here http://bit.ly/KXB6v3

If you any feedback/comment/whatever comment it.
 

If we’re moving to the cloud-era, the undestanding of this architecture style is essential. In the cloud we are presented with services (Storage, Search, Graph, Geolocation, …) that we can and should use to build applications. Almost all of these services, available  in the cloud, provide some kind of interface and happens that, this  interfaces is, generally, a RESTful Web Service. If I want collaborate with these services I must talk the same language!! Moreover, exploring this architectural style in new applications opens the door for realy distributed and scalable systems, while the simplicity is kept high!

Here the slides:

PDF can be downloaded from here.