Шесть различных тем по семь минут на каждую

1. Вопросы, комментарии, предложения:
http://twitter.com/squadette
2015-03-11
Мульти-блиц
Меня зовут Алексей Махоткин, я стою на фейс-контроле в
московском ночном клубе, который называется undev.ru.
Сегодня сбылась моя мечта, я выступаю на разогреве у Валкина.
Некоторые темы преследуют меня всю мою профессиональную
жизнь. Я хочу обсудить сразу несколько таких тем, потратив на
каждую приблизительно по семь с половиной минут. Я не собираюсь
рассказывать об успехах, потому что их нет, или о технических
деталях, потому что они мне не интересны.
Я, скорее, хочу обратить ваше внимание на несколько вещей, на
которые, как мне кажется, имеет смысл обратить внимание.

2. Документирование для программиста
2015-03-11
Мульти-блиц
Для начала я хочу рассказать кое-что о документировании
программного кода для снижения bus-factor. Это одно из
распространенных мечтаний среди программистов —
«документировать программу», чтобы пойти в отпуск или
уволиться. К сожалению, на дороге к этой прекрасной цели нас
подстерегает ряд опасностей.

3. Документация к коду — это текст.
2015-03-11
Мульти-блиц
Вообще, любой текст будет существенно проще писать, если у него
есть цель. Это что-то вроде сильной типизации — если перед
написанием текста сформулировать ответы на несколько простых
вопросов, то текст часто начинает вытекать из-под пальцев
самостоятельно и без напряжения.

4. Для кого конкретно мы пишем текст?
2015-03-11
Мульти-блиц
Кто конкретно тот человек, для которого мы документируем код?
Например, наша задача сильно облегчится, если мы признаем, что
этот человек не уступает нам в компетентности и квалификации.
Ему, в общем, даже не нужно объяснять что-то в духе «здравствуй,
малыш! ты оказался в лабиринте!» — ему это ваш же менеджер
объяснил на собеседовании. Он умеет бегать не хуже вас — просто
он пока еще не знает, где именно в этом лабиринте разложены
сюрпризы. Он все равно узнает об этом так или иначе из своего
опыта — вопрос только в том, о каком проценте сюрпризов вы ему
расскажете на раннем этапе.

5. Что этот человек знает заранее?
2015-03-11
Мульти-блиц
Что этот человек должен знать заранее? Не надо документировать
ничего, кроме сюрпризов. Часто документирование начинается с
описания работы функции max() или класса File, и им же
заканчивается, не добравшись до функции «n-мерная свертка
кластеризованных коэффициентов». Не надо документировать
функции, которые соответствуют всяким стандартам языка —
вашему читателю очевидно, что делает функция to_json.

6. Документируйте сюрпризы
2015-03-11
Мульти-блиц
Я думаю, что эта манера программистов взята из разного рода
документации на разного рода API — именно эту документацию
программисты читают чаще всего и подражают ей. Там, конечно,
надо стремиться к стопроцентному документированию, порой даже
избыточному.

7. Напишите план сочинения, как учили в школе.
2015-03-11
Мульти-блиц
Попытка документировать кодовую базу похожа на марафон —
необходимо планировать время и энергию. Соберите, например,
список классов. Разложите их на три группы — бизнес-логика, не
пойми что и утилиты. Документируйте бизнес-логику. Не тратьте
время на утилиты. На следующей итерации сфокусируйтесь на
второй группе.

8. Что этот человек узнает, прочитав текст?
2015-03-11
Мульти-блиц
Представьте себе, что у вас через три часа поезд. Теперь
документируйте то, что приходит на ум и не тратьте время на
шелуху.
Представьте себе, что вы даете человеку ключи от дачи. Вы не
будете рассказывать ему о том, что в вашей даче есть дверь со
ступеньками и три окна. Вы расскажете, как включить газ и
электричество, где ближайшие электрички (и какую из них часто
отменяют), где покупать по дороге продукты, какой ключ заедает и
т. п.

