Java revisted best practices

Exception Handling Best Practices

Code Reviews Best Practices

7 Habits Of Effective Programmers

good DZone article by Giorgio Sironi. His spin on the classic Stephen Covey habits.
1. Be Proactive: we can work with Test Doubles until a colleague has completed the implementation we need.
2. Begin with the end in mind: TDD and BDD are probably the best expression of beginning with a goal i
3. First things first: Refactoring is often applied as cowboy coding, instead of little transitions between working states of the code. But it is possible to refactor in different directions, horizontally (with the application of a new design across many subclasses or implementations) or vertically (moving code between inheritance and composition relationships).
4. Think win-win: The Agile movement prescribes a search for win-win scenarios between software developers and customers.
5. Seek first to understand, then be understood.  Especially when working with standards: the standard is likely to be more correct than us in many cases
6. Synergize.
7. Sharpen The Saw - Giorgio says he reads technical articles weekly and perform code katas, attend events and conferences. Personally I find inspiration and motivation in San Diego meetups for Java and Android. I also read a gazillion feeds on my Kindle Fire "JustReader" which formats Google Reader which consumes RSS feeds. I will make myself go to at least 1 large conference (JavaOne I hope).

A Programmer's List of Lists

Language popularity (Tiobe)  (Java, C, C++, C#, Objective C, PHP, ...)

Linux Flavors (Mint, Ubuntu, Fedora, Debian,.............., RHEL,....)

Free Programming EBooks (courtesy Hacker News)  (Thinking in Java, The Cathedral and the Bazaar, etc.)

NoSql Databases (Hadoop, MongoDb, MemCache, etc.)

Bits of Programming Advice ((Don't make objects that end with 'er'.))

NoSQL Flavors

On my TODO list: try two of these. 

Big Table or Wide Column Store

-          Hadoop/HBase (Facebook)

-          Cassandra

-          HyperTable (Google)

-          Amazon SimpleDB

Document Store

-          MongoDB (JSON documents) (FourSquare)

-          CouchDB (JSON documents)

Key-Value

-          Amazon DynamoDB

-          Memcached

-          Oracle Coherence

-          Apache Voldemort (LinkedIn)

XML

-          MarkLogic

-          Apache Xindice (retired)

PLoP Links And Other Pattern Links

PLoP = Pattern Languages of Programs, a group that collects good patterns like some people collect baseball cards.
Some interesting links:
Books On Patterns
Patterns Catalog
Some Random Interesting Patterns:
Avionics Patterns
Scrum Patterns

Other Links:
Pattern-Oriented Software Architectures
Patterns & Frameworks for 
Concurrent & Distributed Systems - Patterns For Real Time Avionics Messaging in UAV
Great Article on Inversion of Control Layer
Variability Patterns (Software Product Line)

Thought Leaders

Kent Beck
Bruce Eckel
Martin Fowler
Uncle Bob Martin
Joel Spolsky
Scott Ambler

Java And Eclipse Useful Tips and Best Practices

Java And Eclipse Useful Tips and Best Practices

The Joel Test

Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? Do you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing? Joel Spolsky's Joel Test (How Good is your software team)

Software Architecture Patterns and Best Practices

• The fundamental rule is that all code can depend on layers more central, but code cannot depend on layers further out from the core.  In other words, all coupling is toward the center.   This architecture is unashamedly biased toward object-oriented programming, and it puts objects before all others. Onion Architecture

My Favorite Java Tricks and Tips

•  Classpath wild cards since Java 6: java -classpath ./lib/* so.Main Instead of java -classpath ./lib/log4j.jar:./lib/commons-codec.jar:./lib/commons-httpclient.jar:./lib/commons-collections.jar:./lib/myApp.
• JDK 1.6_07+ contains an app called VisualVM (bin/jvisualvm.exe)
• variable arity. So, instead of just passing an array, now you can do the following

  public void foo(String... bars) {
     for (String bar: bars)
        System.out.println(bar);
  }

  bars is automatically converted to array of the specified type

•  javap disassembler which comes with Sun's JDK is not widely known or used.
• // For each Object, instantiated as foo, in myCollection

for(Object foo: myCollection) {
  System.out.println(foo.toString());
}

• checking for null is not necessary.

Instead of:

if( null != aObject && aObject instanceof String )
{
    ...
}

just use:

if( aObject instanceof String )
{
    ...
}

• anonymous subclass or anonymous impl of an interface:

public void initAnonymousSubclass() {
//anonymous subclass and directly call a method on it even if it implements no interfaces.
new Thread() {
public void run() {
while (true) {
try {
Thread.sleep(2000);
System.out.println("sleeping");
} catch (InterruptedException e) {
e.printStackTrace();
}
}

}
}.start();
}

public void initImplementationOfInterface(){
new TestInterface(){

@Override
public String printId() {
// TODO Auto-generated method stub
String someString = "time "+System.currentTimeMillis();
System.out.println(someString);
return someString;
}

}.printId();
}

Source attributation: http://stackoverflow.com/questions/15496/hidden-features-of-java

Common JEE Application Design Patterns

• Typesafe enum pattern/enum in JDK 1.5+
• code to an interface not an implementation
• abstract parent class to promote reuse for subclasses
• factory method pattern (loose couples calling code from instances created)
• abstract factory pattern  (specific method for each concrete type)
• builder pattern (similar to factory except user had more flexibility (builder.add(x), builder.add(y), etc.)
• strategy pattern (strategy encapsulates algorithms not data)
• decorator design pattern: (implements same interface as object it decorates)
• visitor pattern: (avoids lots of typecasts and instanceof to do common method on different types)
• iterator pattern
• template method pattern (e.g. Spring JDBC and Spring JMS)
• composite design pattern: (act on Manager or Staff object in same way. both subs of employee)
• facade pattern: (interface to large set of classes)
• observer pattern: (observer registers with publisher, publisher notifies observer of event)
• command pattern: OO equivalent of callbacks (sender object invokes operation, receiver object  receives request to execute certain operation)
• proxy pattern: (remote: EJB, RMI, CORBA, virtual: create memory intensive object on demand (lazy load hibernate objects when needed), access: different clients get different access rights)
• dynamic proxy: (reflection based; come at a performance cost; common in AOP)
• adapter pattern (wrap API)
• service activator pattern (ala MessageBean)  services need a way to be activated asynchronously
• For completion: (bridge, chain of responsibility)
• For completion JEE (MVC, front controller, composite view, view helper, dispatcher view, service to worker, business delegate, session facade, value object, fast lane reader, service locator)

more here

Java and General Programming Sites and News Sources

General:
stackoverflow
Refcardz

Java:
Java Community Content on InfoQ
the serverside
refcardz
informit
developerworks
Automation For the People
Java Lobby
Java Developers Journal
(esp. automation for the people)
martin fowler
sdtime
http://java.sys-con.com/, http://java.dzone.com/
Developer.com/java
Java Posse

Java Reference Guide (http://www.informit.com/guides/guide.aspx?g=java)
java almanac, The Register/Software

Automation:

Java, CI and WS Technology

App Server: JBoss, Glassfish, Geronimo, Tomcat (no EJB), WebLogic (OAS), WebSphere
• SOAP Stack: Axis2, CXF, Metro, JBoss WS, Websphere JAX-WS, WebLogic (OAS) JAX-WS, Spring Web Services
• Specs: JAX-WS (JSR 224), JAX-RS (JSR 311), JAX-RPC, SAAJ (JSR 67), JSR 181 (standardize deploy), JSR 109 (WS inside JEE)
• General Features: Spring Support, Eclipse Plugins, Streaming XML (STaX), Client-side Asynchrony, Server-side Asynchrony, Policy-driven code generation)
• Marshalling: JIXB , JAXB, XMLBean
• Attachments: SAAJ (SOAP w/ attach), MTOM (Msg Transmission Optimization Mech), DIME (binary)
• Encoding: XML, FastInfoSet, JSON
• Transports: HTTP, JMS, XMPP

CI: Jenkins, Hudson, Bamboo, TeamCity, Cruise Control

Build and dependency management: Ant, Ant/Ivy, Maven

Static Analysis: Checkstyle, FindBugs, PMD, PathFinder, JDepend, Coverlipse, Cobertura, Clover, Coverity, Structure 101

Test: JUnit, TestNG, EasyMock, SOAPUI, firebug, surefire (maven), STAF(S/W Tasting Automation Framework), Load test (SLAMD distributed load generation , JMeter)

Documentation: Javadoc, SchemaSpy, UMLGraph

XML/XSD create/edit/XSLT transform: XmlSpy, Liquid

Network Tools: wireshark, winscp, putty, tightVNC, nirsoft network tools, pathsync, synergy, filezilla, VMPlayer

Patterns: Observer, Template, Adapter, Proxy

JMS/EAI/SOA/ESB platforms: WebSphere MQ, Tibco, Vitria, WebMethods, BizTalk, Sonic, Fiorano, Mule ESB, Apache ActiveMQ, Fuse, MSMQ, GlassfishMQ, Camel, RabbitMQ

ORM: Hibernate, iBatis

JSSE Provider: BouncyCastle, AlternativeJSSE, Certicom, IBMJSSEFIPS, SunJSSE

Issue Tracking: ClearQuest, XPlanner, Trac, Bugzilla, Jira, Mylin

IDE: Eclipse, SpringSource ToolSuite, plugins: WTP (Web Tools Platform), DTP (Data Tools Platform), ClearCase, Subclipse, m2eclipse, UML2 Tools SDK

Profiling: JProfiler, JVisualVM, JHat, JConsole, SMAPS

Modeling: UML, OO round trip – Java, DB schema modeling, DDL generation, reverse engineering, eclipse integration, measure architecture violations, complexity debt

Enterprise Patterns: WS-Orchestration, BPEL, WS-Choreography/WSDL 2.0 message Exchange Patterns (see Enterprise Integration Patterns), JAX-WS asynchronicity (polling, callbacks, rendezvous with Future, Continuation Passing Pattern), XMPP, MOM (message oriented middleware), JMS (pub-sub), SOAP over JMS, WS (standard request-response), VMWare messaging via GN3/IOS, Contract First WSDL (e.g. Spring WS)

Websites: stackoverflow, infoq.com/java, the serverside, refcardz, informit, developerworks (esp. automation for the people), martin fowler, sdtimes, http://java.sys-con.com/, http://java.dzone.com/, Java Reference Guide (http://www.informit.com/guides/guide.aspx?g=java), java almanac, http://www.theregister.co.uk/software/

Books: J Dev Almanac, Effective Java, Java PowerTools, Pragmatic (Ship it, Manage it, Pragmatic Program Automation), Clean Code (smells), Refactoring Large S/W Projects, Agile s/w with Spring, Hibernate & Eclipse, Java Enterprise Design Patterns, Pattern Oriented S/W Architecture, Antipatterns, pragmatic programmer, beautiful architecture

Nice super list of tech resources

Technology Resource Links
SOA, Java, cloud, db, GIS, ORM, reporting, security patterns, testing, thought leaders (Eckel, Spolsky)

Impedance Mismatches among Relational tables, Objects, and XML Hierarchy

So often, we as software developers, try to map objects to a persistent relational database and run into difficulties because it just doesn't fit right. We end up working with ORM abstractions (e.g. Hibernate) that undo the damage done by normalizing the original object model into multiple tables.

With the object paradigm, you traverse objects via their relationships whereas with the relational paradigm you join the data rows of tables. Scott Ambler has a good discussion of the Object-Relational Impedance Mismatch. He also describes The Cultural Impedance Mismatch Between Data Professionals and Application Developers (e.g.  "Data professionals that claim that your object/component models must be driven by their data models"), Why Data Models Shouldn't Drive Object Models (And Vice Versa).

What about XML hierarchies and database tables. Here's a good article on storing trees in tables. How do you store a tree in a database table?  He discusses a couple of challenges with typical approaches and presents a novel approach.

Some issues in the XML to Objects mapping: Revealing the X/O impedance mismatch (Changing lead into gold). In general I love working with JAXB and it is now part of the JDK. It's a breeze to auto-generate classes from XML schema that can then be used to import and export XML from your code. Strangely, there's a lack of up-to-date tutorials on using xjc from Java 6 or later. I will add that to my todo list.

"I believe the fundamental problem with the database solution comes from the fact that it is often slapped on an application by default. “We need persistence.” “Well, let’s use a database [and the ORM]“. is a good quote from Best alternative to RDBMS and ORMs : Terracotta | Taranfx: Technology Blogbase [and the ORM]“.

Other links:

• Object-relational impedance mismatch - Wikipedia, the free encyclopedia
• ORM - The Leaky Abstraction
• Inheritance vs Relational Databases in RoR
• Implementing Type hierarchies "There are three common patterns for mapping type hierarchies to database tables. Martin Fowler uses the following names for these patterns: Single Table Inheritance, Class Table Inheritance, and Concrete Table Inheritance"
• How XML Threatens Big Data : Dataspora Blog "Data lives in relational databases or as data structures in programs. The common import and export formats of these environments do not resemble XML, so much effort is dedicated to making XML fit. When more time is spent on inter-converting data — serializing, parsing,translating — than in using it, you’ve created a data bureaucracy."

Impedance Mismatches: Relational, Objects, and XML Hierachical

So often, we as software developers, try to map objects to a persistent relational database and run into difficulties because it just doesn't fit right. We end up working with ORM abstractions (e.g. Hibernate) that often seem more trouble than they're worth. This is what we call impedance mismatch.

Part of the problem is often letting the

Lean Software Development

Zero Practices (These practices that must be in place before taking the first step):

• Source Code Management
• Scripted Build

Daily Standup

Automated Testing

Continous Integration

• Use a dedicated build machine
• Check code changes into the repository a minimum of once a day (per developer); once an hour or more is even better.
• Immediately address any failures in the build. Fixing the build takes precedence over further implementation.

Less Code

• Eliminate Unnecessary Code
• Use coding standards to write readable and understandable code.
• Design and implement code with design patterns, refactoring, and emergent design.

Short Integrations

• Use Customer Feedback
• Course correction

Customer Participation

• Requirements Prioritization
• Acceptance Tests
• Accessible Status
• Access To Product

OSGi Evangelism and OO Design Principles

OSGi adds a higher layer of granularity to OO abstraction, information hiding, design by contract, etc. I like this quote  from Modular Mind: "Software development has advanced in large part by increasing the granularity of the aggregations that we have to work with.". In this presentation, Module Systems and Architectures, on OSGI, Martin Lippert also shows another evolution that can be seen in OSGi:


Good Old Design Principles
DIP SOC LSP ADP TDA DRY AIP
ISP SCP OCP IHP SRP SDP

New Design Principles
Use services ---> Separate between interface and implementation
Use extensions ---> working but extensible

Here's a breakdown of Martin's shortlist of "good old design principles":

Class Design Principle

• Separation Of Concerns (SoC)
• Tell, Don't Ask (TDA)
• Don't Repeat Yourself (DRY)
• Dependency Injection Principle (DIP)
• Liskov Substitution Principle (LSP)
• Open Closed Principle (OCP)
• Single Responsibility Principle (SRP)
• Interface Segregation Principle (ISP)

Package Design Principles

Cohesion Principles: 

• Reuse/Release Equivalency Principle (REP)
• Common Reuse Principle (CRP) 
• Common Closure Principle (CCP)

Coupling Principles:

• Acyclic Dependencies Principle (ADP)
• Stable Dependencies Principle (SDP)
• Stable Abstractions Principle (SAP)

  Object-Oriented Reengineering - Principles of OOD - Radu Marinescu,
  OO Design Principles - Stefan Kluth,

Emergent Design

TODO:

• Tracer Bullet Development (see Ship It, ch. 4)

• do light-weight, up front design, create a system of mock objects, and add appropriate automated tests
• System Objects: Encapsulate and Separate 
• incrementally add functionality to the system  
• Incremental Improvements: Iterations
• benefits: scalability, encapsulation, decoupled code, parallel code development, flexible to requirements creep

Static Code Analysis, Defect Detection, Code Smells, Architecture Smells, Dependency Analysis

FindBugs Descriptions

• Bad Practice
• Correctness
• Experimental
• Malicious Code Vulnerability
• Multithreaded Correctness
• Performance
• Security
• Dodgy Practices

PMD Rulesets

Lint4J checks for

• Architectual problems
• Contracts defined in the Java core API
• Java Language Constructs
• Immature code
• Performance
• Code portability
• The Serialization and Externalization contracts
• Suspicious coding and likely bugs
• Java Synchronization and Scalability
• Coding patterns that impact readability and code size
• Violations of the EJB specification

JLint Program Checker

Coverity Static Analysis, Dynamic Analysis , Architectural Analysis

NASA's JPF (Java Path Finder)
Which defects can be found by JPF? Out of the box, JPF can search for deadlocks and unhandled exceptions (e.g. NullPointerExceptions and AssertionErrors), but the user can provide own property classes, or write listener-extensions to implement other property checks. A number of such extensions, like race condition and heap bounds checks are included in the JPF distribution 

Hammurabi Hammurapi is a code quality governance platform to mitigate risks of outsourcing* of software development.

Structure 101