How to GET a Cup of Coffee

 An interesting article about REST
How to GET a Cup of Coffee

Trie: Second Implementation in Groovy

This is another version of Trie implementation in my previous post. The new one comes with a flag to identify a complete word.

Groovy : Trie Implementation

From Wikipedia:

In computer science, a trie, or prefix tree, is an ordered tree data structure that is used to store an associative array where the keys are usually strings. Unlike a binary search tree, no node in the tree stores the key associated with that node; instead, its position in the tree defines the key it is associated with. All the descendants of a node have a common prefix of the string associated with that node, and the root is associated with the empty string. Values are normally not associated with every node, only with leaves and some inner nodes that correspond to keys of interest.

Introsort implementation by Groovy.

Another groovy homework. this time Introsort.

From Wikipedia :
Introsort or introspective sort is a sorting algorithm designed by David Musser in 1997. It begins with quicksort and switches to heapsort when the recursion depth exceeds a level based on (the logarithm of) the number of elements being sorted. It is the best of both worlds, with a worst-case O(n log n) runtime and practical performance comparable to quicksort on typical data sets. Since both algorithms it uses are comparison sorts, it too is a comparison sort.

Log base 2 of an N-bit integer

Another Groovy training post. This time, three different method to find log base 2 of an N-bit integer.

Note: All algorithms and code credits goes to Bit Twiddling Hacks.

Note: All algorithms and code credits goes to Bit Twiddling Hacks.

Priority Queue - Groovy Implementation

Here it is :), Another data structure, implemented by me in Groovy as part of my Groovy learning practices. Priority Queue.

Quick Sort, My Groovy Implementation

My Groovy Implementation for QuickSort:

Heap Sort Implementation in Groovy

My Heap Sort Implementation in Groovy :

My Merge Sort in Groovy

I'm Learning Groovy :) and This is my groovy implementation of Merge Sort.

Least knowledge

Before :

Let's say we have following Address class:

And we are using it in another class like Person:

And at the end, A client code that is going to use it in this way:

After:

Now Lets' change Person to add new methods to return first and second line of address:

So client can utilize new methods in this way:


What are the pros & cons for each solution (before and after) ?

The SOLID Principles, Explained with Motivational Posters

See more posters here  

Patterns of Effective Delivery - Dan North

Another excellent talk from Dan North.

Patterns of Effective Delivery - Dan North from Roots conference on Vimeo.

Velocity is Killing Agility!

• Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
• Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
• Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.
• Particularly for those parts of the business for which high responsiveness (a deployment cycle time of days or weeks) is critical, investment in the delivery engine is as critical as investing in new features.
• Management needs to allocate resources between features and engine work and then create a product ownership team consisting of the product owner and technical leader to do feature prioritization.
• Value (value points) and cycle time metrics will help balance the detrimental effects of velocity measures.

Read the full article : Velocity is Killing Agility!

InfoQ: Apache Harmony Finale

The Apache Harmony PMC initiated a vote earlier this week to begin the process of moving the codebase into the Apache Attic and disbanding the PMC. With 18 for and 2 against, the result will be that the Apache Harmony project will be wound up and placed in the Attic for posterity.

Apache Harmony was an open-source clean-room implementation of the JDK, released under the Apache license, but could never call itself Java compatible as Sun refused to honour the JSPA which would give them access to the Testing Compatibility Kit (TCK), a pre-requisite of which is needed before an implementation can call itself Java. Apache's open letter to Sun, published on April 10th 2007, asked for and failed to receive clarity on the subject.

continue here : InfoQ: Apache Harmony Finale

Being Agile with Lean Software Development

The “Lean” term has only been around in the business world since the 90s, but the underlying concept of lean production goes way back. While Henry Ford wasn’t the father of this approach (lean principles actually have Japanese roots), his strong focus on efficient use of resources is viewed as an important input in the development of this system. Automobile design and manufacture is definitely the industry most people associate with the lean philosophy since Toyota has made a point of marketing around this frugality and value-focused methodology for the last few decades.


read the full article here...

Spring: The art of using GRASP Patterns

When we search for design pattern articles, we found essentially documentation concerning “Gang of Four” patterns, they are very useful and contribute to well design application.

But when I discovered GRASP principles , I advice any one interested to improve his skills design to look at these principles, it gives a design fondamental rules.

In this article we will discover some GRASP principles used by Spring, and the advantages of using them.

read the full article...

From Months to Minutes

Another interesting presentation by Dan North.

Dan North reviews many Agile practices and concepts, mentioning what has really made the difference over the years and what has not, outlining what helps high performing teams to do their job.

Watch the presentation here at InfoQ if you interested in Agile topics.

On the road to being a better developer

Everyone wants to be good in what he’s doing – that’s human nature, that’s how we’re raised. The key is constant improvement without being disappointed by small failures and bumps on the way. In the last 10 years I’ve been working as a developer and I feel I’ve learnt a lot of valuable lessons – many of which can be applied to other areas of life and work. Let me share my lessons with you, dear reader.

Without specific order, a’la ad hoc:

Read the complete article here.

Whose domain is it anyway?

The brittleness of tests or specs is a recurring topic in BDD (or acceptance test-driven development, specification-by-example, or whatever you choose to call the thing where you write acceptance criteria, automate them and then make the application match). This is a tricky area, and there are probably as many styles of defining and grouping acceptance criteria as there are teams automating them.

The aspect I want to focus on in this article is domain language, because there’s a failure mode I encounter surprisingly often, which seems to have a common root cause.

Read the full story here

The perils of estimation

Business people want estimates. They want to know how much it’s going to cost them to get a solution, and they want to know how likely it is to come in on time and on budget. And of course quality is not negotiable.

Agile teams I encounter are at best nervous about estimates and at worst simply evasive. “You don’t need estimates if you’re doing Agile,” they say. “It will be ready when it’s done. We’re constantly adding value so we don’t need to commit to a date.”


read the full story on Don North blog