Interesting Stuff - adarrivi/hidden-data GitHub Wiki

• Only one database creation script for different databases Thanks to Liquibase's cross-database compatibility the same creation (and initial data) is used for integration tests and production environment.
• Thanks to Spring aspectj annotations, the Data Monitor project can intercept any method annotated with @PerformanceLogged. All the performance information is stored in a performance hub component (see PerformanceHub.java), ready to be accessed. The use of the compiler/weaver was necessary: adding aop.xml and the VM argument -javaagent:"<.m2 folder>/repository/org/springframework/spring-instrument/<spring.version>/spring-instrument-<spring.version>.jar
• Although the application is multi-threaded, there is almost not synchronized content, semaphores or atomic operations. This was done minimizing the shared resources.
• Using DbUnit and Liquibase together for the integration tests. See class com.hidden.data.db.dao.impl.InMemoryDaoIntegrationTest
• The Web application relies heavily on Apache Tile's composite view pattern.
• Javascript and css files are included in tiles.xml instead of the jsp pages (see tiles.xml and layout.jsp to see how they are loaded), making the jsp files a bit lighter:

tiles.xml

<put-list-attribute name="mainScripts">
  <add-attribute value="http://code.jquery.com/jquery-1.10.2.js" />
  <add-attribute value="http://code.jquery.com/ui/1.10.3/jquery-ui.js" />

layout.jsp

<tilesx:useAttribute id="mainScripts" name="mainScripts" classname="java.util.List" />
<c:forEach items="${mainScripts}" var="src">
  <script type="text/javascript" src="${src}"></script>
</c:forEach>

• Jquery, Jquery UI and Jqplot used for the frontend side.
• All jsp pages PatternDistribution.jsp have its correspondent javascript file PatternDistribution.js and Java controller PatternDistributionController.java. Having the same name for the three of them makes easier to find resources in the project.

• Using, or better getting comfortable with, Uncle Bob's Clean Code principles. Specially with the proper naming (one of the hardest but the most satisfying :) ) and Single Responsibility Principle
• Using Interfaces over concrete implementations, so it is easier to change the underlying technology (for example ActiveMq with RabbotMq. See data-queue for example
• Experimenting with Not Nullable Object concept for the data-sql-db model to avoid null checks.
• Archived 100% unit test coverage. Can you say you are working using TDD without having 100%?... To get this, some design principles must be kept in mind and another ones are a must (like don't instantiate objects in constructors, for example).
• Added some utility classes to make it easier to archive 100% coverage in unit testing. See com.hidden.data.commons.test package
• In unit testing I've been using the methodology given-when-then. This should improve the test readability and make it easier to modify when refactors happens.