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

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

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

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» — это качество задаваемых разработчиком вопросов. Вопросы должны обнаруживать изъяны или недоработки, и споособны изменять мнение по получению новых данных.

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

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

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

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

Технический пост.

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

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

upd: две одинаковые иконки заметил, но отредактировать их уже нельзя. Ориентируйтесь по левой-правоой.

🧚🏾‍♀️ - люблю нажимать на кнопочки в опросах.
☠️ - не отношусь к айти вообще.
🤖 - работаю в аутсорсе/фрилансе.
👾 - работаю в продуктовом проекте.
👨‍💻(левая) - активно учавствую в опенсорсе.
👨‍💻(правая) - работаю над своим проектом в свободное от основной работы время.
👨🏻‍🔧 - работаю над своим проектом в качестве основной работы.

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

Самое страшное в таком вот проекте — это неопределенность. Работать с таким проектом, как общаться с множественными личностями Билли Миллигана — каждый раз большая загадка что ждет в следующей строчке повествования. Каждый следующий разработчик видит какой ужас происходит в исходном коде вот этого вот файла и старается новый код писать, как ему кажется, хорошо, чем только усугубляет ситуацию, ведь до него проект был написан в N стилях, а теперь он написан в N+1 стилях. И абсолютно неважно насколько неправы предыдущие разработчики и насколько прав текущий.

Вот вам несколько правил работы с такими вот унаследованными проектами:

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

2. Рефакторить код, на который нет тестов недопустимо. Объяснение очевидно.

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

4. Если хочется рефакторить во время исправления багов, то сначала выполняем пункт 3. Сначала тесты, потом рефактринг, потом фиксы. Или сначала тесты, потом фиксы, потом опять тесты, потом рефакторинг. Отдельными пулл реквестами и в строго такой последовательности.

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

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

7. Действуйте постепенно. Не нужно исправлять сразу все и сразу везде. Начните с малого и, скажем, возьмите за привычку вместе с утренним кофе делать маленький шаг в сторону стандартизации кода. Это не должно занимать много времени и каждодневные небольшие пулл реквесты сделают свое дело через пару недель.

8. Поделитесь этими намерениями с коллегами и убедитесь, что вы с ними на одной волне. Если они не хотят вам помогать в стандартизации, то пусть хотя бы не мешают и примут эти правила. Можно взять вот это сообщение и отправить в рабочий чат с предложением вроде «Как раз про наш проект рассказывают. Давайте так сделаем?». С большой радостью услышу возражения и отговорки коллег, если конечно же такие будут.

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

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

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

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

Короче, я называюсь Chief Architect, старший (!) архитектор. А сам лупашу рельсы с реактом, ноль подчинённых, планирую свои фичи, в общем-то даже редко привлекаюсь к серьёзным разговорам «как нам обустроить проект». Так по сути разработчик нужен, и настоящим архитекторам как-то унизительно работать выходит.

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

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

И архитекторство воспринимать нужно именно так. Разработчику платят, называют «Старший Архитектор» за то, чтобы когда задача занесёт его в Реакт, внутренности Постгресса, bulk sql insert, тензорфлоу, заверстать футер, написать гем, написать свой редис, организовать параллельные вычисления с разделяемым ресурсом, собеседовать человека, починить кусок php, решить проблему segmentation fault, задеплоить в амазонон с клауд формейшен и лоад балансером, настроить докер — то разработчик бы не сказал, что этого делать не умеет, а всё сделает как надо. Это немного мешает жить, потому что таким разработчикам непозволительно говорить «я этого не умею/не знаю». И у меня не спрашивают «Дмитрий, как у вас с этим», а сразу назначают задачу. Иногда приходится туго (обычно это с футерами), но положение обязывает.

Ребята, судя по опросу, четверть всех нас тут так или иначе делают свои проекты. Это невероятно круто и у вас наверняка есть что рассказать о своих проектах, продуктах и оупенсорсе.

Давайте расскажем о ваших проектах всем? Присылайте мне личным сообщением ссылку на ваш проект и короткое описание что он делает. Ещё добавьте тег #экстрапиар, чтобы я не потерял сообщение. Все крутые проекты оформим отдельным постом и опубликуем в «Экстраполяции».

Познакомился с таким замечательным термином, как «период полураспада знаний». По ссылке там, конечно говорят о разных отраслях, но нас интересует программирование и IT. Замерять мы, конечно же, ничего не будем, но предположить можно очень просто. Сколько месяцев нужно не менять ничего в проекте, чтобы код в нем устарел? Конечно же учитываем и новые версии библиотек, языка программирования, инфраструктуры и прочего. В качестве мысленного эксперимента представьте абстрактную библиотеку на гитхабе. Сколько времени проект должен быть нетронутым, чтобы его не стоило бы трогать?

Мое субъективное мнение, что период полураспада знаний в программировании составляет 3-4 месяца. Если в гитхаб-репозитории я вижу «last updated 3 month ago», то вряд ли просто так буду её использовать.

https://mi3ch.livejournal.com/2716537.html