Features

• Easy Maven integration: the project is published on Maven Central so you can easily add it as a Maven dependency
• Easily create new Selenium tests by extending a base class which incorporates all the required logic to configure a WebDriver instance
• Utility methods to interact with DB
• Enhances the WebDriver API with new methods
• Utility methods to interact with Excel files
• Utility methods to interact with text files and XML files
• Utility methods to use XMLs over HTTP (make WebService calls for example)
• Easily control different WebDriver instances and configuration through properties
• Get screenshots when Selenium tests are failing

In order to get the most out of Selenium on Steriods you must write your Selenium tests using the JUnit framework.

Getting started

https://github.com/ludovicianul/selenium-on-steroids/wiki/getting-started

Changelog

https://github.com/ludovicianul/selenium-on-steroids/wiki/changelog

Homepage

http://insidecoding.com/selenium-on-steroids/

Wiki

https://github.com/ludovicianul/selenium-on-steroids/wiki

Issue Tracker

https://github.com/ludovicianul/selenium-on-steroids/issues

License

The Apache Software License, Version 2.0

As promised in the previous article I’ll continue presenting Google Guice also for web applications. In order to do this you’ll need to get the servlet extension – part of the standard distribution, along with other extensions like JMX, JNDI, Persist, Struts or Spring. Using Guice, the web.xml will be reduced at minimum – just make the Guice container start. The rest of the configurations will be easily done in Java in the same type-safe manner presented in the previous article.

The servlets will benefit from:

• Constructor injection
• Type-safe configuration
• Modularization
• AOP

In this article I’ll present the following scenarios:

• Developing a web application from scratch
• Adding Guice to an existing web application

Starting a new web application using Guice

Check the bellow image for an Eclipse screenshot with the project structure.

Besides the core Guice libraries presented in the previous article, we must also add the guice-servlet.jar in the application’s classpath (please check the end of the article for the Maven dependency).

After the classpath is properly configured, we must first define the Guice Filter in web.xml. This will actually be the only configuration present in this file.

This is the web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app 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/web-app_3_0.xsd"
       version="3.0">
       <display-name>Guice Web</display-name>
       <filter>
              <filter-name>guiceFilter</filter-name>
              <filter-class>com.google.inject.servlet.GuiceFilter
