Итоги 2016-го

2 января 2017, 22:21, dev · life · music

На работе

Уже больше двух лет я работаю в команде, которая развивает, внедряет и поддерживает e-commerce движок. Этот год по-моему стал переломным. Проект начал выбираться из sql-болота, в которое его долгое время погружали. Держать самые важные функции в хранимых процедурах очень не удобно: нет версионности, тяжело отлаживать, трудно синхронизировать и деплоить. Медленно, но уверенно наш критический код передвигается их хранимых sql-процедур в c#-код.

Мы написали огромное количество тестов: юнит-тесты на бекенде, функциональные тесты на фронтенде (на Selenium). Появилось больше веры в наш код. Теперь деплой на продакшн-серверы — это не стресс и скрещивание пальцев, а обычный процесс, который мы можем делать несколько раз в день.

Очень помогла книжка Егора Бугаенко «Elegant Objects». Мы поняли наконец, что public static — это адское зло, с которым нужно бороться изо всех сил. Маленькие простые классы рулят, они легко тестируются и поддерживаются.

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

Ещё стало понятно, что для проекта нужна новая кровь. Разработчики, которые в проекте 5 лет, костенеют, привыкают, жалеют свой старый код, с которым частенько нужно беспощадно расправляться. Новички лучше видят проблемы и кривости, не жалеют старого кода, готовы всё переписать заново.

Закрыли с партнёром Домовед. Очень важный проект, которому мы уделили много времени и который многому нас научил. Проект постоянно стабильно рос. Мы были вверху поисковой выдачи по запросам «... без посредников». Мы проверили несколько интересных гипотез и убедились в том, что люди готовы платить за объявления без посредников. В конце концов свою квартиру я нашёл на Домоведе. Чтобы проект жил, над ним нужно постоянно работать. Свободное плавание тут не катит. Два года назад разработка остановилась, а год назад стало понятно, что разработка вряд ли продолжится. Чтобы не было стыдно за проект, мы его просто закрыли. Итог за 2013-2015 годы примерно такой: расходы — 36 000 грн, доходы — 16 000 грн. Потерь совершенно не жалко, это было интересно и круто. Спасибо, Домовед!

Музыка

Я уже больше года подписчик Google Play Music и практически всё слушаю там. Слушалось очень много и очень разного. Попытался разобраться в хип-хопе. Услышал и полюбил Мгзавреби. Вспомнил и много раз послушал альбом «Goddess in the Doorway» Мика Джаггера и «Alone in the Universe» от ELO. Нашёлся Hiatus c классным альбомом «Ghost Notes» и Mokhov c «Magic Times». Ну и много-много всего, регулярно оставлю ссылки в твитере.

2017

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

Про управление командой разработчиков

2 января 2017, 19:52, dev · management

В прошлом году я помимо написания кода стал немного заниматься управлением. Самый важный аспект в этом деле — это отношения внутри команды: «люди и взаимодействие важнее процессов и инструментов». Прочитал интересную статью, которая проявила проблемы нашей команды и нашего процесса разработки. Оставил себе конспект.

Будьте осторожны с высокими показателями

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

Поощряйте продолжительное улучшение продукта

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

Поощряйте право собственности на код

Разработчикам нужно дать право собственности на части кодовой базы и не позволять другим разработчикам менять этот код без одобрения владельца. Это приводит к более высокой производительности труда, поскольку разработчик знаком с кодом, с которым он обычно работает.

Распознавайте лидеров

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

Следите за ложными системами показателей

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

Отдельные рабочие места

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

Поощряйте эксперименты

У большинства компаний нет огромных денежных ресурсов, чтобы дать 20% рабочего времени под экспериментальные проекты как у Google. Эксперименты, тем не менее, периодически следует поощрять и поддерживать. Разработчики программного обеспечения не лишены хороших идей и имеют особый опыт, а соответственно у них хорошее чутье касательно приложений, которые могут быть улучшены и расширены.

Позволяйте сотрудникам уходить

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

Всегда выполняйте небольшие просьбы

Ваш сотрудник хочет монитор побольше? Купите. Они хотят определенную клавиатуру? Купите. Они хотят работать из дома каждую среду и это их личное требование? Разрешите. Они хотят Мак вместо ПК? Дайте им его. Даже если у них постоянный поток запросов, который кажется никогда не закончится, никогда не говорите им нет, кроме одного случая: если вы уверены, что эта маленькая просьба появится у всей фирмы и это действительно будет слишком сильно сказываться на бюджете.

Отмените годовые и полугодовые отчеты

Ваши сотрудники не должны ждать шесть-двенадцать месяцев, чтобы узнать, что вы считаете, что они в чем-то преуспели и над чем они должны поработать. Общение между менеджерами и сотрудниками должно быть как река, которая никогда не перестает течь.

