Lines-of-Code (aka SLoC) is a metric with a terrible reputation. Try to google it yourself and you’ll find tons of articles bad-mouthing about its counter-effectiveness and destructiveness for a software development process. The main argument is that we can’t measure the progress of programming by the number of lines of code written. Probably the most famous quote is attributed to Bill Gates:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight

Basically, this means that certain parts of the aircraft will take much more effort at the same time being much lighter than others (like a central computer, for example). Instead of measuring the weight of the aircraft we should measure the effort put into it… somehow. So, here is the idea. How about we measure the amount of times programmers touch the lines. Instead of counting the number of lines we’ll count how many times they were actually modified—we can get this information from Git (or any other SCM). The more you touch that part of the aircraft—the more effort you spent on it, right?

In a few recent posts, including Getters/Setters. Evil. Period. Objects Should Be Immutable, and Dependency Injection Containers are Code Polluters, I universally labeled all mutable objects with “setters” (object methods starting with set) evil. My argumentation was based mostly on metaphors and abstract examples. Apparently, this wasn’t convincing enough for many of you—I received a few requests asking to provide more specific and practical examples.

Thus, in order to illustrate my strongly negative attitude to “mutability via setters,” I took an existing commons-email Java library from Apache and re-designed it my way, without setters and with “object thinking” in mind. I released my library as part of the jcabi family—jcabi-email. Let’s see what benefits we get from a “pure” object-oriented and immutable approach, without getters.

The subject may sound like a joke, but it is not. An empty line, used as a separator of instructions in an object method, is a code smell. Why? In short, because a method should not contain “parts.” A method should always do one thing and its functional decomposition should be done by language constructs (for example, new methods), and never by empty lines.

I’m getting a few emails every day from programmers interested in working with Zerocracy remotely. The first question I usually ask is “what is your rate?” (we pay by the hour) What surprises me is how often people incorrectly estimate themselves, in both directions.

I hear very different numbers, from $5 to $500 per hour. I never say no, but usually come up with my own hourly rate estimate. This article explains what factors I do and don’t take into account. These are my personal criteria; don’t take them as an industry standard. I do find them objective and logical, though—so let me explain.

Twenty years ago, the best programmer was the one capable of fitting an entire application into a 64Kb .COM file. Those who were able to get the most out of that poor Intel 80386 were the icons of programming.

That’s because twenty years ago computers were expensive and programmers were cheap. That was the time of the “hacker mentality.” That time is over. That mentality is not appreciated any more, because the market situation is completely opposite.

Today, computers are cheap and programmers are expensive. This is the era of the “designer mentality,” when the readability of our code is much more important than its performance.

Here is a notation rule I’m using in Java code: a bracket should either start/end a line or be paired on the same line.

The notation applies universally to any programming language (incl. Java, Ruby, Python, C++, PHP, etc.) where brackets are used for method/function calls.

Here is how your code will look, if you follow this “Paired Brackets” notation:

new Foo( // ends the line
  Math.max(10, 40), // open/close at the same line
  String.format(
    "hello, %s",
    new Name(
      Arrays.asList(
        "Jeff",
        "Lebowski"
      )
    )
  ) // starts the line
);

When you hire a software developer (individual or a team), there are basically two types of contracts: fixed price or time-and-material. They are fundamentally different but the truth is that in either case—you lose.

In the eXtremely Distributed Software Development (XDSD) methodology everything is different, including the way we invoice our clients. Let’s see what happens in traditional contracts and what changes in XDSD, which we practice in Zerocracy.

Every software project we work with is started from a Product Vision document. We create it during our Thinking phase. Even though the document is as short as two pages of English text, its development is the most painstaking task in the whole project.

There are a few tricks and recommendations which I’d like to share.

We usually design a Product Vision in four sections: product statement, stakeholders and needs, features, and quality requirements.

Do you have a software architect in your project? Do you need one? Well, most agile teams do not define such a role explicitly and work in a democratic mode. Every important technical decision is discussed with the entire team, and the most voted for solution wins. When such a team eventually decides to put a “software architect” badge on someone’s t-shirt, the most reputable programmer gets it.

A few days ago, my article Why Continuous Integration Doesn’t Work was published at DevOps.com. Almost the same day I received a few strongly negative critiques on Twitter.

Here is my response to the un-asked question:

Why the hell shouldn’t continuous integration work, being such a brilliant and popular idea?

Even though I have some experience in this area, I won’t use it as an argument. I’ll try to rely only on logic instead.

