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.

Definition Of Done

  • 307 words
  • two minutes to read
  • comments
badge

Definition of Done (DoD) is a key definition used in Scrum and the one we also use in XDSD.

DoD is an exit criteria of a simple atomic task and answers the question:"am I done with this task?" Moreover, DoD answers the question: "will I be paid for the task?"

In XDSD, the definition of "done" is very simple—the task is done iff its author accepts the deliverables.

Object-Oriented DynamoDB API

  • 485 words
  • two minutes to read
  • comments
badge

I'm a big fan of cloud computing in general and of Amazon Web Services in particular. I honestly believe that in a few years big providers will host all, or almost all, computing and storage resources. When this is the case, we won't have to worry too much anymore about downtime, backups and system administrators. DynamoDB is one of the steps towards this future.

No Obligations

  • 875 words
  • four minutes to read
  • comments
badge

It is a very common problem in project management—how to make team members more responsible and avoid micro management?

We start with creating plans, drawing Gantt charts, announcing milestones, motivating everybody and promising big bonuses on success.

Bugs Are Welcome

  • 530 words
  • two minutes to read
  • comments

The traditional understanding of a software defect (aka "bug") is that it is something negative and want to avoid in our projects. We want our projects to be "bug-free." Our customers are asking us to develop software that doesn't have bugs. And, we, as users, expect software to work without bugs.

Charlie and the Chocolate Factory (2005) by Tim Burton
Charlie and the Chocolate Factory (2005) by Tim Burton

But, let's take a look at bugs from a different angle. In XDSD, we say that "bugs are welcome." This means we encourage all interested parties to find bugs and report them. We want our team to see bugs as something that we need in our projects. Why?