A month ago I stumbled upon a problem: I wasn’t able to find a Ruby gem which would do in-memory caching with the capability to expire on timeout. After some quick research I decided to implement my own and called it Zache (as in “zero cache,” since there is no back end). Here is how it works:

In my previous article, I described how to set up a private Maven repository in Amazon S3 and deploy there via Rultor. This is a great solution if you’re familiar with managing Amazon Web Services (AWS), S3, and AWS Identity and Access Management (IAM). However, if you’re not comfortable administering an AWS account and all the related permissions, you may want to store your Apache Maven Artifacts in some cloud based repository manager instead. Here is how you make Rultor deploy your Maven dependencies to CloudRepo. I wrote this blog post together with Chris Shellenbarger, their founder.

Do you specify exact versions of your dependencies? I mean, when your software package depends on another one, do you write down, in your pom.xml, Gruntfile, Gemfile, or what have you, its version as 1.13.5 or just 1.+? I always thought that it was better to use exact version numbers, to avoid the so called dependency hell, and I was not alone. However, very soon I realized that dynamic versions, like 1.+, give more flexibility. Just a few weeks ago I realized that neither approach is right and found myself a hybrid formula.

США борется с нелегальной иммиграцией уже давно. Строительство забора между Калифорнией и Мексикой началось еще в 1993-м году. В 2006-м году Джордж Буш добавил к нему еще 900 километров укреплений, а совсем недавно к борьбе подключился Дональд Трамп. Наблюдая за его активностью в Twitter и Instagram, создается ощущение, что последние несколько месяцев вся Америка озабочена только одним: как спастись от нашествия мексиканцев. Других проблем нет? Почему так важна эта стена? Почему именно сейчас? Неужели, все так критично, что пришлось на целый месяц заблокировать работу правительства?

You most definitely have heard about 10x programmers. The gist of this folklore is that some of us coders are very effective (10 or even 100 times more so than others), while the rest are just “normal.” It is definitely not a myth though.

Досмотрел вчера сериал El Chapo (2017-2018), рассказывающий историю еще не оконченной жизни одного из самых успешных наркобаронов современности по имени Хоакин Гусман. Первый сезон оказался самым сильным, второй слабее, а третий удалось переварить только благодаря сюжетной линии Конрадо. Но речь сейчас не о кинематографе, а о наркотиках.

You most probably know what I think about the architect role on a software project—it’s that of a dictator who makes all technical decisions and who bears the entire responsibility for the final result. I wrote about it and even gave a talk Who is a Software Architect? at BuildStuff in 2016. However, the obvious question you may ask is: What happens if the architect is wrong? Does it mean the entire project is at risk of failure? And isn’t it better to make the whole team responsible for the result, instead of having one single point of failure?

Исторически государства были нужны, помимо прочего, для более эффективного ведения войн. Чем крупнее группа, тем легче ей было побеждать более мелких агрессоров, тем проще было захватывать прилегающие территории. Чтобы войну вести более эффективно, нужны были технологии, наука, образование, культура, медицина, и многое другое. Однако, все это можно было бы делать и без образования государств и установления между ними жестких границ. Страны, флаги, гимны, границы, и национальные интересы нужны там, где есть война. А она есть везде и всегда.

On a daily basis I deal with many programmers who contribute to my open source projects, either as volunteers or for money via Zerocracy (and my software projects are all open source). Over the years I have realized that there is a pattern in their behavior, which I need to be scared aware of. I call it “hazardous enthusiasm.” Here are the symptoms.

I speak at software conferences regularly. Over the last three years I spoke in 30 cities and 10 countries. I recorded almost all of them, you can see them here and on my YouTube channel. My principal rule is that I never give the same speech more than once. Every time it’s a new deck of slides and a new flow of thoughts. Of course, they all dance around the ideas I preach about, like Elegant Objects or rebellion against office slavery. I guess it’s time to share some of my secrets, mostly learned the hard way.

Silicon Valley is a great place to be … or maybe not. I’ve spent five years there, from 2011 till 2016. I did enjoy some parts of it, but others were not enjoyable at all. Here is a quick summary of what’s wrong with this territory. I can’t speak about the rest of the United States since, even though I’ve seen some other places, I’ve never lived there for more than a month. Long story short, the territory between San Francisco and San Jose, also known as Silicon Valley, is not the thing you see in the famous TV Series. It is absolutely different…

