Архив недели @xanf_ua
Понедельник
Всем продуктивного понедельника! На этой неделе с вами @xanf_ua и у меня обширный список вопросов и вбросов - от инфоцыганства и молчаливого саботажа в крупных компаниях и стоит ли с этим боться до "тайпскрипт мешает вашей компании зарабатывать деньги" :)
А какие темы вы бы хотели от меня услышать? Давайте вначале соберём глас народа, а потом сравним мой список и ваши ожидания и сделаем максимально насыщенную полезными дискуссиями (я не люблю холивары) неделю :)
Для тех кто не в курсе кто такой @xanf_ua:
- 15 лет пишу на JS
- Работаю в GitLab на позиции Senior Frontend Engineer - в основном клепаю формочки, воюю за тесты и ищу идеальный state management
- Учу людей в проекте javascript.ninja (наконец могу сказать это без иронии)
Спасибо всем за отклики :) Завтра начнём жечь
А пока давайте начнём "за жизнь". Прошлый раз в андерхуде я был в 2016 году jsunderhood.ru/xanf_ua/
За это я время я успел "познать себя", понять чего я хочу и структурировать свою жизнь целиком вокруг этих хотелок. Что же вышло?
Я понял, что больше всего кайфа мне приносит преподавать. Я познакомился с крутыми преподавателями не в IT и понял, что преподаю я как дерьмо. Последние 4 года я занимаюсь с менторами педагогикой, и и по ощущениям и по метрикам я вырос как преподаватель практически на порядок
Понял, что "владеть айти-компанией" - это вообще не моя история, мне нравится быть инженером. Поэтому когда в компании все стало плохо из-за того что продаван я куда хуже чем преподаватель - компанию закрыл и жалею только об одном - что не сделал это раньше
Тем не менее 7 лет управления компанией были бесценным опытом - они научили меня уметь измерять всё деньгами. Теперь я умею смотреть на технологии не только с "инженерной" точки зрения, но и с точки зрения ROI.
В дополнение к этому прилагаются куча важных плюшек, для жизни
Что за плюшки? Финансовая дисциплина, осознание того что не стоит держать все яйца в одной корзине, особенно если эти яйца твои, понимание того что всё что я зарабатываю - это временно, и что надо думать о пенсии. Стоило бы об этом начать думать в 20, но в 26 лучше чем в 40 :)
И поскольку я хотел преподавать, я верил, что нельзя преподавать "голоса в голове" - поэтому устроился на работу в большой продукт (GitLab), где огромное количество проблем, решение которых до сих пор для меня челлендж или даже вызов
Но это приносит кучу проблем (про них говорю отдельно) - фактически это ощущается как 2.5 фултайм нагрузки - ты работаешь, ты учишься преподавать, ты преподаешь. При грамотном тайм-менеджменте это работает, но - до первого фейла в жизни. Любая проблема рушит все планы
От этого регулярно страдали мои студенты (но про это мы еще поговорим, как я лажаю со сроками в преподавании, как мы боремся с этим и куда вообще идем), поэтому хочу извиниться перед каждым студентом за каждое невыполненное или невыполненное пока-еще совещание
"Обещание" конечно! Телефон почему-то решил исправить (про телефон мы тоже поговорим, это первая железка за много лет, которая радует меня неимоверно и стала верным финансовым помощником)
На этом пока остановимся, пока все смотрят презентацию Эппла (я к ней равнодушен) ;)
Тред (@xanf_ua-2)
Вторник
Доброе утро, коллеги! Как вам спалось?
Хочу в качестве утренней разминки рассказать о сне, своих экспериментах с ним и, возможно, подсказать как спать лучше
Для меня сон - это всегда ощущение потерянного времени и маленькой смерти. Мне жалко спать. Поэтому я всегда относился ко сну как к необходимому злу и пытался его оптимизировать
Когда я работал в аутсорсинговой компании, практиковал полифазный сон. Спал 3 часа ночью и 2х45 минут днём. Первые две недели нереально тяжело, потом нормально. Прекратил после 3 месяцев, когда понял что начал тупеть - работать в таком режиме можно, придумывать что-то нет
Когда у меня была своя компания - сон был стрессом. Вернее не сон, а пробуждение, потому что каждое пробуждение было с мыслью "а какая жопа у нас сегодня". Когда у тебя маленькая команда - то и запасы ресурсов для маневров и переживания ударов судьбы маленькая
Когда я закрыл компанию я три месяца высыпался. Помогло слабо. Моя основная проблема - если у меня в голове есть мысль, я не могу перестать ее думать и это очень мешает уснуть.
Лучшее лекарство у меня - мотоцикл. чуть похуже - езда по ночному городу с открытой крышей / окнами
Сейчас должно было стать лучше, но нет - достаточно после 8-9 вечера писать видео "с лицом" - а это два источника света прям "в морду". Все, прощай сон. А учитывая специфику дома где я живу - нормально писать видео можно либо рано утром, либо вечером. Человек-дрель тоже не спит
Ок, поныл, теперь к конструктиву.
Думаю все знают что ложиться спать надо и просыпаться в одно и то же время лучше всего. Для меня это не работает. Иногда мне кажется что объемы сна которые мне нужны выбирает генератор случайных чисел
У меня категорически не работает мелатонин в таблетках. Вот просто ноль эффекта. Пробовал его и как средство для борьбы с джетлагом и с бессонницей. Плацебо, наверное, и то было бы эффективнее
Как я меряю качество сна? Я пробовал разные трекеры сна, самым показательным для меня оказалась комбинация из показателей вариабельности сердечного ритма (больше - лучше, до разумных пределов), частоты дыхания ночью и количества глубокого сна
Эти показатели меряет polar vantage v, да и любые, думаю, спортивные часы с непрерывным трекингом пульса. Они меряют и другие числа, но, как показали 3 месяца ведения статистики сна - для меня они статистически незначимы.
В такую погоду как сейчас тоже прекрасно спится :)
Очень хорошо для меня работает низкая температура в помещении для сна (около 17 градусов), открытое окно. Если вы ещё не купили себе датчик уровня СО2 - купите и приучите себя проветривать при цифре 800 - обнаружите что и спится лучше, и работать можно на пару часов дольше
Правда не знаю как у вас, у меня в городе открытое окно - катастрофический источник пыли, в том числе очередь вредной для здоровья (привет коксохиму!). Борюсь с этим очистителем воздуха который фильтрует PM2.5/PM10 частицы
Ещё я пытался научиться остановке внутреннего диалога чтоб лучше спать. Каждая первая школа медитации этому учит. Не научился. Максимум что умею - долго в деталях представлять огонь, с язычками пламени и потрескиванием. Помогает мозгу прекратить думать о программировании
А теперь что будет если не спать или спать плохо, как я. В 20 лет не будет ничего, в 25 будете уставшим, в 30 - могут начаться проблемы с гормонами. Особенно если стресса в вашей жизни много. Мало спать - это как держать мотор в красной зоне - можно, но опасно
Поскольку сейчас, как вы догадались, за рулём, хотел сделать фото с красной зоной к прошлому твиту, а оказалось, что ее и нет у меня. Помните, есть люди которым надо категорически мало сна, но я не знаю как безопасно проверить, что вы один из них
В завершение темы. Есть мало вещей в жизни, о которых я жалею, что не начал думать раньше. Сон в объемах столько, сколько нужно — одна из них. Когда вы "не спите" - страдает все, от вашего организма до способности здраво оценивать и планировать объемы работ. Крепких вам снов!
Тред (@xanf_ua-2)
Давайте переходить к серьезным темам и начну с самой важной для меня - управление состоянием. Вопрос в зал - какими качествами должен обладать лучши для вас менеджер состояний? Где болит?
Похоже status.fastly.com обеспечил мне перерыв :) а то хотел покидаться ссылками на гитхаб и гитлаб, а оба лежат :)
Посмотрим, надолго ли
Спасибо всем за дельные замечания и вопросы. Как и обещал - делюсь своим видением проблемы стейт-менеджмента
Для меня сейчас - это основная и фундаментальная проблема в рамках GitLab. Я ее формулирую так "как реализовывать хранение и управление состоянием так, чтобы не рос технический долг и не страдал скорость деливери фич"
Нюанс начинается уже с определения: я осознанно ставлю вопрос технического долга важнее скорости деливери фич. Это связано с тем, что в случае "кризиса срочно-надо-на-вчера" (а так бывает и это нормально), когда мы ставим технический долг во главе угла - мы можем им пожертвовать
Другими словами - фокус на "скорость деливери фич" не даёт нам существенного запаса для "критического deliverable" и одновременно систематически убивает код. Фокус на технический долг - помогает коду жить, позволяя иногда использовать запретные заклинания (не злоупотребляя)
Что для меня важно - there is EXACTLY one way to do it. В проектах, где больше одного инженера, если что-то можно сделать "иначе" - оно будет сделано, и потом все будут морщить нос от кода друг друга.
Нам нужна мощная система ограничений, диктующая подходы к написанию кода
Интересно, что программисты часто сопротивляются идее ограничений, ведь мы неизбежно в них упрёмся. Отчасти это, конечно, правда
Забавно, что дизайнеры, к примеру, знают, что "творить" когда заказчиком поставлены ограничения - сильно проще, чем когда просто "сделайте мне ВАУ!"
Именно поэтому, к примеру, "голый" Redux вызывает у меня боль - слишком много способов сделать одну и ту же вещь, да и в принципе поверх него каждый строит что кому нравится - thunk, observable, saga - выбирайте. И даже в рамках одного подхода можно сделать очень по-разному
В то же время, если взять допустим RTK (redux-toolkit) - то это на порядок более взрослая система, которая принудительно навязывает вам подходы "так, а никак иначе".
При этом, что важно, давая достаточное количество escape hatches, если ограничения все-таки сделают вам больно
Нет, я не фанат redux или redux-toolkit :)
Нельзя не упомянуть свежерелизнутую redux-toolkit.js.org/rtk-query/over… RTQ Query (которая вдохновлена react-query и аналогичным). Я рад что фундаментальная мысль, что КЕШИРОВАНИЕ ОТВЕТОВ СЕРВЕРА ЭТО НЕ СОСТОЯНИЕ идет в мейнстрим
Здесь я не могу не кинуть огород в камень Vuex, который является стандартом де-факто в мире Vue - там всё это выглядит как редакс лет 5 назад - совершенно "дикое поле" и мысли о том, что надо разделять состояние и кеш только-только начинают звучать среди разработчиков на Vue
Пока я писал этот пост, @themagicworldof прислал типичный ответ про состояние "в идеале его не должно быть". Как по мне, это неправильное заявление. Мы должны избегать состояния, там, где мы можем это сделать, но не должны отрицать его там, где оно по факту есть
Тред (@xanf_ua-2)
Итак, продолжаем про state management, а именно Apollo Client. apollographql.com/docs/react/
Для тех, кто не в курсе - Apollo Client это "толстый graphql-клиент". Он автоматически выполняет нормализацию кеша, пользуясь тем, что в GraphQL строго типизированные данные
О недостатках, хотя нет, хм... ОСОБЕННОСТЯХ Apollo Client можно говорить очень долго - к примеру, они КРАЙНЕ react-centric, но есть у Apollo Client важная фича - это управление local state
Фактически, вы можете из своих компонентов, продолжать писать GraphQL-запросы и мутации и ваши компоненты почти не будут знать работают ли они с локальным состоянием или с состоянием сервера.
Почему почти? потому что придется писать директиву @client
К примеру, @nodkz не очень любит все эти финты с локальным состоянием в Apollo, и я прекрасно его понимаю
Тем не менее, к примеру, в проектах где локального состояния мало и оно сравнительно простое - такой подход имеет право на жизнь
Среда
Среда, середина недели! И начнем опять с нетехнической темы. Я хочу поговорить о карьерных лестницах. Есть распространённое мнение, что самый простой способ расти - менять компанию. Вы тоже так считаете?
В вашей компании есть четкие матрицы роста? Как они вам по ощущениям?
Итак, карьерные лестницы и мои ощущения на них.
Во многом этот тред навеян заполнением своего Career Mapping в GitLab и обсуждением этого с многими людьми "а как у вас это происходит" :)
Начнём с самого простого - с иерархии. Если с первыми шагами у инженера всё просто - junior, middle, senior, то дальше всё нетривиальнее - часто с точки зрения инженерных позиций наступает карьерный тупик
Когда я говорю о карьерном тупике инженерной работы, то имею ввиду, что часто "продолжением" этой лесенки рисуют всякое "тимлидство" - должности, направленные на управление людьми, а не кодом.
Структура карьерной лестницы целиком диктуется бизнес-потребностями компании, поэтому в том, что к примеру в аутсорсинговой небольшой компании будет такая градация нет ничего убедительного - инженеры выше сенйьора могут быть нужны в единичном экземпляре
По моему опыту, четким признаком такого места является наличие "высокой" технической должности (она может называться очень по-разному в разных компаниях - Solution Architect, CTO, Tech Lead ) без внятных критериев получения подобной должности.
Другими словами, речь идет не о развитии конкретного инженера, а о "заполнении" вакансии. Когда вакансия наверху освободится (или появится, к примеру, вследствие роста компании) - компания тем или иным способом её заполнит. До этого вы можете быть хоть трижды молодцом
Еще раз акцентирую внимание - подобная структура - ни хорошо ни плохо, но важно осознавать её, чтобы понимать, как она соотносится с вашими карьерными целями и задачами.
Одной из главных проблем роста по принципу "молодец" - принцип Питера ru.wikipedia.org/wiki/%D0%9F%D1…
Я не раз видел как хорошие инженеры senior-уровня плохо справляются с функциональными задачами уровня выше
Тред (@xanf_ua-2)
Я помню, что обещал про urql, но уже завтра :)
Сегодня пойду разбираться дальше с React 18, глядишь видео выложу
💡 State management is difficult not because managing state is difficult, but because managing state in a way where the app doesn't get worse as features get added is difficult. We should call it entropy management
К контексту вчерашнего обсуждения twitter.com/mpocock1/statu…
Четверг
Итак urql. Если вдруг это буквосочетание прошло мимо-вас - это мощная и эффективная альтернатива apollo client в качестве graphql клиента
Когда я первый раз узрел formidable.com/open-source/ur… то-ли на Hacker News, то ли на Dev.to мой скепсис был столь же велик, как технический долг @vue/test-utils
Однако из этого выросла мощная библиотека с уникальными фичами
Более того, если бы в абстрактном GitLab я бы сейчас принимал решение - я бы взял именно urql и в этом треде попробую пояснить почему
Я конечнео мог бы просто кинуть ссылку на formidable.com/open-source/ur… но все вот эти разговоры про "быстрее, выше, сильнее" - в пользу бедных :)
Как известно, в программирование есть две проблемы, и обе из них есть в работе с graphql в Apollo
И если с именованием переменных мы ничего не можем сделать, то пуговицу... в смысле инвалидацию кеша частично же мы решить можем?
На данный момент в Apollo есть два с половиной подхода как обновить состояние системы после мутации
Вернуть данные в мутации. Хорошо работает с изменением данных (аве, нормализация), но плохо - когда в результате меняются какие-либо списки
Указать что после мутации вот такие-то query надо рефетчить - по имени
2.5 Руками обновить нужные квери в кеше после апдейта
Проблема с этими подходами очевидна - они ужасно масштабируются с ростом системы. при добавлении новой query по сути надо пройтись и указать после каких мутаций ее надо перегружать (да, здесь я немного утрирую и не рассматриваю сценарии когда нам плевать на десинхронизацию)
Добавьте туда страннейшее решение Apollo делать это в слое отображения (да, если вы вызываете мутацию несколько раз - ответственность за консистетность ваших рефетчей на вас, правда неприятно?) - и вы получите мощнейшую головную боль, а главное - потерю управляемости
Почему так и можно ли лучше? Ответ - потому что GraphQL-схема почти не несёт семантики связей между мутациями и запросами, вот никакой магии и не происходит
Почему "почти"? Потому что со значительной вероятностью если мы изменяем объект типа Х - запросы, у которых тип Х[] и подобные ему есть среди возвращаемого значения будут затронуты
Собственно это и есть киллер-фича urql которая работает на удивление хорошо - он может быть schema-aware и сделать это магически!
Божечки-кошечки! А в urql принесли таки local resolvers! formidable.com/open-source/ur…
С таким подходом могу заявить, что мне неизвестно ни одного киллер-преимущества Apollo перед urql
При этом у urql сверхмощный механизм интеграции в любую часть работы urql - от кеширования до собственно отправки запросов (exchange), в разы мощнее link'ов apollo, которые весьма ограничены в своих возможностях
Другими словами, если у вас "на той стороне" не Apollo-server со специфичными для аполло экстеншнами, если вы не собираетесь в ближайшее время использовать @stream и @defer - посмотрите на urql. Мой инженерный опыт с ним в разы позитивнее чем с Apollo
Тред (@xanf_ua-2)
Так, сегодня у меня работун (вместо того чтобы работать днём игрался с локальными резолверами urql, теперь пора работать). Завтра буду вбрасывать про самое больное для меня - преподавание, инфоцыганство (не люблю этот термин) и тенденции за последние года
Пятница
Пока я пилю тред про обучение, чтоб он не был в стиле @fillpackart и справляюсь с очередным странным багом пока он не дошел до прода, задам простой но важный вопрос.
Как вы считаете, достаточно ли полезно для программиста высшее образование, чтобы тратить на него время?
Суббота
Ну что, поехали первый из пяти (а может и больше) тредов про образование. Тредов будет тамк много, потому что это то, где я вижу своё признание и поэтому тем, которые я хочу поднять очень и очень много
Начнём с животрепещущего вопроса про "нужно ли программисту высшее образование"? !0 лет назад я бы отвечал "однозначно не нужно", 2 года назад - "однозначно нужно", сейчас мой ответ "Скорее нужно, чем нет".
Я не хочу касаться избитых утверждений "диплом не нужен, кроме как чтобы завести трактор" - все так. Я буду говорить о знаниях, навыках и компетенциях. Фактически у вас есть условные 5 лет жизни, которые вы хотите вложить, чтобы на дистанции лет в 20 максимизировать свою прибыль
Я встречал крутых ребят в 23 года с навыками, кругозором и знаниями, которые были выпускниками ВУЗа. Я не встречал крутых ребят в 23 года без высшего образования. Прежде чем вы напишите гневный твит с контрпримером в ответ - давайте определимся с "симптомами крутости"
В рамках этого треда "крутым" я считаю человека не только с хард-скиллами уровня... ну допустим сеньйор (в конце-концов шутки про 23-летних сеньойров у нас все еще актуальны), но и с развитыми софт-скиллами коммуникации, презентации, самопрезентации и работы в команде
Я не хочу скатываться до банальных рассуждений "в 17 лет сложно обеспечить сбалансированное развитие себя", поэтому скажу по себе. Даже сейчас, имея за плечами Ph.D. и педагогическую подготовку и практику я регулярно допускаю существенные перекосы в своем развитии
Почему "перекосы" это проблема - потому что если мы говорим о развитии инженера (как справедливо подчеркивает @mr_mig_by) - то инженер должен обладать огромным количеством компетенций, которые со стороны разработчика/"кодера" кажутся не важными и несущественными
Тред (@xanf_ua-2)
Самое время потизерить следующий тред про образование - поговорим о курсах, которые помогают "войти в айти" и об огромном количестве преподавателей которые обещают 100500 килоденег в секунду :) Приходите гореть вместе через часик ;)
Итак, давайте поговорим о курсах. Сразу хочу сказать (вдруг кто-то не знает) - я заангажирован, так как сам занимаюсь ровно тем же - пытаюсь продавать знания за деньги :) Поэтому не стесняйтесь уличать меня в манипулировании в свою пользу :)
Начну с агрессивного вброса: текущую ситуацию с рынком онлайн-образования в ру-сегменте иначе как ЖОПОЙ я назвать не могу по всем фронтам: как продают, как преподают и кто преподает. Давайте разбираться почему у меня горит :)
Начнем с маркетинга и давайте посмотрим, к примеру, на @Skillbox_ru . Посмотрите на полную версию картинки из тизера. Иначе как манипуляционной я её назвать не могу - "помощь с трудоустройством" и "с трудоустройством" для меня совершанно разные вещи.
/apollo-docs-template2_dohzxt)