Вы не лучше ваших сотрудников

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

Не делайте возврастную скидку

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

Обобщение

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

Конспект книги «Elegant Objects»

13 сентября 2016, 18:01, books · dev

Егор Бугаенко написал полезную книгу про ООП. Я её прочитал и сделал для себя короткий конспект.

Современное ООП не правильно приготовлено, оно больше похоже на процедурный стиль потому, что выросло из него. Проблема больших программных продуктов — maintainability (ремонтопригодность, поддерживаемость). Решить помогает чистый стиль ООП — очень маленькие классы, immutable объекты и прочее.

Не использовать -er в именовании классов

Manager, Controller, Formatter — плохие имена плохих классов. Класс должен отражать не то, что он делает, а то, кто он есть.

Один главный конструктор в классе

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

Конструкторы не должны содержать выполняющий код

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

Делайте классы как можно мельче

Инкаплируйте максимум 4 объекта. Такие классы легче поддерживать и тестировать.

Всегда используйте интерфейсы

Интерфейс — это задокументированный контракт, который класс будет выполнять. (Спорно)

Методы-билдеры именуйте существительными

Например: string content(File file), int sum(int, int)

Методы-манипуляторы именуйте глаголами

Например: void paint(Color color), void write(string s). Такие методы не должны что-то возвращать, всегда void.

Методы возвращающие булевый тип именуйте прилагательными

Например: bool empty(), bool negative().

Не используйте константы

Они добавляют связи между классами, а это плохо. Вместо констант нужно делать классы, которые имплементируют работу с этими константами. (Спорно)

Делайте объекты не изменяемыми (immutable)

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

  • объект всегда остайтся самим собой, нет identity mutability,
  • failure atomicity — ошибки не влияют на внутреннее состояние объекта, он всегда остайтся собой,
  • нет сайд-эффектов,
  • нет null в полях, всё должно быть проинициализировано в конструкторе,
  • потокобезопасность — много потоков могут пользовать объект без синхронизаций,
  • маленькие и простые классы — трудно сделать immutable класс в 5000 строк.

Пишите тесты вместо документации

Плохой код вынуждает писать документацию к нему. Простые маленькие классы не нуждаются в документации. Хорошо написанные юнит тесты для класса и есть его документация.

Не используйте моки, используйте фейки.

Моки это плохо потому, что они связаны с внутренним состоянием класса. Фейковые классы живут рядом с интерфейсами, реализуют их и используются, когда нужна имплемениация интерфейса для юнит тестов.

Максимум 5 публичных методов в классе

Маленькие классы легче понимать, поддерживать и тестировать.

Не используйте статические методы

Статические методы из процедурного стиля программирования. Они удобны для компьютера, но плохи для ООП, классов, поддержки и тестирования. Императивный стиль — это про алгоритмы и исполнение. Декларативный — про объекты и поведение. Нужно стремиться к декоративному стилю.

Не используйте utility классы, хелперы

Это обычно не классы, а набор процедур. Это очень частый антипаттерн в ООП.

Не используйте синглтоны

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

Функциональное программирование

Оно конечно хорошее, но ООП более выразительное и мощное потому, что имеет не только методы (функции), но и объекты.

Не принимайте NULL-аргументов

Это избавляет от проверки на null. Null - это из мира компьютеров, а не из мира объектов.

Be loyal and immutable, or constant

Коротко не скажешь, нужно читать.

Не используйте геттеры и сеттеры

Объекты в ООП не просто структуры данных. Структура данных прозрачная, а объект — черный ящик. Структурв данных пассивная, объект — активный. Геттеры и сеттеры нарушают целостность объекта, он становится не иммутабельным.

Используйте new только во вторичных конструторах

Для создания объектов по-умолчанию.

Избегайте проверки и приведения типов

Reflection — это хороший инструмент для плохих программистов.

Никогда не возвращайте NULL

Лучше выбрасывайте исключение. Fail fast — чем раньше вы упадёте, тем быстрее вы найдёте ошибку. Вариант: возравращать объект специального класса: class NullUser implements User.

Не ловите исключения, которые вы не должны ловить

Пусть они улетают выше, fail fast.

Используйте вложенные исключения

Словили исключение, выбрасывайте новое с хорошим описанием ситуации и вложенным словленным исключением.

Одного типа исключений достаточно

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

Используйте RAII

Получение некоторого ресурса неразрывно совмещается с инициализацией, а освобождение — с уничтожением объекта.

Как писатель Бабель работал над текстом

6 февраля 2016, 00:40, books

В «Повести о жизни» Паустовского есть рассказ писателя Бабеля о работе над текстом, о превращении наброска в рассказ.