The first principle of eXtremely Distributed Software Development (XDSD) states that “everyone gets paid for verified deliverables.” This literally means that, in order to get paid, every programmer has to write the code, commit it to the repository, pass a code review and make sure the code is merged into the destination branch. Only then, is his result appreciated and paid for.

In addition to being a hands-on programmer, I’m also co-founder and CTO of Zerocracy, a custom software development company. I play the role of a technical and management leader in all projects we work with.

I wrote this article for those who’re interested in hiring me and/or my team. This article will demonstrate what happens from day one until the end of the project, when you choose to work with us.

You will see below that our methods of software development seriously differ from what many other teams are using. I personally pay a lot of attention to quality of code and quality of the internal processes that connect our team.

Every project I’m working with starts with a setup of continuous integration pipeline. I’m a big fan of cloud services, that’s why I was always using Travis. A few of my clients questioned this choice recently, mostly because of the price. So I decided to make a brief analysis of the market.

I configured Rultor, an open source project, in every CI service I managed to find. All of them are free for open source projects. All of them are hosted and do not require any server installation Here they are, in order of my personal preference (first four are the best and highly recommended):

	Minimum price	Linux1	Windows2	MacOS3	Pull requests4	Log compress5	Docker6	Build
Shippable☺	free (!)
Travis	$69/mo
AppVeyor	$39/mo					?	---
Wercker	$350/mo
SemaphoreApp	$29/mo
Snap-CI☺	$30/mo					?
Codeship☺	$49/mo				?
CircleCI☺	$19/mo
SonoLabs	$15/mo					?
DeployBot	$15/mo				?	?
Vexor	¢90/hr				?	?
GreenHouseCI	$49/mo				?	?

While dependency injection (aka, “DI”) is a natural technique of composing objects in OOP (known long before the term was introduced by Martin Fowler), Spring IoC, Google Guice, Java EE6 CDI, Dagger and other DI frameworks turn it into an anti-pattern.

Monetary rewards for employees. Do they work? Should we use them? Can money motivate creative minds? Will a programmer work better if he gets paid only when he reaches his goals and objectives?

Much research has already been done on this subject, and most of it proves that connecting results with money is a very demotivating approach. For example, Ian Larkin says that the most productive workers “suffered a 6-8% decrease in productivity after the award was instituted.”

I believe this is completely true. Money may become a terrible de-motivator for all modern employees (not just programmers).

My question is—why is this so?

While mock objects are perfect instruments for unit testing, mocking through mock frameworks may turn your unit tests into an unmaintainable mess. Thanks to them we often hear that “mocking is bad” and “mocking is evil.”

The root cause of this complexity is that our objects are too big. They have many methods and these methods return other objects, which also have methods. When we pass a mock version of such an object as a parameter, we should make sure that all of its methods return valid objects.

This leads to inevitable complexity, which turns unit tests to waste almost impossible to maintain.

There is an old debate, started in 2003 by Allen Holub in this Why getter and setter methods are evil famous article, about whether getters/setters is an anti-pattern and should be avoided or if it is something we inevitably need in object-oriented programming. I’ll try to add my two cents to this discussion.

The gist of the following text is this: getters and setters is a terrible practice and those who use it can’t be excused. Again, to avoid any misunderstanding, I’m not saying that get/set should be avoided when possible. No. I’m saying that you should never have them near your code.

There were a few articles already about our usage of Rultor for automating continuous delivery cycles of Java and Ruby projects, including RubyGems, CloudBees and Maven Central.

This one describes how Heroku deployment can be automated. When I need to deploy a new version of an Aintshy web application, all I do is create one message in a GitHub ticket. I just say @rultor release 0.1.4 and version 0.1.4 gets deployed to Heroku. See GitHub ticket #5.

You can do the same, with the help of Rultor.com, a free hosted DevOps assistant.

When I explain how Rultor automates deployment/release processes, very often I hear something like:

But I already have a script that deploys everything automatically.

This response is very common, so I decided to summarize my three main arguments for automated Rultor deployment/release processes in one article: 1) isolated docker containers, 2) visibility of logs and 3) security of credentials.

Read about them and see what Rultor gives you on top of your existing deployment script(s).

Here they come:

• NULL References

• Utility Classes

• Mutable Objects

• Getters and Setters

• Data Transfer Object (DTO)

• Object-Relational Mapping (ORM)

• Singletons

• Controllers, Managers, Validators

• Public Static Methods

• Class Casting

• Traits and Mixins

