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

Болезнь непонятна, симптомы очевидны. И отсюда и появляются правила, которые лечат эти самые симптомы.

- Программисты пилят фичи самостоятельно и не обсуждают решения? Давайте обяжем проводить код-ревью.

- Разбились на маленькие команды и понятия нет что происходит в других командах? Давайте устроим еженедельное собрание тимлидов с обязательным выступлением рт каждого.

- Программист зря зарывается на несколько недель над фичей? Давайте устроим каждодневные письменные отчеты.

- Менеджерам нужны какие-то данные для отчета стейкхолдерам? Утренние митапы решат эту проблему.

Ну, и так далее.

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

— Вы используете скрам?
— Нет, у меня в команде только адекватные люди, которые поступают максимально разумно.
— Зря не используете, мне помогло.

Решил поддаться тренду и завёл MTProxy с автопиаром канала. Уверен, что все, кто хотел воспользовался ботом, который бесплатный сокс-прокси раздаёт (@cimon_proxy_bot), но вы здоровски поможете каналу, если порекомендуете наш MTProxy своим друзьям и коллегам. Использовав этот прокси, ваши друзья увидят канал «Экстраполяции» в своём списке каналов и, возможно, подпишутся на него. Спасибо!

https://yangx.top/proxy?server=mtproxy.cimon.pub&port=443&secret=64b764d215a377c1676d3ea45b65fc2d

Категорически неправильно оправлять сообщение непосредственно перед тем, как уйти с рабочего места, хоть такое встречается сплошь и рядом. Ну, это когда «в конце рабочего дня письмо заказчику напишу», «мне пока нечего писать» или «вот доделаю задачу и тогда сразу напишу». И в конце рабочего дня, когда задача еще не доделана и писать все еще нечего, а надо рождаются в муках письма со смыслом «мы делали, делали, но еще не сделали. Есть куча проблем, которые мы героически пытаемся решить». Это, прям, самый ужасный выбор времени для отправки сообщения. Правда, хуже только отсутствие сообщения вообще. А ведь нужно всегда учитывать, что на ваше сообщение и ответить могут!

Самое позднее, когда еще можно отправить сообщение — это где-то за час до того, как закрываете крышку ноутбука. Хорошо писать письма в середине рабочего дня, скажем, сразу после обеда. Конечно же, утренние письма, которые остались должком со вчера, конечно же, не в счет.

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

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

----

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

#коммуникация

В тему общения с иностранными партнерами очень хорошо высказался Эдуард Лобас, соведущий в «Вечернем лямбдашоу» и директор компании Webinerds. Очень важно понимать иностранного партнера на том уровне, на котором понимаешь своего хорошего друга. Лайки, подписки, колокольчики и все такое.

https://youtu.be/Riw0XCIh364

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

1. Аудиосообщения могут быть только ответом на сообщение выше, но никак не первым сообщением диалога. Собеседник должен понимать тему того, что ему предстоит прослушать.

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

3. Убедись, что вокруг минимум посторонних шумов при записи аудио. Если шумы нельзя убрать — пиши текстом.

4. Сообщения короче пяти секунд не имеют оправдания на существование.

Идеальный пример использования аудиосообщения: коротко описать текстом мысль, а потом сразу после этого голосом рассказать эмоциональные детали.

Четвертый выпуск «Lambda Night Show» с моим участием уже на всех ютубах планеты. Говорим в основном про игры, потому как в гостях у нас продюсер игровой студии Роман Томилин.

К слову, у нас появился режиссер, сценарий и сцена после титров.

Ссылка на полный выпуск

Недостаточная коммуникация — это не причина плохого управления проектом, а тоже симптом. Конечно, «у нас все в проекте плохо, потому что у нас плохая коммуникация», безусловно, немного лучше, чем «у нас все разваливается, потому что нет ежедневных утренних коллективных стэндап-шоу», но все ещё плохо для формулировки Главной Болезни В Проекте.

#коммуникация

Ребята, #коммуникация в «Экстраполяции».

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

Сегодня будет практический совет со стратегической моралью под эгидой рубрики «Лайфхаки от Экстраполяции».

