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

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

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

@pmdaily. Фёдор Борщёв — разработчик, который с лаконичностью, ничуть не уступающей «Экстраполяции» пишет о буднях разработчиков и менеджеров. Когда-то работал у Лебедева, а сейчас, по всей видимости, развивает свой собственный бизнес. Но это не точно.

@full_of_hatred. Владимир Рожков — тимлид из Киева. Много времени уделяет самоанализу и пропускает любую мысль через призму своего опыта. Поэтому его и интересно читать.

@denissexy. Дениса Ширяев занимается нейронными сетями и машинным обучением, что очень хорошо описывает и показывает в своём авторском канале. Передовая технологии нашей с вами.

@evilmartians. Марсиане — пожалуй, единственный корпоративный канал, который ведут с душой.

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

Для вас — только самое лучшее, мои дорогие ❤️.

Позавчера Максим Ищенко в твиттере написал то, что «Экстраполяция» описывала еще два года назад. Не кликайте, я перескажу.

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

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

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

В трендах стартапов наблюдаю невероятной глупости новый вид приложения с общим названием «nocode».

Беда в том, что он был всегда, просто сейчас ему название придумали.

У вас на работе пользуются чем-то таким? Нравится?

Ух, какая жаркая дискуссия в чатике! В рамках #dimoneverything от Дмитрия у нас тизер дискуссии:

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

На мой взгляд, nocode имеет практическую применимость в прототипировании:

1. Заказчик/продакт думает, как могла бы выглядеть фича. И "рисует" её не в фотошопе и не на салфетке, а в nocode. Сразу со всеми подробностями и до тех пор, пока оно не начинает "работать" так, как ему нравится. Показывает её ребятам, которые тоже принимают решения. А потом в качестве части описания задачи спускает группе разработки. Которой, в отличие от фотошопа, не приходится задавать вопрос о том, а куда ведёт эта ссылка или как выглядит форма с ошибками. Это очень здорово, но. Это очень здорово в мире, где твои постановщики задач -- латентные программисты, только в код не умеют. На практике часть того, благодаря чему мы регулярно наполняем свои банковские счета, состоит в превращении бесформенной жвачки из головы постановщика задач в поставленную задачу, и исполнение этой задачи может занять зачастую и меньшее время, чем это превращение.

2. У ребят помельче, дизайнер превращает жвачку из головы заказчика не в набор слайдов в инвижнапп, а вот в такой нокод, показывает ему... в общем, всё как в №1. Это очень здорово, но если бы дизайнеры это умели, они бы программировали и не умели видеть красоту.

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

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

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

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

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

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

Понятное дело, за использование идеологически неверного языка программирования на кострах еще никого не сожгли, но вот неприязнь, которую вы испытываете по отношению к радикально-экстремистским языкам программирования имеет ту же суть, что и боязнь Чужого авторства Ридли Скотта. Я сейчас сделаю несколько утверждений, а вы прислушайтесь к внутреннему голосу. То, что вы почувствуете — это ксенофобия в легкой форме, друзья:

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

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

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

И это очень наглядный пример отношений дизайнеров и разработчиков. Дизайнеру плевать на мелкие детали (вроде насечек на объективе). Он не думает о продолжительном использовании устройства (вроде поверхности, за которые берутся потными руками). Дизайнеру важно составить общее впечатление.

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

#dimoneverything из рабочей переписки:

«Окунулся я тут недавно в мир px, em, rem и прочих LGBTQ…»

Мы решили поэкспериментировать и выпустить пилотный выпуск подкаста c названием «Лямбда Подкаст» и в нём мы, редакцией «Экстраполяции», успели поговорить о двух темах.

1. На чём писать микросервисы.
2. Сколько стоит работать на своей первой работе.

Зайдите в чатик и напишите что вы думаете по поводу этого пилотного выпуска. Ваше мнение очень важно для нас.

Приятного прослушивания.

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

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

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

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

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

Иными словами: не можешь сопротивляться — возглавь.

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

#dimoneverything

«Всегда оставляй код в состоянии лучше, чем он был до тебя»

#dimoneverything

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

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

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

Лучший ajax в моей жизни назывался .js.haml. Это было офигенно. Потом я отвернулся, потом я как-то гастролировал с FRP, а потом произошло вот это: https://github.com/reduxjs/redux/commit/9276ff0af6400633d6731b15fed6e70c3561887e

#dimoneverything

Короче, у меня тут ситуация, ещё круче той, что Дмитрий описывал, помните?

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

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

В общем, я в шоке, этому сейлзов молодых учат?

Давным давно, когда я ещё работал в аутсорсе, у нас появился термин локальный, которым мы объясняли вид деятельности, где мы как бы выполняли свою работу по программированию, но при этом не программировали. Термин этот — «программирование в емейлах». Задачей было убедить заказчика с помощью аргументов в письме, что вот эта вот конкретная фича ему не нужна.

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

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

Сова и глобус.

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

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

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

https://telegra.ph/Zlodei-05-15

Ладно, лето красное пропело и пора в онлайн возвращаться. Надеюсь что вы по Экстраполяции скучали так же, как Экстраполяция скучала по вам.

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

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

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

Некоторые такие подсказчики не ставят амбициозных целей и пытаются бить наверняка, подсказывая имена даже новых переменных по первой букве, всякие устоявшиеся конструкции, вроде has_many :projects, если рядом есть класс Project и всякие for i++ конструкции. Это здорово помогает и экономит время.

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

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