Прилетела бета нового UI для WebStorm — ну красиво же!

И тут же письмо от GitHub — мол бета Copilot заканчивается, несите ваши денежки

Утром выдвигаюсь на Holy.js. Посмотрим, кто тут ещё остался, кажется получается такой небольшой междусобойчик. К осени ещё меньше останется, кажется.

Есть план на лайтнингах утопить Nest.js

Трём за будущее

Самые добрые ведущие для самых непростых времён

Чинил сегодня багу на проде, которая прошла через казалось бы имеющуюся типизацию и юнит-тесты как горячий нож сквозь масло. E2E бы спасли, но их там не было. А разгадка одна — безблагодатность.
А дело было в том, что входящий DTO превращался в исходящий не путём честного маппинга, а путём выкидывания ненужного через деструктуризацию и приведение …rest остатка через as в тип выходного DTO. Ну и появление новых полей во входящей DTO строгий валидатор на бэке уже не переварил.

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

В канале Максима Соснова увидел ссылку на статью — размышления одного из разработчиков из инфраструктурной команды DigitalOcean о принципах и подходах, применяемых при разработке ui-кита. И в ней автор тоже пинает spread-оператор за неявность. А именно, JSX-конструкцию {…props}
—
Отказ от использования в JSX spread для внешних данных спасает от появления странных багов.

Т.е. я избегают использования любых spread-операторов при обработке внешних данных. Да, я не хочу иметь возможность прокидывать вслепую пропсы из одного компонента в другой (если быть честным, мне кажется что это отличное общее правило при работе с пропсами)
1. Может быть непонятно, откуда неожиданно прилетело значение конкретного атрибута (пропа). И поиск тут не поможет.
2. Это позволяет переслать неожиданные атрибуты и TypeScript тут ничего не поймает

Рекомендация — делать деструктуризацию и честно пересылать атрибуты, выкидывая заодно мусор.

Примеры в статье, ищите по фразе «Avoiding JSX spread»

Важная вещь в планировании работы платформенной команды — её циклы разработки не должны совпадать с циклами бизнесовых команд. Если вы живёте двухнедельными спринтами, то пусть спринт платформенной команды идёт со сдвигом в неделю. Если кварталами, то сдвиньте хотя бы на месяц. Понимаю, сложно, особенно если на это завязаны защиты DoD (Definition of Done) и OKR (Objectives and Key Results) у топов и прочие премии. Но необходимо.

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

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

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

Ну и какой язык у нас более объектно-ориентированный — тот, где объект можно создать литералом, забрать деструктуризаций и накинуть дефолтные параметры (решение в одну строчку) или тот, где для решения этой базовой задачи целый паттерн придумали, который без код комплишена руки устанут набирать? Синк эбаут ит

Для раскрашивания кода на слайдах пользуюсь консольной утилитой highlight. Классно, здорово, но иногда её нет под рукой. Ну и не хватает наглядности. А тут Семён Левенсон подсказал SlidesCodeHighlighter . Неплохо, неплохо.

Пользуйтесь и не вставляйте на слайды скриншоты из IDE. И портянки кода не вставляйте, никто в зале их читать не будет. Мой выбор — verdana 36pt отступ 1.5. Не только видно с последнего ряда, но и не даёт засунуть в слайд слишком много кода.

Глеб Михеев в докладе про contract first упомянул, что этот подход позволяет одновременно стартовать работу фронта и бэка, на что получил резонный комментарий из зала, что важней не начать, а закончить вместе. А чтобы закончить вместе, нужно:
а) точнее прогнозировать
б) устранить узкие места

Как уже ранее писал, одним из наиболее узких мест является тестирование, которое, как правило, начинается когда все компоненты системы готовы. И вот тут нам на помощь приходит статегия тестирования Shift-left. Идея простая — мы должны начасть тестировать как можно раньше. В идеально мире даже раньше разработки. Как это так? Ну так же как мы делаем TDD — разработка ещё не началась, а тесты написаны.

Так-то и TDD, и BDD, и линтеры, и статический анализ, и contract-first и автотесты — всё это вписывается в стратегию shift-left. Мы должны отловить максимум возможных проблем до того как код будет финализирован перед релизом.