9. Pidgin English, ч. I.
2015-03-11
Мульти-блиц
У программистов есть несколько способов продемонстрировать
знание английского языка. Один из них — написать на нем
документацию. Это порочная идея (если, конечно, вы не работаете
на западного работодателя). Скорее всего, ваш преемник будет
говорить на одном с вами языке. Скорее всего, и вам будет трудно
писать, и ему будет трудно восстанавливать смысл из чужого языка.
Я так понял, что у многих программистов есть некое стремление
интегрироваться в мировую инфраструктуру. Обычно это
выражается в некоем полуоформленном стремлении «когда-нибудь
подключиться к опен-сорсу». Готовясь к этой мечте, они пытаются
писать тексты на английском языке. Почему при этом они не
подключаются собственно к опен-сорсу — вопрос открытый.
Однако — не надо обманывать себя.

10. Pidgin English, ч. I.
2015-03-11
Мульти-блиц
Либо подключитесь к опен-сорсу и начните разрабатывать там
какую-то нетривиальную фичу — и тогда у вас моментально
вырастет искомый английский язык от дискуссий с коллегами. Либо
перестаньте самообучаться на безвинных людях, которые потом
будут переводить ваш текст обратно на русский язык.

11. Самодокументируемый код
2015-03-11
Мульти-блиц
Хорошо, если код прозрачен, как слеза программиста, сидящего на
его поддержке. Тяжело документировать код, который вообще-то
надо бы частично переписать, переименовать несколько функций,
убрать коросту и прочее. Однако, в этот момент лучше включить
режим патологоанатома: «у ребенка три ножки, зато отсутствует
правая ручка. также его нельзя отключать от вот этого вот
проводочка. число, подпись.»
Это тяжело. Часто программист, сформулировав очередной абзац об
устройстве какого-нибудь очередного компонента, с мучительной
ясностью осознает, насколько далеко его детище от одного из
идеалов, которые он носит в сердце. Его окружают демоны, они
воют и призывают то покаяться, то рефакторить, то бросить это
бессмысленное занятие и пойти почитать что-нибудь утешающее.
Скорее всего, ситуация сейчас такова, что ничего трогать не нужно.
Лучше потратьте это время на то, чтобы хотя бы классифицировать
области возможного рефакторинга.

12. Самодокументируемый код
2015-03-11
Мульти-блиц
Завершение секции про документирование

13. Отслеживание требований
2015-03-11
Мульти-блиц
В долгоживущих проектах некоторые требования с течением
времени отмирают. Однако, зачастую код, поддерживавший эти
требования, остается в кодовой базе и в лучшем случае ничего не
делает (а на самом деле он тратит внимание разработчиков,
всплывает в выдаче grep’а и т. п.). Конечно, в таких проектах всегда
есть процесс рефакторинга, который постепенно позволяет
избавляться от такого кода.
Интересно было бы подумать и поэкспериментировать с разметкой
кода по определенным требованиям, чтобы превратить требования в
некоторый объект первого класса. Например, можно было бы вести
файл со списком «требований», и размечать с помощью
спец-комментариев отдельные функции, участки кода, классы и
файлы на предмет их принадлежности к требованию.

14. Отслеживание требований
2015-03-11
Мульти-блиц
Маркапить можно и нужно все что угодно — яваскриптовые файлы,
CSS-файлы, картинки и проч.
Требованием могут быть разные вещи — инфраструктурная фича,
обеспечивающая надежность и отказоустойчивость; конкретный
юзкейс, который должна поддерживать наша программа; поддержка
какой-то третьейсторонней системы, которая в какой-то момент
может оказаться ненужной, и т. п.

15. Метрики
2015-03-11
Мульти-блиц
Все это великолепие можно парсить и проводить глобальный анализ
кодовой базы. Процент покрытия, относительные объемы каждого
требования, степень изолированности требования (сколько файлов
оно затрагивает) и проч.
Если требование устарело, то его можно удалить из
соответствующего файла и тогда автоматически соответствующий
код можно диагностировать как «устаревший».

16. Метрики
2015-03-11
Мульти-блиц
Завершение секции про отслеживание требований

