Shahzad Bhatti Welcome to my ramblings and rants!

Most agile methodologies recommend using Vertical slice or spiking to reduce risks. It is also referred as tracer bullet by Dave Thomas, Walking Skeleton by Alistair Cockburn and thin thread by Iterative Agile Development (IAD).

What’s in the Title
Software development profession has severe identify crisis. From, very start its process were borrowed from other engineering principles, primarily Civil Engineering or Manufacturing. People compared building software development to construction and came up with the waterwall based processes. Educational institutes started programs for Computer Science, Computer Engineering, Computer Information System, but what the hell that exactly means.

There is no minimum boundar to software development field, there is no professional certification to enter this field. Unlike other fields, you don’t need degree to enter this field. Similarly, titles in this field have been a great source of confusion. What is difference between Programmer, Developer or Software Engineer. Yeah some people consider Developer to be generalist and Programmer to be specialists, and Software Engineer sound like we are doing real engineering but it means little to most people. Similarly, senior titles are equally meaningless, most companies don’t understand difference between Senior Software Engineer or Developer, System Analysts or lately they have been calling Architect. Many other people have expressed similar views and have introduced other titles like Craftman, Hacker, or Gardner.

Writing software matches closely with art, so it is very hard to define, develop or track. Though, some aspects for software development can engineered, and there are tons of methodologies that keep trying it. Nevertheless, most productive environments have very little process and methodologies

Monitor Wireless Network
Download AirSnare

PHLAK Linux distribution
Download

Law of Demeter (LoD)
The Law of Demeter was originally formulated as a style rule for
designing object-oriented systems. “Only talk to your immediate friends”
is the motto. The style rule was discovered at Northeastern University
in the fall of 1987 by Ian Holland.
A more general formulation of the Law of Demeter is: Each unit should
have only limited knowledge about other units: only units “closely”
related to the current unit. Or: Each unit should only talk to its
friends; Don’t talk to strangers.

In this general form, the LoD is a more specific case of the Low
Coupling Principle well-known in software engineering. The Low Coupling
Principle is very general and we tried to make it more specific. The
benefit of the specific Law of Demeter shown below is that it makes the
notion of unnecessary coupling very explicit.

The main motivation for the Law of Demeter is to control information
overload; we can only keep a limited set of items in short-term memory
and it is easier to keep them in memory if they are closely related. The
definition of “closely related” is intentionally left vague so that it
can be adapted to particular circumstances.

In the application of LoD to object-oriented design and programming we
have:
unit = method f
closely related = methods of class of this/self of f and other argument
classes of f and methods of immediate part classes (both computed and
stored) of class of f (classes that are return types of methods of class
of this/self (= computed) and the classes of data members (= stored))
and methods of classes of objects that are created in f.

Bayesian Filter
Finished implementation of Bayesian Filter to detect SPAM. Now, I need to gather couple of thousand emails (good and bad) to test it.

Few interesting articles today (June 16, 2003):

1. J2EE Clustering with JBoss: Singleton and Scheduler Services
2. ONJava Article on JBoss 3 Clustering
3. Make the Java-Oracle9i connection Put Oracle9i’s object-oriented features to work

Well, I am not at the JavaOne, but plan to read each day’s highlights.
Hopefully, sun will release PDF and powerpoint slides.

OO Summary

OO Principles:

1. Encapsulation – information and implementation hiding
2. Inheritance – interface and implementation inheritance
3. Polymorphism – ability of different objects to respond differently
   to the same message. Inheritance polymorphism, operational polymorphism.

Design Principles:

1. Single Responsibility Principle (SRP) – cohesion
2. Open/Closed Principle – open to extension but closed to modification
3. Liskov Substitution Principle – subclass can be substitute for their
   base classes. Design by contract – polymorphic method of a subclass
   can only replace its pre-condition by a weaker one and its
   post condition by a stronger one.

4. Dependency Inversion Principle (DIP) – high level modules shouldn’t depend
   on low-level modules. abstraction should not depend on details.
   
   dependencies should point in the direction of abstraction.

5. Interface Separation Principle

Stability and Instability

1. Acyclic Dependency Principle – prohibits cyclic dependencies among packages
   
   The dependencies among mdoules must be arranged in Directed Acyclic Graph

2. Package Cohesion
   1. Common Closure Principle – classes that change together belong together
      
      Code with different kinds of volatility should be placed in different modules.
      Modules should not depend on other modules that are more volatile than they
      are.
      volatile code goes into instable modules, vice verse.

   2. Reuse/Release Equivalency Principle – release granularity equal to reuse granularity
   3. Common Reuse Principle – classes that aren’t reused jointly shouldn’t be grouped together
3. Stable Dependency Principle – reinforce package stability
   
   no modules should depend on a module that is less stable than it is
   
   Ce # of modules that this module depend on
   
   Ca # of modules that depend on this module
   
   Instability (I) = Ce / (Ca – Ce)
   
   If I is 1 the module is instable and 0 means module is very stable.

4. Stable Abstraction Principle – stable packages should be abstract
   
   more stable module is, the more abstract it should be
   
   Abstractness = Na / Nc, where Na is the number of abstract/interfaces and Nc
   is number of classes in the module
   
   D = |A + I – 1|
   
   0 means module is on the main sequence and 1 means it is far from the sequence

Golden Rules

1. it contains no dependencies cycles (ADP)
2. Every dependency between modules should terminate on a module whose I metric is less than or equal to the depending mdoules’ I metric (SDP).
3. Every dependency between modules should terminate on a module whose A metric is greater than or equal to the depending module’s A metric (SAP).