Блокнотик Centaur’а

Какие есть хорошие инструменты для ревью кода?

Критерии хорошести, в нулевом приближении, следующие:

• Установка on-premise.
• Одно ревью может включать несколько коммитов из разных (но заранее известных) Git-репозиториев. Коммиты каждого репозитория линейно упорядочены. Для каждого файла в ревью ревьюер может смотреть дифф любого подинтервала по своему выбору. (Как в Crucible, если бы он порядок брал из графа, а не выводил из временных меток.)
• Коммент, не являющийся ответом на другой коммент, привязывается к произвольному, в общем случае не непрерывному, подмножеству строк файла. (Как в Crucible.)
• Работает подсветка синтаксиса как минимум для C++, Python’а, Go, шелла, XML, JSON и YAML. Распознавание того, какой синтаксис применять к файлу, работает более умно, чем просто по расширению (в частности, #!/usr/bin/python3 или #!/usr/bin/env python3 для файлов без расширения однозначно указывают на Python).
• Невозможна ситуация, когда отображается строка файла N (типично документационный комментарий) с комментом к ней и при этом существует и не отображается строка N+1 (типично заголовок или прототип функции с аргументами). (То есть не как в GitLab’е.)
• Работает скроллинг средней кнопкой в Firefox’е. (А не как в Crucible — {overflow-y: hidden; overflow-x: auto} и привет, средней кнопкой скроллится только в стороны.)

Большая зелёная кнопка «вмёржить это в master прямо сейчас не думая» категорически нафиг не нужна.

Спецификация JSON’а вмещается в пять страниц и её может читать пятиклассник. Однажды прочитанная, она укладывается в голову навсегда.

Спецификация YAML — это 84 страницы мелкого умного текста. Попробуйте запомнить, чем отличается unquoted, 'single-quoted', "double-quoted", | literal и > folded скаляры, и как в них работает удаление ведущих пробелов.

И ещё вот эта грабля с массивами и отображениями, эта дурацкая неоднородность в окрестности нуля:

# Массив из двух элементов
array2:
  - foo
  - bar

# Убираем один, получаем массив из одного элемента
array1:
  - foo
  #- bar

# Убираем один, получаем пустой массив?
array0:
  #- foo
  #- bar

# Отображение из двух ключей
map2:
  foo: bar
  baz: quux

# Убираем один, получаем отображение из одного ключа
map1:
  foo: bar
  #baz: quux

# Убираем один, получаем пустое отображение?
map0:
  #foo: bar
  #baz: quux

А вот фиг. Значения array0 и map0 — null.

Сейчас начнутся возражения, что если тебе нужен пустой массив или пустое отображение, то напиши [] или {} соответственно. Ну так продемонстрируйте, как это будет выглядеть в вышеприведённых примерах. Чтоб раскомментирование элемента немедленно приводило обратно к одноэлементной коллекции.

Опять-таки, если мы согласны писать скобки и запятые, почему мы не пишем JSON?

Синтаксис аргументов командной строки следует рассматривать и проектировать аналогично синтаксису человеческого языка. В частности, в нём бывают различные части речи и члены предложения.

Название бинарника может быть глаголом в повелительном наклонении (reboot) или существительным в роли обращения (firefox, git). В последнем случае отсутствие аргументов соответствует запуску приложения с пользовательским интерфейсом; если аргументы есть, то первый — это опять глагол в повелительном наклонении (git fetch).

Ключ без аргумента соответствует наречию, обычно в роли обстоятельства образа действия (--quietly, --verbosely; по истерическим перчинам устоялось написание без суффикса -ly).

Ключ с аргументом — это косвенное дополнение, где имя ключа играет роль предлога (install -t /usr/bin foo — установить в /usr/bin foo); или уточняющее родовое слово в составе прямого дополнения (install -d /var/lib/foo — установить каталог /var/lib/foo).

Позиционный аргумент — это прямое дополнение (git clone git://github.com/git/git.git).

Это, конечно, не все паттерны — что-то я наверняка упустил.

Базовый язык для команднострочного интерфейса — разумеется, английский. (Если бы командную строку изобрёл японец, глагол ставился бы последним, а sudo записывалось бы как 下さい [kudasai] после глагола.)

Собственно, я это всё к чему? У системы виртуализации/контейнеризации LXC есть команды lxc-start, lxc-stop и несколько других. И все они принимают название контейнера, над которым работать, именованным аргументом (lxc-start -n foo). Жутко бесит. Очевидно же, что это должно быть прямое дополнение.

Когда-то в прошлой жизни я сидел на Windows. Там был FAR. FAR был инструментом для всего.

Потом я пересел на X11/GNU/Linux. Там FAR’а нет. Есть отдельно Midnight Commander, у которого убогий редактор, и отдельно Emacs, у которого убогий файловый менеджер. Об Emacs’е я здесь и сейчас говорить не буду. Буду говорить о классе программ, позиционирующихся как файловые менеджеры. Говорить буду резко и в основном для себя и про себя. Всем остальным читателям к каждому высказыванию неявно добавлять «IMHO».

Итак, что такое файловый менеджер? Многие считают, что файловый менеджер — это две синие панельки, между которыми можно копировать файлы. Ну и изредка запускать команды шелла. А вот и ни фига.

Microsoft закрывает MSN Messenger, поэтому надо успеть.

У MSN Messenger’а были ужасные коды смайликов. Особенно вот эти меня бесили: Girl (X), Guy (Z), Thumb up (Y) и Thumb down (N). Потому что с ними любая математика с функциями и аргументами внезапно превращается в непонятно что.

А пересечься с смайликами MSN’а мне довелось, когда я пользовался одним из первых мультипротокольных instant messenger’ов — Trillian. Там смайлики задавались темой оформления, и многие темы были совместимы с MSN’ом.

В вебфорумостроительстве есть типичная холиварная тема: Плоские темы vs Древовидные темы. У того и другого подходов есть свои плюсы и минусы, мы их здесь обсуждать не будем.

Почти все почтовые клиенты сходятся в том, что email относится к Древовидным. (Единственное известное мне исключение — Gmail, который считает, что к Плоским.)

Далее, почти все клиенты, умеющие группировать письма, отображают их в виде, натурально, леса. Где сообщения — вершины, а рёбра выражают тот факт, что одно сообщение является ответом на другое (в терминах заголовка In-Reply-To).

Внимание, вопрос! Что не так на этой картинке?

Вынесено из комментов к посту vitus_wagner’а про pump.io.

Из опыта работы с MongoDB получается, что её писали вредители. Абсолютно весь API и дизайн заточен под то, чтобы как можно сильнее оградить клиентский код от возможности делать полезные запросы к базе и увеличить вероятность непреднамеренного уничтожения данных.

Типичный симптом при использовании Mongo — приложение работает, пока объём или количество документов в базе не превышает некоторого эпсилона, достаточно большого, чтобы проблемы не возникали в тестировании.

Иногда при разборе какого-нибудь проекта с кучей файлов бывает удобно посмотреть на общую картину — какие файлы зависят от каких других файлов. Это может быть надо для того, чтобы решить, в каком порядке их читать, или разрулить цикл в #include’ах.

Съездили в Красноярск на фестиваль интеллектуальных игр «Енисейская знать». 8 (из 38 команд) место в ЧГК, чуть-чуть не прошли в плейофф Брейн-ринга.

Вот чего я не понимаю: почему для обсчёта результатов ЧГК пишут специальную программу на Delphi, где достаточно было бы spreadsheet’а типа Excel’я или OpenLibreOffice Calc.