17. SELECT * FROM <tblname> — плохой способ организации
контента
2015-03-11
Мульти-блиц
Экономия энергии — эволюционно обусловленный механизм
развития человека, и разработчики интерфейсов — не исключение.
Все знают про оператор «SELECT *», все знают ключевые слова
«LIMIT и OFFSET». Очень легко придумать интерфейс, основанный
на этих двух идеях. В этот момент включается эволюционный
механизм экономии энергии — в глазах возникает характерная
черно-белая спираль и голос «ЭКОНОМЬ ЭНЕРГИЮ». Таким
образом получается привычная всем пагинация.

18. Страница обсуждения 1, 2, 3, 4, ..., 6740, 6741, 6742
2015-03-11
Мульти-блиц
Этот интерфейс очень эффективно нагружает базу данных, но
спускает в унитаз всю структуру контента, который он призван
визуализировать.

19. Придумайте что-нибудь
2015-03-11
Мульти-блиц
Рискуя гибелью от нехватки ресурсов, можно попробовать придумать
что-нибудь. Например, многие виды контента размещаются на
некотором таймлайне, и можно попытаться визуализировать именно
его. Эволюционный инстинкт настаивает на том, чтобы придумать
календарь и ограничиться этим (экономим энергию).
Может быть, можно сделать что-то еще — например, что-то вроде
heat-map активности на линии времени. Шарики разного размера и
цвета? Учитывать как количество сообщений, так и количество
участников?
Может быть, это гистограмма активности, как в графиках
статистики посещений, как в Google Analytics? График активности
можно аннотировать, «подсвечивая» причину всплеска — сезонные
обострения? важные события в жизни сообщества? тренды?

20. Emotion mining
2015-03-11
Мульти-блиц
Вообще говоря, вся эта история — она про data mining. Она про
построение производных структур поверх некоторого первичного
контента.
С одной стороны, наверняка половина обсуждений, для пагинации
которых требуется 649 страниц — представляет из себя шум на 95
процентов. С другой стороны, это надо еще доказать. С третьей
стороны, получение такого механизма обратной связи может
улучшить качество обсуждения, улучшить само сообщество.
Я буду еще говорить про производный контент в приложении к
классификации стартапов.

21. Emotion mining
2015-03-11
Мульти-блиц
Завершение секции про пагинацию

22. Деградация глобального контента
2015-03-11
Мульти-блиц
Интернет полон устаревшей информации. Гугл покупает все больше
дисков, заполняя свой поисковый индекс. Индустрия не стоит на
месте, и почти каждый текст о ее фактическом состоянии рано или
поздно устаревает.
Иногда при поисках решений некоторых вопрос программирования
на рельсах в первых позициях серпа находятся блог-посты,
датированные 2006 годом, то есть где-то районом версии 1.2.
Понятно, что указанные в них советы давно и невероятно устарели.
Понятно, что так же устаревают аналитические статьи, переписка в
форумах, описания продуктов и многое другое.

23. Деградация глобального контента
2015-03-11
Мульти-блиц
Проблема не только с технологическими статьями, но и с другой
фактографией — информация о визах, юридические консультации,
рассказы о медицинских технологиях (например, технология
лазерной коррекции зрения радикально меняется за пару лет, и
читать ужасающие отзывы делавших операцию пять лет назад нет
никакого смысла).
Понятно, что никто ничего не будет менять, потому что контент не
вырубить топором.

24. Таймлайны
2015-03-11
Мульти-блиц
Мне кажется, что можно было бы ввести в оборот такую идею, как
таймлайн событий. Таймлайн это некий объект первого класса,
который ведется совместно в духе Wiki. Таймлайн можно
подключить к тому или иному сайту — форуму и т. п. Глядя на
время написания текста, можно выводить некие, что ли, подсказки
— «На всякий случай сообщаем, что с тех пор вышло уже две
мажорные версии рельсов. Обратите внимание, что визовые правила
шенгенского соглашения изменились.» и т. п.
Подобные напоминания может также выдавать расширение к
браузеру, так или иначе анализируя содержимое страницы (или
просто позволяя пользователю выбирать нужный таймлайн).
В любом случае, мне кажется, что таймлайны как
структурированный объект первого класса — это перспективная идея.
Кстати, домен timewiki.ru свободен )

