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

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

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

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

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

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

Команда эта — 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/

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

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

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

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

Ведущий нашей постоянной рубрики Дмитрий комментирует последнюю запись «Экстраполяции», мол не всегда «Понравилось, но порекомендовать не смогу» — это плохой пост.

««Понравилось, но порекомендовать не смогу» — это как после визита в БДСМ бордель», говорит Дмитрий. Просто не хочется, чтобы кто-то знал.

Недавно попросили написать рекомендательное письмо разработчику, в котором был простой вопрос, заставивший серьезно задуматься. Спрашивали о самом сильном качестве кандидата. Мол, «назовите самое сильное и одно». Такой банальный вопрос сформулировал проблему самого важного критерия разработчика.

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

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

Свой вариант ответа я напишу следующим постом, а сейчас хочу попросить вас прислать мне (@aratak) свой личным сообщением. Я уверен, что ваши версии будут не менее захватывающими, чем моя.

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

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

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

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

Два варианта были, прям, шикарные:

Несмотря на иронию, очень понравился вариант «Knowing when to put off the keyboard and go to bed is one of the best skills you can get as an engineer».

Еще один шикарный вариант качества от Леонида, соведущего «Lambda Night Show» — это качество задаваемых разработчиком вопросов. Вопросы должны обнаруживать изъяны или недоработки, и споособны изменять мнение по получению новых данных.

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

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

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

​​Ребята, это фронтенд у нас сейчас такой или что-то конкретно с этим кодом не так? Голосуем, интересно ваше мнение.