yurikhan: (Default)

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

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

  • Установка 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 прямо сейчас не думая» категорически нафиг не нужна.

yurikhan: (Default)

Бритва Постела наоборот:

  • Принимай на вход всё, что разрешено спецификацией, но не больше.
  • Производи на выходе максимально возможное разнообразие в рамках спецификации.

Софт, который в этих условиях выживет, — будет супернадёжен и при этом корректен.

yurikhan: (Default)

Спецификация 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 и map0null.

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

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

yurikhan: (Default)
while not done():
    task = pop(queue)
    try:
        do(task)
    except Exception as e:
        log("Cannot do %s: %s", task, e)
        # possibly sleep(5)
        # possibly push(queue, task)

Что не так на этой картинке?

Read more... )
yurikhan: (Default)

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

Название бинарника может быть глаголом в повелительном наклонении (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). Жутко бесит. Очевидно же, что это должно быть прямое дополнение.

yurikhan: (Default)

Раздаточный материал: Описание протокола WialonRetranslator 1.0 (PDF, 156K, 3 не очень плотных страницы)

Задача 1: Перечислите ошибки, допущенные при документировании этого протокола.

Задача 2*: Перечислите ошибки, допущенные при проектировании этого протокола.

Комменты не скринятся. Ответы выложу через пару-тройку дней.

Upd: [livejournal.com profile] kgeorgiy нашёл практически все ошибки документирования.

Ответы )

Вот с такой фигнёй иногда приходится работать.

yurikhan: (Default)

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

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

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

Read more... )
yurikhan: (Default)

До чего же всё плохо с тем, что называется syndication.

Во-первых, читалки. Подавляющее большинство — на PHP с базой MySQL. В лучшем случае — с PostgreSQL, но всё равно PHP. Есть одна на Go с базой Google App Engine Datastore. What is this I don’t even. (Нет, десктопные читалки рассматривать принципиально не будем, потому что они не дают гарантию непропуска постов.)

Казалось бы, чего сидишь, ниша открыта, напиши RSS-читалку с архитектурой, которая не будет оскорблять твои чувства.

Да только дело в том, что сами форматы данных (RSS 0.9, RSS 1.0, RSS 0.91, RSS 2.0 и Atom вместе с ними) — тяжело больны антипаттерном «само выросло». Сначала у item’ов вообще были только название и ссылка. Потом добавилось описание, предполагаемое коротким и неформатированным. Потом внезапно оказалось, что люди пихают туда HTML! Иногда даже забывая сохранить well-formedness окружающего XML’я. Окей, сняли ограничения на длину, задокументировали, что блин, раз уж вы туда пишете HTML, то эскейпьте его по правилам XML’я. Ну и под конец Atom — «пишите хоть плейн текст, хоть заэскейпленный HTML, хоть валидный XHTML, но явно подпишите, какой именно формат вы используете».

Естественно, при прочих равных софт на стороне производителя генерирует тот формат, к которому проще привести входные данные. А входные данные у большинства[citation needed] блогов — не валидируемый и потому массово невалидный HTML. '<[CDATA[' + post_body + ']]>' и не волнует, пусть кто-то другой с этим потом мучается.

Поэтому всякий, кто решает сейчас писать RSS-читалку, через некоторое время погружается в бочку этого самого… дёгтя.

Пойду засуну свой инстанс Tiny Tiny RSS в контейнер от греха подальше. Тем более что оно, оказывается, перешло с нормальной модели релизов «вот вам полурегулярные orig.tar.gz, собирайте себе пакеты под что хотите» на rolling-модель «текущая стабильная версия — это то, что сейчас в master’е».

yurikhan: (Default)

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

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

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

yurikhan: (Default)

Есть ровно один канонический интерфейс парсера. На вход подаётся строка или поток символов, на выходе — одно из трёх:

  • распарсенный объект и остаток входной строки;
  • распарсенный объект и пустая строка, если ничего лишнего не осталось;
  • объект ошибки с указанием места во входной строке.

Если вы парсер и ваш интерфейс не позволяет различить первые две ситуации, то эти лучи поноса — вашему разработчику.

