Concurrency, Time and Clojure

by Suresh Harikrishnan

Download this one-page Geek snack episode, and place it at your snack area.

Have you ever wondered what concurrency and time related constructs your favorite programming language provides?

I did, after watching this wonderful presentation by Rich Hickey:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

Java supports concurrency using its Threads library. There are a few constructs supporting multi-threading, but mostly to ensure you play safe when using threads. These constructs are available to protect the mutable state in objects. And Java's notion of time is limited to a few (rather awful) classes in its library. Rich Hickey uses the example of athletes running a race to show the problem of concurrency with most languages in use today. If you want to know who is leading a race, you don't ask the athletes to stop running. The athletes keep running as you notice the current standings. Simply put, Java and other popular languages presumes single shared timeline.

Compare this with Clojure. Clojure's approach to concurrency is provided by 2 distinct features - functional approach to its data structures and different styles of concurrency constructs. It's pure functions are time independent, in other words, side effects free. Clojure data structures are immutable, but persistent. It differentiates "Value" from the notion of identity. Most OO languages treat them as one - an Account object could have no balance, and then when you deposit something into this account, it takes a positive balance. Clojure on the other hand would differentiate the account identity from the actual balance in that account.


















Only the references are mutable. And Clojure supports 3 types of mutable references:
•Synchronous coordinated changes between threads using refs.
◦Clojure uses STM for ref modifications.
◦You need to be inside a transaction context to change refs
•Asynchronous coordinated changes between threads using agents.
◦Ala Actor models
◦You pass a function to change the state of the agent
•Isolate changes within a thread using vars.
◦Equivalent to thread locals.

Check out more about clojure at http://clojure.org. There is lot more to say about clojure, maybe later :)

Java – Bridges in Generics - By Venkat RS

by Venkatesh R S

Download this one-page Geek snack episode, and place it at your snack area.

In the non-Generics Java world (JDK 1.4 or before) we would have noticed all wrapper classes that implement Comparable interface have got two compareTo methods as shown below:

public interface Comparable {

public int compareTo( object obj );

}

public final class Long extends Number implements Comparable {

//Override

public int compareTo( Object obj )

{

return compareTo( (Long)obj );

}

public int compareTo( Long anotherLong) {

//logic for comparing two Long objects.

return result;

}

}

A convenient method taking in an argument of type Long for comparison.

And the one that’s implemented as a result of implementing Comparable interface which takes in an argument of type Object. This method internally casts the incoming object to the given class type (Long) and delegates the call to the convenient compareTo method as shown above. If it couldn’t cast, then a ClassCastException is thown. We call this method as ‘bridge‘ method.

But Post Java 5, with introduction of Generics and type safety, things have improved and we no more need the bridge method, compareTo(Object o) and doesn’t have to worry about any ClassCastException anymore. The implementation of the wrapper class, Long, in Java 5 or above looks as follows:

public final class Long extends Number implements Comparable<Long> {

@Override

public int compareTo(Long anotherLong) {

//logic for comparing to Long objects

return result;

}

}

But hold on second, isn’t Java 5 and above compilers has got something called type erasure, a process where the compiler will remove all the information related to type parameters and type arguments within a class or method for the sake of being binary compatible with Java libraries/applications that were created before generics?

Doesn’t it mean that the above Java 5 Long code after compilation should get translated as it is in the Java 1.4 versions?

If that’s the case, where does the bridge method go which maintains the contract between Long and Comparable interface?

Things are suppose to break here. But it actually doesn’t why?

That’s where ‘Bridges‘ in Generics comes into picture. When the compiler translates the code for binary compatibility with older applications, it also adds the required bridge methods automatically in order to sustain the implementation contracts. In this case the contract is between Comparable and the class(Long) that is implementing it.

The following snippet of reflection code for the Long.class should reveal the secret.

final Method[] methods = Long.class.getDeclaredMethods();

for (Method method : methods) {

System.out.println(method.toString() +

" - IsBrige?:" + method.isBridge());

}

Output: .....

public int

java.lang.Long.compareTo(java.lang.Long) - IsBrige?:false

public int

java.lang.Long.compareTo(java.lang.Object) - IsBrige?:true

Does it Really Work?

by Francisco Trindade

Download this one-page Geek snack episode, and place it at your snack area.