25. Таймлайны
2015-03-11
Мульти-блиц
Завершение секции про таймлайны

26. Future shock.
2015-03-11
Мульти-блиц
Меня бесит ситуация, на мой взгляд сложившаяся в мире NoSQL.
Отсутствует единый согласованный корпус знаний о теории и
практике. Есть много разрозненных сведений о практическом
применении. Есть классическая теория, которая лежит в основе
многих решений.
Есть удивительная инженерная культура, которая помогает людям
находить остроумные и свежие решения для актуальных проблем.
Нет целостности. Тысячи, десятки тысяч человеко-часов тратятся на
подбор решения опытными специалистами. Тысячи, десятки тысяч
менее опытных разработчиков могли бы получить десятки мощных
инструментов в свое распоряжение. Однако, сообщество продолжает
накапливать все новые реализации, все новые отчеты об
использовании, отчеты о переходах и миграциях. Половину этих
историй, честно говоря, сложно читать без слез.

27. Future shock.
2015-03-11
Мульти-блиц
Я понимаю, что все в стрессе, у всех внезапный успех или внезапное
изменение требований, или внезапная недооценка необходимости и
переоценка возможностей. Однако, от выслушивания историй о том,
что сначала мы пользовались MongoDB, а потом оно ВНЕЗАПНО
вдруг стала работать со скоростью один запрос в час, поэтому мы в
панике поставили Redis, и все работало хорошо, пока однажды мы
ВНЕЗАПНО перезагрузили сервер и оказалось, что то что мы
принимали за персистентный сторадж, оказалось RAM-based
решением, и поэтому мы...
Я с ужасом понимаю, что я не застрахован от всей этой истории. Я
набираю команду из полудюжины высококлассных разработчиков, и
я понимаю, что мы будем идти по всем текущим граблям всех
текущих решений, и перед нашим носом снова будут маячить
морковки из альтернативных решений.

28. Коммодитизация технологии
2015-03-11
Мульти-блиц
Лично мне для возможности принимать чуть более предсказуемые
технические решения не хватает очень простой вещи — актуального,
поддерживаемого сообществом экспертов, нейтрального
классификатора NoSQL-решений. Хорошо структурированный текст,
который без соплей излагает факты, с расчетом на компетентную
аудиторию.

29. нижележащая структура данных;
первые производные структуры;
возможные алгоритмы;
алгоритмическая сложность;
конкурентное поведение (блокировки);
классификация по CAP-теореме;
распределение нагрузки и отказоустойчивость ×
алгоритмы;
ad-hoc решения;
список внедрений;
родственные связи;
протокол доступа;
2015-03-11
Мульти-блиц
Вообще хочется обойтись в этом тексте без историй типа здравствуй
малыш! сейчас я расскажу тебе, что такое графы, а потом мы споем
вместе песенку.
Ad-hoc решения — это например про то, что Redis позволяет
работать в режиме message queue.
На сайты решений сложно смотреть без слез. Больше всего меня
бесит фраза про «высокую производительность» и «надежность»,
которая повторяется на всех сайтах.
У меня есть идея сделать СбербанкДБ. Это такое nosql-решение, в
котором каждый запрос обрабатывается минут по 15-20, и еще
перерывы на обед с двух до трех по часовому поясу сервера. Также
оно иногда отвечет фразой «ой а мы ваш ключик потеряли».

30. Таймлайны снова
2015-03-11
Мульти-блиц
Как мы все понимаем, вся эта история — снова во многом про
таймлайны как механизм устаревания контента. Также эта история
— про первичную информацию, это будет темой одной из
следующих частей.

31. Сообщество
2015-03-11
Мульти-блиц
Никто не в состоянии в одиночку поддерживать такой корпус знаний
в одиночку. Однако, мы могли бы поработать вместе, объединить
наш опыт и знания и создать вещь, которая позволит нам всем
увеличить свою техническую эффективность.
Если вы чувствуете, что в моих словах есть смысл — давайте
свяжемся и попробуем стартовать этот проект.

