azizkhani.net

I know that I know nothing

50 Tricks for Faster Web Applications

clock November 25, 2012 13:05 by author Administrator

Jatinder Mann, an Internet Explorer PM at Microsoft, held the session 50 performance tricks to make your HTML5 apps and sites faster at BUILD 2012, providing many tips for creating faster web applications.

The advice provided by Mann was organized around six principles outlined below.

1. Quickly Respond to Network Requests.

  • Avoid Redirections. 63% of the top 1,000 websites use redirections. They could increase the speed of their pages by 10% by not performing a redirect.
  • Avoid Meta-refresh. 14% of the world’s URLs use meta-refreshes.
  • Minimize server response time by using CDNs located as close as possible to the user
  • Maximize the usage of concurrent connections by downloading resources from different domains
  • Reuse connections. Don’t close the connection when responding to a request.
  • Make sure data served by partner sites is not delaying page load
  • Understand the network timing components –Redirect, Cache, DNS, Request, Response, etc. –. Use the Navigation Timing API on IE 9&10 to measure the time spent by the browser on each operation.

2. Minimize Bytes Downloaded. Minimize the amount of data downloaded when a web page is loaded. The average website downloads 777KB of data out of which 474KB being images, 128KB scripts, and 84KB Flash.

  • Request gzipped content
  • Keep resources locally in packages, such as the Package Resource Index generated for the Windows Store apps. That way they are readily available when necessary.
  • Cache dynamic resources in HTML5 App Cache. This cache downloads the resources only once avoiding multiple network trips. The cache automatically re-downloads resources when the version of the application changes.
  • Provide cacheable content whenever possible by using the “Expires” field in the response.
  • Use conditional requests by setting the If-Modified-Since field of the request. 
  • Cache data requests –HTTP, XML, JSON, etc. – because about 95-96% of the requests don’t change over the day. Although a reasonable idea, less than 1% of the websites cache the requests received.
  • Standardize file naming capitalization. While a server may recognize Icon.jpg as icon.jpg, they are different resources for the web platform, generating different network requests.

3. Efficiently Structure Markup. For IE use the latest markup standardization since it is the fastest. Earlier IE6-IE9 markup styles are recognized by IE 10 but they are not as fast as the latest one.

  • Use the HTTP header field “X-UA-Compatible: IE=EmulateIE7” instead of the HTML tag <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"> to force IE run in a legacy mode that might be needed for certain business web applications. It’s faster that way.
  • Stylesheets should be linked at the top of the page inside the <head>, after the <title> in order to provide a smooth rendering.
  • Stylesheets should never be linked at the bottom of the page. The page may be flashing while loading.
  • Avoid “@import” for hierarchical styles because it synchronously blocks the creation of CSS data structures and screen painting.
  • Avoid embedded and inline styles because it forces the browser to make a context switch between the HTML and CSS parsers.
  • Only include the necessary styles. Avoid downloading and parsing style that won’t be used.
  • Link JavaScript only at the bottom of the page. This makes sure that the images, CSS, etc. are already loaded so the scripts can do they job without waiting on the resources, and avoiding context switching.
  • Do not link JavaScript in the head of the page. Use the “defer” attribute if some scripts must be loaded at the beginning.
  • Avoid inline JavaScript to avoid context switching.
  • Use the “async” attribute to load JavaScript to make the entire script loading and executing asynchronous.
  • Avoid duplicate code. 52% of the world’s web pages contain 100 lines or more of duplicate code such as linking a JavaScript file twice.
  • Standardize on one JS framework, be it jQuery, Dojo, Prototype.js, etc.. The browser won’t have to load multiple frameworks that provide basically the same functionality.
  • Don’t load scripts –FB, Twitter, etc. - just to be cool. They compete for resources.