Some time ago, during a TW London Thursday event, I had the pleasure to see the Agile Methods and User Centered Design presentation from Dave Robertson and John Johnston (or at least part of it), about how Agile and User Centered design are more a match, sharing goals and values, than different approaches to software development.

If you have some time you should really watch it, it is worth the time.

The overall presentation is really good, but the reason I’m posting here is one specific point that was mentioned, which I believe really hit the spot, and that’s when they say we should rethink the word work in the “the simplest thing that could possibly work” sentence.

This point goes back to the Agile Vs Usability discussion and it is very correct IMO, because it reiterates that development teams should not deliver any code just because it was quick to develop it and the client is happy (although he shouldn’t be at all) since it didn’t cost a fortune.

And what is interesting about this subject is how agile teams don’t usually accept low quality code standards (code without tests, lots of hacks, etc..), but easily accept low usability standards, not understanding that is also their responsibility to define what a good user experience is.

What I’m NOT trying to say is that the user should be left outside from the application design. He should definitely have his opinion (and a strong one), but should also receive advice in UX standards as much as he should in code quality, making sure that he understands what he loses when is trying to save money on each particular feature.

(read more at Franciscos’s Blog).

Measuring Value of Automation Tests

by Preetam Reddy

The value of test automation is often described in terms of the cost benefits due to reduction in manual testing effort (and the resources needed thereof) and also their ability to give fast feedback. However, this is based on a key assumption that the automated tests are serving their primary purpose – to repeatedly, consistently, and quickly validate that the application is within the threshold of acceptable defects.

Since it is impossible to know most of the defects in an application without using it over a period of time (either by a manual testing team or by users in production), we will need statistical concepts and models to help us design and confirm that the automated tests are indeed serving their primary purpose... (read more at Preetam’s blog).

Download this Geek Snack episode here.

Velocity gone wrong #1: Done is not done

by Danilo Sato

Dan North wrote an interesting post about the perils of estimation, questioning our approach to inceptions, release planning, and setting expectations about scope. This made me think about the implications of those factors once a project starts, and I came up with some anti-patterns on the usage of velocity to track progress. This is my first attempt at writing about them.

Before we start, it’s important to understand what velocity means. My simple definition of velocity is the total number of estimation units for the items delivered in an iteration. Estimation unit can be whatever the team chooses: ideal days, hours, pomodoros, or story points. The nature of items may vary as well: features, use cases, and user stories are common choices. Iteration is a fixed amount of time where the team will work on delivering those items. Sounds simple? Well… there’s one concept that is commonly overlooked and that’s the source of the first anti-pattern: what does delivered means?

… (read more at Danilo’s blog).


Download this Geek Snack episode here.

Document Oriented Databases

by Hari Krishnan

History

Relational Databases have been almost the only way applications persist data. In the old days when code was written mostly with languages like COBOL, even navigational databases were sufficient. The switch to relational databases made it easier to query. Not much has changed in the way we store data since then. This may be attributed to fact that query performance is still the most important aspects for choosing a persistence mechanism.
Object oriented code as we all know has to go through mapping tools to be persisted as relational entities. Are we going to use the same database concepts in the coming years?

Retrospect

Have you been bothered by the below issues?
• We model business logic as interaction between objects. Concepts such as triggers also model some amount of business logic. Though the confusion should not arise, many a times people mix business logic in database layer and business layer. In some rare circumstances there may even be duplication of logic in Business layer and Database layer. Example: When a new customer is created, a trigger inserts a new row into another table called privileged customer based on a data condition. The trigger here has business logic in it which is not covered by unit test cases.
• Applications have Domain validations like customer name cannot be null. If you have such validations are in our code, which we normally do, then why do we need a database that also does these validations?
• We create great Object oriented business layer and lose sleep over mapping them to a relational model. All I care about is persistence of the state of my objects. Though I agree relational databases have very good query performance, are we really keeping our eyes closed to other persistence techniques?

Alternate Approach

CouchDB – A Document Oriented Database: Document-based databases do not store data in tables with uniform sized fields for each record. Instead, each record is stored as a document that has certain characteristics. Any number of fields of any length can be added to a document.
CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Couch DB is not an object-oriented database.

