All posts by coach

Book Read : The Practice of Programming

Phew!
I read a book. Complete. End to End.
It is in my morning travel time, thanks to the 17 kilometers I need to travel everyday one side, increasing my carbon footprint(or is it natural gas?), that I have started to devote time to reading.

Motivation:
I have access to a library that boasts of some timeless titles.

I can quote just one part from the book that I really liked.It refers to the ways of Debugging-Explain your code to someone else.
It states:
“One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.”

These precious gems are already jotted down by someone who likes this book here.

What I would want to put across here is the quote which the authors have chosen to convey the essence of each chapters:

Chapter 1 : Style

It is an old observation that the best writers sometimes disregard the rules of the rhetoric. When they do so, however, the reader will usually find in the sentence some compensating merit, attained at the cof violation. Unless he is certain of doing as well, he will probably do best to follow the rules.

-William Strunk and E. B. White, The Elements of Style.

Chapter 2: Algorithms and Data Structures

In the end, only familiarity with the tools and techniques of the field will provide the right solution for a particular problem, and only a certain amount of experience will provide consistently professional results.

-Raymond Fielding, The Technique of Special Effects Cinematography.

Chapter 3: Design and Implementation


Show me your flowcharts and conceal your tables, and I shall continue to be mystified.
Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious

-Frederick P. Brooks, Jr., The Mythical Man Month.

Chapter 4: Interface

Before I built a wall I’d ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
Something there is that doesn’t love a wall,
That wants it down.

-Robert Frost, Mending Wall.

Chapter 5: Debugging

bug.
b. A defect or fault in a machine, plan, or the like. orig. U.S.
1889 Pall Mall Gaz. 11 Mar. 1/1 Mr. Edison, I was informed, had been up for the two previous nights discovering ‘a bug’ i his photograph–an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble.

Oxford English Dictionary, 2nd Edition.

Chapter 6: Testing

In ordinary computational practice by hand or by desk machines, it is the custom to check every step of the computation and, when as error s found, to localize it by backward process starting from the first point where the error is noted.

-Norbert Wiener, Cybernetics.

Chapter 7: Performance

His promises were, as he then as, mighty;
But his performance, as he is now, nothing.

Shakespeare, King Henry VIII.

Chapter 8: Portability

Finally standardization, like convention, can be another manifestation of the strong order. But unlike convention it has been accepted in Modern architecture as an enriching product of our technology, yet dreaded for its potential domination and brutality.

-Robert Venturi, Complexity and Contradiction in Architecture.

Chapter 9: Notation.

Perhaps of all the creations of man language is the most astonishing.

-Giles Lytton Strachey, Words and Poetry.

No doubt, the book needs to be read again atleast twice to imbibe by its sayings.
A similar java specific list can be found from Effective Java.

This is something to get used to and keep with oneself always.
~rohit.

The New Service Layer Architecture.

I have been associated with 3 major softwares that were developed for corporates and large businesses. In each of them, I had seen somewhat common layered architecture where either a facade layer exists for the flow or did not.One of the three architectures had a dedicated facade layer on top of the service/business flows. Incidently it was the only application that was designed for the web.

That could be the reason where the architect might have envisioned mashups of business objects that might be requested from the client side.This decision seemed to be motivated by the controlled requests coming from the web vs the uncontrolled calls on a desktop application.But then, the speed with which the desktop applications have also started gaining back popularity since the past couple of years, it might not be incorrect to assume that the architecture of a web and a desktop application should overlap.The desktop applications are becoming more and more responsive and with an expert user the desktop application demand more challenging screens as compared to web applications.

It is with these understandings I propose the following layered architecture:
The core difference lies in the way the business service calls are divided into two sub layers namely:
1/Facade layer.:: Responsible for mashed-up/secondary business object screens.
2/Business Service layer.:: Responsible for manipulation of core business objects screens.

The process layer calls can go directly to the service layer and also can talk to the facade layer also.

For example, consider the problem domain of bicycles, where we are writing an application for selling of bicycles.

For the initial iteration, the service layer would be enough to cater to the needs of operations like getting a quote of bicycle from different sources, getting different color models, different frame sizes etc.