#ненависть #mongo #jsoncpp #wellknown

yurikhan: (Default)

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

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

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

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

Read more... )
yurikhan: (Default)

Прошу совета у опытных людей.

Вот есть аккаунт на корпоративном IMAP-сервере. В него сыплются письма по разным проектам, иногда много. Если за этим не следить, то скоро они перемешиваются и хрен что найдёшь. Даже с message threading’ом.

Хочется мочь из всей этой помойки выбрать письма, относящиеся к конкретному проекту, по следующим правилам:

  1. Письмо, имеющее в сабжекте имя проекта, относится к этому проекту. (Это идеальный, но недостижимый случай — реальные люди не пишут точное машиночитаемое имя проекта в сабже.)
  2. Письмо, которое я пометил руками, относится к проекту. (Это видится как необходимый и достаточный ручной труд.)
  3. Ответ на письмо, относящееся к проекту, также относится к проекту. (Вот это хочется энфорсить автоматически.)

Механизм сознательно не фиксирую. Это могут быть IMAP-серверные папки, IMAP keyword’ы, клиент-сайд-тэги и т.п. Допускаю переезд с Thunderbird’а на другой клиент, работающий под X11/GNU/Linux.

Хм, нашёл похожую на нужную функциональность в Evolution’е, хоть он монструозен и гномообразен. Держим всё в Inbox’е, создаём лейблы для всех проектов, создаём поисковые фолдеры с условиями «Include threads: All related», «Label is имя проекта» и «Search Folder Sources: Specific folders: Inbox».

yurikhan: (Default)

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

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

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

Обоснование )
yurikhan: (Default)

Поскольку скоро о Winamp’е можно будет говорить либо хорошо, либо ничего, то нужно успеть сейчас.

Именно Winamp виновен в двух преступлениях против человечества:

  1. Зоопарк кодировок в ID3-тэгах. По спецификации в ID3v2 допустимы ISO 8859-1 и три вида юникода. А он туда писал текущую ANSI-кодировку винды, маркируя её как ISO 8859-1.
  2. Популяризация скинованных интерфейсов. Именно после Winamp’а разработчики стали массово нарушать гайдлайны UI, оправдываясь тем, что «это работает».
yurikhan: (Default)

За пару недель по вечерам и две недели отпуска:

  • вспомнил детство, восьмибитные игрушки процессоры;
  • дизассемблировал/декомпилировал прошивку своей клавиатуры;
  • нашёл в ней недокументированную фичу (программируемые макросы) и баг в её реализации;
  • поверхностно познакомился со спецификациями USB и HID;
  • переделал обработку медиаклавиш, Num Lock’а и клавиши Fn на схему, более подходящую для кастомизации раскладок;
  • написал веб-приложение для кастомизации;
  • собрал, прошил и протестировал;
  • выложил всё на GitHub.

По мере прогресса описывал свои находки на форуме GeekHack (тут и далее в теме), в результате чего мне (в личку) написали разработчики Truly Ergonomic и предложили для них портировать прошивку ErgoDox (с Teensy на китайскую проприетарщину Megawin). (Я не взялся, под предлогом того, что прошивка ErgoDox по своей природе предполагает, что пользователь будет её дорабатывать, перекомпилировать и прошивать, а у них прошивающая программа только для Windows, что дискриминирует пользователей остальных систем. Но, кажется, они удовлетворятся уже сделанным.)

HTML+CSS+Javascript отлично подошли для написания конфигуратора. JSFiddle — отличная штука. Прошивать USB-устройства оказалось вполне возможно из Windows, работающей внутри VirtualBox’а — полной версии из оракловских репозиториев, с поддержкой USB.

yurikhan: (Default)

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

Read more... )
yurikhan: (Default)

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

yurikhan: (Default)

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

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

Как организовать таблицу )
yurikhan: (Default)

Хихи. Меня цитируют на ithappens.ru.

Profile

yurikhan: (Default)
Yuri Khan

June 2017

S M T W T F S
    123
45678910
1112 1314151617
18192021222324
252627282930 

Links

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2017-07-22 04:33
Powered by Dreamwidth Studios