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).
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).
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?
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.