</filter-class>
       </filter>
       <filter-mapping>
              <filter-name>guiceFilter</filter-name>
              <url-pattern>/*</url-pattern>
       </filter-mapping>
</web-app>

We are sure now that all requests will be processed by Guice.

Next step is creating the Injector and defining the Modules. Besides the “normal” modules used by an application – presented in the previous article – in order to actually use the Guice Servlet module we must declare an instance of com.google.inject.servlet.ServletModule. This Module is responsible for setting the Request and Sessions scopes and this is the place where we’ll configure the servlets and filters within the application.

Considering that we write a web application, the most logical and intuitive place to create the Injector is within a ServletContextListener. A ServletContextListener is a component that fires just after the application is deployed and before any request received by the server. Guice comes with its own class that must be extended in order to create a valid injector. As we’ll use Servlet 3.0 API we’ll annotate this class with @WebListener – we won’t need to declare it in web.xml.

I was saying that the ServletModule is the place where we configure our servlets and filters. This is the content of the class that it will extend this module. It will configure a servlet mapped to all the .html requests:

package com.insidecoding.samples.guice.modules;

import com.insidecoding.samples.guice.servlet.MyServlet;

import com.google.inject.servlet.ServletModule;

public class MyServletModule extends ServletModule {

       @Override
       protected void configureServlets() {
              serve("*.html").with(MyServlet.class);
       }
}

The ServletContextListener:

package com.insidecoding.samples.guice.listener;

import javax.servlet.annotation.WebListener;

import com.insidecoding.samples.guice.modules.MyServletModule;

import com.google.inject.Guice;
import com.google.inject.Injector;
import com.google.inject.servlet.GuiceServletContextListener;

@WebListener
public class MyGuiceConfig extends GuiceServletContextListener {

       @Override
       protected Injector getInjector() {
              return Guice.createInjector(new MyServletModule());
       }

}

Please note inside the getInjector() method the creation of the Injector based on the servlet module defined before. If the application has many other modules all of them must be declare here.

Also, you can see how intuitive the declaration of the servlet mapping is.

This is the MyServlet class:

package com.insidecoding.samples.guice.servlet;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.insidecoding.samples.guice.service.MyService;

import com.google.inject.Inject;
import com.google.inject.Singleton;

@Singleton
public class MyServlet extends HttpServlet {

       private static final long serialVersionUID = 1861227452784320290L;

       @Inject
       private MyService myService;

       protected void service(HttpServletRequest request,
                     HttpServletResponse response) 

throws ServletException, IOException {
              response.getWriter().println(
                           "Service: " + myService.doStuff());
       }
}

Let’s analyze this code:

1. A servlet must be a singleton – mark it using the @Singleton annotation – otherwise the application will throw an Excepton
2. We use field injection in order to get a MyService instance
3. The class extends HttpServlet just like any other servlet

The MyService interface:

package com.insidecoding.samples.guice.service;

import com.google.inject.ImplementedBy;

@ImplementedBy(MyServiceImpl.class)
public interface MyService {

       String doStuff();
}

And its implementation:

package com.insidecoding.samples.guice.service;

public class MyServiceImpl implements MyService {

       @Override
       public String doStuff() {
              return "doing stuff!";
       }

}

The application is ready to be deployed. This is the result of calling index.html:

Integrating Guice into an existing web application

In order to integrate Google Guice into an existing web application we must make sure that everything is in place:

• The required jar are in classpath
• The Guice filter is defined in web.xml
• We have a ServletContextListener that extends GuiceServletContextListener

At this stage, all these configurations will not have any impact on the application – everything will work as before.

We can have 2 directions:

• Use Guice only for new things – of course, this is not a best practice, but this is a normal scenario for big applications with legacy code
• Guicefy the entire application – ideal case

For the second case you must follow the same path presented in the first part of the article.

For the first case we’ll end up using DI in servlet classes that are not instrumented by Guice. We can access the Injector instance using the ServletContext:

Injector injector = (Injector) request.getServletContext().getAttribute(Injector.class.getName());

In order to get all the dependencies injected you can:

1. Call injector.injectMembers(this) –this will inject all the dependencies
2. Call injector.getInstance(clazz) for each instance that needs to be injected

Request and Session scope

The servlet extension adds 2 new scopes: Request and Session. We’ll see next an example of using the Session scope.

We’ll slightly modify some of the classes presented before. Considering that we’ll need to mix scopes and we want to access an object with a narrower scope from an object with a wider scope (access a Session scoped object from a Singleton) we’ll use Providers (see the Note section for details).

The servlet module will look like this:

package com.insidecoding.samples.guice.modules;

import com.insidecoding.samples.guice.provider.PojoProvider;
import com.insidecoding.samples.guice.servlet.MyServlet;
import com.insidecoding.samples.guice.servlet.PojoClass;

import com.google.inject.servlet.ServletModule;
import com.google.inject.servlet.ServletScopes;

public class MyServletModule extends ServletModule {

       @Override
       protected void configureServlets() {
              serve("*.html").with(MyServlet.class);

              bind(PojoClass.class).toProvider(PojoProvider.class).in(
                           ServletScopes.SESSION);
       }
}

Please note the ServletScopes.SESSION binding.

The PojoProvider class:

package com.insidecoding.samples.guice.provider;

import com.insidecoding.samples.guice.servlet.PojoClass;

import com.google.inject.Provider;

public class PojoProvider implements Provider<PojoClass> {

       public PojoClass get() {
              return new PojoClass();
       }

}

The PojoClass class:

package com.insidecoding.samples.guice.servlet;

public class PojoClass {

       private String name;

       public void setName(String s) {
              this.name = s;
       }

       public String getName() {
              return this.name;
       }
}

In order to prove that the application is actually working, we’ll modify the MyServlet class to display additional information:

package com.insidecoding.samples.guice.servlet;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.insidecoding.samples.guice.service.MyService;

import com.google.inject.Inject;
import com.google.inject.Provider;
import com.google.inject.Singleton;

@Singleton
public class MyServlet extends HttpServlet {

       private static final long serialVersionUID = 1861227452784320290L;

       @Inject
       private Provider pojoClass;

       @Inject
       private MyService myService;

       protected void service(HttpServletRequest request,
                     HttpServletResponse response) 

throws ServletException, IOException {
              response.getWriter().println(
                           "Service: " + myService.doStuff() + " with ");
              if (pojoClass.get().getName() == null) {
                     pojoClass.get().setName("name");
              } else {
                     pojoClass.get().setName("existing name");
              }
              response.getWriter().println(pojoClass.get().getName());
       }
}

In order to demo the functionality we’ll access the application twice in the same session. The first time it will display the below result:

The second time it will display the following result:

This example can be easily changed in order to use Request scope instead of Session scope.

This is how a simple Guice web application looks like. I tried to touch the most important points from the Guice Servlet extension. As mentioned in the previous article, this is just a small intro. You can continue experimenting different situations and you’ll learn the most by actually using Guice into a real project.

Notes

Guice as a Maven dependency

<dependency>
 <groupId>com.google.inject</groupId>
 <artifactId>guice</artifactId>
 <version>3.0</version>
 </dependency>

Providers

Providers address the following situations:

-          A client needs more instances of the same dependency per injection

-          A client wants to get the dependency when it will actually use it (lazy loading)

-          You want to inject a narrower scoped object into a wider scoped object

-          Additional logic is needed in order to create the object being injected

-          You want to control the process of creating instance per binding

As you can see in the previous examples, it is very easy to write a Provider. You just need to implement the Provider<T> interface, where T is the concrete type of the object being injected.

Recommendations:

Automating the Code Review process

You can split the Code Review process into 2 parts: the Low Level part (styling, code duplicate, naming conventions, etc) and the High Level part (architecture, design, business).

Starting from a Coding Standards document, you can easily automate the Low level part of the Code Review process. The automation tools for Code Review will eliminate most of the styling issues, naming conventions, cyclomatic complexity, duplicate code, code coverage, etc. They can’t though detect major design issues, architectural flaws or project specific functionality and this is where the reviewer skills are the most important. I’ll present below the most used tools for Java projects.

Sonar

Each time you talk about Code Quality in the Java world there are very high chances that Sonar is mentioned one way or another in the discussion. Sonar aggregates and displays code quality metrics on a web site allowing drilling down to the source code to view the details of violations. Sonar’s main purpose is to display the metrics in a nice visual manner and uses various plugins to produce these code quality metrics. All the below tools integrate with Maven, Ant and are also available as Eclipse plugins. In order to get the same set of rules for both Sonar and these Eclipse plugins, Sonar publishes the rules for PMD, Checkstyle and Findbugs associated to a specific profile. You can easily link to them from your Eclipse plugins.

Make sure you save all these files as separate XML files: findbugs.xml, checkstyle.xml and pmd.xml.

PMD

PMD is a source code analyzer. It finds unused variables, empty catch blocks, unnecessary object creation, and so forth.

This is the official page: http://pmd.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse: http://pmd.sourceforge.net/pmd-5.0.0/integrations.html#eclipse. Unfortunatelly the Eclipse plugin is not actively supported and some rules are not recognize by it. In order to fix this you must do the following:

• Save the PMD rules from Sonar as an XML file
• Delete the following rules from the file: GuardDebugLogging, GenericsNaming, DontCallThreadRun, AvoidLiteralsInIfCondition, AvoidCatchingGenericException, AvoidLosingExceptionInformation

After doing this you can proceed with the next steps.

• Access Window->Preferences
• Expand PMD
• Click on Rules Configuration

In order to import the Sonar rule set you must do the following:

• First click on the Clear All button in order to remove all the existing rules
• Click on the Import Rules button and select the pmd.xml file you just modified.

An alternative to this is to disable these 6 rules in Sonar and import the ruleset from the published URL. In this way you have all the other rules in sync.

Cobertura

Cobertura is a free Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage.

This is the official page: http://cobertura.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse: http://ecobertura.johoop.de/.

Since Sonar 3.2 Cobertura is not the default code coverage tool anymore. JaCoCo is the new default.

Checkstyle

Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

This is the official page: http://checkstyle.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse: http://marketplace.eclipse.org/content/checkstyle-plug#.UFggAI3iZSo.

You can configure the Checkstyle Eclipse plugin to use the Sonar published rules as follows:

• Open Window->Preferences->Checkstyle
• Click on New
• Choose Remote Configuration from the Type drop-down
• Enter the permalink URL from Sonar
• Click OK after
• Set the profile as default

Findbugs

Findbugs is a program which uses static analysis to look for bugs in Java code.

This is the official page: http://findbugs.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse:

http://findbugs.cs.umd.edu/eclipse/

In order to import the Sonar findbugs tules into Eclipse you must do the following:

Choose the findbugs.xml you saved previously and make sure you select the checkbox in order to enable the rules.

JaCoCo

JaCoCo is a free code coverage library for Java, which has been created by the EclEmma team based on the lessons learned from using and integration existing libraries over the last five years.

This is the official page: http://www.eclemma.org/jacoco/.

This is the default code coverage library since Sonar 3.2.

For example, in order to use JaCoCo as the code coverage tool you must include the following properties in your pom file:

<sonar.dynamicAnalysis>true</sonar.dynamicAnalysis>
<sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>

More details here: http://docs.codehaus.org/display/SONAR/Code+Coverage+by+Unit+Tests.

Squid

Squid is part of the Sonar core plugin. More details here:

http://www.sonarsource.org/detect-dead-code-and-calls-to-deprecated-methods-with-sonar-squid/

More about Sonar

Sonar offers out of the box support for Java. No additional configuration is needed.

Sonar will use all the above tools in order to display the Code Quality metrics. This is a high level overview of the Sonar architecture:

Although this article presents the default just some of the plugins, Sonar can be further enhanced in order to display additional information using plugins. Additional plugins can be found here: http://docs.codehaus.org/display/SONAR/Plugin+Library.

You can get the Sonar violations directly into Eclipse. You can find here: http://docs.codehaus.org/display/SONAR/Installing+Sonar+in+Eclipse how to install Sonar for Eclipse and here: http://docs.codehaus.org/display/SONAR/Configuring+Sonar+in+Eclipse how to configure it.

You can also find more info about Sonar for Eclipse here: http://docs.codehaus.org/display/SONAR/Using+Sonar+in+Eclipse.

Monitoring the Code Review process

Until now I presented advises about what to pay attention on when implementing a Code Review process within a project and how you can automate a part of the process, allowing the reviewer to focusing on the important things like design, architecture and business requirements.

What’s the best way to track the review progress: through emails, excel files, just talking or using specialized tools? Although the obvious answer is specialized tools, each team has its own particularities. Usually each team will found its own mechanic when dealing with reviews:

• You can have a rule that no one does a commit until another colleague will review the code
• Each team member will check all the commits when doing an update
• You have a person assigned per day/sprint/iteration that does the code review for everyone
• You do peer code review
• You have a dedicated that does the review team formed only by senior and architects

If you are in an environment where you already use Atlassian tools (JIRA, Confluence, FishEye), the wise choice is Crucible as it integrates with the whole stack of Atlassian products. Currently I think this is the best tool for keeping track of code reviews.

There are also other choices like: Gerrit (dedicated to Git projects) or ReviewBoard.

Recommandations

Please also read Code Review Guidelines Part 2.

What is a Code Review?

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

Why Reviews are important?

Quoting from Code Complete: A Practical Handbook of Software Construction, Second Edition

.. software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:

• In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
• In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
• The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
• IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
• A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
• Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.

The main goals of code review are:

1. To spot and fix defects early in the process.
2. Better-shared understanding of the code base as team members learn from each other
3. Helps to maintain a level of consistency in design and implementation.
4. Helps to identify common defects across the team thus reducing rework.
5. Builds confidence of stakeholders about technical quality of the execution.
6. Uniformity in understanding will help interchangeability of team members in case of non-availability of any one of them.
7. A different perspective. “Another set of eyes” adds objectivity. Similar to the reason for separating your coding and testing teams, peer reviews provide the distance needed to recognize problems.
8. Pride/reward. Recognition of coding prowess is a significant reward for many programmers.
9. Team cohesiveness. Working together helps draw team members closer. It also provides a brief respite from the isolation that coding often brings.

Let’s see how important is to fix potential defects from the development phase:

The main areas a reviewer is focusing on are as follows:

• General Unit Testing
• Comment and Coding Conventions
• Error Handling
• Resource Leaks
• Thread Safety
• Control Structures
• Performance
• Functionality
• Security
• Compliance with existing Design & Architecture
• Proper use of 3rd party libraries

Roles and Responsibilities

1. Developer: is the person who has written the code to be reviewed and has initiated the review request.
2. Reviewer/s: are the people who are going to review the code and report the findings to the developer.

Tips for the Developer:

1. The primary reviewer is the author i.e. YOU.
2. Create a checklist for yourself of the things that the code reviews tend to focus on. Some of this checklist should be easy to put together. It should follow the outline of the coding standards document. Because it’s your checklist, you can focus on the thing that you struggle with and skip the things that you rarely, if ever, have a problem with. Run through your code with the checklist and fix whatever you find. Not only will you reduce the number of things that the team finds, you’ll reduce the time to complete the code review meeting—and everyone will be happy to spend less time in the review.
3. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
4. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
5. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
6. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
7. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
9. Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Please note that Review meetings are NOT problem solving meetings.
11. Help to maintain the coding standards. Offer to add to the coding standards for things discussed that aren’t in the coding standards. One of the challenges that a developer has in an organization with combative code review practices is that they frequently don’t know where the next problem will come from. If you document each issue into the coding standards, you can check for it with your checklist the next time you come up for code reviews. It also will help cement the concept into your mind so that you’re less likely to miss opportunities to use the feedback.

 Tips for the Reviewer

1. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
2. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
3. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
4. Please note that Review meetings are NOT problem solving meetings.
5. Ask questions rather than make statements. A statement is accusatory. “You didn’t follow the standard here” is an attack—whether intentional or not. The question, “What was the reasoning behind the approached you used?” is seeking more information. Obviously, that question can’t be said with a sarcastic or condescending tone; but, done correctly, it can often open the developer up to stating their thinking and then asking if there was a better way.
6. Avoid the “Why” questions. Although extremely difficult at times, avoiding the”Why” questions can substantially improve the mood. Just as a statement is accusatory—so is a why question. Most “Why” questions can be reworded to a question that doesn’t include the word “Why” and the results can be dramatic. For example, “Why didn’t you follow the standards here…” versus “What was the reasoning behind the deviation from the standards here…”
7. Remember to praise. The purposes of code reviews are not focused at telling developers how they can improve, and not necessarily that they did a good job. Human nature is such that we want and need to be acknowledged for our successes, not just shown our faults. Because development is necessarily a creative work that developers pour their soul into, it often can be close to their hearts. This makes the need for praise even more critical.
8. Make sure you have good coding standards to reference. Code reviews find their foundation in the coding standards of the organization. Coding standards are supposed to be the shared agreement that the developers have with one another to produce quality, maintainable code. If you’re discussing an item that isn’t in your coding standards, you have some work to do to get the item in the coding standards. You should regularly ask yourself whether the item being discussed is in your coding standards.
9. Remember that there is often more than one way to approach a solution. Although the developer might have coded something differently from how you would have, it isn’t necessarily wrong. The goal is quality, maintainable code. If it meets those goals and follows the coding standards, that’s all you can ask for.
10. You shouldn’t rush through a code review - but also, you need to do it promptly. Your coworkers are waiting for you.
11. Review fewer than 200-400 lines of code at a time.

Security Code Review

If the applications requires a very close attention to security then www.owasp.org is the right place for resources. This is a very good Security Code Review document to consider: https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf

Assign Severity to Review Findings

The severity to find issues with code should go as below. Reviewer must focus on issues with High severity first and then to Medium severity and then Low severity issues.

1. Naming Conventions and Coding style = Low
2. Control Structures and Logical issues = Medium or High
3. Redundant Code = High
4. Performance Issues =High
5. Security Issues = High
6. Scalability Issues= High
7. Functional Issues =High
8. Error Handling = High
9. Reusability = Medium
10. Design & Architecture = High
11. Proper use of 3rd party libraries = Medium

Checklist for developers and reviewers

Checklists are a highly recommended way to find the things you forget to do, and are useful for both authors and reviewers. Omissions are the hardest defects to find – after all, it’s hard to review something that’s not there. A checklist is the single best way to combat the problem, as it reminds the reviewer or author to take the time to look for something that might be missing. A checklist will remind authors and reviewers to confirm that all errors are handled, that function arguments are tested for invalid values, and that unit tests have been created.
Another useful concept is the personal checklist. Each person typically makes the same 15-20 mistakes. If you notice what your typical errors are, you can develop your own personal checklist (PSP, SEI, and CMMI recommend this practice too). Reviewers will do the work of determining your common mistakes. All you have to do is keep a short checklist of the common flaws in your work, particularly the things you forget to do. As soon as you start recording your defects in a checklist, you will start making fewer of them. The rules will be fresh in your mind and your error rate will drop. We’ve seen this happen over and over.

Checklist for Developers

 Checklist for Reviewers

I also made them in checklist format to be printed: CodeReview_ChecklistforDevelopers, CodeReview_ChecklistforReviewers.

Continue reading Code Review Guidelines Part 2.

Recommendations

References:

1. http://www.codinghorror.com/blog/2006/05/the-ten-commandments-of-egoless-programming.html
2. http://www.developer.com/java/other/article.php/3579756
3. http://www.smartbear.com/docs/BestPracticesForPeerCodeReview.pdf
4. Peer Reviews in Software: A Practical Guide
5. http://www.techrepublic.com/article/developers-guide-to-peer-reviews/1050834
6. http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf

You are trying to run JAXB 2.0 runtime but you have old JAXB 1.0 
runtime earlier in the classpath.
Please remove the JAXB 1.0 runtime for 2.0 runtime to work correctly.

The ideal solution would be to migrate everything to JAXB2 and remove the JAXB1 dependencies, but if you have certain constrains around this (and there usually are a lot) like: time, legacy systems, too much effort to retest everythig, etc there is an easy solution to have the old code run smooth and in the same time write the new code using the latest version of JAXB.

Here are the steps you need to follow:

• Download jax1-impl-XXX.jar, where XXX is something like 2.x.x (this can be found in the JAXB2 distribution)
• Remove your old jaxb-impl.jar (version 1) from the classpath
• Add the new jaxb1-impl-XXX.jar into the classpath

All done!

I had the following situation: I’ve wanted to select group all the calls from the call log either by the caller name if the number was in the agenda or by number if the number was not in the agenda. To do this you need a content resolver, a URI and a projection to tell Android which columns you want to select. A typical call will look as follows:

getContentResolver().query(CallLog.Calls.CONTENT_URI, 
new String[] { projection}, selection, new String[] 
{selectionArgs}, sortOrder)

As you notice there is no way of telling android how to group the rows. But we can trick it:

getContentResolver().query(CallLog.Calls.CONTENT_URI, new String[] 
{"_id", "name", "number",
 "duration","type", "numbertype", MAX(date) AS date",
"(CASE WHEN name=null THEN name ELSE number END) as logname"}, 
" 1=1 ) GROUP BY (logname",null,null);

You can notice the 1=1 ) GROUP by (logname String placed as the selection argument. This is why the magic happens. Also notice the syntax for the CASE statement that conditionally selects the number or the name. You can further use it in any place you need conditional select of the columns.

Happy Android programming!

To quote from the Guice official page

“Guice alleviates the need for factories and the use of new in your Java code. Think of Guice’s @Inject as the new new. Guice embraces Java’s type safe nature, especially when it comes to features introduced in Java 5 such as generics and annotations. You might think of Guice as filling in missing features for core Java. Ideally, the language itself would provide most of the same features, but until such a language comes along, we have Guice”

If you’ve used Spring or other DI frameworks you’re probably familiar to the above ideas. I’ll present in this article how to get started with Guice in a non-web application. I’ll detail the web side in a future article.

Is it better than Spring?

Well, this is one of those talks that could last forever. Like EJB vs Spring, Struts vs JSF and so on. It’s a matter of choice. I can say one thing though: if you need just  DI in your application go for Guice. It’s very lightweight, it’s type safe and it’s faster than Spring.

Using Guice for a non-web application

Suppose you have an application and the class that contains the main method its called Application. When using Guice the approach is a little changed. Besides starting the application you’ll also want a way to trigger the dependency injection. In order to to this you must have an “entry-point” that “manually” triggers the creation of the graph of objects that will get injected and only after that starts the actual application logic. We’ll call the class responsible for these 2 things the Bootstrap class. We also need to create a Module by extending the AbstractModule class. Quoting from the Java Doc of the Module interface:

A module contributes configuration information, typically interface bindings, which will be used to create an Injector. A Guice-based application is ultimately composed of little more than a set of Modules and some bootstrapping code.

Let’s see the code:

The Bootstrap class:

package com.insidecoding.guice;
import com.google.inject.Guice;

import com.google.inject.Injector;
/**
 * Bootstrap class that creates the root object that triggers the graph of
 * objects creation and injection
 */
