Алгебраист. Космоопера

Иэн Бэнкс. Алгебраист. Книга в жанре космооперы. В результате череды войн, в том числе с искусственным разумом было уничтожено много искусственных порталов-червоточин. Главный герой случайно натыкается на информацию, которая возможно откроет доступ к параллельной сети порталов. В солнечную систему одновременно двигаются разные силы, которые желают захватить эту информацию, шифр, ключ,инопланетную алгебру или преобразование. В это время герой отправляется на газовый гигант к расе насельников, чтобы добыть эту информацию

Я всегда буду сравнивать книги этого жанра с тетралогией Дэна Симмонса - Гиперион, Падение Гипериона, Эндемион, Рассвет Эндемиона, по количеству неразгаданных загадок, Алгебраист тихо курит в сторонке (основная загадка раскрыта, остальные крайне поверхностны). Трилогия John C. Wright: The Golden Age, The Phoenix Exultant, The Golden Transcendence - в свою очередь опережает по чуждости технологий (технологии не вызывают восхищения), в частности полностью раскрыта тема искусственного разума и нанотехнологий, которых Иэн Бэнкс в своем произведении просто "запретил". Итог - средне.

Идеальные команды

Beautiful Teams. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга

Долгая книга, приобретенная мной на распродаже от books.ru, которую я читал полтора месяца. 600 страниц, 31 история, среди авторов Тим О'Рейли, Гради Буч, Кори Доктороу, Стив Макконнелл. Каждая глава представлена в виде истории от одного лица, интервью или коллективного потока сознания, некторое  читаются на одном дыхании, некоторые скучные. Эта книга напоминает "Хакеры. Герои компьютерной революции", только про менеджеров, руководителей, тимлидеров. Темы необычайно широки: марсианская программа и исследование дальнего космоса, военные технологии, Боинг 777, 9/11, бум доткомов, экономические кризисы, киноиндустрия, музыка, игры, Microsoft, Google,. Сами истории сгруппированы в 5 разделов: люди, цели, методы, препятствия и заключительный - музыка. 

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

Дальше идут цитаты.

Markdown в репозитории и оформление веб-интерфейса Mercurial

В мае появилась задача подумать над хранением документации. Где мы только не пытались хранить документацию: и в Dropbox, и в Google Docs. Последнее, где мы остановились, это - Confluence. Совершенно наркоманская система редактирования, потребовалось ставить отдельный плагин, чтобы можно было редактировать чистый HTML. Главная проблема всех этих подходов - рассинхронизация. Документация не соответсвует коду. На втором месте - невозможность автоматической генерации документации в процессе сборки проекта. От системы документации не требуется многого: вставка изображений и кросс-ссылки - более чем достаточно. 

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

Mercurial + Markdown

Хотя README встречались и раньше, а wiki хранилась в репозитории еще на Google Code, но именно с приходом GitHub README.md стало обязательным требованием. Краткое описание проекта, в wiki-стайл разметке markdown. После знакомства с возможностями этой системы на github.io любые сомнения в возможностях разметки пропадают. Приятным бонусом является плагин для IntelliJ IDEA.

Очень хотелось получить это на локальном репозитории. Поиск вывел на относительно молодой проект (не первый раз ищу) hgext.markdown от Chris Eldredge. Плагин для mercurial, покрывающий требования к встроенной системе документации на 100%. Когда я его поставил, выснилось, что разметка применяется только к readme, плагин не умеет работать с кодировками (пришлось вспомнить эпичнейший доклад про кодировки), с картинками (необходимое требование), ну и несколько проблем шаблонами вообще и с разметкой в частности.

Pull request or GTFO

В общем все это я пофиксил и заслал Крису толстенный пуллреквест, пару дней назад он принял его. Линуксоиды могут спокойно качать плагин, виндузятники в пролёте, поскольку требуется библиотека а у mercurial встроенный python, и как подсунуть одно в другое, еще не разбирался. Как выкурю - зашлю еще один пуллреквест с инструкцией.

