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

Че делать-то? Есть какие-нибудь идеи? Буду рад услышать ваших советов личным сообщением (@aratak). Нахожусь я в Киеве, если что, советы актуальны для него.

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

https://goo.gl/forms/2u4qAm2Vm9veal7i1

Клавиатура все еще не вызывает желания печатать, поэтому копипаста от автора в рубрику #экстрапиар.

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

—
Пишу библиотеку и всё сопутствующее для комфортной работы из JVM с Erlang/Elixir. Для работы используется протокол Erlang Distribution Protocol.

В отличии от Ericson’кого jinterface более дружелюбный API, есть полезняшки из разряда POJO serialization/deserialization, Spring Boot starter, куча утилит, ну и главная фича, ради которой это всё и делалось — под капотам юзаю Netty, а нетормозного jinterface.

ссылка на проект:
https://appulse.io
—

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

Вот вам еще один клевый термин с этим словом: «Презумпция калофикации». Ну, это когда код говно уже заранее, когда еще не открывал его. И попробуй-ка доказать обратное.

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

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

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

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

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

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

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

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

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. Задачу, конечно же, очень полезно разбить на отдельные, более мелкие задачи, но только при условии смысла в каждой отдельной задаче для пользователя системы.