public class Bootstrap {
public static void main(String[] args) {
 Injector injector = Guice.createInjector(new MyModule());
 IApplication app = injector.getInstance(IApplication.class);
 app.start();
 }
}

The IApplication interface:

package com.insidecoding.guice;
public interface IApplication {
 /**
 * Starts the current application
 */
 void start();
}

The Application class:

package com.insidecoding.guice;

import com.google.inject.Inject;

public class Application implements IApplication {
@Inject
 private IPrintingService ip;
public void start() {
 ip.print("Hello from guice");
 }
}

Suppose the logic of your application is as follows: use the IPrintingService to print a String and the printing service will use a ICachingService to cache that String. The implementations of these services will be injected using Guice in the Appplication, respective the ICachingService implementation class.

The IPrintingService interface:

package com.insidecoding.guice;
import com.google.inject.ImplementedBy;

@ImplementedBy(PrintingService.class)
public interface IPrintingService {
/**
 * Prints a string
 * @param s
 */
 void print(String s);
}

The PrintingService class:

package com.insidecoding.guice;

import javax.inject.Inject;

public class PrintingService implements IPrintingService {

	@Inject
	private ICachingService cs;

	@Override
	public void print(String s) {
		System.out.println(s);
		cs.cacheIt(s);
	}

}