Later on the application owner might want to move to custom built bicycles where the complete bicycle is not the single object that is passed across the process and service layers, as wheels, frames,handle-bars,seat-posts all start bringing in different compositions for the custom build bicycle.
In this scenario, the facade would be a great place to assemble different parts of the bicycle bind them together and return to the process as the complete bicycle object.
Even later on when the bicycle sub parts are further broken down like the wheel composition can give multiple options to choose from, this structure can be extended further.

Some might argue that the facade layer can exist at the same level as the service layer. Quite true, but over a period of time when the service layer gets fat with lots and lots of business specific code being written, the objects that go in and out of this layer becomes unclear, as to the core set of objects around which the whole application revolves. This loss of focus from the core objects of functionality can result in a loss of a perspective in writing new code/flow for the application, the consequences of which can be differently dangerous in varied scenarios.

To conclude,I like this layout because:

1/ It keeps a unique object being passed across layers.

2/Multiple Do’s and Do not Do’s from design perspective get constrained for the developer.

3/Gives greater and cleaner objectivity to the flow of the objects in the complete application.The service layer can be controlled as one that caters to core business and the one that is responsible for supported objects.

4/Easy refactoring capabilities and pluggable architecture.

Is it fair to partition the service layer on primary objects?Does it limit the growth of the application(and business itself)?

What do you think?

The agile India Scenario

The extreme programming wave initiated by Kent Beck et al in 1999 and since then the mature world programmers have embraced that change. A lot many clones started from that movement like agile itself, and the much widespread like scrum and lean.
Although these methodologies(or approaches?) had existed since long time, I remember reading somewhere that motorola had these practices in place since the 1960’s.

Flash-forward to India, I do not know who or when was the first project here was done with the wisdom of sound agile practices? But since I stepped into the professional way of writing software(means I was paid for what ever I did or did not), I was fortunate to see a genuine mix of these practices from the very start.Moving on to different software vendors, I notice that India per say is yet to embrace agile in spirit.

I do not travel at all, but looking around the small sample of professionals(incl self claimed agilist’s) I am dis-heartened to say the least, when I see my self surrounded by a lot of certified SCrUM(pun intended).
No doubt it has made its mark and helped realize XP too, ever since I got to know about XP, I had(still do) predicted the end of the software manager(with MBA) as a career.
The point that I want to make across is that these managers have misused the insights from agile practices to abuse the Indian developer. I have seen(and heard) *only* Indian managers who have been doing this to their Indian counterparts.
I dare say if they are given a mix of developers from different geographies, they would not do the mistake of exploiting more work in lesser time.
That is like a blind person blessed with more powers.

That being the problem around how do I( or we?) as the Indian developer in the clutches of the Manager (with MBA) cope with it?

Ahh! Its a complex mix out there.There are managers without MBA also.
Need to get back to the drawing board and start afresh!

Look Maa! No Tables Only Objects!

Databases are one topic that I have never had a chance to get deeper insights.

I started JDBC’ing when later I was surprised to know that one could connect to the database using ‘C’.

I had not worked enough to feel the pain of iterating over ResultSet and writing insert/update scripts that virtually went outside the screen when I saw the onset of “Hibernate-Relational Persistence for Idiomatic Java”. I never liked the writing/seeing/understanding XML, but I had no choice but to Well Hmmm!

And with most of the time spent in Hibernate, I never felt its features were intuitive to that of Java(in no specific order).

  • First and foremost in Java, Enum are first class citizens, in Hibernate, working with an Enum is not at all trivial.
  • Using composite keys asks you to maintain a seperate object for it.
  • Already there were two worlds of entities in Application(objects) and entities in DB(records), now to understand the two, one needed to know how Hibernate understands the two worlds.

For simple applications, Hibernate is way to work with, but with very large applications, I did not like the complexity that it brought in atleast two occasions, requiring extra time to keep the DB and the hbm files in sync.
It could be the incorrect way of not completely relying on hbm for schema generation, but because these applications had predefined schema’s, this was the only possible safe-path.

Issues with RDBMS:

  • Application<---->Mapping<---->DB
  • Cost of mapping conversion(second level cache’s are not enough!)
  • Transactions duplicates Locking- In general.

Tired of looking at xml, and with the option to write an application for fun, I have the option to evaluate the usage of Object Oriented Database.
I had found atleast a dozen implementation of such software, at the end it came down to db4o and Perst. And here is the summary of them:

db4o

  • Most commonly used OODBMS.
  • Easy to learn.
  • Supports intuitive Refactoring of persistent classes.
  • Support for Projections is not available(could not find).
  • Lazy initialization supported with default level of depth.

Perst

  • Has GIS Dataset
  • Fastest amongst all OODBMS.
  • Cryptic creation of indices for faster search.
  • Concept of Links for references pollutes domain.
  • No fixed DTD for import/export feature for refactoring.

Both the products have the following in common:

  • Support for Transactions.
  • Zero mismatch between object and saved data.
  • Confusing Licence!

At the end, I have to give in to db4o for simplicity and refactoring features.
And that’s where I would start looking at injecting it into the application.

Concerns about OODBMS:

  • Not Yet widely used – I wonder why?
  • Clustering – I do not need it.
  • Backup – RDBMS or File?
  • Optimization – Exotic feature than a requirement.

So I would look forward to working on the application on db4o and will update on the findings!

~rohit.

My JUnit Arsenal!

Writing unit tests for working on a piece of code is an exciting task that I enjoy.
To accomplish this with ease, for now my junit arsenal has the following approach:

1/ Mathematical Induction

2/ Boundary Value Analysis

3/ Permutation of the variables.

What’s yours?

Care to share?

Reverse Logic :: Launched!

Gang,

I am pleased to announce that we own a domain name on the world wide web!

we are *http://reverselogic.info*

Our next steps:

1/Subscribe to the gang(gangRemovemE@reverselogic.info)– ALL

2/Download the pencil plugin(firefox) and start sketching the screen
design how we want the web to reflect us!– ALL

3/Pen down how you would want your information made available on the
web for presence!–ALL

4/Pull your thinking hat’s on and start chalking out
mail-boxes/sections you would want to see on
http://reverselogic.info –ALL

5/Atleast feel excited! 🙂 –ALL(mandatory!)

Keep The Stir In!

~rohit.

White Code!

Today while working at my desk, I came across a situation where a colleague was writing some piece of code as a missing implementation when a module changed hands.
There was little time and so, the part had to be just written for the sake of it.
And that’s where I wanted to dis-associate myself from the partnership.
It so happened that the situation was getting complex and two heads were good at solving it.
I could not yet overcome my hesitation to help in a piece of code that would not be tested, so rather than saying this, I called it the white code: The one that was written on the white background of eclipse editor and never get through living in the main memory and get executed!
To my happy surprise, he got motivated and understood my hesitation and ensuring the missing implementation code was atleast working on a non matching scenario and breathe life into the code.
There we called it the green code:Simply because it was executed, not for complete scenarios, but it was executed!

Green is the way to go!

Public Network Passwords under attack!

With options like this which are available now, the public network passwords are a vulnerable lot today!
Coming to the solutions mode, the question that raises concerns and needs to be addressed is:

How to protect public network password from brute force attack?

And we think about the answers:

1/Biometrics?
No, can be easily imitated, and IMHO, causes the power to rest with anyone who has power/money.

2/Special fonts?
Kinda-OK, the fonts that are created, should reside on a system only.
Limits mobility, but sure seems a viable option.

3/Thick client logins?
Yup, Can be mobile, enables a secure area.
More like double-check locking!

4/Best of 3 login attempts?
Black list the brute force IP. (+)Good for cleaning up the internet, (-)bad for businesses!

5/Image/Non-Text based passwords?
(+)Increases complexity (+) can be copyrighted/encrypted (-)Need to carry that picture always! (-) little randomness.

What could give the password crackers a new challenge?
It seems brute force is won over and the text books needs to be edited!

Comment Anywhere!

Has it occurred to you(the reader) that you came across something and you like to comment on it?
Be it a feedback/improvement/suggestion/Aha moment or something you recall, simply said, how something that you see or read related to you?
If this could happen, you got another encyclopedia of stories of people and their experience getting ready to be scripted.
What would be unique to this movement is everyone takes the role of an author and a reader!

Very Exciting!

Challenges:
1/ How to track different people commenting at different times!
2/ How to keep it consistent with varying media on which comment is to be made?
3/ We have become thick, we use the desktop, and our applications sit on top of them, How to bring it to the desktop?

Now its becoming interesting!

~rohit.