На rozetked вышел обзор Huawei MateView 28.2”. Сам сижу полгода на таком, жутко доволен и всем рекомендую. Соотношение сторон 3:2 просто идеально для работы в IDE. Цветопередача сравнима с макбуком. Дизайн — словно Джонни Айв лично подсказывал. Цена максимально приемлимая. А будете уезжать из страны — можете взять с собой, он лёгкий.

Классическая проблема канбан-досок в разработке (upd речь о scrum и его доске спринта)— необходимость передать задачу в QA. Вот взял разработчик задачку в первом столбце бэклога, перевёл в столбец разработки, пожёг стори-поинты, а передвинуть в релиз не может. Задача уходит в столбец “Ready for QA” и висит там в очереди, иногда днями. Велосити страдает, сторипоинты не сгорают, не происходит вообще ничего. Дальше QA вынимает задачу из очереди, переводит на себя, тестирует неизвестно сколько (никто же не закладывает сторипоинты на тестирование), по итогам либо возвращает в разработку либо переводит в “Ready to merge” что и даёт возможность запустить автоматику релиза.

И как из этого всего делать аналитику? Вся красота системы ломается об бутылочное горлышко QA, да и в принципе система не работает, если движение задачи зависит больше, чем от одного человека. А ещё и веточки с задачами висят больше одного дня и никак не могут попасть в main, что прямо совсем несовременно и плохо.

И никто в целом мире не придумал, как эту проблему решить и заставить чудесный Agile Sprint работать, вот так вот, чтобы сколько напланировали — столько и сделали, и бёрндаун такой под 45 градусов вниз летел как паровоз, от спринта к спринту всё быстрей и мощней.

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

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

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

И весь мой наброс именно на доски в рамках одного Scrum-спринта — что смена владельца задачи с разработчика на QA ломает систему.

Пятничной боли вам. На рабочем монолите с TS сломался WebStorm. Зависает на “Analayzing…” и дальше по цепочке ломаются все остальные открытые проекты. Помогает только сброс кешей и перезапуск. Печаль печальная, EAP тоже не спасает. И ладно бы только у меня — страдают все!

Выпуск №323: Алексей Симоненко, Вадим Макеев, Андрей Мелихов про возвращение и смысл, Media Queries и Container Queries, релиз-ноуты V8, бету Safari 16, Telegram и веб, мир без паролей и IE, который снова всё.

Слушайте на Ютубе https://youtu.be/yc55iTIcVCc
Ссылки на сайте https://web-standards.ru/podcast/323/

00:05:00 Понятные Media Queries
00:10:17 Релиз-ноуты V8 всё
00:14:37 Бета Safari 16
00:26:29 Container Queries
00:36:18 Telegram защитник веба
00:46:53 Мир без паролей
00:58:08 Что попросить у Safari
01:03:27 IE снова всё

Мы немножко воскресли, потому-что потому, там в начале выпуска всё сказано.

Прилетела бета нового 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»