The traditional way of integrating object-oriented back-end with an external system is through data transfer objects, which are serialized into JSON before going out and deserialized when coming back. This way is as much popular as it is wrong. The serialization part should be replaced by printers, which I explained earlier. Here is my take on deserialization, which should be done by—guess what—objects.

Most startups don’t have enough cash to pay programmers as much as they deserve, unfortunately (or maybe not). Instead of cash, startups give their early employees shares of stock, which they will be able to either 1) sell in a few years and become millionaires billionaires, or 2) throw away and remain nobodies. It’s a common practice. The question, however, is what is the right procedure, and the optimal algorithm, to transfer those shares to programmers. When exactly do they become shareholders? What is the formula?

A bug is something we find in a software product that “doesn’t look right” (this is my personal definition). A bug can be hidden or visible; it can be “already fixed” or “still present”; it can be critical or cosmetic; it can be urgent or of a low priority. What is important is that the more bugs we are able to find and fix before our customers see them, the higher the perceived quality of the software. Simply put, bugs are a very good thing, if they are found by us, not our customers. We pay our programmers for each bug they find. Here is a cheat sheet for them, showing where and how they can find those bugs, to make more money.

Software development and coding are two different things. Usually, the former includes the latter, but not always. Coding produces lines of code, while software development creates products. Unfortunately, the majority of programmers joining Zerocracy now are coders. Even though they claim to be developers, in reality they are lacking the very important sociotechnical skills that differentiate product creators from lines-of-code writers.

Very often new programmers who join our projects ask us whether we have auto-formatting instruments to make Java code look exactly the way Qulice expects. (Qulice is the static analyzer we use.) I always reply that having such an automated code polisher would only be harmful and wouldn’t help the project and its members improve and grow. Here is why I think so.

Говорят, что во времена холодной войны существовал План Даллеса, разработанный ЦРУ с целью уничтожения своего главного противника на геополитической арене — Советский Союз. Сработал ли именно этот план, существовал ли он вовсе, и был ли его автором Аллен Даллес — мы точно не знаем. Однако, СССР действительно развалился. Нечто подобное происходит сейчас с Россией — она движется к развалу, без видимой внешней причины. А может быть она есть и у нее существует план?

Microtasking, which I explained in an earlier post, works only when each task has a very specific reward for success and a punishment for failure. I believe that the best reward and punishment instrument is money. The budget is fixed, the programmer gets it only when the task is completed (reward), no matter how much time it costs; if it is not completed, there is no money at all (punishment). Pure and simple. However, a logical question arises: how can we know upfront what is the right budget? Who sets it?

Главной задачей любого государственного режима является выживание. Главной потенциальной угрозой этому всегда является народ, этим режимом угнетаемый. Наиболее активные и решительные представители народа, сплоченные вокруг единой цели, называются оппозицией. Переход оппозиции к решительным действиям выливается в митинги, демонстрации, забастовки, бунты и теракты. Неудачные попытки квалифицируются как государственный переворот и жестоко режимом наказываются. Удачные получают гордое имя Революция и празднуются. Новым режимом.

To instantiate objects, in most object-oriented languages, including Java, Ruby, and C++, we use operator new(). Well, unless we use static factory methods, which we don’t use because they are evil. Even though it looks so easy to make a new object any time we need it, I would recommend to be more careful with this rather toxic operator.

How do you define the quality of a software product? There is definitely an intrinsic emotional component to it, which means satisfaction for the user, willingness to pay, appreciation, positive attitude, and all that. However, if we put emotions aside, how can we really measure it? The IEEE says that quality is the degree to which a product meets its requirements or user expectations. But what is the formula? Can we say that it satisfies requirements and expectations to, say, 73%?

The Single Responsibility Principle, according to Robert Martin’s Clean Code, means that “a class should have only one reason to change.” Let’s try to decrypt this rather vague statement and see how it helps us design better object-oriented software. If it does.

From time to time someone asks me what I think about what Alan Kay, the father of OOP, the designer of Smalltalk, the first object-oriented language, said in 1998 about OOP. He literally said that the very term “object” was misleading and a more appropriate one would be “messaging.” Here is what I think.

Someone asked me what I think about DAO and I realized that, even though I wrote about ORM, DTO, and getters, I haven’t had a chance yet to mention DAO. Here is my take on it: it’s as much of a shame as its friends—ORM, DTO, and getters. In a nutshell, a Data Access Object is an object that “provides an abstract interface to some type of database or other persistence mechanism.” The purpose is noble, but the implementation is terrible.

“What are you doing now?”—when you hear this question from your boss, be aware: you’re dealing with a micromanager. Keeping us busy is the key objective of these creatures and this is what makes them so annoying. To the contrary, effective managers make sure we are productive, meaning that our results satisfy their expectations. They are not interested in knowing what we are doing to deliver them—they manage the project, instead of managing us. And the first step to making the project manageable is to decompose its scope into smaller pieces.

Меня недавно спросила одна знакомая, в оппозиции ли я к власти. Вопрос заставил меня задуматься, и очень скоро найденный ответ удивил мою собеседницу и немного меня самого. Я в оппозиции не к власти — я в оппозиции к своему народу. Не власть я вижу главным врагом, а наш собственный украинский народ. С ним я в непримиримой оппозиции. Его считаю виновником всех бед и его считаю необходимым срочно люстрировать.