В гите есть замечательная способность автоматически находить баги. Нет, конечно далеко не все и далеко не всегда, но в некоторых редких случаях это оказывается очень полезным. Это в тех случаях, когда точно понятно и видно, что баг есть, а где он происходит понять не получится. Мне эта штука понадобилась два или три раза всего, но сильно время сэкономила. Главное, что необходимо, чтобы воспользоваться этой штукой — вы точно знаете как воспроизвести баг.

Команда эта — git bisect (документация). Это такой бинарный поиск виноватого коммита. git bisect bad говорит о том, что в коммите баг есть, а git bisect good — что бага нет. И бисект за несколько таких вот маркировок коммитов сам выберет тот коммит, в котором все сломалось. И обещанное «автоматически» можно сделать с помощью команды git bisect run scriptname и бисект сам определит good или bad по коду возврата работы скрипта. Здорово, правда? Скажем, пишете вы новый тест в новый файл (чтобы гит игнорировал его при скачках по коммитам) и запускаете git bisect run bin/mocha test/newfile_test.js. Через несколько минут гит вам скажет где конкретно это сломалось.

И теперь несколько философских выводов.

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

2. Сплющивать коммиты при мерже, как это стало модным, не очень хорошая идея. Да, это уменьшит количество коммитов и, возможно, станет немного лучше смотреть на дерево проекта, в котором работает тысяча человек, но в команде из тысячи человек и одним репозиторием есть проблемы куда важнее, чем распухшее гит-дерево. В принципе плющить коммиты можно, но нужно это делать осознанно вручную, чтобы объединить некоторые коммиты в один. Это удобно делать в интерактивном режиме гита (git rebase --interactive с документацией). И придумайте мне, пожалуйста, нормальный русский термин для «squash commits».

3. Комментарий к коммиту должен содержать причину сделанного, а не тупо пересказывать содержимое коммита. Комментарий вроде «Добавлен метод такой-то в модуль сякой-то» — плохой и не несет никакого дополнительного смысла. Уж лучше вместо таких комментариев рисуйте смайл какашки: git commit -m "💩", будет не менее информативно. Комментарий «Теперь модуль сякой-то может работать с вон тем вот» – хороший и пояснит зачем нужно было делать то, что было сделано. Сильно экономит время при дебаге.

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

1. Итак, с точки зрения переменной в коде не существует никакого гита, веток и коммитов. Есть только текущая кодовая база и соседи всяческие — переменные, классы, функции и прочее. Окружающая наблюдаемая реальность, так сказать. Каждый коммит в данном случае — изменение окружающего мира во времени.

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

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

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

4. Итак, у нас существуют параллельные вселенные и наша текущая файловая система умеет отображать содержимое одной из вселенных. С помощью команд гита можно увидеть всю историю той или иной вселенной и увидеть взаимосвязь между ними. С точки зрения переменной в файлике в одной из веток, нет никаких других веток, нет никакого «мастера». Есть только сквозная история от «git init» до текущего момента.

И дальше самое интересное. Что такое «git rebase»? Это такая попытка повторить исторические события одной вселенной в другой. Ну, вот родился некий мальчик Адольф в 1889 году и как-то взаимодействовал с объектами из его вселенной и времени. Если мы сделаем «git rebase --onto v2018 v1889 v1918» то фактически мы попытаемся воспроизвести все события с 1889 года во вселенной 2018 года. Что, естественно приведет к конфликтам, которые нужно как-то решить. Ну, вот в 1889 году была у него мать Клара. В 2018 году той Клары, понятное дело, нет. И чтобы наш Адольф в 2018-м родился, необходимо выбрать другую мать, которая его родит. Или, согласно коммитам ветки v1889...v1918 наша переменная «Адольф» учавствовала в Первой мировой войне. И это тоже прийдется как-то решать программисту, инициировавшему ребейз на ветку 2018-го.

Фактически «git rebase» — это попытка воспроизвести все коммиты старой ветки в новой реальности. И относиться к каждому коммиту нужно так, как будто бы это совершенно новые коммиты, которые делаются по образу и подобию старых. Некоторые коммиты будут просто лишены смысла — для этого есть «git rebase --skip», некоторые коммиты будут выглядеть чуть менее, чем полностью другими. Не стесняйтесь использовать «git rebase --interactive», чтобы переставить коммиты местами, если это необходимо, выбросить лишнее и сплющить несколько коммитов в один, если так будет казаться, что это новая целостная история, а не просто под копирку воспроизведенная старая. Все существа текущей реальности не должны даже подозревать, что существуют какие-то другие вселенные. Если кто-то найдет у себя под домом аномалию вроде «<<<<<<<» и «>>>>>>>», то это может стать причиной кучи бед в этой вселенной.