The ICachingService:

package com.insidecoding.guice;

import com.google.inject.ImplementedBy;

@ImplementedBy(CachingService.class)
public interface ICachingService {

	/**
	 * Caches a String
	 * @param s
	 */
	void cacheIt(String s);
}

The CachingService class:

package com.insidecoding.guice;

public class CachingService implements ICachingService {

	@Override
	public void cacheIt(String s) {
		System.out.println("Caching: " + s);
	}

}

The MyModule class:

package com.insidecoding.guice;

import com.google.inject.AbstractModule;

public class MyModule extends AbstractModule {

       @Override
       protected void configure() {
          bind(IApplication.class).to(Application.class);
       }
}

The code is pretty simple and straightforward. In order to make this code work, you need to add just the following JARs from the Guice distribution:

• aopalliance.jar
• guice-3.0.jar
• javax.inject.jar

If you take a look closer on the above code you’ll see a small different as far as injection is concerned: the Application class uses the com.google.inject.Inject annotation and the PritingService class uses the javax.inject.Inject annotation. This is because Guice 3.0 is compatible with JSR-330. Mixing JSR-330 and Guice annotations though is discouraged so stick with Guice @Inject for now.

Types of injection

Guice has 3 types of injection:

• field injection
• constructor injection
• method injection

package com.insidecoding.guice;