4. Optimize Media Usage. Images are the most utilized resource, on average a website downloading 58 images.

  • Avoid downloading too many images, keeping their number to maximum 20-30 due to page load time.
  • Use image sprites to combine multiple images into one. This technique reduces the number of network connections, and the number of bytes downloaded and GPU cycles.
  • Create image sprites by hand because tools may leave large empty spaces leading to larger downloads and more GPU cycles.
  • Use PNG: best compromise between download size, decoding time, compatibility, and compression rate. JPEG may be used for photographs.
  • Use the native image resolution to avoid unnecessary bytes download and CPU processing for scaling.
  • Replace images with CSS3 gradients when possible.
  • Replace images with CSS3 border radius when possible.
  • Use CSS3 transforms to create move, rotate or skew effects.
  • Use Data URI for small single images. It saves an image download.
  • Avoid complex SVGs which require longer downloads and processing.
  • Specify an image preview when including an HTML5. The browser won’t have to download the entire video to figure out what the preview image should be.
  • Use HTML5 instead of Flash, Silverlight, or QuickTime. HTML5 is faster and the plug-in runtime takes system resources.
  • Proactively download rich media asynchronously and keep it in the app cache.

5. Write Fast JavaScript.

  • Use Integers when doing math operations in JavaScript, if possible. Floating point operations take much longer in JavaScript than their corresponding integer operations. Convert floating points into integers with Math.floor and Math.ceil, especially for computationally intensive operations.
  • Minify JavaScript code for smaller downloads and better runtime performance.
  • Initialize JS on demand. Load JS dynamically when needed.
  • Minimize DOM interactions by caching variable such as document, body, etc.
  • Use the built-in DOM code such as element.firstChild or node.nextSibling. They are highly optimized, better than what a third party library might provide.
  • Use querySelectorAll for accessing a large number of DOM elements.
  • Use .innerHTML to construct dynamic pages.
  • Batch markup changes.
  • Maintain a Small and Healthy DOM – maximum 1,000 elements.
  • JSON is faster than XML.
  • Use the browser’s JSON native methods.
  • Don’t abuse the usage of regular expressions.

6. Know What Your Application is Doing

  • Understand JavaScript timers: setTimeout and clearInterval. Don’t let timers run unless you use them for something. Also, combine timers.
  • Align timers to the display frame at 16.7 ms if the monitor refreshes at 60Hz.
  • Use requestAnimationFrame for animations to do graphics work in IE 10/Chrome/Firefox. It makes a call back when it is the time to paint, so there is no need for a timer.
  • Use the visibility API (document.hidden, Visibilityhange) to determine the visibility state of the application, and throttle down activity when the page is hidden. Saves CPU and battery life.

Mann recommended using Windows Performance Tools to measure the performance of web pages in IE and optimizing pages for less CPU time and increasing parallelism.

 



The Principles of Good Programming

clock November 23, 2012 13:56 by author Administrator

The principles of good programming are closely related to principles of good design and engineering. The following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient and to produce code which is easier to maintain and that has fewer defects.

DRY - Don’t repeat yourself. - Probably the single most fundamental tenet in programming is to avoid repetition. Many programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more). As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction.
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.”
http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal.
http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it.
http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design.
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplified
http://www.sensible.com/dmmt.html

Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend.
http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else.
A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.”
http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible.
http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task.
http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability”
http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion - Code that has similar functionality should be found within the same component.
http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component.
http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.)
http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" Knuth.
http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time.
http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code.
http://en.wikipedia.org/wiki/Separation_of_concerns

ref:http://area.autodesk.com/blogs/chris/the_principle_of_good_programming



Introduction To Scrum

clock November 23, 2012 13:46 by author Administrator

This post is an introduction to Scrum, one of the Agile methods to drive software application implementation. Reading this post is a prerequisite to this post.

