Posted by vikashazrati on Wednesday, June 24, 2009
For the entire project
- Go to menu Window > Preferences
- In the dialogue that appears, select Installed JREs
- Select your JRE, and click Edit. A new dialog opens.
- Enter -ea under Default VM Arguments
- Click Ok to save the change.
For a particular program execution
- Open the Run Dialog (this should be an option under the “Run” menu).
- Click on the tab, “(x)= Arguments.”
- In the field for “VM arguments,” enter -ea to enable assertions.
- Click on the “Apply” button.
Posted in Java | Leave a Comment »
Posted by vikashazrati on Thursday, June 11, 2009
We have a legacy application and a lot of presentation code is written using Struts 1.2.4. For unit tetsing the action classes we used the following approach.
StrutsTestCase provides both a Mock Object approach and a Cactus approach to actually run the Struts ActionServlet, allowing you to test your Struts code with or without a running servlet engine. When you want to execute your tests as a part of the continuous integration environment in which all the unit tests should execute without deploying the application to the container.
For the following entry of Struts-config.xml
<action path="/login" type="com.dnbi.simpleaction.LoginAction" name="loginForm" input="/login/login.jsp" scope="request">
<forward name="success" path="/action/simpleAction" />
<forward name="failure" path="/failurePath" />
</action>
and for the following action,
public class LoginAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) {
ActionErrors errors = new ActionErrors();
String username = ((LoginForm) form).getUsername();
String password = ((LoginForm) form).getPassword();
if ((!username.equals("vikas")) || (!password.equals("pass")))
errors.add("password", new ActionError("error.password.mismatch"));
if (!errors.isEmpty()) {
saveErrors(request, errors);
return new ActionForward(mapping.getInput());
}
HttpSession session = request.getSession();
session.setAttribute("authentication", username);
return mapping.findForward("success");
}
the test would look like this
Read the rest of this entry »
Posted in Better Software, Java, testing | Leave a Comment »
Posted by vikashazrati on Friday, June 5, 2009
So this one completes the hat-trick on blogs related to differences in succession.
Today during our discussion about defining service orchestrations we came up with the argument about the difference between Encapsulation and Information hiding. I cover abstraction here as a bonus
Abstraction – in a nutshell is making visible what you want the external world to see and keeping the other details behind the wraps. Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. It hides the complexity. It is a technique by which we decide what information to hide and what to expose.
Information hiding - is making inaccessible certain details which would not affect other parts of the system. Just hiding it so that it is not exposed.
Encapsulation - is like enclosing in a capsule. That is enclosing the related operations and data related to an object into that object.If encapsulation was “the same thing as information hiding,” then one might make the argument that “everything that was encapsulated was also hidden.” This is obviously not true. For example, even though information may be encapsulated within record structures and arrays, this information is usually not hidden and is available for use. Encapsulation is just getting a set of operations and data together which belong together and putting them in a capsule.
Abstraction, information hiding, and encapsulation are different but related. Abstraction is a technique that helps us identify which specific information should be visible, and which information should be hidden. Encapsulation is the technique for packaging the information in such a way as to hide what should be hidden, and make visible what is intended to be visible. Encapsulation can be thought of as the implementation of the abstract class.
Posted in Architecture | 1 Comment »
Posted by vikashazrati on Thursday, June 4, 2009
There is enough confusion and debate about what is the best model for publishing from a CMS based system. Some advocate the pull model and others the push model based on the ability to scale and be more reliable.
Let us see the pros and cons of these
Pull
- Suited for highly dynamic content
- Suitable for situations in which you want to feed content based on personlization.
- Pull CMS must be used with caching for ensuring faster reads and content independence.
- Can feed data on demand and does not need time based or trigger based push mechanism
Push
- Content Independence – if the CMS engine or database is unavailable the site could be down but with push, users would not know
- Pull CMS with it’s server side scripting language and database requirements could place a higher load on a server than a Push CMS, at least during heavy usage hence Push would be useful for static content with a lot of reads.
- Is server independent, it can push a set of HTML files in a web server independent format for consumption
- Should have a schedule based or trigger based push mechanism
Theoretically, one can achieve push benefits by using pull+caching and hence all the benefits and dynamicity of pull come along with it.
Any page with the need of frequent updates such as real time statistics, user comments, automated relevant links and a host of other things would become stale pictures of the “baking” moment in a push environment such as described.
- Information on push
- Comparison between push and pull
Posted in Architecture | Leave a Comment »
Posted by vikashazrati on Tuesday, June 2, 2009
In our production environment we had to review and replicate all the CRON jobs running on one of the stacks to the other new stack. Since the stack consists of multiple nodes clustered together running Jboss and another cluster of tomcat nodes, we would have to collect the details from all the servers.
By definition CRON has a single-tier architecture. This means that it is running as a single process on a single machine without any agents or server to communicate with. It also means that each instance of CRON is isolated and a problem in one of the instances on one of the machines would not affect others. This prevents it from becoming a SPOF (Single point of failure) but increases the maintenance and data aggregation overhead. Any changes have to be installed on all the nodes instead of a central machine. Therefore, each scheduler must reside on its own machine and contain its own database. Since there is no integration between the schedulers on the various machines, it is not possible to transfer jobs from one machine to the other, even if one machine has a heavy workload.
To view all the cron jobs on a machine by a user use
- crontab -u exampleuser -l
You can create a cron job from that file as follows:
- crontab /tmp/my_cron_jobs.txt
(Or for exampleuser:
- crontab -u exampleuser /tmp/my_cron_jobs.txt
For more information on creating and editing a cron job refer this and this.
Control-M by BMC software, takes the scheduling and execution of jobs at a higher level of abstraction where in all the jbos can be defined on multiple nodes using a central console. The results would be available on the central dashboard and can be tracked. Alerts are generated from the central location. There is failover support too.
For more differences between Control-M and Cron, refer to this pdf.
Posted in General, linux | Leave a Comment »
Posted by vikashazrati on Tuesday, April 28, 2009
Read these interesting series of motivational thoughts, I would keep updating this post as I stumble upon others

If I am good I could add years to my life
I would rather add some life to my years
And life is really what you make it they say
I can’t even make my mind up today
- Spiritualized,
Bob Parson’s founder of Go Daddy!
Posted in Business | Leave a Comment »
Posted by vikashazrati on Sunday, April 26, 2009
If you have been like eagerly installed the latest distribution of Ubuntu which was available a couple of days back then welcome to the party of misbehaving wireless connections.
The Ubuntu version 9.04 was released publically on April 23rd and is called the Jaunty Jackalope. Given the cool features it was a high priority on my update list.
After I updated my wireless connection started dropping at frequent intervals of 5-10 minutes and this was enough to frustrate me. At first I thought it was due to a heavy download that I had initiated but the problem persisted even when i paused the download.
Next step was to explore the Internet to see how many other people were facing the issue. Not many but some. But, none is close to the problem that I am facing.
So this is what I did,
I changed the grub order of menu.lst to load an earlier version of the kernel to see if the problem went away. First, I loaded the
title Ubuntu 9.04, kernel 2.6.24-16-generic version by changing the default boot order to 8
i.e in the menu.lst look at the following section and change the highlighted portion
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify ’saved’ instead of a number. In this case, the default entry
# is the entry saved with the command ’savedefault’.
# WARNING: If you are using dmraid do not use ’savedefault’ or your
# array will desync and will not let you boot your system.
default 8
Read the rest of this entry »
Posted in linux | 5 Comments »
Posted by vikashazrati on Monday, April 20, 2009
In Part-I of this series we looked at what non-functional requirements were and how different people react to non-functional requirements.

Ask any team what do we mean by NFRs and most probable answer would be the following and most probably in the order mentioned below
- Performance
- Scalability
- Availability
- Security
- Maintainability
- Reliability
If you come up with a different list on your first pass when asked about NFRs, let me know.
The NFRs which would generally give the biggest bang for your buck are Performance, Scalability, Reliability and Availability. Once you have taken care of these I would recommend looking at the others like Security, maintainability, re-usability, usability etc.
So lets us look at them one by one
Read the rest of this entry »
Posted in Agile, Architecture, Better Software, Java | 1 Comment »
Posted by vikashazrati on Thursday, April 16, 2009
WikiPedia defines the NFRs as

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.
In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints“, “quality attributes”, “quality goals” and “quality of service requirements”. Qualities, that is, non-functional requirements, can be divided into two main categories:
- Execution qualities, such as security and usability, which are observable at run time.
- Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.
Many people would turn their head in anguish on the mention of Non Functional Requirements primarily because of 2 reasons
Read the rest of this entry »
Posted in Agile, Better Software | 1 Comment »
Posted by vikashazrati on Thursday, April 16, 2009
This is one of the frequent questions asked in Agile adoption. I have worked on a project with 135 developers and as expected it was not going anywhere until someone thought that it was death march to proceed in that way. The team was downsized to 60. The process was changed to Scrum. 6 teams of 10 people each were individual scrum teams. But again within this team of 60 people dispersed across 4 geographic locations coordination and communication was still a challenge.
The “silverish bullet” came in the form of dividing the 6 scrum teams to collocated teams of smaller sizes. So the teams were distributed further with each team now having between 5-8 people. The crux was collocated on the same geography. Of course team communication cannot be ruled out hence one member from each team also met in a Scrum of Scrums fashion. Though the teams were drinking from the same backlog, however the sprint backlog for the teams was decided during the sprint planning meeting. The Sprint backlog were kept as much mutually exclusive as possible, but again SoS (Scrum of Scrums) helped for the rest.
So far it has been working for us. But still, what is the ideal team size? People would mention anything between 3-20! Some Agilists argue that the team size should be FIVE. This is the common denominator number based on various studies and falls on the intersection point of these studies. Want to read more about this magic # 5. Refer my post on InfoQ.
What have been the team sizes that have worked for you and how has that environment been any different from any other environment?
Posted in Agile | Leave a Comment »