GitHub Guidelines

  • 887 words
  • four minutes to read
  • comments

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

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

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

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?

PDD by Roles

  • 1769 words
  • 7 minutes to read
  • comments

In this post, I'll try to walk you through a project managed with the spirit of Puzzle Driven Development (PDD). As I do this, I will attempt to convey typical points of view of various project members.

Basically, there are a few key roles in any software team:

  • Project Manager—assigns tasks and pays on completion
  • System Analyst—documents the product owner's ideas
  • Architect—defines how system components interact
  • Designer—implements most complex components
  • Programmer—implements all components
  • Tester—finds and reports bugs

Everybody, except the project manager, affects the project in two ways: they fix it and they break it at the same time. Let me explain this with a simple example.

Fluent Java HTTP Client

  • 515 words
  • two minutes to read
  • comments

In the world of Java, there are plenty of HTTP clients from which to choose. Nevertheless, I decided to create a new one because none of the other clients satisfied fully all of my requirements. Maybe, I'm too demanding. Still, this is how my jcabi-http client interacts when you make an HTTP request and expect a successful HTML page in return:

String html = new JdkRequest("")
  .uri().path("/users").queryParam("id", 333).back()
  .header("Accept", "text/html")

I designed this new client with the following requirements in mind:

How Much Do You Pay Per Line of Code?

  • 832 words
  • four minutes to read
  • comments

Yes, I know, "line of code" (LoC) is a very wrong metric. There are tons of articles written about it, as well as famous books. However, I want to compare two projects in which I have participated recently and discuss some very interesting numbers.

Xembly, an Assembly for XML

  • 677 words
  • three minutes to read
  • comments

I use XML in almost every one of my projects. And, despite all the fuss about JSON/YAML, I honestly believe that XML is one of the greatest languages ever invented. Also, I believe that the beauty of XML reveals itself when used in combination with related technologies.

For example, you can expose your data in XML and render it for the end-user using XSL stylesheet.

PhantomJS as an HTML Validator

  • 400 words
  • two minutes to read
  • comments

I created a few months ago, but yesterday finally found the time to make some needed changes to it. So, now is a good time to explain how I'm using Phandom in some of my unit tests.

Before I get started, though, I should say a few words about phantomjs, which is a JavaScript interface for WebKit. WebKit, on the other hand, is a web browser without a user interface. WebKit is a C++ library that enables manipulation of HTML content, through DOM calls. For example, this is a simple JavaScript located code in example.js:

var page = require('webpage').create();
  function() {

We run phantomjs from the command line with the following code:

$ phantomjs example.js

PhantomJS creates a page object (provided by webpage module inside phantomjs), and then asks it to open() a Web page. The object communicates with WebKit and converts this call into DOM instructions. After which, the page loads. The PhantomJS engine then terminates on line 6.