Просыпаешься в шаббат с мыслью заняться чем-нибудь бесполезным, но дрочащим ЧСВ.
Решаешь позадрачивать код кавераж на юнит-тестах.
Находишь опечатку в коде, доволен собой.
Удаляешь ненужный код. Снова доволен собой.
Решаешь покрыть тестом вот это вот условие.
ДВА ЧАСА ЕБЁШЬСЯ РАЗБИРАЯСЬ С ВЫЯВЛЕННОЙ ПРОБЛЕМОЙ.
РАЗОБРАВШИСЬ, ПОНИМАЕШЬ, ЧТО ПРОБЛЕМА НЕ АКТУАЛЬНА НА ПРОДАКШЕНЕ

позавчера вышла tika-1.9 наконец-то умеет толком извлекать всякую метаинфу из видеофайлов

Почему Base and Derived ковариантны, однако, shared_ptr<Base> and shared_ptr<Derived> - нет?

tfw кто-то в 2017 году всё ещё использует Closeable объекты вне try-with-resources

Угадайте не гугля откуда ента цитата:

Именно поэтому я считаю с++ программистов именно «Программистами» с большой буквы. Они как хирурги в современном мире программирования ) А остальные так… педиатры всякие, медбратья )

Чо там, в 2015 еще программируете на языках без декораторов?

public class AsyncLock
Можно было бы поставить тег */b/ если бы я это в репозиторий не запушил

Это чувство, когда JVM от IBM считает себя умнее тебя и приходится идти на ухищрения дабы его наебать и сэкономить памяти на долгоживущих строках:

$ cat Main.java
import java.lang.reflect.Field;

public class Main {
    public static void main(final String... args) throws Exception {
        Field f = String.class.getDeclaredField("value");
        f.setAccessible(true);
        StringBuilder sb = new StringBuilder(40);
        sb.append("01234567890123456789012345");
        String s1 = sb.toString();
        sb.append("hello, world!");
        String s2 = sb.toString();
        Object v1 = f.get(s1);
        Object v2 = f.get(s2);
        System.out.println(v1 == v2);
    }
}

$ javac Main.java
$ java Main
false
$ /opt/ibm/java-x86_64-80/bin/java Main
true

Собрал пакет отдал в тестирование.
Опередил тестировщиков, написал ещё кучу функционала, собрал новую версию пакета и отдал в тестирование.
Снова опередил тестировщиков, нашёл у себя багу стал готовить фикс.
Опередил самого себя и обнаружив, что бага — фича. Кажется.
Такая неделя.

protected Members:If members are declared as protected then these are accessible to all classes in the package and to all subclasses of its class in any package where this class is visible.

tfw программа указывает тебе на ошибки в твоём коде

интересная статья как в джаве вызвать незаоверрайженный метод родительского класса не из наследного класса: http://javachannel.org/posts/bypassing-subclass-method-overrides/

бывают дни, когда за один день с нуля целиком реализуешь какую-то нетривиальную фичу. ложишься спать довольным собой, но утром просыпаешься с пустой головой и отсутствием желания что-то делать. как побыстрее восполнить потраченные ресурсы мозга?

оказалось, что joda-time изкоробки нет метода у DateTimeFormatter, который бы максимальное быстро распарсил из строки столько сколько нужно, и вернул количество символов, на которое нужно отступить

the matasano crypto [http://cryptopals.com/](challenges)
Гоъ проходить.

У меня вопрос, но начну с введение в то как я до него дошёл.
Допустим, у нас есть какой-то коллбэк, в качестве примера возьмём FutureCallback из всячески уважаемой мной библиотеки HttpCore.
Допустим также, что мы угорели по асинхронности и поэтому после того как коллбэк завершил свою работу, мы хотим сообщить об этом куда следует. Например, чтобы там новый запрос запустили или ещё чего.
Наивная имплементация будет выглядеть примерно так:

public class CompletingFutureCallback<T> implements FutureCallback {
    private final FutureCallback<? super T> callback;
    private final Runnable completionCallback;

    public CompletionFutureCallback(
        final FutureCallback<? super T> callback,
        final Runnable completionCallback)
    {
        this.callback = callback;
        this.completionCallback = completionCallback;
    }

    @Override
    public void cancelled() {
        callback.cancelled();
        completionCallback.run();
    }

    @Override
    public void completed(final T result) {
        callback.completed(result);
        completionCallback.run();
    }

    @Override
    public void failed(final Exception e) {
        callback.failed(e);
        completionCallback.run();
    }
}

Зоркий глаз сразу скажет: А что если коллбэк был написан говнокодером и он кинет unchecked exception в ответ на вызов cancelled, completed или failed? Тогда completionCallback вызван не будет. Ладно, переделаем на finally. Далее уже рассматриваем рефакторинг одной функции, благо все они однотипные:

@Override
public void cancelled() {
    try {
        callback.cancelled();
    } finally {
        completionCallback.run();
    }
}

Зоркий глаз возразит ещё раз: А что если оба коллбэка написаны одним и тем же говнокодером и completionCallback.run() так же кинет unchecked exception? Да, после того как unchecked exception кинул callback.cancelled(). Даже если мы где-то снаружи ловим все Throwable, то информация о первом эксепшене будет безвозвратно потеряна.
В этот момент перфекционист вырывает клок волос из головы и призывает в помощь try-with-resources:

class Completer implements AutoCloseable {
    private final Runnable completionCallback;

    public Completer(final Runnable completionCallback) {
        this.completionCallback = completionCallback;
    }

    @Override
    public void close() {
        completionCallback.run();
    }
}

public class CompletingFutureCallback<T> implements FutureCallback<T> {
    …
    @Override
    public void cancelled() {
        try (Completer completer = new Completer(completionCallback)) {
            callback.cancelled();
        }
    }
    …
}

Вот теперь всё предельно корректно:
Если callback кинет исключение, то completer.close() так же будет вызван, и если он также кинет исключение, то это второе исключение будет добавлено к первому в список suppressed и при печати стек-трейса его будет видно и можно будет поанализировать.
Ну а если callback отработал как следует, то completer.close() так же будет вызван, а если исключение, if any, будет также проброшено наружу.

Посоветуйте годную гуглгруппу или иной ресурс, куда можно было бы запостить
пост со сравнением двух сходных идиом и чтобы получить нормальную дискуссию.
SO не подходит, потому что у меня скорее не вопрос, а приглашение к обсуждению.
В гуглгруппсы глянул и их там сотни и первые две на полнены вопросами типа
how to hide and show cursor in JTextField? и происками HR

Зачем вникать в суть проекта, пытаться проанализировать архитектурные решения, модульность,
выявлять недостатки с т/з безопасности,
когда можно просто сказать софт написан на питоне, C++, whatever и поэтому говно априорно?