32. Сообщество
2015-03-11
Мульти-блиц
Завершение секции про классификацию NoSQL

33. Немного о резюме программистов
2015-03-11
Мульти-блиц
Давайте немного поговорим о чем-нибудь попроще, например о
резюме. Я нанял наверное человек 80 для Undev.ru, то есть я
прочитал около 1000 резюме, или может быть тысячи полторы.
Процентов двадцать этих резюме я предпочел бы никогда не видеть.

34. Сопроводительное письмо (cover letter)
2015-03-11
Мульти-блиц
Некоторые почему-то считают, что кавер леттер — это
формальность. Наоборот, кавер леттер — это специальный формат,
который был придуман для того, чтобы обратиться непосредственно
к личности нанимающего менеджера (если, конечно, компания
устроена так, что у нанимающих менеджеров есть личности).
Идеально, если вы хотите работать в той или иной компании,
например, в Undev.ru. Тогда вы пишете в кавер-леттер, почему
именно там, и фокусируете внимание на те или иные аспекты своего
опыта которые, как вам кажется, должны быть особенно интересны
компании. Идеально, конечно, если вы еще и подстраиваете резюме
под работодателя.

35. Сопроводительное письмо (cover letter)
2015-03-11
Мульти-блиц
Понятно, что вы можете и не быть таким мотивированным (хотя тут
надо бы задать себе вопрос — а почему?) Тогда вы рассылаете одно
и то же резюме без всякого кавер-леттера на двадцать разных
адресов и ждете ответа. Постарайтесь организовать свое резюме,
как и всякий целенаправленный текст, так, чтобы оно хотя бы не
мешало нам его читать.

36. резюме должно быть;
не пишите туда ерунду;
не надо устраивать балаган;
заполните moikrug.ru;
пишите по-русски;
2015-03-11
Мульти-блиц
Даже если вы адский специалист, который никогда не ходит по
собеседованиям, я все равно скорее всего захочу увидеть ваше
резюме. Оно нужно мне для того, чтобы сориентировать коллег и
руководство.
До сих пор встречаются резюме, в которых самое свежее место
работы находится в конце списка. Это настолько отвратительно, что
я вычеркиваю этот пункт.

37. резюме должно быть;
не пишите туда ерунду;
не надо устраивать балаган;
заполните moikrug.ru;
пишите по-русски;
2015-03-11
Мульти-блиц
Не надо присылать смешные резюме — в виде кода на Ruby, в виде
комиксов, а особенно — в виде resumup (этот стартап занял первое
место на проведенном мною конкурсе самых идиотских стартапов).
К сожалению, чистая статистика заставляет меня относиться с
подозрением к смешным резюме — я видел может быть один случай,
когда под таким резюме скрывался адекватный профессионализм.
Мы очень любим moikrug.ru, и мы хотели бы, чтобы в нем было
больше активных на рынке труда людей, и чтобы у них были
максимально полные резюме.

38. Pidgin English, ч. II
2015-03-11
Мульти-блиц
Зачем вы присылаете мне резюме, записанное латинскими буквами?
Присылайте в российские компании резюме на русском языке,
пожалуйста.

39. Начало карьеры
2015-03-11
Мульти-блиц
Завершение секции про резюме

40. Вопросы, пожелания, предложения?
2015-03-11
Мульти-блиц
Вопросы

41. UNDEV.RU
2015-03-11
Мульти-блиц
Несколько заключительных объявлений.
На стенде undev.ru можно купить экземпляр книги Бенджамина
Пирса «Типы в языках программирования». Из-за особенностей
книжной дистрибуции он продается слишком дорого в Москве,
Санкт-Петербурге и интернет-магазинах книга-почтой. Я постепенно
распространяю эту книгу среди еще неохваченных слоев общества.
Там же можно получить по листу прикольных лопающихся
пупырышков, у нас их почти четыре квадратных метра.