I wrote some time ago about anti-patterns in OOP. Now it’s time to write about unit testing anti-patterns—because they also exist, and there are many. I will try to include every example I know in this list. If you know any others, please add them via a pull request or post a comment below. For each anti-pattern I will try to mention where it was found, if it’s not mine. Keep in mind that if I found it somewhere, that doesn’t necessarily mean it was invented there. If you spot an error, please comment.

OK, it’s time to publish this piece. I’ve been dancing around it for quite a while, telling you how to make more per hour, how to manage those stupid managers that don’t let you grow, how to boost your career and how to deal with office slavery. Now here is a simple, plain list of recommendations for you: what you should do if you want to be a more successful programmer. Not a better algorithm designer, even though that’s important. Not a funnier clown team player, even though that’s also important. But a more successful software engineer, both financially and socially.

The outsourcing in combination with low-cost offshoring was a major trend in the software industry twenty years ago. Since then small groups of enthusiasts grew into large companies with thousands of employees and dozens of offices all over the world, like Wipro, EPAM, Luxoft, and others. Despite the obvious success, the future of software development may need a different business model, since clients’ requirements are rapidly changing. The market is quickly shifting towards more flexible work models, which compete with full-time office employment and time&material contracts.

This July, just four months ago, I submitted an article to InfoQ, a popular online tech magazine. In the article I suggested that in order to improve our projects we must not make programmers worry about the quality of code they write, but instead let them focus mostly on the speed of delivery. The quality, I argued in the article, must be the concern of the delivery pipeline. You have most probably already read the blog posts where I mention this idea, especially this one: Don’t Aim for Quality, Aim for Speed.

Bobby Fischer, the eleventh World Chess Champion, was one of the best chess players of the last century. Did you know that, along with anti-Semitic statements, he also said that women chess players “aren’t creative and are all fish”? Did you also know that he publicly described the 9/11 events as “wonderful news”?

Are you a Ruby developer? If you are, I’m pretty sure you have a very vague idea of what concurrency and thread safety are. No offense, but this is what I’ve figured out after dealing with Ruby code and speaking with Ruby programmers over the last half a year. I’ve been writing in Ruby pretty actively recently and I do like the language and the ecosystem around it. Zold, the experimental cryptocurrency we are creating, is written almost entirely in Ruby. What does that tell you? I like Ruby. But when it comes to concurrency, there are blank spots. Big time.

There are other products doing something similar, including MailChimp, AWeber, and many others. They are great. Maybe. I don’t really know. I tried some of them, some time ago. And I was frustrated. They are expensive, clumsy, and heavy. That’s my experience. I wanted something lightweight, where I can upload a list of emails, create a simple HTML/text letter, configure my SMTP outbound server, and call it a day. I spent a few days and created Mailanes. It’s free (for all of you), it’s simple, and it’s open source.

It’s Sunday. I’m at home, drinking tea and writing a new document for one of our future investors. One of my contacts in Telegram all of a sudden shoots me a message. I haven’t talked to this guy for at least two months. He is a software developer. I know him because he works at Zerocracy. His name is Paul.

I was explaining how Zerocracy works to one of our prospective clients yesterday. He texted me today: “[At Zerocracy] there is no commitment and anybody is free to leave any time, so the risk of entrusting a highly important project to such a platform and failing to deliver it on time is very high. We will develop it on our own with hired developers who will have salaries, and I’ll be architect and project manager, that way it will be under our entire control.” I think this word “control” he used deserves a comment.

Иосиф Сталин, по словам Александра Голованова однажды сказал: “Я знаю, что, когда меня не будет, не один ушат грязи будет вылит на мою голову. Но я уверен, что ветер истории всё это развеет.” Ветер истории — это мы с вами. А ушат грязи — это наши родители. Так он видел будущее из тяжелого 1943 года. Однако, случилось все наоборот: грязи у нас оказалось значительно больше, чем он ожидал от своих ближайших последователей, а ветра истории пока не слышно.

Referring to the latest news, we know that nowadays people prefer to work distantly and we also know that this is productive, according to a Stanford study that shows the astonishing productivity boost of working from home. Simon Slade in his recent post says: “Creating a positive work environment that responds to millennial desires will ensure that your business becomes a coveted place to work and hires only the best.”

Objects talk to each other via their methods. In mainstream programming languages, like Java or C#, an object may have a unique set of methods together with some methods it is forced to have because it implements certain types, also known as interfaces. My experience of speaking with many programmers tells me that most of us are pretty scared of objects that implement too many interface methods. We don’t want to deal with them since they are polymorphic and, because of that, unreliable. It’s a fair fear. Let’s try to analyze where it comes from.

