W3C Java Validators

  • 191 words
  • a minute to read
  • comments
badge

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();

XML/XPath Matchers for Hamcrest

  • 285 words
  • two minutes to read
  • comments
badge

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!']"
      )
    );
  }
}

Typical Mistakes in Java Code

  • 1099 words
  • five minutes to read
  • comments

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.

Incremental Requirements With Requs

  • 1070 words
  • four minutes to read
  • comments

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.

In XDSD projects we specify requirements using Requs, a controlled natural language that sounds like English, while at the same time is parseable by computers. A simple requirements document in Requs may look similar to:

Department has employee-s.
Employee has name and salary.
UC1 where Employee gets raise: "TBD."

This Software Requirements Specification (SRS) defines two types (Department and Employee) and one method UC (aka "use case").

Java XML Parsing Made Easy

  • 205 words
  • a minute to read
  • comments
badge

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>"
);

Basic HTTP Auth for S3 Buckets

  • 855 words
  • four minutes to read
  • comments
badge

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.

How Hourly Rate Is Calculated

  • 821 words
  • four minutes to read
  • comments
badge

In XDSD, everyone—including project managers, analysts, programmers, and product owners—receives payments based on deliverables with agreed upon budgets. In the fhe 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.

Mocking of HTTP Server in Java

  • 541 words
  • three minutes to read
  • comments
badge

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.

How XDSD Is Different

  • 1019 words
  • four minutes to read
  • comments
badge

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.

GitHub Guidelines

  • 887 words
  • four minutes to read
  • comments

This manual explains the workflow used when working with a XDSD project hosted on GitHub.com. 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.