Что такое «git merge»? А это, друзья, путешествия между параллельными вселенными. Когда результаты одной вселенной единовременно оказываются в другой. И, обратите внимание, это возможно только если между этими вселенными нет конфликтов. Если существует конфликт, скажем, в одной вселенной папы Адольфа не существовало и, следовательно, Адольф и не родился, а в другой его картина висела в спецхранилище американского правительства, то смержить одну ветку в другую система просто не позволит и путешествия между мирами не произойдет. Получится, так сказать, банальный мерж-конфликт.

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

Леонид Шевцов в рамках «Lambda Night Show» рассказывает об идеальном коде, времени, как входном параметре и разнице восприятия фичи программистами и пользователями. Я бы лучше не сказал.

https://youtu.be/rd5HQaE_7lY

dev.to выглядит достаточно свежо на фоне всяких медиумов, реддитов и хабров. Прям, настолько свежо, что мы решили завести там корпоративный блог. Первая статья уже есть и она о том, как подружить PostgreSQL и Rails. Подписывайтесь!

https://dev.to/riter

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

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

И выводы, как для кандидатов собеседования, так и для собеседующих:

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

2. Показательное выступление на собеседовании, позволят с пафосом пройти отбор, но это никак не поможет определить как он себя покажет в боевых условиях.

3. Олимпиадное решение задач хороший повод повнимателнее присмотреться к кандидату, но никак не решающий фактор.

Пятый выпуск «Lambda Night Show», где я учавствую, уже почти готов, а пока мы к нему активно готовимся. Чтобы два раза не вставать, как вам шоу?

https://youtu.be/t-DyviU0MWk

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

У меня проект такая огромная навороченная дура, что я в 80% не могу проклацать функциональность руками. Я этот зоопарк просто правильно запустить не могу. Ну и навставлять в базу так, чтобы я мог добраться до того места и сделать ту штуку. И речь не о том, плохо это или хорошо, речь о тестах.

Я в команде уже известен, как маньяк тестов. «На каждый фикс Дмитрий присылает экран тестов» — это не я о себе, это они обо мне.

И что ты думаешь?

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

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

Короче, перефразируя классика, всё, что не протестировано, не существует.

Больше половины опрошенных не смотрели «Lambda Night Show», но мы не отчаиваемся.
Этот выпуск получился самым длинным, но от этого он только выиграл.

https://youtu.be/a8NCWGlACSo

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

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

А все потому что это видимая часть работы. И по ней встречают, а многие и провожают.

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

Нам в команду нужна пара нетехнических специалистов по общению с потенциальными клиентами и медиа.

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

Выходит что-то среднее между smm, pr и sales я бы сказал.

Заявки принимаются на почту [email protected] до 15 августа.

В теле письма необходимо указать желаемую заработную плату в долларах и парой абзацев на английском рассказать почему подавляющее большинство ICO используют сеть Ethereum. С криптовалютами и будет связана основная деятельность.

Форвардните друзьям, наверняка у вас есть с кем поделится. Спасибо.

По аналогии с термином «пуленепробиваемый дизайн», давайте сформулируем «пуленепробиваемый код».

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

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

Это и есть пуленепробиваемый код.

Критериев и признаков такого кода много. Опустим такие банальные штуки, вроде «понятен при прочтении», «делает только одно действие» и тому подобное. Есть и вполне практичные штуки, описанные не в одной книге, на подобии «глобальные переменные это плохо» или «чистые функции это хорошо», о них тоже упомянем вскользь.

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

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

Украине 30 августа проходит конференция «Развитие кластеров IoT: Украина-Польша». Программа обещает быть клевой с докладами польских, литовских и украинских экспертов. Специально для вас, дорогие мои, цену уполовинили по промокоду «IT200».

Билеты: https://industry4-0-ukraine.com.ua/conference/
Почитать больше: https://www.facebook.com/events/272740313536684/