import javax.inject.Inject;

public class PrintingService implements IPrintingService {

	private ICachingService cs;

        @Inject
        public PrintingService(ICachingService cachingService) {
             this.cs = cachingService;
        }

	@Override
	public void print(String s) {
		System.out.println(s);
		cs.cacheIt(s);
	}

}

       @Inject
       public void printMe(IPrintingService ps) {
            ps.print("Printing with Guice method injection");
       }

@ImplementedBy vs bind()

You can notice in the above code that there are 2 ways of declaring bindings between interfaces and implementations:

• annotate the interface with @ImplementedBy
• use the bind() method in a Module to specify the actual implementation: see the MyModule.configure() method.

bind(ICachingService).to(CachingService).in(Scopes.SINGLETON)

Please continue reading about using Guice for Web applications.

Recommendations:

https://market.android.com/details?id=ro.tipspedia.chronotimer

QR Code:

The servlet

package insidecoding.servlet;

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.ByteArrayInputStream;
import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import org.springframework.web.HttpRequestHandler;

import insidecoding.service.UserService;

@Component("imageServlet")
public class ImageServlet implements HttpRequestHandler {

    @Autowired
    private UserService UserService;

    @Override
    public void handleRequest(HttpServletRequest request,
            HttpServletResponse response) throws ServletException, IOException {
        // get the thumb from the user entity
        byte[] thumb = userService.getCurrentUserAvatar();

        String name = "userAvatar";
        response.setContentType("image/jpeg");
        response.setContentLength(thumb.length);

        response.setHeader("Content-Disposition", "inline; filename=\"" + name
                + "\"");

        BufferedInputStream input = null;
        BufferedOutputStream output = null;

        try {
            input = new BufferedInputStream(new ByteArrayInputStream(thumb));
            output = new BufferedOutputStream(response.getOutputStream());
            byte[] buffer = new byte[8192];
            int length;
            while ((length = input.read(buffer)) > 0) {
                output.write(buffer, 0, length);
            }
        } catch (IOException e) {
            System.out.println("There are errors in reading/writing image stream "
                    + e.getMessage());
        } finally {
            if (output != null)
                try {
                    output.close();
                } catch (IOException ignore) {
                }
            if (input != null)
                try {
                    input.close();
                } catch (IOException ignore) {
                }
        }

    }
}

Map this servlet to the /image path in web.xml

     <servlet>
        <servlet-name>imageServlet</servlet-name>
        <servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>imageServlet</servlet-name>
        <url-pattern>/image/*</url-pattern>
    </servlet-mapping>

Usage in JSP

....
<img src="image/avatar" height="75px" width="75px" align="left" />
....

The code is pretty self-explanatory:

• get the byte[] array from the database
• wrap it with an InputStream
• write the data from the InputStream to the servlet output stream in chunks

This code version supposes that you want to display the avatar of the current logged user. But this servlet can be used with any type of situation. For example, if you want to display images by the imageId, you can do this:

....
<img src="image/1212" height="75px" width="75px" align="left" />
....

Where 1212 is the imageId. You can then grab this imageId in the servlet, get the corresponding byte[] from the DB and continue as in the above code.

Nice, elegant and easy.

If you have questions please leave a comment below.