Но давайте говорить по порядку. Когда я в первый раз записываю какой-нибудь рассказ, то рукопись у меня выглядит отвратительно, просто ужасно! Это – собрание нескольких более или менее удачных кусков, связанных между собой скучнейшими служебными связями, так называемыми «мостами», своего рода грязными веревками. Можете прочесть первый вариант «Любки Казак» и убедитесь в том, что это – беспомощное и беззубое вяканье, неумелое нагромождение слов.
Но тут-то и начинается работа. Здесь ее исток. Я проверяю фразу за фразой, и не однажды, а по нескольку раз. Прежде всего я выбрасываю из фразы все лишние слова. Нужен острый глаз, потому что язык ловко прячет свой мусор, повторения, синонимы, просто бессмыслицы и все время как будто старается нас перехитрить.
Когда эта работа окончена, я переписываю рукопись на машинке (так виднее текст). Потом я даю ей два-три дня полежать – если у меня хватит на это терпения – и снова проверяю фразу за фразой, слово за словом. И обязательно нахожу еще какое-то количество пропущенной лебеды и крапивы. Так, каждый раз наново переписывая текст, я работаю до тех пор, пока при самой зверской придирчивости не могу уже увидеть в рукописи ни одной крупинки грязи.
Но это еще не все. Погодите! Когда мусор выброшен, я проверяю свежесть и точность всех образов, сравнений, метафор. Если нет точного сравнения, то лучше не брать никакого. Пусть существительное живет само в своей простоте.
Сравнение должно быть точным, как логарифмическая линейка, и естественным, как запах укропа. Да, я забыл, что прежде чем выбрасывать словесный мусор, я разбиваю текст на легкие фразы. Побольше точек! Это правило я вписал бы в правительственный закон для писателей. Каждая фраза – одна мысль, один образ, не больше. Поэтому не бойтесь точек. Я пишу, может быть, слишком короткой фразой. Отчасти потому, что у меня застарелая астма. Я не могу говорить длинно. У меня на это не хватает дыхания. Чем больше длинных фраз, тем тяжелее одышка.
Я стараюсь изгнать из рукописи причастия и деепричастия и оставляю только самые необходимые. Причастия делают речь угловатой, громоздкой и разрушают мелодию языка. Они скрежещут, как будто танки переваливают на своих гусеницах через каменный завал. Три причастия в одной фразе – это убиение языка. Все эти «преподносящий», «добывающий», «сосредоточивающийся» и так далее и тому подобное. Деепричастие все же легче, чем причастие. Иногда оно сообщает языку даже некоторую крылатость. Но злоупотребление им делает язык бескостным, мяукающим. Я считаю, что существительное требует только одного прилагательного, самого отобранного. Два прилагательных к одному существительному может позволить себе только гений.
Все абзацы и вся пунктуация должны быть сделаны правильно, но с точки зрения наибольшего воздействия текста на читателя, а не по мертвому катехизису. Особенно великолепен абзац. Он позволяет спокойно менять ритмы и часто, как вспышка молнии, открывает знакомое нам зрелище в совершенно неожиданном виде. Есть хорошие писатели, но они расставляют абзацы и знаки препинания кое-как. Поэтому, несмотря на высокое качество их прозы, на ней лежит муть спешки и небрежности. Такая проза бывала у самого Куприна.
Линия в прозе должна быть проведена твердо и чисто, как на гравюре.
Вас запугали варианты «Любки Казак». Все эти варианты – прополка, вытягивание рассказа в одну нитку.
И вот получается так, что между первым и последним вариантами такая же разница, как между засаленной оберточной бумагой и «Первой весной» Боттичелли.

Вот такой непростой и интересный процесс.

2000 котлет

2 января 2016, 14:58, books

В «Чемодане» Довлатова есть прекрасное:

— А что делать? Способностей у меня нет. Уродоваться за девяносто рублей я не согласен...Ну, хорошо, съем я в жизни две тысячи котлет. Изношу двадцать пять темно-серых костюмов. Перелистаю семьсот номеров журнала «Огонек». И все? И сдохну, не поцарапав земной коры?.. Уж лучше жить минуту, но по-человечески!..

Эти «2000 котлет» мне запомнились и я считал их прекрасной находкой Сергея Донатовича.

Но вот в «Повести о жизни» Паустовского нашлось такое:

... Его звали Багров. Несколько лет спустя он стрелял из револьвера в Киевском оперном театре в царского министра Столыпина, убил его и был повешен.
На суде Багров держался лениво и спокойно. Когда ему прочли приговор, он сказал:
— Мне совершенно все равно, съем ли я еще две тысячи котлет в своей жизни или не съем.

Константин Георгиевич закончил эту часть книги в 1946 году. А Довлатов лет на тридцат пять позже, после 1978 года, когда уехал из Союза.

Выходит «2000 котлет» — находка совсем не Довлатова и даже не Паустовского, а убийцы царского премьер-министра.

