Docker is a command line tool that can run a shell command in a virtual Linux, inside an isolated file system. Every time we build our projects, we want them to run in their own Docker containers. Take this Maven project for example:

$ sudo docker run -i -t ubuntu mvn clean test

This command will start a new Ubuntu system and execute mvn clean test inside it. Rultor.com, our virtual assistant, does exactly that with our builds, when we deploy, package, test and merge them.

You get a GitHub pull request. You review it. It looks correct—it’s time to merge it into master. You post a comment in it, asking @rultor to test and merge. Rultor starts a new Docker container, merges the pull request into master, runs all tests and, if everything looks clean—merges, pushes, and closes the request.

Then, you ask @rultor to deploy the current version to production environment. It checks out your repository, starts a new Docker container, executes your deployment scripts and reports to you right there in the GitHub issue.

Continuous integration is easy. Download Jenkins, install, create a job, click the button, and get a nice email saying that your build is broken (I assume your build is automated). Then, fix broken tests (I assume you have tests), and get a much better looking email saying that your build is clean.

Then, tweet about it, claiming that your team is using continuous integration.

Then, in a few weeks, start filtering out Jenkins alerts, into their own folder, so that they don’t bother you anymore. Anyway, your team doesn’t have the time or desire to fix all unit tests every time someone breaks them.

After all, we all know that unit testing is not for a team working with deadlines, right?

Wrong. Continuous integration can and must work.

Liquibase is a migration management tool for relational databases. It versionalizes schema and data changes in a database; similar to the way Git or SVN works for source code. Thanks to their Maven plugin, Liquibase can be used as a part of a build automation scenario.

Every Java package (JAR, WAR, EAR, etc.) has a MANIFEST.MF file in the META-INF directory. The file contains a list of attributes, which describe this particular package. For example:

Manifest-Version: 1.0
Created-By: 1.7.0_06 (Oracle Corporation)
Main-Class: MyPackage.MyClass

When your application has multiple JAR dependencies, you have multiple MANIFEST.MF files in your class path. All of them have the same location: META-INF/MANIFEST.MF. Very often it is necessary to go through all of them in runtime and find the attribute by its name.

jcabi-manifests makes it possible with a one-liner:

import com.jcabi.manifests.Manifests;
String created = Manifests.read("Created-By");

I needed to create a custom syntax highlighting for requs.org on which I’m using Jekyll for site rendering.

This is how my code blocks look in markdown pages:

{ % highlight requs %}
User is a "human being."
{ % endhighlight %}

I created a custom Pygments lexer:

SASS is a powerful and very popular language for writing CSS style sheets. This is how I’m using SASS in my Maven projects.

First, I change the extensions of .css files to .scss and move them from src/main/webapp/css to src/main/scss.

Then, I configure the sass-maven-plugin (get its latest versions in Maven Central):

<plugin>
  <groupId>nl.geodienstencentrum.maven</groupId>
  <artifactId>sass-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>generate-css</id>
      <phase>generate-resources</phase>
      <goals>
        <goal>update-stylesheets</goal>
      </goals>
      <configuration>
        <sassSourceDirectory>${basedir}/src/main/scss</sassSourceDirectory>
        <destination>${project.build.directory}/css</destination>
      </configuration>
    </execution>
  </executions>
</plugin>

Separating data and their presentation is a great concept. Take HTML and CSS for example. HTML is supposed to have pure data and CSS is supposed to format that data in order to make it readable by a human. Years ago, that was probably the intention of HTML/CSS, but in reality it doesn’t work like that. Mostly because CSS is not powerful enough.

We still have to format our data using HTML tags, while CSS can help slightly with positioning and decorating.

On the other hand, XML with XSLT implements perfectly the idea of separating data and presentation. XML documents, like HTML, are supposed to contain data only without any information about positioning or formatting. XSL stylesheets position and decorate the data. XSL is a much more powerful language. That’s why it’s possible to avoid any formatting inside XML.

The latest versions of Chrome, Safari, Firefox and IE all support this mechanism. When a browser retrieves an XML document from a server, and the document has an XSL stylesheet associated with it—the browser transforms XML into HTML on-fly.

This blog is written in Jekyll and is hosted at GitHub Pages. It uses half a dozen custom plugins, which are not allowed there.

Here is how I deploy it:

$ jgd

That’s it. jgd is my Ruby gem (stands for “Jekyll GitHub Deploy”), which does the trick. Here is what it does:

I’m a big fan of automated testing in general and integration testing in particular. I strongly believe that effort spent on writing tests are direct investments into quality and stability of the product under development.

CasperJS is a testing framework on top of PhantomJS, which is a headless browser. Using CasperJS, we can ensure that our application responds correctly to requests sent by a regular web browser.

Say, you want to allow a Java method to work for a maximum of five seconds and want an exception to be thrown if the timeframe is exceeded. Here is how you can do it with jcabi-aspects and AspectJ:

public class Resource {
  @Timeable(limit = 5, unit = TimeUnit.SECONDS)
  public String load(URL url) {
    return url.openConnection().getContent();
  }
}

This is “string concatenation,” and it is a bad practice:

// bad practice, don't reuse!
String text = "Hello, " + name + "!";

Why? Some may say that it is slow, mostly because parts of the resulting string are copied multiple times. Indeed, on every + operator, String class allocates a new block in memory and copies everything it has into it; plus a suffix being concatenated. This is true, but this is not the point here.

In object-oriented programming, an object is immutable if its state can’t be modified after it is created. In Java, a good example of an immutable object is String. Once created, we can’t modify its state. We can request that it creates new strings, but its own state will never change.

Sometimes, I want to log (through slf4j and log4j) every execution of a method, seeing what arguments it receives, what it returns and how much time every execution takes. This is how I’m doing it, with help of AspectJ, jcabi-aspects and Java 6 annotations:

public class Foo {
  @Loggable
  public int power(int x, int p) {
    return Math.pow(x, p);
  }
}

This is what I see in log4j output:

[INFO] com.example.Foo #power(2, 10): 1024 in 12μs
[INFO] com.example.Foo #power(3, 3): 27 in 4μs

Nice, isn’t it? Now, let’s see how it works.

I’m a big fan of Amazon Web Services (AWS). I’m using them in almost all of my projects. One of their most popular services is Simple Storage Service (S3). It is a storage for binary objects (files) with unique names, accessible through HTTP or RESTful API.

Using S3 is very simple. You create a “bucket” with a unique name, upload your “object” into the bucket through their web interface or through RESTful API, and then download it again (either through HTTP or the API.)

Amazon ships the Java SDK that wraps their RESTful API. However, this SDK is not object-oriented at all. It is purely imperative and procedural—it just mirrors the API.

For example, in order to download an existing object doc.txt from bucket test-1, you have to do something like this:

AWSCredentials creds = new BasicAWSCredentials(key, secret);
AmazonS3 aws = new AmazonS3Client(creds);
S3Object obj = aws.getObject(
  new GetObjectRequest("test-1", "doc.txt")
);
InputStream input = obj.getObjectContent();
String content = IOUtils.toString(input, "UTF-8");
input.close();

As always, procedural programming has its inevitable disadvantages. To overcome them all, I designed jcabi-s3, which is a small object-oriented adapter for Amazon SDK. This is how the same object-reading task can be accomplished with jcabi-s3:

Region region = new Region.Simple(key, secret);
Bucket bucket = region.bucket("test-1");
Ocket ocket = bucket.ocket("doc.txt");
String content = new Ocket.Text(ocket).read();

Why is this approach better? Well, there are a number of obvious advantages.

This is a very common practice in Java (using LoggerFactory from slf4j):

import org.slf4j.LoggerFactory;
public class Foo {
  private static final Logger LOGGER =
    LoggerFactory.getLogger(Foo.class);
  public void save(String file) {
    // save the file
    if (Foo.LOGGER.isInfoEnabled()) {
      Foo.LOGGER.info("file {} saved successfuly", file);
    }
  }
}

What’s wrong with it? Code duplication.

I was using MySQL in a few Java web projects and found out there was no Maven plugin that would help me to test my DAOs against a real MySQL server. There are plenty of mechanisms to mock a database persistence layer both in memory and on disc. However, it is always good to make sure that your classes are tested against a database identical to the one you have in production environment.

I’ve created my own Maven plugin, jcabi-mysql-maven-plugin, that does exactly two things: starts a MySQL server on pre-integration-test phase and shuts it down on post-integration-test.

