Crude Java and Agile thoughts
Category Archives: Java
Maven Lucene Plugin is an open source maven plugin for Apache Lucene developed by Xebia India IT Architects Ltd . The project is hosted on SourceForge and can be found here. It is released under GNU General Public License (GPL).
maven-lucene-plugin creates a Lucene index from a file source. The structure of the lucene index i.e. fields, analyzers, indexLocation, fileSourceLocation, store etc can be configured in a configuration file lucene.xml.
lucene.xml contains all information regarding the lucene index and the data source (from which the index is created). The Maven Lucene Plugin looks for lucene.xml file in the project root directory (adjacent to pom.xml) and creates the lucene index from the file source mentioned in lucene.xml based on the index configuration provided. Read more of this post
The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:
The Blog-Health-o-Meter™ reads Wow.
Unzip it and extract it to some location. This location will be referred later when Eclipse plug in for android development will be installed.
There is a Eclipse plug in for Android development called ADT(Android Development Tools). It provides a comfortable environment for development and execution of android applications.
OSGi is standard/framework which can provide modularity to any java application. Its believed that there is lack of modularized development support in Java and some points sort of justify it. I’ll list few of them:
Low-level code visibility control
Java has very low level code visibility controls like private, protected, package, public. If you want any code in one package to view any code in another package then it needs to be declared as public which might expose certain functionality at other unwanted places. You either keep everything in same package or expose it through public methods but both has some trade offs.
Not so intelligent class path concept
Applications are generally composed of various versions of libraries and components. The class path does not deals with different versions in an intelligent way, it simply returns the first version that it finds. Even if it did pay attention, there is no way to explicitly specify dependencies.
Read more of this post
Continuous addition of code to the existing code base can make it unreadable and it needs re factoring and redesigning. There is no doubt regarding that. To redesign the code every time you add a functionality is not quite possible. Sometimes you allow small fixes to get in the existing code as patch with a promise that you will redesign it once more changes drop in.
So, how to manage the continuous inflow of sporadic changes here and there.
There is a trade off between the effort applied to redesign the code every time a functionality is added and the gain obtained from it. You cannot afford to spend twenty five percent of sprint in redesigning the application every time you inject something new.
I have been using JBoss Drools 5 in my project for a while. In the beginning we were not confident about how it will fit in the project. There were also doubts about the performance and maintainability of Drools Stuff.
So, to start with, we decided to implemented a small functionality using Drools. A big list of objects was passed to drools and some functionality was implemented with Drools. This resulted in setting up the infrastructure for Drools framework along with measuring Drools performance with a big set of data.
The best thing noticed was the readability of the logic. Had the same code been written in java, no matter how readable it would have been , the java code could never surpass the crispness and simplicity of the Drools code.
Reason being, Drools has certain features which saves some amount of java code to be written . Suppose you use 5 such features and then guess the amount of java code you just saved. This in turn increased the readability of the code.
The readability of the Drools code helped in transforming the business logic whenever needed. This tempted to add more business logic in Drools.
Read more of this post
I have been writing Junits for a while. Sometimes I feel proud of my junit tests as they really look meaningful. However, sometimes the junit tests look so ugly and pointless. I relate this difference to the Abstraction of the code.
Lets talk about abstraction first. Abstraction is generally governed by “separation of concerns”. Each unit of code should have a separate responsibility. These components are later integrated to perform certain functionality. So, if these separate components are tested separately, then its tested that each component is working perfectly.
Don’t confuse abstract with abstract keyword in java.
If a class is truly Abstract, then it handles only one responsibility. The sole purpose of the class is to perform a function which can not be broken down further into more non-trivial functions. In a junit test class for a truly abstract component (class), the test cases will be dedicated to test a fine grained module. So, it will be easier to concentrate on the functionality and more test scenarios cases can be thought upon.
This in turn increases the meaningfulness of the test code. The test case doesn’t need to bother about behavior of the dependencies. This will automatically decrease the time taken to write junit test cases.
Read more of this post
Unlike most of the people writing on Agile, I have only two and a half years of experience in software development. But that’s not the only unlikeness, unlike most of them, who were born in “The waterfall era”, when I was born in software industry, Agile was already quiet famous, and that’s the only software development process that I have worked upon. So, I am completely unbiased towards waterfall, I have just read and heard (from senior colleagues , both praises and slangs :)) about it .
I have seen people migrating from different development models in Agile. I have also seen few freshers (like me) being born in Agile era directly. And after a very short interval , almost all of them feel it’s a very comfortable and efficient way of software development. I agree too.
However, when you will read about Agile, re factor and rewrite will accompany it everywhere. Why So?
We all know that change is unavoidable and we must adapt ( so must re factor). But the amount of re factoring done in agile is awful. There has to be some reason behind that and I think its pair programming.
Lets see why I blame the pair programming:
- Generally people don’t think a lot while pair programming as the person who wants to think about the pros and cons will be considered inefficient (as he will slow down the coding speed). So, generally people show fake confidence on the effectiveness of the proposed solution. Some common comments will be (“We will change the code if problem occurs”). The re-factoring tasks generated due to this type of attitude is the outcome of pair programming only as no single person can be held responsible for the mess created.
- One of them suggests solutions very fast, which are always crap, and will always need a reimplementation . His pair has to find the loopholes in the proposed solution in almost no time. If not, he has to go with the proposed solution. (And it’s not necessary that the fastest solution will be the best one).
- Persons having aggressive and inhuman behavior will make their decisions accepted (even if his pair is having a better solution).
When two persons pair, the entire code flow is neither of them, as two persons can not think exactly same things at same time. So, the outcome is a spaghetti of their thoughts which will need re factoring for sure.