Look at GitHub RESTful API, for example. To get information about a repository you should make a GET request to api.github.com/repos/yegor256/rultor. In response, you will get a JSON document with all the details of the yegor256/rultor repository. Try it, the URL doesn’t require any authentication.

To open the same repository in a nice HTML+CSS page, you should use a different URL: github.com/yegor256/rultor. The URL is different, the server-side is definitely different, but the nature of the data is exactly the same. The only thing that changes is a representation layer.

In the first case, we get JSON; in the second—HTML.

How about combining them? How about using the same URL and the same server-side processing mechanism for both of them? How about shifting the whole rendering task to the client-side (the browser) and letting the server work solely with the data?

An execution of a shell command via SSH can be done in Java, in just a few lines, using jcabi-ssh:

String hello = new Shell.Plain(
  new SSH(
    "ssh.example.com", 22,
    "yegor", "-----BEGIN RSA PRIVАTE KEY-----..."
  )
).exec("echo 'Hello, world!'");

jcabi-ssh is a convenient wrapper of JSch, a well-known pure Java implementation of SSH2.

Docker starts a process inside its container as a “root” user. In some cases, this is not convenient though. For example, initdb from PostgreSQL doesn’t like to be started as root and will fail. In rultor.com, a DevOps team assistant, we’re using Docker as a virtualization technology for every build we run.

Here is how we change the user inside a running container, right after it is started.

When I release a new version of jgd, a Ruby gem, to RubyGems.org, it takes 30 seconds of my time. Here is how I released a bug fix for version 1.5.1, in GitHub issue #6:

As you see, I gave a command to Rultor, and it released a new version to RubyGems. I didn’t do anything else.

Now let’s see how you can do the same. How you can configure your project so that the release of its new version to RubyGems.org takes just a few seconds of your time.

When I deploy a new version of stateful.co, a Java web application, to CloudBees, it takes 30 seconds of my time. Maybe even less. Recently, I deployed version 1.6.5. You can see how it all happened, in GitHub issue #6:

As you see, I gave a command to Rultor, and it packaged, tested and deployed a new version to CloudBees. I didn’t do anything else.

Now let’s see how you can do the same. How you can configure your project so that the deployment of its new version to CloudBees takes just a few seconds of your time.

“The Art of Software Testing”” by Glenford J. Myers, Tom Badgett and Corey Sandler is one of my favorite books concerning testing and software engineering in general. In this article, I will provide an overview of the book, as well as highlight the ideas and quotes that I found to be the most interesting.

When I release a new version of jcabi-aspects, a Java open source library, to Maven Central, it takes 30 seconds of my time. Maybe even less. Recently, I released version 0.17.2. You can see how it all happened, in GitHub issue #80:

As you see, I gave a command to Rultor, and it released a new version to Maven central. I didn’t do anything else.

Now let’s see how you can do the same. How you can configure your project so that the release of its new version to Maven Central takes just a few seconds of your time.

This is how you fetch text from a SQL table with jcabi-jdbc:

String name = new JdbcSession(source)
  .sql("SELECT name FROM employee WHERE id = ?")
  .set(1234)
  .select(new SingleOutcome<String>(String.class));

Simple and straight forward, isn’t it? The library simplifies interaction with relational databases via JDBC, avoiding the need to use ORM.

If you have a method that fails occasionally and you want to retry it a few times before throwing an exception. @RetryOnFailure from jcabi-aspects can help. For example, if you’re downloading the following web page:

@RetryOnFailure(
  attempts = 3,
  delay = 10,
  unit = TimeUnit.SECONDS
)
public String load(URL url) {
  return url.openConnection().getContent();
}

This method call will throw an exception only after three failed executions with a ten seconds interval between them.

There are many tools that control the quality of Java code, including Checkstyle, PMD, FindBugs, Cobertura, etc. All of them are usually used to analyze quality and build some fancy reports. Very often, those reports are published by continuous integration servers, like Jenkins.

Say, you have a method that takes time to execute and you want its result to be cached. There are many solutions, including Apache Commons JCS, Ehcache, JSR 107, Guava Caching and many others.

jcabi-aspects offers a very simple one, based on AOP aspects and Java6 annotations:

import com.jcabi.aspects.Cacheable;
public class Page {
  @Cacheable(lifetime = 5, unit = TimeUnit.MINUTES)
  String load() {
    return new URL("http://google.com").getContent().toString();
  }
}

The result of load() method will be cached in memory for five minutes.

Rultor is a coding team assistant. Travis is a hosted continuous integration system. In this article I’ll show how our open source projects are using them in tandem to achieve seamless continuous delivery.

I’ll show a few practical scenarios.