www.yegor256.com Open in urlscan Pro
2606:50c0:8000::153  Public Scan

Form analysis
1 forms found in the DOM

GET https://www.google.com/search

<form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction">
  <meta itemprop="target" content="https://www.google.com/search?q={q}"> <input name="sitesearch" value="yegor256.com" type="hidden"> <input itemprop="query-input" type="text" id="search-query" class="field field-text" required="required"
    onfocus="$('.google').css('visibility', 'visible');" name="q" placeholder="Search..." autocomplete="off"> <input type="image" src="/images/google-search-icon.svg" class="google" title="Search via Google" alt="Search via Google">
</form>

Text Content

☰
Subscribe
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 

 * Home
 * 12 Best
 * All 378
 * Webinars
 * Talks
 * Books
 * Papers
 * Pets
 * Award
 * Testimonials
 * Shift-M
 * Art
 * Политика


 * Are you a computer scientist working on program analysis, code optimization
   and generation, bug detection, or program maintenance? Submit your paper to
   the 3rd ICCQ conference, co-organized by me and sponsored by IEEE. CFP closes
   on the 18th of December!
 * Are you familiar with open source and have a decent GitHub portfolio of
   contributions? I need freelancers, working remotely and paid by result, for
   EO, a new programming language. Email me, we'll discuss.


SMALLER TRY-BLOCKS ARE BETTER

 * 8 September 2022
 * 573 words
 * 3 minutes to read
 * 5 comments

It often happens, especially in Java, that a few places in the method are
potential exception originators. Usually, we make a large method-size try block
with a single catch at the bottom. We catch all the exceptions, usually even
using grouping. This helps us minimize the noise, which is the exception
catching. However, such large try blocks jeopardize maintainability: we are
unable to provide proper error context inside catch blocks.

Continue...


DON'T GROUP EXCEPTION CATCHERS

 * 30 August 2022
 * 668 words
 * 3 minutes to read
 * 2 comments

Sometimes we rethrow exceptions. In Java we do this more often than in other
languages, because it has checked exceptions. Sometimes we must catch and
rethrow a few exceptions that originated from different places in a method.
Java 7 introduced grouping of different types of exceptions in a single catch
block. But even without the grouping, it is possible to just catch IOException
or even Exception and provide a single catch block for all types and all
originators (methods that throw). Recently I realized that this is a bad
practice. Here is why.

Continue...


RESEARCH PAPER SIMPLE TEMPLATE

 * 24 August 2022
 * 878 words
 * 4 minutes to read
 * post a comment

My first academic paper was accepted and published in 1998. My most recent one
was rejected by SPLASH just a week ago. I’m writing two papers right now and
co-authoring about ten others. So far, my results are very poor: way more
rejections than I expected. The key lesson I’ve learned so far: the reason most
papers get rejected is not because they are essentially wrong. Instead,
reviewers reject them because they have no enthusiasm for decrypting a poorly
structured text, even though it may contain potentially interesting thoughts. In
this blog post I suggest how to structure a research paper. Take it with a grain
of salt though.

Continue...


DECLARATIVE AND IMMUTABLE PIPELINE OF TRANSFORMATIONS

 * 10 August 2022
 * 1212 words
 * 6 minutes to read
 * 22 comments

A few months ago I made a small Java library, which is worth explaining since
the design of its classes and interfaces is pretty unusual. It’s very much
object-oriented for a pretty imperative task: building a pipeline of document
transformations. The goal was to do this in a declarative and immutable way, and
in Java. Well, as much as it’s possible.

Continue...


THE CODE AND ITS TESTS IN DIFFERENT PULL REQUESTS

 * 4 August 2022
 * 592 words
 * 3 minutes to read
 * 9 comments

I suggested this idea a few weeks ago on Twitter and got mostly negative
reactions. That’s why I wrote this blog post, to elaborate on the subject in an
attempt to convince you. Here is the rule I’m suggesting: always submit changes
to the code separately from the changes to its unit tests. Simply put, in one
pull request you modify the tests, maybe marking some of them as “disabled.” You
merge this pull request and then make the second one, modifying the code and
most probably removing the “disabled” markers from the tests. You don’t touch
the body of the tests in the second pull request.

Continue...


COMMAND LINE DEFAULT OPTIONS IN LINEARIZED PLAIN TEXT

 * 20 July 2022
 * 505 words
 * 2 minutes to read
 * 11 comments

A few years ago I created xcop, a simple command line tool that can check the
style of an XML file. It’s similar to Checkstyle (for Java) and Pep8 (for
Python), but for XML. It’s pretty easy to use xcop: just run it with a few
command line arguments and it returns the list of errors found in your XML file,
if there are any. However, some of the arguments may be convenient to have as
defaults and instead of passing them through the command line on every
execution, we could store them in some configuration file. The question is: What
is the best format for this file? YAML, JSON, or TOML? None of them! I suggest
plain text.

Continue...


AUTOMATED TESTS ARE THE SAFETY NET THAT SAVES YOU

 * 5 July 2022
 * 694 words
 * 3 minutes to read
 * one comment

Automated tests are the ones that are usually called unit tests or integration
tests, or just any tests that are being executed automatically. That’s the
difference between them and manual tests. What is the purpose of automated
tests? First and foremost, they reduce the amount of routine work: we don’t need
to remember how to test a module, the tests remember. We just click a button and
a suite of tests, which may consist of hundreds or thousands, runs and reports
errors, if any are found. Saving time is important, but it’s not the only and,
if you ask me, not the most important purpose of automated tests. A more
important one is their role as a safety net.

Continue...


THE PRINCIPLE OF ONE

 * 14 June 2022
 * 341 words
 * 1 minutes to read
 * 5 comments

When I make a slide deck for a new presentation, invent a new domain name, think
about a name for a new Java class, itemize bullet points in an academic paper,
even write an email—I try to follow a simple principle which helps me make my
content more solid. Well, at least I believe it does. Maybe it will help you as
well. The principle is simple: at all costs, try to squeeze the content into one
word, one sentence, one paragraph, or one page.

Continue...


REFLECTION MEANS HIDDEN COUPLING

 * 5 June 2022
 * 2930 words
 * 16 minutes to read
 * 11 comments

Reflective programming (or reflection) happens when your code changes itself on
the fly. For example, a method of a class, when we call it, among other things
adds a new method to the class (also known as monkey patching). Java, Python,
PHP, JavaScript, you name it—they all have this “powerful” feature. What’s wrong
with it? Well, it’s slow, dangerous, and hard to read and debug. But all that is
nothing compared with the coupling it introduces to the code.

Continue...


BUGS OCCAM'S RAZOR

 * 29 March 2022
 * 484 words
 * 2 minutes to read
 * 10 comments

For each accepted explanation of a phenomenon, there may be an extremely large,
perhaps even incomprehensible, number of possible and more complex alternatives.
The principle of parsimony, also known as Occam’s razor, suggests we prefer the
simplest one. For example, “I can’t open the door and can’t attend the meeting”
is a description of a problem, which could be reduced to “I can’t open the door”
without losing any information, which might be important for those who are
waiting for me in the meeting room. I suggest applying the same principle to bug
reports.

Continue...


FALLACIES OF AI DRIVEN CODING

 * 16 February 2022
 * 949 words
 * 5 minutes to read
 * 9 comments

A few days ago, DeepMind (acquired by Google in 2014) released AlphaCode and
self-published a paper explaining how their artificial intelligence (AI) can
“understand” a programming contest task written in English and then write a
Python, Java or C++ program, which would work in about 30% of cases. Earlier
last year OpenAI ($1B-funded by Microsoft in 2019) released Codex and published
a paper, claiming that their AI can also solve around 30% of the programming
tasks it was tested with. Wired, the Financial Times, The Verge and many others
have already announced the victory: AI will replace programmers and we are all
going to lose our jobs.

Continue...


ACADEMIC TEACHING IS HARD

 * 1 December 2021
 * 1600 words
 * 8 minutes to read
 * 10 comments

A few months ago I got an opportunity to teach a single course for 3rd-year BSc
students at Innopolis University (Russia). The title was “System Software
Design.” The size of the group was about 150 people and the duration was 8
weeks. I was supposed to give them sixteen lectures, two lectures per week. And
I was asked to examine their knowledge by the end of the course. Pretty much a
normal job for a university teacher. And you know, in my opinion, I failed most
parts of it. Here is what I learned.

Continue...


OBJECTIONARY: DICTIONARY AND FACTORY FOR EO OBJECTS

 * 21 October 2021
 * 2429 words
 * 13 minutes to read
 * 5 comments

Since the time of Kernighan and Ritchie we share binary code in libraries. You
need to print some text with printf() in C++? You get libc library with 700+
other functions inside. You need to copy a Java stream? You get Apache Commons
IO with copy() and 140+ other methods and classes. The same happens in all
languages I’m aware of, like Ruby, Python, JavaScript, PHP: you need an object,
or a class, or a function, or a method—you have to add the entire library to
your build. Wouldn’t it be more elegant to deal with individual objects instead?

Continue...


CALIBRATED ACHIEVEMENT POINTS

 * 12 October 2021
 * 1314 words
 * 7 minutes to read
 * 12 comments

It’s a well-known problem nowadays: how can we measure the performance and
productivity of individual contributors who do non-routine creative work? The
best examples are research and development (R&D) teams, which usually consist of
software engineers, designers, scientists, architects, quality experts, product
managers, and so on. Such professionals deliver results that are hard to get
down to simple numbers. Many authors argue that the very idea of measuring
individual performance is toxic and may only lead to negative consequences. We
tried to challenge this point of view and did an experiment in our team, which
demonstrated that individual performance can indeed be measured, even if
people’s work involves creativity, and results are hard to predict. We designed
a system of Calibrated Achievement Points (CAPs), which are rewarded to those
who deliver visible and tangible results of different kinds. This article
explains how CAPs work and summarizes the results of the experiment.

Continue...


SIMBA: SIMPLIFIED MANAGEMENT BY ARTIFACTS

 * 9 September 2021
 * 1169 words
 * 6 minutes to read
 * 5 comments

Here is a very simple management framework, which we have used in our teams for
the last two years. We came to it experimentally, trying to merge some Agile
principles, PMBOK ideas, and common sense. Our experience so far is positive,
even though the proposed rules of work are not really about project management,
but more about keeping an eye on the situation and making sure it’s not falling
apart. This is the best most modern teams can afford anyway.

Continue...


LOGGING IN UNIT TESTS, A BAD PRACTICE

 * 11 August 2021
 * 779 words
 * 4 minutes to read
 * 6 comments

Logging is an inevitable part of debugging. Well, at least in modern high-level
programming languages and architectures. It wasn’t thirty years ago, in
Assembly, but it is now. Sometimes we trace variables, but rarely. More often we
just print them to console. Moreover, we don’t just print them using println or
whatever it is we have for console printing; instead, we send messages to a
logging framework, which deals with the console or any other logging
destinations, like files. The beauty of such frameworks is that we don’t need to
remove logging after debugging is finished—we just configure the framework to
suppress all debug-level messages in the production environment. Some logging
may happen inside unit tests. Do we also leave them there or maybe not?

Continue...


page 1 of 24