Author Archive

Author:
Thursday, March 24th, 2011

Problem

Most Java 2 Platform, Enterprise Edition (J2EE) applications have a search and query requirement to search and list certain data. In some cases, such a search and query operation could yield results that can be quite large. It is impractical to return the full result set when the client’s requirements are to traverse the results, rather than process the complete set. Typically, a client uses the results of a query for read-only purposes, such as displaying the result list. Often, the client views only the first few matching records, and then may discard the remaining records and attempt a new query. [From Sun Developer Network]

Solution:

Pagination is the process of dividing information (content) into discrete pages. Pagination can be handled client-side or server-side. Server-side pagination is more common. Below image show a simple pagination:

social

Consider 20 records are shown per page.  How many records you fetch from database? 20 or complete result set or 20X10=200? Ideally you should restrict the fetch size to 200 for better performance.

Code snippet of EmployeeSearchValueListHandler:

public class EmployeeSearchValueListHandler {
private Integer currentPage;
private List<EmployeeDto> searchResult = new ArrayList<EmployeeDto>();
private List<EmployeeDto> currentPageRecords = new ArrayList<EmployeeDto>();
private Integer firstPageNbr;
private Integer lastPageNbr;
private final Integer MAX_RECORDS_PERPAGE=20;
private final Integer MAX_PAGELINKS=10;
private boolean isNextClicked=false;
private boolean isPreviousClicked=false;
private Map searchParams=new HashMap();
public void reset(){
// set default value to properties
}
// set this value when the user click on the page nbr
public void setSelectedPage(Integer selectedPageNbr){
this.currentPage=selectedPageNbr;
setNextPageRecords();
}
public void setNextClicked(boolean isNextClicked){
this.isNextClicked=isNextClicked;
}
public void setPreviousClicked(boolean isPreviousClicked){
this.isPreviousClicked=isPreviousClicked;
}
private void setNextPageRecords() {
if (isNextClicked) {
// retrieve next set of records from database by passing searchParams and addAll rows to searchResult
firstPageNbr=currentPage+1;
lastPageNbr=firstPageNbr+searchResult.size()/MAX_PAGELINKS;
if(searchResult.size()%MAX_PAGELINKS>0){
lastPageNbr++;
}
}
}
public List<EmployeeDto> getCurrentPageRecords(){
currentPageRecords.clear();
for(int count=1;count<=MAX_RECORDS_PERPAGE && (currentPage*MAX_RECORDS_PERPAGE+count)<searchResult.size();count++){
currentPageRecords.add(searchResult.get(count));
}
return currentPageRecords;
}
}

Save the instance of EmployeeSearchValueListHandler in session scope and reuse the same. Remove this object from session when the user navigates to other page.

Category: Java  | One Comment
Author:
Wednesday, February 09th, 2011

 

This article briefly explains why documentation is required in development of software projects, what types of documents you should create and myth about agile documentation.

‘Working software over comprehensive documentation’ 2nd manifesto of agile software development (http://agilemanifesto.org/) .  In traditional approach, you will find most of documents shown in Fig-01 are created before the development phase (coding) starts.  The project starts with requirements phase, design phase etc each phase deliverables are just documents. Progress is ZERO until the coding phase starts. Documentation is not one time activity, you need to maintain it (update & reviewed) so more time & money spent.  Sometimes project fails due to hefty documentation i.e. exceeding project budget or delay in completion.

Do we need really need all the listed documents? NO, Travel light. We get more business value in working software than in comprehensive (broader in scope) documentation.  

waterfall-dox

Fig-01

 

Agile myth: Zero Documentation

Some believe that Agile doesn’t require (or, even, cannot support) documentation.  Agile manifesto never says documents are waste or not useful.  Agile documentation says: travel light (Write fewest documents), Just-in time, Update only when it hurts.  You may save time & cost without documents but the project may fail in long run i.e. when the project is given to another team for maintenance. In simple words, no projects should be developed without supporting documents.

Why Do People Document?

  • To support organizational memory

Working Software is Your Primary Goal.   An important implication is that we not only need to develop software, but we also need to develop the supporting documentation required to use, operate, support, and maintain the software over time. 

What type of documents do you need?

  1. Project Proposal

    Think about the environment before printing!

    Think about the environment before printing!

  2. Product Backlog: list of features to develop. Link features to use case doc
  3. Use case/User story/Feature Specs: covers
    1. Use case scenarios & screen prototype
    2. business rules & validation messages
    3. class diagram (nice to have)
  4. Design & Architecture document: consists of
    1. Technology, frameworks chosen for the projects
    2. Sequence diagram to explain execution flow
    3. Explanation on layers of architecture (mostly MVC2)
    4. How to develop & configure? Code snippets on view, controller, model, configuration files etc
    5. Non functional requirements
  5. Quality management:
    1. Defect tracker
    2. Functional test cases
  6. Build & Deployment document: covers
    1. System architecture/Deployment diagram
    2. Environment details e.g. IP details of DEV, TEST, UAT, PROD environments
    3. How to build & deploy?
    4. Labeling/Versioning strategy, SCM details
    5. Configuration Management details
    6. Post-deployment verifications
  7. Miscellaneous documents like
    1. Traceability matrix

I strongly encourage Product Owners to produce User Stories/Usecases/Functional Spec documents because they connect very deeply with the project, rest of the documents should be created & maintained by project team (Architects, Developers & Testers).

Also visit:

Category: Agile/Scrum  | 2 Comments