Concepts

  • Scrum projects deliver software application features iteratively.
  • Each iteration is called a sprint.
  • Scrum projects have 4 stages:
    • Planning – Definition of the vision, budget, and expectations. The first version of the product backlog should containing enough implementation items for the first sprint.
    • Staging – This is the first iteration where the requirements and product backlog created in the planning are refined.
    • Development – It is the set of sprints required to implement the project fully. It ends when the product backlog is empty.
    • Release – The final product is deployed, training is performed, documentation is finalized, etc… The release backlog can be used as the product backlog for the next release of the product.
  • There are 4 main roles in scrum projects: team member, product owner, stakeholders and scrum master:
    • A product owner is a customer representative acting as a single point of contact on the customer side.
    • A stakeholder is anyone having a vested interest in the project, providing information about requirements and participating to the decision process of features to be implemented.
    • A scrum master is a facilitator and single point of contact on the development team side. It is a support function, not a ‘controlling chief’ role. It is a mix between a team leader and a software engineering role, which does not include people management or profit & lost responsibilities.
    • A team member is a software engineer.
  • Scrum of scrum can be implemented when multiple scrum teams are working on the same large project. Scrum master and product representatives get together.
  • The product backlog is a list of features, use cases, enhancement, defect, etc… to be implemented in the project’s forthcoming sprints.
  • The release backlog is the list of features, uses cases, enhancement, defect, etc… which are postponed to the next version of the project (not next sprint).

 
Practice

  • Spring teams typically do not have more than 7 members.
  • A sprint duration is 30 days.
  • Scrum projects are client-driven. They select the features to be implemented.
  • Each sprint begins with two meetings:
    • The stakeholder meeting, with the scrum master and customer representative to re-prioritize the product backlog and update the release backlog.
    • The product owner and team meeting where tasks are created from the product backlog.
  • Each task must require between 4 and 16 hours of work. Bigger tasks must be subdivided into smaller tasks.
  • The scrum master and product owner check whether there are enough resources to support the efforts required to achieve the sprint and adjust the workload accordingly.
  • Team member pick their tasks and work on their implementations.
  • Each spring finishes with a presentation of implemented features to the stakeholders.
  • Every day, a stand-up meeting (15-20 mins) with the team members and eventually the product owner is organized in front of a white board. The following is discussed:
    • Which tasks have been achieved since the last meeting?
    • Are there new tasks? New requirements?
    • What is blocking? Any impediments?
  • If decisions have to be taken, the Scrum Master should take them quickly, within an hour if possible
  • The Scrum Master should deal quickly with any impediments and communication issues
  • Scrum teams should preferably operate from the same room

 
Conclusion

As for all Agile methods, the Scrum approach is best suited for new projects created from scratch. Over time, when successive application releases are implemented, the project can slowly transform into a continuous integration or even maintenance project, where less stakeholders input or daily supervision is required. The cogs are well oiled and operate naturally.

Reference: Introduction To Scrum



ROW LEVEL SECURITY (BEST SOLUTION?)

clock October 25, 2012 19:21 by author Administrator

 

HELP ME
here might be special rows in a database which should only visible and accessible by users with special privileges. To avoid unnecessary round-trips, we currently modify the SQL queries to join with our authorization data to get only the visible rows for the current user.

But this concepts doesn't feel 'right' to me, because we mix business code with security related code which should be orthogonal and independent from each other.

 

  • What solutions are available/possible?
  • How do you implement row-level security (especially in combination with hibernate)?

The idea is that you can implement row level functionality in two ways: directly setting restrictions in your repository or binding the restrictions via AOP. The latter is preferred because security layer should be separated from business logic (orthogonal concerns).

 

In Hibernate you can use the concept of filters which are applied transparently and repository doesn't know about them. You can add such filters via AOP. The other way is intercepting session.createCriteria() and adding Restrictions to the Criteria transparently using AOP.

 



Spring and hibernate 4 integration

clock October 25, 2012 18:29 by author Administrator

add this dependancy

 

    <!-- Hibernate framework -->
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>4.1.4.Final</version>
        </dependency>
        <dependency>
            <groupId>javax.persistence</groupId>
            <artifactId>persistence-api</artifactId>
            <version>1.0.2</version>
        </dependency>
        <!-- end hibernate -->

 