Какая роль здесь у QA? Заняться тем же BDD. Подключиться на самом раннем этапе к обсуждению с бизнесом, выяснить для чего делаются эти изменения, понять, что они могут затронуть, описать все тестовые сценарии, передать эти знания разработчикам и начать писать автотесты (ну совсем идеальный случай). На стендапах внимательно слушать, что делают разработчики и как продвигается работа, какие в ней есть проблемы, задавать вопросы и просить заранее закрыть проблемные сценарии (список-то уже в задаче).

Пока цены упали, обновил домашнюю машинку с M1 13” на MBP14 M1 Pro 10c 16gb 1Tb (вот такой вот набор цифр и букв). Бомба, конечно. Размер классный, экран запредельный, портов раздолье. Очень хотел 32gb, но их не днём с огнём не отыщешь, а те, что есть, стоят страшно. Благо и на этом летает всё, что нужно.

А зачем обновлял — ну, прежде всего, 2 type-c мне мало. 3 вот прямо на пределе, но уже можно жить. 14 дюймов, опять же, больше, чем 13”, но ещё не такой гроб, как 16”.

Есть у нас один важный эндпоинт, общий для фронт-бэк и для сервер-сервер взаимодействия. Вот только принимает он форму с файлами. Ну вы понимаете, да? Multipart/form-data и, что хуже, никаких контрактов. А уж как приятно тесты на это писать с парсилками текстовых строк в моках.
Разделяйте интерфейсы, господа и дамы, зря вам дядя Боб про ISP рассказывает что ли. Пойду фасады напилю что ли.

«Я не могу тратить много времени на ревью, потому что у меня есть своя работа, вообще-то».

Очень распространённое, очень популярное и в корне, как мне кажется, неверное мнение. Ревью чужого кода это точно такая же часть работы, как и написание собственного. Золотое правило Гитлаба, которым стоит руководствоваться (сам не проверял, но точно слышал от Ильи Климова, что оно существует) — сначала разблокируй других, потом занимайся своими делами.

Стараюсь раза три в день минимум заглядывать в колокольчик гитхаба и очищать инбокс. А лучше, конечно, почаще. Большой минус, что не выходит работать в режиме «сегодня встреч нет, днём погуляю, а вечером всё сделаю». Свою задачу сделаю, а чужие заблокирую. И QA не помогу. И команде на вопросы не отвечу.

Тимлидам совет — при оценке эффективности специалиста не забывайте проверять, насколько человек обращает внимание на что-то, кроме своих непосредственных задач.

На днях читал лекцию для библиотекарей про IT и айтишников. Кто мы такие, с чем нас едят и как нам помочь, когда мы ещё маленькие, но глаза уже горят. Пока готовился — нашёл уникальный артефакт из прошлого, выпуск журнала «Семья и школа» за 1989 год, который познакомил менял с понятием алгоритма.
Делюсь. Собственно, алгоритмические задачи для детей — https://disk.yandex.ru/i/nRbiqN_eBvTcHA

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

В далёком уже 2018 году я читал доклад «Как я полюбил и возненавидел React Native». TL;DR RN даёт потрясающие возможности делать вообще всё силами одной кроссфункциональной команды JS-разработчиков, но, к сожалению, печально сырой. Сырой настолько, что сложно было тогда думать о каком-то продакшене.

Иначе говоря, я влюбился в идею, но был опечален реализацией. Тут я слышу голос Глеба Михеева «да зачем это всё, заворачивайте сайты в webview». Да, можно, но я продолжаю фанатеть от хороших нативных интерфейсов в iOS. Понятное дело, в Android можно любую шляпу отгружать (я почти не шучу), но iOS мы любим за плавность и выверенность. И RN (в отличие от HTML-based и canvas-based) позволяет делать 100% нативные интерфейсы.

В любом случае, выбор в Деньгах тогда был сделан в пользу отдельной команды мобильных разработчиков и мобильных QA. Которые худо бедно, но разгребают огромную очередь задач и пытаются успеть за вебом. А веб пилится и релизится с дикой скоростью. Схема плохая, но рабочая.

И вот на дворе 2021, я наконец-то попадаю в команду, где есть выделенные iOS и Android разработчики. Все фичи пилятся параллельно под 3 фронта, всё здорово. Но в какой-то момент мы теряем iOS-разработчика. Через пару месяцев находим нового и он начинает срочно догонять по фичам. А ещё через пару месяцев нам говорят, что все мобильщики уезжают в отдельную команду, которая будет пытаться разгребать огромную очередь задач и догонять веб. Потому что мобильщиков мало и они дорогие.

Да ёшкин крот.