There is a famous book by Robert Martin called Clean Code. The title is an obvious call to all of us: the code must be clean. Clean, like a kitchen, I suppose—there are no dirty dishes, no garbage on the floor, no smelly towels. Dirt to be cleaned in a code base, according to Martin, includes large methods, non-descriptive variable names, tight coupling, lack of SOLID and SRP compliance, and many other things. Read the book, it’s worth it. However, there is yet another aspect of source code. How clear is it?

Our Policy expects our developers to be fast. Section §36 pays for quicker delivery and §8 penalizes slow movers by removing them if they don’t close in ten days (at the time of writing). Why even ten days, if our tasks are so small? And how long does it really take to close an average task? Can we do something to close them sooner?

We all keep our code in Git version control repositories. The question is whether we should create a new repository for each new module or try to keep as much as possible in a single so called “monolithic” repo (or simply monorepo). Market leaders, like Facebook and Google, advocate the second approach. I believe they are wrong.

There are tech skills and there are soft skills. Every programmer knows that. Tech skills are about algorithms, operators, classes, objects, and everything else they teach us in tech schools. Soft skills are about something else. What exactly? Difficult to say. Let’s try to clear the air.

We at Zerocracy, as you know, are strong advocates of freedom and the “No Obligations” principle. You, as a developer, are supposed to work only when you feel like it. If you don’t like the task assigned to you, you simply refuse it. No strings attached. However, Zerocrat will penalize you for such a refusal with a few negative reputation points, according to the §6 of the Policy. Why so? Here is the logic explained.

Here is a simple principle for naming methods in OOP, which I’m trying to follow in my code: it’s a verb if it manipulates, it’s a noun if it builds. That’s it. Nothing in between. Methods like saveFile() or getTitle() don’t fit and must be renamed and refactored. Moreover, methods that “manipulate” must always return void, for example print() or save(). Let me explain.

A few days ago, a friend of mine asked me to join him in a new startup. He said that he needed a partner, to help him partially finance the project, promote it, bring in new ideas, and push the business forward. I liked the business idea and wanted to participate. I started to ask questions about our future partnership and attempted to draw a simple partnership agreement. He quickly got offended. He said that he was looking for a real partner, who would share his goals and would never require any papers or lawyers.

Here is how it goes, over and over again. I find a new developer for one of my projects managed by Zerocracy. He claims to be an expert with 10 years of hands-on coding experience, $60 hourly rate (we don’t hire US guys), and fluent English. Then he joins the project and attempts to close a few tickets. But he hardly can. For many reasons. Then he comes back and explains why our microtasking methodology doesn’t work, trying to convince me that I have to pay him per hour, instead of per result. Here is my answer.

Only lazy people haven’t written already about how global variables are evil. It started in 1973 when W. Wulf et al. claimed that “the non-local variable is a major contributing factor in programs which are difficult to understand.” Since then, many other reasons where suggested to convince programmers to stop using global variables. I think I read them all, but didn’t find the one that bothers me most of all: composability. In a nutshell, global variables make code difficult or impossible to compose in ways which are different from what its original author expected.

Over twenty five years ago, in 1992, at an OOPSLA workshop in Vancouver, Kent Beck, in answer to the question “What is an architect?” said, according to Philippe Kruchten, that it is “a new pompous title that programmers demand to have on their business cards to justify their sumptuous emoluments.” Not much has changed since then. There is a big difference between a smart programmer and a project architect. Here is a list of traits that, I believe, a good architect has.

You know what OAuth login is, right? It’s when your users click “login” and get redirected to Facebook, Twitter, Google, or some other website which then identifies them. Then they go back to your website and you know who they are. It’s very convenient for them. It’s convenient for you too, since you don’t need to implement the login functionality and don’t need to keep their credentials in a database. I created a simple Ruby gem to simplify this operation for GitHub only. Here is how it works.

I said earlier that constructors must be code-free and do nothing aside from attribute initialization. Since then, the most frequently asked question is: What about validation of arguments? If they are “broken,” what is the point of creating an object in an “invalid” state? Such an object will fail later, at an unexpected moment. Isn’t it better to throw an exception at the very moment of instantiation? To fail fast, so to speak? Here is what I think.

