— Чем занимаешься сейчас?
— Занимаю сейчас своим проектом
— А каким? Расскажи, интересно.
— Сейчас не могу ничего рассказать, потом все увидишь.

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

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

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

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

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

Нашел и прислал ссылку Андрей, тот самый, который рассказывал о его опыте работы с «проклятыми кастомными селектами» в «Экстраполяции».

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

https://www.psychologytoday.com/us/blog/ulterior-motives/200905/if-you-want-succeed-don-t-tell-anyone

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

Собеседуя матёрых разработчиков, нет смысла докапываться до того, знают ли они принципы сортировки данных, разбираются ли они в красно-черных деревьях или любое другое выводимое или табличное знание. Считается, что умудренный опытом разработчик либо досконально знает такие штуки либо уже пару раз их успел забыть. И если забыл, то ему ничего не стоит это вспомнить с интернетом под рукой. Значительно важнее как такие разработчики себя ведут в диалогах на переговорах, дискуссиях или митапах. Очень важно как они умеют рассказывать о своих знаниях, как они могут объяснить какую-то сложную штуку коллеге или донести свою мысль аудитории. Тестовое задание (или скорее просто собеседование) должно это хорошо демонстрировать.

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

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

Ребята, среди нас же есть проектные и продуктовые менеджеры, сейлзы? А какие вы ресурсы читаете? Ну, там бложики, каналы в телеграме, соцсети каких-то личностей особых. Скиньте личным сообщением мне (@aratak), пожалуйста.

Ребята, экстраполяция, конечно, экстраполяцией, она никуда не делась и все по-старому. Но я буду рад вас видеть еще и в соцсетях в традиционном смысле этого слова. Например, в фейсбуке (https://www.facebook.com/alexey.osipenko) или в инстаграм (https://www.instagram.com/aratak/). Программирования там мало, потому как оно все тут сосредоточено. А вот непрограммирование в экстраполяцию не попадает, а попадает все туда.

В общем, добро пожаловать.

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

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

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

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

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

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

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

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

Основной принцип все же соблюдается — необходимо думать на несколько ходов вперёд.

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

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

Дело в том, что современные верстальщики очень быстро учатся программировать (и это очень хорошо) и пытаются решать проблемы вёрстки патернами программирования. Это когда:

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

— Начинают использовать css-фреймворки. Ничего не меняется, а редактировать стили фреймворков ещё страшнее.

— Ищут спасения в генерации стилей всякими sass или less. Становится неочевидно хуже, ведь писать приходится меньше букв, а код все так же страшно менять.

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

Расскажите мне, дорогие друзья, как вы боретесь с постоянно растущей и пухнущей таблицей стилей. Лучше всего личным сообщением (@aratak) и с хештегом, чтобы не потерять (#cssэкстраполяция). Мне очень интересно и, уверен, многим тоже.

Недавно мы проводили опрос о проектном инструменте и вот результаты. Как и предполагалось, большинство используют Джиру и подавляющее большинство не в восторге. Ну, типа работает и ладно.

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

Подробнее в аккуратно написанной статье:
https://riter.co/blog/results-of-our-survey-on-project-management-tools

Как и ожидалось, ответов по поводу организации css в проектах было много. Тех, которые будут публиковаться — всего парочка и начнём с самого крутого. Прислал его Андрей, который практически уже соавтор канала.

Тырим подходы у этих парней: https://innoq.style/. У них там Atomic Design (общая философия для делелния на компоненты)+ ITCSS (структура организации стилей, где они раскладываются по слоям. Там находится место и всяким миксинам/тулзам, которые даже не генерируют цсс и всяким ресетам/нормалайзам) + BEM (для синтаксиса и правил для определения классов). В последнем проекте мы заменили BEM на bliss-css, что слегка поменяло синтаксис классов, в некоторые места принесло чуток больше ясности, а в некоторые конфликты с ITCSS. В чем были конфликты не вспомню, но они были мелкими и вполне нормально разруливаемыми и документируемыми. В этом последнем проекте мы действительно заморочились и сделали все правильно: https://visdeal.gitlab.io/

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

Сегодня просто цитата из рабочей переписки:

«Я год работал над собой, прежде чем смог сменить чувство, что я подвёл чьи-то ожидания, не сделав задачу в срок, на чувство "какой дебил написал здесь "два часа".»

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

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

​​Внезапная заметка о пулл реквестах.

Ошибочно считать, что фича должна быть сделана за один пулл реквест. Или, если подходить формально, за наименьшее количество пулл реквестов. С такими пулл реквестами искать ошибки и причины их появления становится значительно тяжелей. В добавок совершенно непонятно на какой стадии находится разработка текущей фичи. Почти готова ли она или там только начало — точно не знает даже разработчик этой самой фичи. Кроме того, гит-конфликты будут возникать на каждом шагу и будут настолько огромны, что будут тянуть на небольшую такую задачку с абсурдным названием «пытаемся смержить текущий мастер в мою ветку на 100+ коммитов» с оценкой часов в пять. Ну, и вишенкой на торте будет полностью парализованный git bisect. При марафонском пулл реквесте с мириадой коммитов с уверенностью можно будет утверждать, что «баг где-то там, между двумя мастерами».

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

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

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

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

2. Очень важно разобраться с формулировкой задач. Задачи, вроде «обновить библиотеку А с версии 1.0.3 до 1.0.5» быть не может, ведь это никому не интересно, ни разработчику, ни менеджеру, ни управляющему. Все задачи должны быть сформулированы исключительно с точки зрения пользователя системы. В этом смысле очень нравится термин «user story» (не знаю как это правильно перевести, не потеряв смысл), где сразу становится понятно что же будет являться той самой историей пользователя, а что не будет.

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

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

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

Итак, физика (наука).

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

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

Если вам надо сверстать новую страничку с какими-то новыми доселе неведомыми сущностями и при этом не пришлось выписывать новую пачку css-правил, то у вас в стилях все хорошо.

#cssэкстраполяция

Последний пост в цикле #cssэкстраполяция и он будет про попиксельную верстку. И сначала у меня несколько утверждений.

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

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

В-третьих, дизайнера не заботит количество пикселей слева и справа от блока. Когда ему надо поставить блок посередине, он берет мышку и тянет блок в середину. Если слева будет 56 пикселей, а справа 57, то для дизайнера это посередине.

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

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

Итого:

1. Дизайнеру нужно рисовать больше макетов, чтобы было с чем сравнивать попиксельно.

2. Верстальщик превращается в “psd2html converter” и от него требуют перестать задумываться над смыслом свёрстанного. Мол, ты верстай, а думать другие будут.

3. Пропадает возможность исправить логическую ошибку на этапе верстки.

4. Умным и творческим или просто амбициозным людям нет никакого резона оставаться просто верстальщиками.

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

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

https://github.com/reduxjs/redux/commit/9276ff0af6400633d6731b15fed6e70c3561887e

Если рекрутер начинает своё письмо «Дмитрий, я вижу, что вы открыли моё предыдущее письмо, но мне ничего не ответили, неужели со мной что-то не так?», допустимо ли ответить «я когда открывал письмо, вас за спиной точно не стояло, хватить следить за мной, ненормальная»?

Здесь много сарказма, и хамить я не собираюсь, но мне просто интересно — да, я знаю, что есть эти однопиксельные картинки, и сам такое прикручивал, но разве деловой этикет признал их чем-то, что можно упоминать в разговоре?