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

Как только в наш ЖК начали возвращаться жильцы, в домовом чате творилось что-то невероятное. Шерлоки Холмсы в чате есть? Что тут происходило есть какие-нибудь здравые идеи? Что этой инсталляцией хотели сказать асвабадители?

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

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

Я не силён в поговорках, но помните, кто не рискует тот, кто не пьёт шампанское с огурцами.

Тут сейчас волна вайти-вайти, а вот Александр Парамонов, (с которым мне удалось поработать), снял короткометражный фильм «Выйти из IT». Актуальненько. Приятного просмотра.

https://vimeo.com/683521638

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

В 2004 году был сформулирован принцип «ложной слепоты». Этот термин объеденяет в себе несколько разнообразных феноменов нашего восприятия. Обычно выделяют два вида ложной слепоты: слепоту невнимания и слепоту к изменениям. Слепота невнимания (или перцептивная слепота) подразумевает неготовность нашего мозга воспринимать изменения, которые мы не ожидаем увидеть. Как гориллу в ролике, которую уже окрестили «невидимой гориллой» и даже сайт отдельный есть по этому поводу. Еще причиной называют рассеянность, которая вызванная необходимостью полностью сконцентрировать внимание. Очевидно, что на себе вы этот феномен можете почувствовать только если о нем не знаете. И действительно, при повторном эксперименте с другими футболистами и совершенно другой макакой вы ее обязательно заметите, так как ожидаете ее увидеть.

Слепоту к изменениям тоже можно заметить гораздо проще, есть довольно много роликов в интернете на эту тему. Даже BBC снял передачу, посвященную этому феномену. В обычных условиях изменение наблюдаемой картины мгновенно обращает на себя внимание. Однако мы можем не замечать изменения, если они совпадают с коротким прерыванием наблюдаемой картинки. Это может быть кратковременное моргание экрана, монтажный стык видео или короткая помеха. В экспериментах по слепоте к изменениям обнаружилось, что почти 70% испытуемых не замечали подмены главного действующего лица, а изменения менее существенных деталей оставались проигнорированными почти в 100% случаев.

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

#перечитываяэкстраполяцию

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

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

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

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

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

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

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

В телеграме работа с публичными каналами кардинально отличается от привычных площадок. В ютубе, например, все блоггеры, как один, начали просить нажимать на колокольчик, чтобы мгновенно узнавать о новой публикации, новостные ресурсы начали добавлять бесячую браузерную нотификацию о новых постах. А в телеграме же с точностью до наоборот. Пользователей просят нажимать «mute», чтобы новые посты не раздражали. Даже тем, кто не убрал звук оповещений, сообщение не приходит благодаря особому тихому режиму отправки сообщений. Попробуйте отжать «mute» на недельку на канале и убедитесь сами — появится значок непрочитанного сообщения, но форсированное уведомление приходить не будет. За другие каналы ручаться не могу :-)

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

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

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

Люблю, целую, ваша «Экстраполяция».

Ссылка для ответственных, но ленивых: https://www.tgoop.com/itextrapolation

Азимов когда-то сказал про магию и технологии, но в современности эта фраза должна звучать как «Любая достаточно продвинутая программа неотличима от интеллекта»

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

Если писать тесты на код тяжело, неудобно и вообще проще вручную проверить, то значит код этот — говно.

«Самое клёвое в работе программиста выбирать технологии и мечтать о том, каким будет твой код. Самое скучное в работе программиста — писать этот самый код»

Про тесты.

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

А вот тесты — это прям сплошной антипаттерн. Там сплошное дублирование, и процветает макаронный стиль. Но фишка в том, что так и должно быть.

Давным давно коллега мой придумал шикарное правило в отношении тестов и называл его «правилом Шапокляк». Идея в том, что тесты должны быть, как крокодил Гена — плоскими и зелёными. Чем больше в ваших тестах разного устранения дублирования, наследования, переменных и всяких ленивых вызовов, тем больше тест похож на код, а не на тест.

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

Плохо писать:

user = create(User)
expect(user.full_name).to equal("#{user.first_name}  #{user.last_name}")

Это сильно упрощённый пример, но вот expect(2 + 2).to equal(2 + 2) уже отчётливо прослеживается.

Хорошо писать:

user = create(User, first_name: ‘Bob’, last_name: ‘Smith')
expect(user.full_name).to equal("Bob Smith")

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

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

Ко вчерашнему рассказу вспомнили язык Гхеркин и тут историю вспомнил одну.

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

Короче, через неделю наш Мэтью сделал первый пулл реквест в проект с фича-реквестом. Подумать только! Чувак, далекий от программирования, понял, что описать то, что он хочет получить, можно на языке, кхм-кхм, программирования и программисты сделают так, чтобы оно формально удовлетворяло описанным требованиям.

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

Считаю лучшим применением этого языка.

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

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

Ребята. У нас открыт сбор всё тому же отряду. Будем рады любой помощи. Спасибо.

Ссылка банки не поменялась: https://send.monobank.ua/jar/4QxM3tuPTR

Монобанк-карта: 5375411201873143

Приват-карта: 5168752003854042

Пейпал: alexey@osipenko.in.ua

Мы большие молодцы. Эта сумма пойдёт на покупку десяти тактических рюкзаков и шестнадцати пар летних берцев. Отчёт будет, ессно.

Всем участвовавшим большое-пребольшое спасибо. Но не расходимся, война только начинается.

Продолжаем рубрику «хорошо-плохо» и опять про тесты.

Месседж очень простой: Перестаньте писать циклы в тестах.

Плохо:

[2, 4, 6].each { |item|
expect(item).to_be_odd()
}

Хорошо:

expect(2).to_be_odd()
expect(4).to_be_odd()
expect(6).to_be_odd()

Иногда ещё, если позволяет фреймворк, можно это красиво завернуть в макрос (или что там у вас есть в фреймворке):

expect_to_be_odd(4)

Но нужно помнить, что такие вот макросы в тестах — это тоже код, который тоже бы неплохо протестировать. Правило всё такое же — любой мало-мальски сложный код нужно тестировать. Поэтому код должен быть максимально простым.

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

Парадоксально, но с гитхаб-копилотом молодому и неопытному джуну станет сильно проще писать код и насколько же сложнее будет найти работу.

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

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

В итоге, джунам проще писать с ним код и сложнее чему-то научиться.