Ситечко для чая

25 марта 2015, 10:55, tea

ситечко для чая

Ситечко для заварки чая — отличная вещь. Чаинок не остаётся в чашке, а я терпеть не могу чаинки в чае. Заварка быстро выбрасывается, ситечко легко моется. Просто регулировать время заварки — вытаскиваешь ситечко в нужный момент.

В последнее время я завариваю чай только с его помощью. Набираю в ситечко побольше заварки, полторы или две чайных ложки на чашку. Ложу его в чашку и заливаю кипятком, держу не долго, 30-60 секунд. Чай получается насыщенным вкусным, но не крепким. Ситечко идеально подходит для такого способа.

Синдром эмигранта

23 марта 2015, 00:09, emigration · life · ukraine

Наблюдаю за знакомыми, которые совершили или собираются совершить акт эмиграции. У них есть одно сходство: они бранят и унижают родину. Один находит самые мерзкие новости о родной стране, делится ими в соцсетях, с довольствием смакует и обсуждает. Другой сравнивает страну с говном и призывает не привыкать к нему и не приучать детей. Третий высокомерно осуждает всё вокруг.

Я хочу такое поведение назвать «синдром эмигранта». Люди, чтобы еще больше утвердиться в своём решении, опускают и унижают свою страну. Чем больше разница между родиной и новым местом, тем логичнее и разумнее выглядит их шаг. Страна наша не самая лучшая, но не стоит забывать, что она дала нам не самое плохое воспитание, образование и культуру.

Мы тоже рассматриваем в будущем переезд в теплые края, но не форсируем. Неужели я и буду так бранить свою Украину?

Книга Арутюнян о лечении заикания

5 января 2015, 00:18, books

Нашлась хорошая книга о лечении заикания: «Как лечить заикание: Методика устойчивой нормализации речи», автор Лилия Зиновьевна Арутюнян (Андронова). Но нашлась она или в виде 80 кусочков на сайте pedlib, или в виде документа Word. Что бы было удобно читать, сделал книгу в формате fb2. Этот формат понимают все электронные читалки. Качайте без регистрации и смс.

Скачать книгу в формате fb2,
скачать исходник книги в формате odt.

Итоги 2014-го

26 декабря 2014, 15:57, life · music

Сменил работу

В Helicon Tech я проработал больше семи лет. Мы сделали много классных проектов. Это было здорово и интересно. Но всему приходит конец. Случилось предложение, от которого невозможно было отказаться. И я его принял. Теперь я участвую в разработке большой e-commerce системы. Получил должность, длинное название которой, греет моё самолюбие, но не более. Технологии и средства, которые я не любил, стали мне почти родными: C#, Visual Studio, SQL Server. Ну и конечно много JS, CSS, Less. Мой любимый Python совсем исчез из ежедневной работы, это немного огорчает.

Домовед

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

Музыка

В этому году нашлось много хорошей музыки. В большинстве своём — рок. Первая современная русскоязычная группа, которая не «русский рок», а вполне себе «западный рок» — Сегодняночью. Образцовый рок-альбом, который я долго искал: Ryan Adams — именно так на мой вкус должен звучать рок. В инди-поп-альтернативе нашёлся Asgeir — люблю его слушать. Открыл для себя Beck, его последний альбом Morning Phase — волшебный. Новый альбом Аквариума Соль совсем не похож на альбомы последних лет: роковый, жесткий, суровый, но хороший несомненно. Любимую и интересную музыку я теперь сохраняю на специальной страничке.


Но самый мой главный проект и большая радость — подрастающий сын. Рожайте детей и будьте счастливы!

Сегодняночью

23 июня 2014, 00:14, music

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

Я искал что-нибудь интересное в клипах Fairlane Acoustic и нашёл кухонную запись классной песни «Почему?»

Чувак за заднем плане в трусах с пивом и сигаретой отдельно доставляет. А затем обнаружилась балконная запись «Никто не может унять эту свору». Чистый рок-н-ролл:

Вот концертная версия, очень зажигательно:

Это — «Сегодняночью». Мой восторг. Есть две причины, по которым я их полюбил.

Первая: Русские ребята, играют классную музыку, поют на русском. Но это не Русский Рок. Без тоски, без высокой поэзии, без обреченности и скреп. Добротный брит-поп, местами похожий на Oasis, местами на Coldplay, местами на Rolling Stones. Очень живо, профессионально, задорно. Вторая: с отрочества я ищу песни, которые можно петь под гитару. Пою я теперь очень редко, но привычка осталась. У «Сегодняночью» много песен, которые я хочу петь. Простые понятные слова, роковая гармония, рифы. Что ещё нужно?

В общем, всем рекоммендую к прослушиванию.

Сегодня Ночью / Проституция

Все записи