Archive for the ‘Computer Science’ Category

A DRY KISS

October 29, 2010

Absolutely Don’t Repeat Yourself and Keep It Simple, Stupid! (A DRY KISS) .

DRY and KISS are common concepts between software developers, but are very difficult to follow. Specially when you start with some idea, run with it, and it starts to layer up in complexity. Without even recognizing it goes out of control. With each of there added layers, you might find yourself repeating things without even recognizing the fact.

Drawing the very fine line between simplicity and and complexity is a very difficult task. It gets even more difficult without taking a step back to look at the big picture, the original aim, the purpose.

This is why an external review of the matter by a 3rd party is often vital. It givesĀ perspective that helps the general good. Such a review process is often excruciating, painful, and long. But in the end of day, without it there is no real gain.

A a final note, I believe that A DRY KISS is something to try and follow in general.

Advertisements

Proposal: Hierarchical Unit Testing for less woes

October 2, 2010

Disclaimer: The following content is of an idea which might be already existing, so please feel free to comment if you find it in existing testing frameworks šŸ™‚

A common problem I face during test-driven development is when having to tests (for ease i’ll call them T1 and T2). T1 and T2 test the functionality of F1 and F2 respectively. The fun starts when F2 isĀ dependent on F1, and both tests fail. In a test suit of thousands of tests, it would be hard to see the correlation from only the report of running the test suite.

It gets worse when theĀ dependency between tests is not direct. For example Ā if F3->F2->F1 (-> means “depends on”), where only T1 and T3 fail and T2 is fine. These relations need a very careful reviewer of the test results, and one who is well aware of the relations between components and their tests. This might be impossible in HUGE teams spanning many components.

But what if the testing framework was aware of these relations, and was able to report them. Such relations could be represented for example as new annotations in JUnit. With building the relation graph between tests it would be easy show that T2 might have failed because T1 failed.

So this is an open call, any one willing to try creating this, if it is not already out there?

The Recurring Beauty

December 27, 2009

Recently, I stared reading one of the essential books for a computer scientists, namely Concrete Mathematics. After the first chapter, it really got me thinking “Oh My!! Recurrences could solve anything.” This is of course not matched to the thrill of the challenge in funding recurring patterns in a structure.

Along my college years, colleges tend to step away from recurrences. In fact, many cases it is the easier approach to tackle. Furthermore, it could be in some cases the more efficient approach. This reminds me of many algorithm techniques that largely depend on finding substructures or small solutions that are used for generalizations. The most vivid example comes to me in the form of memoization in dynamic programming (DP). For me the corner stone of DP is finding the “magical” recurrence. Thus, from super slow, to super fast (lots of memory use though :D).

Other examples of how recursive thinking makes complex problems elegantly simple could be seen in graph theory. Just by examining some properties on nodes, arcs, degrees, huge complexities just boil down to some elegantly beautiful properties that are easily generalizable.

Such beauty could be easily seen when recurrences could end up in something that is visually breath taking. An example are Fractals, a stunning example of how simple math with recursion lead to amazing imagery.


%d bloggers like this: