Как обрабатывать ошибки в Golang – рассказываем на собственном примере

Для создания ошибки мы решили не делать отдельный конструктор, потому как структура не такая объемная. Для того чтобы разработчики не ошиблись при создании ошибки (например забыли & или не создали ошибку без Err и Message), мы используем собственный линтер для golangci-lint

Так если есть вещи которые важны при конструировании (обязательное поле Err и Message), может все таки есть смысл завести конструктор? Зачем валидировать линтером то, что можно повалидировать компилятором?

MVCC-5. Внутристраничная очистка и HOT

Благодарю и возьму на заметку!

MVCC-5. Внутристраничная очистка и HOT

Ответ описан в первых пару абзацах продолжения)

MVCC-5. Внутристраничная очистка и HOT

Егор, спасибо вам большое за ваш титанический труд!

У меня вопрос по очистке версий строк:

Итак, при следующем обращении к странице должна произойти внутристраничная очистка. Проверим это.

=> UPDATE hot SET s = 'E';
=> SELECT * FROM heap_page('hot',0);

 ctid  | state  |   xmin   | xmax  | hhu | hot | t_ctid
-------+--------+----------+-------+-----+-----+--------
(0,1) | dead   |          |       |     |     |
(0,2) | dead   |          |       |     |     |
(0,3) | dead   |          |       |     |     |
(0,4) | normal | 3982 (c) | 3983  |     |     | (0,5)
(0,5) | normal | 3983     | 0 (a) |     |     | (0,5)
(5 rows)

Все неактуальные версии строк (0,1), (0,2) и (0,3) очищены; после этого на освободившееся место добавлена новая версия строки (0,5).

Указатели на удаленные версии строк освободить нельзя, поскольку на них существует ссылки из индексной страницы.

А что будет с этими указателями? Они остаются в странице навсегда? Или в конечном итоге они тоже будут удалены? Если да, то каким образом? Спасибо

Две культуры программирования: почему обе из них важны?

Вообще, в первой культуре от ошибок защищаются статически…

Во второй культуре от ошибок защищаются статистически…

По моему опечатка?

Документирование кодовой базы. Зачем и как?

Тесты как документация — тема

Документирование кодовой базы. Зачем и как?

Документация должна ограничиваться описанием методов, параметров, эксшепшенов и т.п. Т.е. документация для автокомплита ИДЕ

Это один из тезисов, который я несу на протяжении всей статьи.

Проблема заключается в том, что всё очень индивидуально. Что одному очевидно, другому не понятно

Я согласен. Но ведь команда на то и команда — в ней должно быть как можно больше понимания и взаимодействия внутри. Нужно писать документацию так, чтобы понятно было всем. Для этого нужны обсуждения с коллегами (о чем я упомянул).

Всё встало на свои места, когда я его код увидел, он был усыпан документацией и выглядел так

В вашем примере я не вижу ни капли документации. Я вижу одни комментарии, которые создают шум (об этом я кстати тоже упомянул).

Документирование кодовой базы. Зачем и как?

«документация даже в коде требует поддержки»

Что значит даже? Любая документация несет за собой ответственность за ее поддержку, это очевидно. Независимо от того, в коде это документация, или вне.

«не все можно запихнуть в текст»

Пишите свой код так, чтобы текст комментариев не пришлось никуда «запихивать». Большую часть информации о коде должен предоставлять сам код.

90% документации реально никогда никому не нужно

От куда такая цифра? Проводились какие-то иследования?

Многопоточный HTTP-сервер с ThreadPool’ом и конечным автоматом

Когда я занимался написанием сервера, я не знал ни о пуле потоков, ни о конечном автомате, поэтому искал скорее «не так» а не «не там». За ссылки спасибо, буду смотреть)

Многопоточный HTTP-сервер с ThreadPool’ом и конечным автоматом

Причина — учебный проект)
Статья написана не написана на широкую публику и не показывает что-то новое. Статья скорее для тех кто так же, как и я в свое время, искал способы написания многопоточки в сервере.