In a relational database we would store addresses of a customer in a different table, with a foreign key linking it to the customer.
With a document-oriented database, such as CouchDB, the nested resources maybe stored together with the main resource. Example JSON Document:
{
"name": "Geeky Customer",
"adresses": [
{"street": "Wall Street", "Number": "2"},
{"street": "Dalal Street", "Number": "4"},
]
}
This brings us to an interesting thought. We do not require ORM frameworks like hibernate and active record which are mostly written around SQL-like problems that CouchDB just doesn’t have.
There are libraries like CouchRest, RelaxDB, ActiveCouch etc which provide simple ways to connect to CouchDB.
I have taken CouchDB only as an example. There are many new database which are quickly becoming popular for specific situations. It may be worth the effort to take a look at such alternatives.

Download this Geek Snack episode here.

Agile linear algebra questionnaire

Test your Agile linear algebra

By Paulo Caroli

Releasing planning, Iteration planning, velocity and burn up charts are basic linear algebra!

From Wikipedia: “Algebra is a part of mathematics (math) that helps show the general links between numbers and math operations (adding, subtracting, multiplying or dividing) used on the numbers. Algebra does this by using letters (a,b,c,...) or other symbols to represent numbers, either because the numbers are unknown or because the numbers change during the course of the problem, in which case the letters are called variables.
Let’s test your basic Agile linear algebra knowledge!

Check out the formulae below and try out the questionnaire.

The Formulae

Vp = Ro / Ip
The planned average velocity (Vp) is the number of story points planned for the release (Ro) by the number of planned iterations (Ip).

V = ∑Si / i
The average velocity of a team (V) is the sum delivered story points per iteration (∑Si) by the number of iterations elapsed (i).

Ve = V + ∆V
Velocity expected is the average velocity (V ) plus the expected velocity variation (∆V). Velocity expected is commonly used for planning activities, such as iteration and release planning.

R = Ro + ∆R
The current total story points planned for the release (R) is the original story points planned for the release (Ro) plus the delta of story points for the release (∆R).

Rm = R - ∑Si
The number of story points remaining for the release (Rm ) is the current total Story points for the release (R ) minus the sum of completed story points for the iterations (∑Si).

Ir = Rm / Ve
The number of iterations remaining (Ir) is the number of story points remaining for the release (Rm ) by the expected velocity (Ve)


Questionnaire

Problem 1
An agile team plans to deliver 400 story points in 10 iterations. What is the planned average velocity for the team?
(a) 10 sp/it (b) 20 sp/it (c) 40 sp/it (d) 400 sp/it (e) other

Problem 2
A team has average velocity of 10 sp/it. Extra resources are added to the team, thus creating an expected rise in velocity of 4 sp/it. What is the expected velocity for the team?
(a) 10 sp/it (b) 14 sp/it (c) 4 sp/it (d) 6 sp/it (e) other

Problem 3
In Iteration 1, the team delivered 10 story points, in iteration 2 the team delivered 14 story points, in Iteration 3 the team delivered 12 story points. What is the average velocity for the team?
(a) 6 sp/it (b) 12 sp/it (c) 24 sp/it (d) 36 sp/it (e) other

Problem 4
Consider the team iteration history of Problem 3. The original release plan is to deliver 400 story points. Assume that the team is about to start Iteration 4, and that the team is able to keep the same average velocity from the first 3 iteration for the remaining iterations of the release. The project manager decides to add an extra pair of developer to the team; and the velocity is expected to increase by 2 sp/it. How many iterations (in total) will it take for the team to deliver the 400 story points planned for the release?
(a) 23it (b) 26 it (c) 29 it (d) 32 it (e) other

Problem 5
Same as Problem 4, but 140 sp have been de-scoped from the release. How many more iterations will it take for the team to deliver the number of story points planned for the release?
(a) 12it (b) 16 it (c) 26 it (d) 36 it (e) other

Problem 6
Same as Problem 4. How many story points should be de-scoped from the release to enable the software to be released after a total of 12 iterations?
a) 0sp (b) 112 sp (c) 196sp (d)238 sp (e) other

Download this Geek Snack episode here.

Welcome to GeekSnack

Often we (geeks) find ourselves at the pantry looking for snacks and geeking out.

To support these hungry geeks, we are periodically printing out some geeky one-page article and placing it in our office area (next to the snacks cabinet).

In this blog we will upload the Geek Snack episodes. Also we will post comments and discussions for the episodes.