and then change spring configuration like this

 



    <tx:annotation-driven transaction-manager="hibernateTransactionManager" />
    <bean id="dataSource"  class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName" value="${hibernate.connection.driver_class}" />
        <property name="url" value="${hibernate.connection.url}" />
        <property name="username" value="${hibernate.connection.username}" />
        <property name="password" value="${hibernate.connection.password}" />
    </bean>
    <bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="mappingLocations">
            <list>
                <value>/WEB-INF/classes/hibernate/**/*.hbm.xml</value>
            </list>
        </property>

        <property name="hibernateProperties">
            <props>
                <prop key="hibernate.connection.driver_class"> ${hibernate.connection.driver_class}</prop>
                <prop key="hibernate.connection.url"> ${hibernate.connection.url}</prop>
                <prop key="hibernate.connection.username"> ${hibernate.connection.username}</prop>
                <prop key="hibernate.connection.password"> ${hibernate.connection.password}</prop>
                <!-- <prop key="hibernate.connection.internal_logon"> ${hibernate.connection.internal_logon}</prop> -->
                <prop key="hibernate.dialect"> ${hibernate.dialect}</prop>
                <prop key="hibernate.show_sql"> ${hibernate.show_sql}</prop>
                <prop key="hibernate.hbm2ddl.auto"> ${hibernate.hbm2ddl_auto}</prop>
                <!-- <prop key="hibernate.default_schema"> ${hibernate.default_schema}</prop> -->
            </props>
        </property>
    </bean>

    <bean id="hibernateTransactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>

 

and now

 

package org.azizkhani.dao;

import java.util.List;

import org.azizkhani.core.QueryResult;

public interface IGenericRepository<T> {
    public List<T> getAll();
    public List<T> getAll(String where, String order, int pageNumber,int pageSize);
    public QueryResult<T> getAllGrid(String where, String order, int pageNumber,int pageSize);
    public T loadByEntityId(int entityId);
    public T single(String where);
    public void add(T entity);
    public void delete(T entity);
    public void deleteByEntityId(int entityId);
    public void update(T entity);
    public int count();
}

 

implementation

 

package org.azizkhani.dao.impl.hibernate;

import java.util.List;

import org.azizkhani.common.utility.HQLUtility;
import org.azizkhani.core.QueryResult;
import org.azizkhani.dao.IGenericRepository;
import org.hibernate.Criteria;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Transactional;

@Repository
public abstract class GenericRepository<T>  implements IGenericRepository<T> {
    protected Class<T> domainClass = getDomainClass();

    protected abstract Class<T> getDomainClass();
   
    @Autowired
    private SessionFactory sessionFactory;
   

    @Override
    public List<T> getAll() {
        Criteria criteria = getSession().createCriteria(domainClass.getName());
        return criteria.list();
    }

    public Session getSession() {
        try {
            return sessionFactory.getCurrentSession();
        } catch (Exception e) {
            System.out.println(e.getMessage().toString());
        }
        return sessionFactory.openSession();
    }

    public QueryResult<T> getAllGrid(String where, String order, int pageNumber, int pageSize) {
        Session session = getSession();
        StringBuffer jql = new StringBuffer("from " + domainClass.getName()
                + " e ");
        HQLUtility.toHQL(jql, where, order);
        Query query = session.createQuery(jql.toString());
        if (pageSize > 0)
        {
            query.setFirstResult(pageNumber * pageSize);
            query.setMaxResults(pageSize);
        }
        List<T> list = query.list();

        StringBuffer jqlCount = new StringBuffer("select count(*)  from "
                + domainClass.getName() + " e ");
        HQLUtility.toHQL(jqlCount, where, "");
        int count = ((Long) getSession().createQuery(jqlCount.toString())
                .uniqueResult()).intValue();

        return new QueryResult<T>(pageNumber, count, pageSize, list);
    }