Пока ждал - пошел на IRC канал, чтобы найти кого-нибудь с правами на запись в wiki-страницу со списокм плагинов. Оказалось, что особых прав не нужно и достаточно зарегистрироваться (порадовала каптча, которая требует ответить на вопрос про команды mercurial). Вооружившись руководством, создал по фэн-шую страничку плагина.

Темы для mercurial

В процессе ковыряния плагина набрел на встроенную систему шаблонов и тем для hgweb. Внутри крайне разухабистый движок, с доступом ко внутреннему API, позволяющий изобразить решительно всё. Заскриншотил каждую тему и добавил на страницу со списком, чтобы было понятно как каждая выглядит. Кстати, сам mercurial размазан по файловой системе: бинарники лежат в /usr/share/mercurial/templates, а основной код в /usr/lib/python2.7/dist-packages/mercurial.

Пять стандартных тем и Markdown, идущий в комплекте с плагином

Про коммуникабельность, умение договариваться и странные вещи

Постоянно записываю мысли, которые надо подумать. Иногда поток сознания созревает до чего-то осмысленного. Вот и сейчас читаю: "Бесят люди которые не находят в себе силы признать неправоту и после тотального слива заканчивают фразу: всё разговор окончен, почему ты споришь и т.д.". Перечитываю. Где-то я это уже видел. Ищу. Восемь месяцев назад. Раз за разом, одни и те же проблемы.

Про коммуникабельность

Не смотря на это, я достаточно эффективно общаюсь с большинством людей вокруг себя, особенно с теми, кто мне близок, важен или интересен. Если был неправ стараюсь явно это признать, если человек обиделся - извиниться. Пока не доказано обратное считаю, что все люди хорошие и адекватные, любое действие содержит внутренний смысл и продиктовано какими-то обстоятельствами, даже если для меня и, в худшем случае, для окружающих это крайне странно.

Про решение проблем

До сих пор считаю, что абсолютно любую проблему можно решить. Рассказ про 7 перпендикулярных линий у меня вызывает яростное отторжение. Есть способы. Нерешаемых проблем нет. Начиная, с проактивности из 7 навыков, и кончая тяжелой артиллерией - картами реальности из Целей и Критической цепи. Инструменты на любой вкус. Всё решаемо. Если есть воля, мотивация, эмоциональная энергия - куча слов - всё возможно.

Но однажды возникает проблема. Я вижу, что она решаема, даже вижу как - совсем не проблема, ерунда. Но воли сделать даже минимальное усилие нет. Есть понимание, что было затрачено достаточно усилий, время вспомнить про феномен Базермана и сказать стоп. Спросить себя "а не херню ли я делаю", или сказать: "делай как считаешь нужным, но без меня", или уйти, просто в другую комнату или совсем - варианты по обстоятельствам.

Странные вещи

Иногда люди делают странные вещи. Попытка доказать бредовость затеи, аппеляция к физическим законам, математике, здравому смыслу натыкается на яростный отпор "всё разговор окончен...". Если это меня никак не касается, то в этот момент разговор же и заканчивается. Но иногда требуют от меня делать странные вещи. В этот момент встает дилемма: продолжать делать по своему, провоцируя конфликт, или делать бредовую вещь, с ясным осознанием того, что делаешь бред. Диалог крайне затруднителен. И, обычно, после нескольких итераций заканчивается: пофиг, мне это не трудно. Но иногда люди делают опасные вещи. Если они опасные для себя, то мне в общем-то поровну: взрослые люди должны сами за себя отвечать. Гораздо хуже, когда своей глупостью, они начинают представлять опасность для окружающих. Здесь уже приходится быть начеку, чтобы вовремя вмешаться.

P.S.

Кстати, возвращаясь к тому Петрову из 7 линий, быть может ему уже всё равно?

Bleeding Edge