“Listen up, dude,” a friend of mine said when he called yesterday, “I trusted them for over a year—we’ve been partners. They’ve been programming it all and I was busy doing business development. Now they’ve quit and I’m left with nothing! What am I supposed to do with all these JavaScript files? How do I even know they are mine? Moreover, they don’t even want to cooperate. I feel like a hostage. Please, help me out!” What could I say? “It’s too late, dude,” was my answer, “but the good news is—you are not the first to have this problem.”

I believe Joshua Bloch said it first in his very good book Effective Java: static factory methods are the preferred way to instantiate objects compared with constructors. I disagree. Not only because I believe that static methods are pure evil, but mostly because in this particular case they pretend to be good and make us think that we have to love them.

“Крым наш!” кричат с обеих сторон пропускного пункта “Чонгар” на границе между материковой Украиной и Крымом. Каждый имеет свои доводы, с которыми можно согласиться. Украина и ООН считают, что Крым был оккупирован, вопреки действующей Конституции Украины. Россия считает, что Крым лишь воспользовался своим правом на самоопределение, как и недавно Каталония. Кто прав? А так ли нам это важно? Какая нам разница, под властью Киева или Москвы находится полуостров?

I stumbled upon this proposal by Brian Goetz for data classes in Java, and immediately realized that I too have a few ideas about how to make Java better as a language. I actually have many of them, but this is a short list of the five most important.

Я недавно высказался против насильственной украинизации и вытеснения русской культуры с территории Украины, чем вызвал массу негативных комментариев от читателей, большинство которых сводились к одному: “не нравится — уезжай”. И лишь немногие поинтересовались, к чему конкретно я призываю, в чем мой конструктив? Я рад, что все же нашлись те, кто сумел за критикой увидеть невысказанный призыв к реальным действиям. Сейчас я его выскажу.

Пару дней назад один мой знакомый американец спросил меня, переживаю ли я за свою страну в связи с ее тяжелым положением. Он имел в виду и войну на Донбассе, и нынешнее экономическое состояние Украины, и все вместе взятое, как им это видится из-за океана. Я ответил, что своей эту страну не считаю, потому и переживать особо не за что. Он удивился. Патриотизм у американцев, видимо, в крови. У меня, видимо, нет. А должен быть?

You obviously know what lazy loading is, right? And you no doubt know about caching. To my knowledge, there is no elegant way in Java to implement either of them. Here is what I found out for myself with the help of Cactoos primitives.

The Streams API was introduced in Java 8, together with lambda expressions, just a few years ago. I, as a disciplined Java adept, tried to use this new feature in a few of my projects, for example here and here. I didn’t really like it and went back to good old decorators. Moreover, I created Cactoos, a library of decorators, to replace Guava, which is not so good in so many places.

Java 9 was released a few weeks ago. Check the release notes, they include many interesting features. However, I think that not everything is as good as Oracle and Java adepts seem to picture it. I see three trends in the Java world, which are good, bad, and ugly, respectively. Let’s start with the good one.

I have a number of data resources which exist in one place only and which I don’t really want to lose. For example, I have a hosted PHP website, and a MySQL database hosted at the same place. I also have a NoSQL database at Amazon DynamoDB, a PostgreSQL database at Heroku, and also… Well, there are many of them. How to back them up was always a question for me.

I wrote a number of sarcastic articles about management and motivation, where some traditional and very popular practices were criticized. Now I’ve decided to think it all over and summarize what actually motivates me as a programmer when I’m working for someone else. Let’s say you hire me tomorrow as a Java coder and ask “What do you want us to do for you so that you will be most productive?” This would be my wish list.

Some time ago we were talking about “-ER” suffixes in object and class names. We agreed that they were evil and must be avoided if we want our code to be truly object-oriented and our objects to be objects instead of collections of procedures. Now I’m ready to introduce a new evil suffix: Client.

I faced a problem a few weeks ago with 0pdd.com, one of my web apps that is supposed to receive HTTP requests (known as webhooks) from GitHub: sometimes the app is down, GitHub gets an HTTP error, and never sends the request again. The request simply gets lost. There is absolutely no way to receive it again once the app is back up. I realized that I needed a service mesh between GitHub and my web app, to accept HTTP requests and repeat them later if they can’t be delivered immediately.

One of the biggest advantages of XML versus many other data formats is that it is human-readable. Well, to some extent, you may say. Indeed, a badly formatted XML document may be rather difficult to digest. I’m not talking about XML validity now, but about its formatting style. Just like we format our Java/Ruby/Python nicely and then check their “prettiness” with static analyzers, we can also check our XML documents. Six years ago I asked the Stack Overflow community for such a tool, but unfortunately my question was down-voted and closed (you will need 10K+ reputation to see it). Last week I finally decided to create a tool myself and I called it xcop.

I stumbled upon this two-year-old article Why It’s Safe for Founders to Be Nice, written by Paul Graham (a co-founder of Y Combinator), whom I honestly respect, and I decided to explain why I disagree. Not that I think we shouldn’t be nice. Not at all. But I do think that “being nice” is not a solution for organizational, management, marketing, sales, or business development problems. Moreover, in most cases it is actually not safe for founders to be nice.

In September 2016 I paid Coinbase $1,222 for two BTCs, $611 each. Seven months later, in April 2017, they paid me back $2,490, which was $1,245 for each BTC. My profit before tax was $1,268, over 100% of the investment, in just seven months. Moreover, if I had waited until today, I would have made $6,800 profit instead. Actually, I still have a few BTCs in my Coinbase account and I can make that 750% profit, if I sell now. Should I? The BTC price is over $4,000. Will it go up? Or down? What would you do?