    @Override
    public List<T> getAll(String where, String order, int pageNumber, int pageSize) {
        Session session = getSession();
        StringBuffer jql = new StringBuffer("from " + domainClass.getName()
                + " e ");
        HQLUtility.toHQL(jql, where, order);
        Query query = session.createQuery(jql.toString());
        if (pageSize > 0)
        {
            query.setFirstResult(pageNumber * pageSize);
            query.setMaxResults(pageSize);
        }
        return query.list();
    }
    @Transactional(readOnly=true)
    @Override
    public T loadByEntityId(int entityId) {
        return (T) getSession().load(domainClass, entityId);
    }

    @Override
    public T single(String where) {
        return null;
    }

    @Override
    public void add(T entity) {
        Session session = getSession();
        session.beginTransaction();
        session.save(entity);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public void delete(T entity) {
        getSession().delete(entity);
    }

    @Override
    public void deleteByEntityId(int entityId) {
        Session session = getSession();
        session.beginTransaction();
        Object obj = session.load(domainClass, entityId);
        session.delete(obj);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public void update(T entity) {
        Session session = getSession();
        session.beginTransaction();
        session.update(entity);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public int count() {
        int count = ((Long) getSession().createQuery(
                "select count(*) from " + domainClass.getName()).uniqueResult())
                .intValue();
        return count;
    }
}



 

 





creating and manipulating Microsoft Office(Word docx, Powerpoint pptx, and Excel xlsx) in java

clock October 25, 2012 18:03 by author Administrator

Create complex Word (.docx) documents programatically with docx4j

lvdpal's  Creating Word documents with Docx4j, which covers tables in some detail

Jos Dirksen's  Create complex Word (.docx) documents programatically with docx4j

Joshua Born's  Creating Word Documents in Java

Glen Smith's  Creating Word docx documents dynamically from Grails (or Java)

  Spring MVC (Russian)

java api

http://poi.apache.org/

http://www.docx4java.org/trac/docx4j



Decorator Design Pattern Case Study

clock October 24, 2012 22:36 by author Administrator



Decorator pattern is basically a way to extend functionality of an object by decorating with other objects which can wrap the target object and add their own behavior to it. If you never used or heard of decorators, I highly recommend reading chapter 3 of Head First Design Patterns.

Pretty much like other patterns mentioned in my posts before, JavaEE has an easy an elegant way to use the decorator pattern. Lets start with a simple stateless session bean.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService {
    
    public void startService(){
        System.out.println("do something important here...");
    }
}

To start implementing the decorator pattern, we need an interface so we can bind the decorators and the object to be decorated together.


package com.devchronicles.decorator;

/**
 *
 * @author murat
 */
public interface ServiceInterface {
    public void startService();
}

The interface has the method which the decorators will add functionality on. Next we need some changes on our existing EventService bean to make it decoratable.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService implements ServiceInterface{
    
    public void startService(){
        System.out.println("do something important here...");
    }
}


Now we are ready to add as much as decorator we need. All we need to do is to annotate our class, implement the ServiceInterface and to inject our service delegate.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator //declares this class as a decorator
public class DecoratorService implements ServiceInterface{ //must implement the service interface
    
    @Inject //inject the service
    @Delegate //and annotate as the delegate
    ServiceInterface service;

    @Override
    public void startService() { //implement the startService method to add functionality
        System.out.println("decorating the existing service!");
        service.startService(); //let the execution chain continue
    } 
}

Several decorators can be using the service interface.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator
public class Decorator2Service implements ServiceInterface{
     @Inject
    @Delegate
    ServiceInterface service;

    @Override
    public void startService() {
        System.out.println("decorating the service even further!!!");
        service.startService();
    }
}

Most of the configuration can be done via annotation in JavaEE6. However we still need to add some xml configuration to make decorators work. It might seem disappointing since we already annotated our decorators but still the configuration is pretty simple and needed in order to declare the order of execution. Add the following lines to the empty beans.xml.


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
           <decorators>
               <class>com.devchronicles.decorator.DecoratorService</class>
           <class>com.devchronicles.decorator.Decorator2Service</class>
           </decorators>
</beans>

When the startService method of our EventService is executed, the decorators will decorate the ejb and add their own behavior to the execution.

...

INFO: WEB0671: Loading application [Decorator] at [/Decorator]
INFO: Decorator was successfully deployed in 2,534 milliseconds.
INFO: decorating the existing service!
INFO: decorating the service even further!!!
INFO: do something important here...
...

Reference: JavaEE Revisits Design Patterns: Decorator



Factory Design Pattern Case Study

clock October 18, 2012 21:52 by author Administrator

I had a job to check our project code quality. And have to report it back to my team leader for any obstacle that i found in the project. I found a lot of leaks and i think would be good to be discussed on the blog. Not to mock the author, but to learn and improve ourselves together.

Like this code, this is the part that i found in our code.

 

public ContactInfoBean(final Reseller resellerInfo) {

       switch(resellerInfo.getType()) {

           case PROGRAM_CONTACT:
                   readExecutiveInfo(resellerInfo);
               break;
           case FILE_CONTACT:
                  readOperationalInfo(resellerInfo);
               break;
           default:

               break;

       }

   }

The code works fine, and do its job pretty well. But some problem will appear by using this code-style. This class will grow tailing the biz changes, as usual, the bigger one class, the “merrier” to maintain it is. And most likely this class, will be having more than one purpose, can be called low-cohesion.

Better OOP Approach

Well the better approach for the case above would be using the Factory Design Pattern. We can let the factory of READER to generate every single instance according to their type. It would be easier to grow the instance type, since we just need to create a new class and do a little modification in the Factory class. The caller class, wont grow and will stand still at its current shape.

public interface InfoReader {

      public void readInfo();

}


public class ExecutiveReader implements InfoReader {

      public void readInfo() {
           // override
      }

}

 


public class OperationalReader implements InfoReader {

        public void readInfo() {
         // override
        }

}

And The Factory

public class InfoReaderFactory {

      private static final int PROGRAM_CONTACT = 1;

      private static final int FILE_CONTACT = 2;

      public static InfoReader getInstance(Reseller resellerInfo) {

              InfoReader instance = null;

             switch (resellerInfo.getType()) {

                 case PROGRAM_CONTACT:

                       instance = new ExecutiveReader();

                    break;

                 case FILE_CONTACT:

                     instance = new OperationalReader();

                   break;

                default:

                    throw new IllegalArgumentException('Unknown Reseller');

      }

     return instance;

   }

}

And now The Caller

InfoReader reader = InfoReaderFactory.getInstance(resellerInfo);

reader.readInfo();


The Benefits

With the Factory Design Pattern to handle this case, we can achieve some benefits,

  • Specifying a class for one task, means, easier to maintain since one class is for one purpose only (modularity/High Cohesion). i.e: Operational Reader is only to read data for Operational only, no other purpose. Just in case, one day in the future we need another Reader (say: NonOperationalReader). We just need create a new Class that extends (or implements) the InfoReader class and then we can override our own readInfo() function. This Caller class will have no impact. We just need to do some modification in the Factory code.


public class InfoReaderFactory {
    private static final int PROGRAM_CONTACT = 1;
    private static final int FILE_CONTACT = 2;
    private static final int NEW_READER = 3;

    public static InfoReader getInstance(ResellerInfo resellerInfo) {
        InfoReader instance = null;
        switch (resellerInfo.getType()) {
          case PROGRAM_CONTACT:
              instance = new ExecutiveReader();
              break;
          case FILE_CONTACT:
              instance = new OperationalReader();
              break;
          case NEW_READER:
              instance = new NonOperationalReader();
              break;
          default:
              throw new IllegalArgumentException('Unknown Reseller');
        }
        return instance;
    }
}

Higher Reusability of Parent’s Component (Inheritance): Since we have parent class (InfoReader), we can put common functions and thingies inside this InfoReader class, and later all of the derivative classes (ExecutiveReader and OperationalReader) can reuse the common components from InfoReader . Avoid code redundancy and can minimize coding time. Eventhough this one depends on how you do the code and cant be guaranteed.


But, It’s Run Perfectly, Should We Change It?

Obviously the answer is big NO. This is only the case study and for your further experience and knowledge. OOP is good, do it anywhere it’s applicable. But the most important thing is, if it’s running, dont change it. It would be ridiculous if you ruin the entire working code just to pursue some OOP approach. Dont be naive also, no one can achieve the perfect code. The most important is we know what is the better approach.

 

 

ref:http://namingexception.wordpress.com/2012/10/17/case-study-factory-design-pattern/



linq order by desc and get first row

clock October 15, 2012 21:46 by author Administrator

SortedDictionary<int, int> result = new SortedDictionary<int, int>();

int max=result.OrderByDescending(t => t.Value).FirstOrDefault().Key;



Things Great Engineers (almost) Never Say

clock October 12, 2012 22:48 by author Administrator
  • “I’ve used _____ but I have no idea how it works”
    – Great engineers gained their skills through probing and curiosity.  They go ‘under the hood’ of the products they use just to understand how things work, even if that information will never be very useful to them.  It is unclear whether this need to dig deeper is a choice or a compulsion, but it seems that it is a trait of the best talent.
  • “______ works, I just don’t know how to explain it”
    – Not only do the greats know how things work, but most of them derive genuine pleasure in telling others why and how things workThis is often true even if the other person doesn’t care to know.  Over the course of my career I’ve listened to engineers talk for thousands of hours, and in almost all cases my conversations with the most talented go much longer.  I actually made a point of scheduling an extra fifteen to twenty minutes on my calendar when I will be speaking to someone who appears to be great on paper, as I know that the person will go deep into some technical details and nuances that will come up in conversation.
  • “I will need ______ (tool/condition) to complete this task”
    – The masters of development will have the ability to improvise and adjust on the fly to arrive at a solution in non-ideal conditions.  When you hear of engineers being compared to MacGyver they are speaking of this very rare skill.  Greats will figure out a way based on minimal resources and will be aware of alternatives to their first choice of tool.
  • “I’ve learned all I want/will ever need to know about ________ “
    – Continuous learning and improvement is probably the most obvious differentiation between the good and the great.  They don’t just get to a high level and then rest.  The best engineers understand that industry progress causes them to never stop learning, and if they are not gaining enough new knowledge in their day jobs they will invest the time to learn during off hours.
  • “There is no solution” – The greats will continue looking at a problem different ways to come up with an answer instead of conceding.  This characteristic can be both a blessing and a curse.
  • “I hate programming” - At times a great engineer will hate their job or employer, but their love of solving problems with code is what brought them to this skill level.
  • “I’m an expert in _____” (when it’s not true, and even sometimes when it is true) – The strongest engineers have no need or desire to lie or exaggerate the depth of their skills.  Much of the great talent will be reluctant to say they are an expert in anything, as they are aware others could know more.
  • “I don’t understand the business” – The stronger engineers will always want to know how their code impacts the employer and is able to describe their contribution and value to the organization.
  • “I don’t pay particular attention to industry trends” – Being both great and relevant (in demand) is only possible if you keep an eye on where the industry is headed.  When speaking to talented engineers, the topic of which new technologies are actually viable and which are a passing phase will often come up.

If you find yourself using any of these lines on a regular basis, give some thought to why.  Quoting one of these lines in a job interview could be a serious mistake.

 

 

Reference: Things Great Engineers (almost) Never Say



About the author

 Welcome to this web site . This page has two purposes: Sharing information about my professional life such as articles, presentations, etc.
This website is also a place where I would like to share content I enjoy with the rest of the world. Feel free to take a look around, read my blog


Java,J2EE,Spring Framework,JQuery,

Hibernate,NoSql,Cloud,SOA,Rest WebService and Web Stack tech...

RecentPosts

Month List

Sign In