Очень интересное ощущение - оказаться на переднем краю (во временных масштабах Java) развития какой-то технологии (JavaFX) после работы со стабильной, читай мертвой (Swing). Стабильный API, JavaDoc, книги, стопицот ответов на StackOverflow в конце концов. Для любой проблемы известно не одно решение, боле того "после двух релизов баг становится фичей", а следовательно ждать исправления нет смысла. Первое что замечаешь - нет JavaDoc, в том, что есть - нет примеров. Второе - есть баги. Тысячи их, а багтрекер почему-то не просто доступен только после регистрации, более того, он закрыт для индексации. Когда делал что-то на Swing у меня ни разу не было желания засабмитить багрепорт, сейчас - постоянно. Третье - всё самое вкусное и желанное будет в версии next. Восьмерка выйдет весной следующего года, если опять не отложат.

Инкапсуляция говнокода

When a small hack could solve all my problems

Рано или поздно все сталкиваются с нерешаемой красивыми путями проблемой, а чем активнее развитие технологии, тем чаще это случается. У всех, правда, разный порог нерешаемости. Приняв неизбежность, пишем свою обёртку, если код написан с принципом Open-Closed в голове, то перегружаем пару методов, если нет - то копируем всё. После чего исправляем ту самую проблему, пишем обоснование и ссылку на багрепорт. Когда-нибудь это можно будет удалить.

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

Вопросы читабельности кода

Схороненный псто из умершего базза.

PEP-20

Наткнулся на интересную статью у avva, про избыточность кода с целью повышения читабельности. А потом и +Евгений Доронин запостил про законы Мерфи для разработки. Пару лет назад я тоже задавался подобным вопросом. До сих пор не нашел однозначного ответа, хотя и //do nothing с тех пор эволюционировал в log.error("Inconsistent state {}",...) или throw new IllegalStateException, чтобы сильно умный статический анализатор заткнулся и не предлагал убрать пустые условия и максимально быстро упасть если забыли, после добавления enum, также добавить обработку этого значения.

Тернарные операторы по возможности избегаю, а уж если там сложные выражения, с подусловиям, то гораздо читабельней становится замена их на обычный if-else.

Родовая память

Продолжаю читать "Идеальные команды", и там Гради Буч высказал интересную мысль про неявные решения.

И теперь, поскольку мир не стоит на месте, встает интересный вопрос – та архитектура не была подробно отражена в документации, зачастую никакой документации вообще не было, и хотя код верен, он
не может быть истиной в последней инстанции, потому что не  отражает ни логического обоснования, ни аспектов, по которым принималось компромиссное решение, ни любых других вещей, которые невозможно вывести из отдельных строк кода; есть схемы, выходящие за пределы самих этих строк. Такие вещи обычно сохраняются в «родовой памяти». И в любой организации есть патриархи, которые работают там уже давно и лично помнят эти обоснования и возникавшие междисциплинарные вопросы. Сложность здесь в том, что организация продолжает расти, люди перемещаются, и этот адресат может, фактически, уже на ходиться в другом месте.
То есть помимо проблемы временного и географического распределения есть проблема утечки интеллектуальной собственности, потому что хранить ее в «родовой памяти» – страшно дорого, точнее, память эта ничего не стоит, но извлечь из нее информацию может оказаться очень затратным, и чем меньше этой памяти, тем она дороже.

Такие вещи нужно выносить из головы и в код, давая обоснование принятым решениям и описывая допущения в которых эти решения принимались. Такие послания на порядок повышают читабельность кода.

Порой решение принять нельзя потому, что не хватает информации, либо времени на детальный анализ. Такие места описываются через TODO или FIXME с описанием проблемы и текущей ситуации:

// TODO Нужно ли это внести в контейнер?
// TODO подумать как прикрутить локализацию

// FIXME не уверен, что первоначальное заполнение списка должно выполняться по событию
// FIXME без этой строчки список почему-то не инициализируется
// FIXME when resolved https://javafx-jira.kenai.com/browse/RT-19089
// FIXME пока нет нормального чего-то, делаем так-то

Когда случается проблема, то такие места выделенные ядовито зеленым цветом сразу привлекают внимание.