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.

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.

This looks cool - jcabi-dynamo - a #Java Object layer atop the #DynamoDB SDK - http://t.co/khRFR2joKX #aws

— Jeff Barr ☁️ (@jeffbarr) September 19, 2013

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.

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.

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?

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.

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("https://www.google.com")
  .uri().path("/users").queryParam("id", 333).back()
  .method(Request.GET)
  .header("Accept", "text/html")
  .fetch()
  .as(RestResponse.class)
  .assertStatus(HttpURLConnection.HTTP_OK)
  .body();

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

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.

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.

I created phandom 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();
page.open(
  'http://google.com',
  function() {
    console.log('loaded!');
    phantom.exit(0);
  }
);

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.

Sometime ago, I recommended a list of movies to a friend of mine after he told me was losing all interest in “Hollywood.”

Level C titles are supposed to be impossible to understand unless you’ve seen (and understood) their prequels—listed in sections A and B. So, start browsing the lists in sections A and post your comments if you have any.

Level A

• True Romance (1993)
• Pulp Fiction (1994)
• Kill Bill (2003)
• Doberman (1997)
• La fille sur le pont (1999)
• Irreversible (2002)
• Fear and Loathing in Las Vegas (1998)
• Perdita Durango (1997)
• Golden Balls (1993)
• The Million Dollar Hotel (2000)
• Y Tu Mamá También (2001)
• Reservoir Dogs (1992)
• Trainspotting (1996)
• Fight Club (1999)
• Arizona Dream (1992)
• Black Cat, White Cat (1998)
• Buffalo ‘66 (1998)
• Jamon Jamon (1992)
• Natural Born Killers (1994)
• Thursday (1998)
• Bullet (1996)

This is the first post on my new blog. Therefore, it’s not about anything in particular—just an introduction and my way of saying hello. This blog will be primarily about software development ideas. As my About Me page says, I’m passionate about software quality, and will write solely about my ideas and views on it.

Anyway, welcome to my new blog. Together, let’s see how this works out!