In a typical Java application of significant size, numerous domain objects are present, each often featuring identifiers. These identifiers are commonly defined as Strings, Integers, or similar data types within many codebases. Moreover, there might be additional alternative identifiers like account numbers or social security numbers. The challenge arises when interface methods are exposed, requiring these identifiers as parameters. Without strong typing, it becomes ambiguous which identifier should be passed in a given method call. Hence, it is crucial to strong-type these identifiers. Additionally, when accepting and providing JSON representations of domain objects, it’s vital to serialize these identifiers in their raw form.

Crafting effective tests is as vital as writing clean production code. A well-structured test not only validates functionality but also serves as documentation for the system. However, creating such tests often encounters a common roadblock – the excess baggage of fluff. This includes generating test data, defining parameters for the “system under test,” creating responses for mocks/stubs, and establishing expectations for asserts.

In React applications, the construction of user interfaces often involves assembling custom components. While the common practice for a child component to communicate with its parent is through the firing of custom events, there are scenarios where a more imperative approach is necessary. This is particularly true when dealing with third-party widgets lacking convenient events or when the computation of state required by the parent is resource-intensive and should be performed only when explicitly requested by the parent. Achieving this functionality involves leveraging two key concepts: forwardRef and useImperativeHandle.

In Micronaut applications, Singleton beans are typically initialized lazily by default. This deliberate choice aims to enhance the application startup speed. However, a drawback of this approach is that potential wiring errors may only surface when the bean is actually initialized. To mitigate this, we can employ a startup test.

It is hard to overestimate the role that good code reviews can play in ensuring the high quality of any software. Unfortunately, I feel that in many teams, reviews mostly become part of a bureaucratic process, consuming lots of time and resources but providing very little real added value.

Sometimes I need to add a very simple UI to my Micronaut applications. Lightweight javascript libraries such as JQuery or AngularJS are quite convenient for this purpose. Traditionally, CDNs are used to reference and download these libraries at runtime, but I prefer to use webjars. This way, my app will continue to work even if there is no internet connection or if a certain CDN is blocked e.g. by corporate network policies.

Wouldn’t it be nice to work only on greenfield projects with a team that shares the same vision and style? Unfortunately, we have to spend a significant portion of our professional lives dealing with the messy legacy code. Such code is very hard to comprehend. It often consists of tangled classes with some arbitrary division of responsibilities. Unit test coverage is often very low. Sometimes unit tests are formally there, but you can clearly see that they have been written after the fact, simply repeating the production code mess. These tests are very fragile and don’t provide an adequate “safety net”.

These days, most software projects set the master branch to be read-only, use pull requests to merge feature branches, and require code reviews with multiple approvals. Theoretically, this is a great practice, no doubt; but, as always, the devil is in the details, and typical code reviews are frequently ineffective or even harmful.

Today’s very short post is about ways to identify technical debt and how to find components/classes that require immediate attention.

I recently read a very interesting article called Test Desiderata, published by Kent Beck. In this article, Kent describes the properties of good tests. He also mentions that tests of different levels (unit, integration, acceptance, etc.) should focus on different properties.

Yesterday, I had a discussion with my colleagues about the properties of good tests. I think in general, tests have four purposes in the following increasing order of importance:

Two very useful Gradle plugins:

1. axion-release-plugin https://github.com/allegro/axion-release-plugin

There are some very useful command line options you can specify when executing maven tests:

If your server is running in one timezone, but you want to have log messages be printed using different timezone, here is a simple solution:

1. Add log4j extras to project classpath (maven GAV is log4j:apache-log4j-extras:1.0)
2. In log4j.xml use EnhancedPatternLayout, specifying required timezone for logging purposes (see example below for EST TZ)

<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
    <param name="Threshold" value="TRACE" />
    <layout class="org.apache.log4j.EnhancedPatternLayout">
        <param name="ConversionPattern" value="%d{ISO8601}{EST} %-5p [%t][%c:%M(%L)] %m%n" />
    </layout>
</appender>

In several projects we participated, there was a need to call external Web Services using Java classes generated by wsdl2java Axis tool (or wsdl2java goal of axistools-maven-plugin).

In many projects, especially big ones, developed over several years, there is a lot unused code. Cleaning up projects and deleting such unused code is important.

• Eclipse can detect unused methods and variables.
• PMD (and PMD maven plugin) can also do this and even be integarated into CI process.
• Eclipse Core Tools plugin can find unused classes (see description here).

Unfortunately all above methods will mark code invoked by reflection (e.g. using IoC container such as Spring) as unused. At the same time garbage code that was left behind together with its unit test won’t be detected.

Automatic code format and correcting indentation are essential features of any IDE. Unfortunately FlexBuilder currently doesn’t have them. Recently I found very cool plugin called flexformatter that solves this issue. Start by installing flexformatter using eclipse update site. After restaring Eclipse/FlexBuilder you will find “Flex Formatting” menu under “Preferences”.

I use MacBook as my primary computer at home and Windows in the office.

QuickLook is a feature in Leopard, which allows to view file content without opening it, directly from Finder.

In small applications it makes sense to combine Java and Flex code under same project. I’m a big fan of maven and one of my favorite maven plugins is embedded jetty container. This plugin runs jetty directly from maven and supports automatic monitoring and redeployment of java classes and resources. I thought it would be nice to run Java+Flex projects in the same way and have updated SWF file instantly available in the browser immediately after Flex Builder compiles it.

Note: This is a copy from my old blog posted in 2007. Some things mentioned here have been changed since then.