Amazon DynamoDB is a great NoSQL cloud database. It is cheap, highly reliable and rather powerful. I’m using it in many web systems.

There is one feature that it lacks, though—auto-increment attributes.

Say that you have a table with a list of messages:

+------+----------------------------+
| id   | Attributes                 |
+------+----------------------------+
| 205  | author="jeff", text="..."  |
| 206  | author="bob", text="..."   |
| 207  | author="alice", text="..." |
+------+----------------------------+

Every time you add a new item to the table, a new value of id has to be set. And this has to be done with concurrency in mind. SQL databases like PostgreSQL, Oracle, MySQL and others support auto-increment features. When you add a new record to the table, the value of the primary key is omitted and the server retrieves the next one automatically. If a number of INSERT requests arrive at the same time the server guarantees that the numbers won’t be duplicated.

However, DynamoDB doesn’t have this feature. Instead, DynamoDB has Atomic Counters and Conditional Updates, which are very similar features. Still, they’re not exactly the same.

In case of an atomic counter, you should create a supplementary table and keep the latest value of id in it.

In case of conditional updates, you should retry a few times in case of collisions.

To make life easier in a few of my applications, I created a simple web service—stateful.co. It provides a simple atomic counter feature through its RESTful API.

GitHub is an awesome platform for maintaining Git sources and tracking project issues. I moved all my projects (both private and public) to GitHub about three years ago and have no regrets. Moreover, GitHub gives access to almost all of its features through RESTful JSON API.

There are a few Java SDK-s that wrap and expose the API. I tried to use them, but faced a number of issues:

• They are not really object-oriented (even though one of them has a description that says it is)
• They are not based on JSR-353 (JSON Java API)
• They provide no mocking instruments
• They don’t cover the entire API and can’t be extended

Keeping in mind all those drawbacks, I created my own library—jcabi-github. Let’s look at its most important advantages.

A simple example of NULL usage in Java:

public Employee getByName(String name) {
  int id = database.find(name);
  if (id == 0) {
    return null;
  }
  return new Employee(id);
}

What is wrong with this method?

A utility class (aka helper class) is a “structure” that has only static methods and encapsulates no state. StringUtils, IOUtils, FileUtils from Apache Commons; Iterables and Iterators from Guava, and Files from JDK7 are perfect examples of utility classes.

DynamoDB Local is a locally running copy of Amazon DynamoDB server. Amazon developed the tool and based it on SQLite. It acts as a real DynamoDB service through the RESTful API.

I guess, DynamoDB Local is meant to be used in integration testing and this is how we’re going to use it below.

I use Maven to run all of my Java integration testing using maven-failsafe-plugin. The philosophy of integration testing with Maven is that you start all your supplementary test stubs during the pre-integration-test phase, run your tests in the integration-test phase and then shutdown all stubs during the post-integration-test.

It would be great if it were possible to use DynamoDB Local that way. I didn’t find any Maven plugins for that purpose, so I decided to create my own—jcabi-dynamodb-maven-plugin.

A few years ago, I created two Java wrappers for W3C validators: (HTML and CSS). Both wrappers seemed to be working fine and were even listed by W3C on their website in the API section. Until recently, these wrappers have always been part of ReXSL library.

A few days ago, though, I took the wrappers out of ReXSL and published them as a standalone library—jcabi-w3c. Consequently, now seems to be a good time to write a few words about them.

Below is an example that demonstrates how you can validate an HTML document against W3C compliance rules:

import com.jcabi.w3c.ValidatorBuilder;
assert ValidatorBuilder.html()
  .validate("<html>hello, world!</html>")
  .valid();

Hamcrest is my favorite instrument in unit testing. It replaces the JUnit procedural assertions of org.junit.Assert with an object-oriented mechanism. However, I will discuss that subject in more detail sometime later.

Now, though, I want to demonstrate a new library published today on GitHub and Maven Central: jcabi-matchers. jcabi-matchers is a collection of Hamcrest matchers to make XPath assertions in XML and XHTML documents.

Let’s say, for instance, a class that is undergoing testing produces an XML that needs to contain a single <message> element with the content "hello, world!"

This is how that code would look in a unit test:

import com.jcabi.matchers.XhtmlMatchers;
import org.hamcrest.MatcherAssert;
import org.junit.Test;
public class FooTest {
  @Test
  public void hasWelcomeMessage() {
    MatcherAssert.assertThat(
      new Foo().createXml(),
      XhtmlMatchers.hasXPaths(
        "/document[count(message)=1]",
        "/document/message[.='hello, world!']"
      )
    );
  }
}

This page contains most typical mistakes I see in the Java code of people working with me. Static analysis (we’re using qulice can’t catch all of the mistakes for obvious reasons, and that’s why I decided to list them all here.

Requirements engineering is one of the most important disciplines in software development. Perhaps, even more important than architecture, design or coding itself. Joy Beatty and Karl Wiegers in Software Requirements argue that the cost of mistakes made in a requirements specification is significantly higher than a bug in source code. I totally agree.

Unlike with many other modern languages, parsing XML in Java requires more than one line of code. XML traversing using XPath takes even more code, and I find this is unfair and annoying.

I’m a big fan of XML and use it it in almost every Java application. Some time ago, I decided to put all of that XML-to-DOM parsing code into a small library—jcabi-xml.

Put simply, the library is a convenient wrapper for JDK-native DOM manipulations. That’s why it is small and dependency-free. With the following example, you can see just how simple XML parsing can be:

import com.jcabi.xml.XML;
import com.jcabi.xml.XMLDocument;
XML xml = new XMLDocument(
  "<root><a>hello</a><b>world!</b></root>"
);

Amazon S3 is a simple and very useful storage of binary objects (aka “files”). To use it, you create a “bucket” there with a unique name and upload your objects.

Afterwards, AWS guarantees your object will be available for download through their RESTful API.

A few years ago, AWS introduced a S3 feature called static website hosting.

With static website hosting, you simply turn on the feature and all objects in your bucket become available through public HTTP. This is an awesome feature for hosting static content, such as images, JavaScript files, video and audio content.

When using the hosting, you need to change the CNAME record in your DNS so that it points to www.example.com.aws.amazon.com. After changing the DNS entry, your static website is available at www.example.com just as it would be normally.

When using Amazon S3, though, it is not possible to protect your website because the content is purely static. This means you can’t have a login page on the front end. With the service, you can either make your objects either absolutely public—so that anyone can see them online—or assign access rights to them—but only for users connected through RESTful API.

In XDSD, everyone—including project managers, analysts, programmers, and product owners—receives payments based on deliverables with agreed upon budgets. In the first section of the article, How XDSD Is Different I explain exactly how this concept works. I don’t explain in the article, though, how we decide which hourly rate is acceptable for each project participant.

When new people come to us, usually they have some numbers in mind. They know how much they expect to make per week, per month or per day. We rarely negotiate the payment rates, but rather just accept reasonable offers (see How Much Do You Cost?). Nonetheless, every few months, we review payments rates and change them accordingly (increasing or decreasing them as appropriate).

Further along in the article, is a list of factors that influence our decision making process regarding payment rates. However, before we get to the factors that influence our rate-setting decisions, it is important to mention that—unlike most other companies or software teams—we don’t pay attention to the following:

• Your geographic location;
• Skills and experience listed in your CV;
• Amount of time already spent on our projects;
• Age, sex, nationality, religious beliefs, etc.

Recently, I explained a fluent Java HTTP client created (mostly) to make HTTP interactions more object-oriented than with other available clients, including: Apache Client, Jersey Client and plain old HttpURLConnection.

This client ships in the jcabi-http Maven artifact. However, the client part is not the only benefit of using jcabi-http. Jcabi also includes a server component that can help you in unit and integration testing of your HTTP clients.

eXtremely Distributed Software Development, or XDSD for short, is a methodology that differs significantly from working in traditional software development teams. Most XDSD methods are so different (yet critical) that many newcomers get confused. This article should help you bootstrap once you join a project managed with by XDSD principles—either as a developer or a project sponsor.

This manual explains the workflow used when working with a XDSD project hosted on GitHub. You start when a GitHub issue is assigned to you. Next, you will receive a message from a project manager containing the issue number, title, description and its budget in hours (usually 30 minutes).

If you don’t agree with the budget allotment, don’t hesitate to ask for an increase. As soon as you are comfortable with the budget and understand the scope of the work, say so in a reply to the ticket and start working. Be aware that you won’t be paid for time spent above and beyond the allotted time budget.