Memory Leaks

Trie: Second Implementation in Groovy

noreply@blogger.com (Mohammad Shamsi) — Fri, 10 Feb 2012 22:58:10 PST

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

noreply@blogger.com (Mohammad Shamsi) — Fri, 10 Feb 2012 05:47:32 PST

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.

noreply@blogger.com (Mohammad Shamsi) — Tue, 31 Jan 2012 08:04:43 PST

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

noreply@blogger.com (Mohammad Shamsi) — Fri, 27 Jan 2012 08:02:14 PST

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.

Priority Queue - Groovy Implementation

noreply@blogger.com (Mohammad Shamsi) — Sun, 22 Jan 2012 04:32:17 PST

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

noreply@blogger.com (Mohammad Shamsi) — Fri, 20 Jan 2012 06:13:45 PST

My Groovy Implementation for QuickSort:

Heap Sort Implementation in Groovy

noreply@blogger.com (Mohammad Shamsi) — Tue, 17 Jan 2012 06:26:57 PST

My Heap Sort Implementation in Groovy :

My Merge Sort in Groovy

noreply@blogger.com (Mohammad Shamsi) — Tue, 10 Jan 2012 08:23:19 PST

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

Least knowledge

noreply@blogger.com (Mohammad Shamsi) — Mon, 12 Dec 2011 01:57:40 PST

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

noreply@blogger.com (Mohammad Shamsi) — Wed, 07 Dec 2011 00:00:44 PST

See more posters here

Patterns of Effective Delivery - Dan North

noreply@blogger.com (Mohammad Shamsi) — Sat, 26 Nov 2011 07:58:02 PST

Another excellent talk from Dan North.

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

Velocity is Killing Agility!

noreply@blogger.com (Mohammad Shamsi) — Sat, 12 Nov 2011 07:52:47 PST

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

noreply@blogger.com (Mohammad Shamsi) — Tue, 08 Nov 2011 17:29:28 PST

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

noreply@blogger.com (Mohammad Shamsi) — Sun, 06 Nov 2011 05:09:48 PST

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

noreply@blogger.com (Mohammad Shamsi) — Sat, 05 Nov 2011 08:00:36 PDT

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

noreply@blogger.com (Mohammad Shamsi) — Thu, 06 Oct 2011 08:50:05 PDT

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

noreply@blogger.com (Mohammad Shamsi) — Sun, 21 Aug 2011 03:14:01 PDT

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?

noreply@blogger.com (Mohammad Shamsi) — Fri, 25 Feb 2011 22:49:53 PST

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

noreply@blogger.com (Mohammad Shamsi) — Fri, 25 Feb 2011 22:44:48 PST

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

Singletons are Pathological Liars

noreply@blogger.com (Mohammad Shamsi) — Mon, 27 Dec 2010 06:29:52 PST

You can live in a society where everyone (every class) declares who their friends (collaborators) are. If I know that Joe knows Mary but neither Mary nor Joe knows Tim, then it is safe for me to assume that if I give some information to Joe he may give it to Mary, but under no circumstances will Tim get hold of it. Now, imagine that everyone (every class) declares some of their friends (collaborators), but other friends (collaborators which are singletons) are kept secret. Now you are left wondering how in the world did Tim got hold of the information you gave to Joe.

read full story here.

Dependency Injection, The manual way

noreply@blogger.com (Mohammad Shamsi) — Mon, 27 Dec 2010 05:35:36 PST

Dependency Injection, The manual way

"The JCP Is Dead" ?

noreply@blogger.com (Mohammad Shamsi) — Sat, 11 Dec 2010 23:51:11 PST

The JCP Is Dead
... and Oracle killed it.

By this time, most people know that the ASF has resigned from the JCP EC.

What was posted was our final version of the notice, but I'd also like to share with the community an earlier, rougher and more "emotional" version. It says the same, but in a more face-to-face conversational way. I feel that both versions represent the disappointment, anger and sadness over this whole issue, which has been fostering since 2006. The below just captures it from a different point of view:

Read the full story on Jim's blog

What's in a Story? [Dan North]

noreply@blogger.com (Mohammad Shamsi) — Sun, 21 Nov 2010 06:57:28 PST

Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria.

Introduction
Software delivery is about writing software to achieve business outcomes. It sounds obvious, but often political or environmental factors distract us from remembering this. Sometimes software delivery can appear to be about producing optimistic reports to keep senior management happy, or just creating “busy work” to keep people in paid employment, but that’s a topic for another day.

Usually, the business outcomes are too coarse-grained to be used to directly write software (where do you start coding when the outcome is “save 5% of my operating costs”?) so we need to define requirements at some intermediate level in order to get work done.

Behaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on. To do this, we need a way to describe the requirement such that everyone – the business folks, the analyst, the developer and the tester – have a common understanding of the scope of the work. From this they can agree a common definiton of “done”, and we escape the dual gumption traps of “that’s not what I asked for” or “I forgot to tell you about this other thing”.

This, then, is the role of a Story. It has to be a description of a requirement and its business benefit, and a set of criteria by which we all agree that it is “done”. This is a more rigorous definition than in other agile methodologies, where it is variously described as a “promise of a conversation” or a “description of a feature”. (A BDD story can just as easily describe a non-functional requirement, as long as the work can be scoped, estimated and agreed on.)

continue here : http://blog.dannorth.net/whats-in-a-story/

Writing Testable Systems

noreply@blogger.com (Mohammad Shamsi) — Sun, 21 Nov 2010 05:31:03 PST

Writing Testable Systems
— Complex enterprise applications are generally hard to maintain, and risky and difficult to change. As a new developer on a team, a large legacy code base is often difficult to understand, especially when the code has evolved over a long period and new functionality has been grafted onto an existing application.

Test-Driven Development Is Not About Testing

noreply@blogger.com (Mohammad Shamsi) — Sun, 21 Nov 2010 05:22:02 PST

Test-Driven Development Is Not About Testing
— I am always on the look out for good questions to ask candidates in an interview. Not the 'How many oranges can I fit in this room?' kind of nonsense (the stock response to which is apparently 'with or without us standing in it?').