You know what NULL is, right? It’s evil. In OOP, your method can return NULL, it can accept NULL as an argument, your object can encapsulate it as an attribute, or you can assign it to a variable. All four scenarios are bad for the maintainability of your code—there are no doubts about that. The question is what to do instead. Let’s discuss the “return it” part and I will suggest one more “best practice” on top of what was discussed a few years ago.

A few weeks ago someone suggested I should try to integrate IntelliJ IDEA’s static analysis rules into Qulice, our aggregator of Checkstyle, PMD, FindBugs, and some other analyzers. I do love IDEA’s rules—some of them are unique and very useful. I asked whether I could find them somewhere in Maven Central (they are written in Java) and the answer was “You’ll have to figure out yourself how to use them, but they are open source.” Here comes my opinion about this situation: I believe that open source doesn’t just mean the code is readable without authorization. It means something much bigger.

You know, at Zerocracy, either you are a programmer or a tester, and we pay for each bug you find and report. Well, not quite. We pay for each bug report a project architect considers good enough to pay for. The architect’s decision is totally subjective and non-disputable, according to §29 of the Policy. Some of our developers find this unfair and ask me to explain how they can report bugs such that they are definitely paid. Here is a non-exhaustive list of my recommendations.

What frustrates me most in my profession of software development is the regular necessity to understand large problem scopes before fixing small bugs, especially if the code is legacy and not mine. Actually, it’s even more frustrating when the code is mine. The “deep thinking,” as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how.

I was asked on Twitter recently how is it possible to refactor if one doesn’t understand how the code works. I replied that it is “learning by refactoring.” Then I tried to Google it and found nothing. I was surprised. To me refactoring seems to be the most effective and obvious way to study the source code. Here is how I usually do it, in nine object-oriented steps.

Open source is free, as in beer: you write code, nobody pays you. Of course, there are many ways to monetize your efforts, but there will be no direct cash payments from your users, usually. There are ways to collect money, which include an obvious “tip jar” button on your GitHub project page. The chances anyone will pay are low though. In my opinion, this is mostly because nobody trusts you enough—they are not sure you will use the money to make the product better. Most likely you will just spend it and nothing will change. But they want the product, not to make you happier. At least that’s what I feel when I see a Patreon button.

I touched on this problem in one of my recent webinars, now it’s time to explain it in writing. Thread-safety is an important quality of classes in languages/platforms like Java, where we frequently share objects between threads. The issues caused by lack of thread-safety are very difficult to debug, since they are sporadic and almost impossible to reproduce on purpose. How do you test your objects to make sure they are thread-safe? Here is how I’m doing it.

Несколько недель назад в Лондоне был отравлен Сергей Скрипаль, его дочь, несколько полицейских и несколько десятков случайных прохожих. По информации британского премьер-министра Терезы Мэй отравлены они были газом “Новичок”, который мог быть произведен только в России. За этим последовали дипломатические санкции. Куда далее может завести этот конфликт, сейчас сложно прогнозировать. Интересно другое — что на самом деле произошло, и какой был план?

I’ve been in the software business for almost 30 years. I wrote my first piece of code when I was 12. Since then I have been programming and managing other programmers, hiring and firing them, planning projects and their budgets, finding and losing customers, investing into software teams and losing my investments, even teaching others how to manage software projects. What is my overall impression? It’s a pain. I think I’ve found a solution though.

Завтра в России выборы президента, на которых победит Владимир Путин. Это будет его четвертый президентский срок. Фактически он находится у власти уже 18 лет, начиная с момента ее захвата передачи в январе 2000 года. Почти 150 миллионов человек в территориально самой большой стране мира завтра в очередной раз выдадут этому человеку мандат на управление их судьбой. Трудно не согласиться, что это заслуживающий уважения результат. Как он это делает?

Fluent interface, first coined as a term by Martin Fowler, is a very convenient way of communicating with objects in OOP. It makes their facades easier to use and understand. However, it ruins their internal design, making them more difficult to maintain. A few words were said about that by Marco Pivetta in his blog post Fluent Interfaces are Evil; now I will add my few cents.

I decided to write this blog post after reviewing this pull request. What happened there? The author of the PR wasn’t able to figure out the “right” way to implement it, and the code reviewer was waiting and waiting. Eventually, the reviewer came to me, since I was an architect, and complained that it was taking too long and he wasn’t able to earn his money for the review he had done. Then the author of the changes explained that he couldn’t finish since there were impediments and design inconsistencies; he also couldn’t earn the money he deserved for fixing the issue. What did I say? I said: Forget the quality, just finish it any way possible.