Есть компании, где разработка полностью подчинена бизнесу. Каждый лишний чих должен проходить защиту перед топ-менеджерами. Платформенная команда если и существует (что для таких компаний удивительно. Как это так, целая команда высокогрейдовых специалистов не направлена напрямую на генерацию прибыли!), то испытывает постоянные проблемы с обоснованием необходимости решаемых задач. Какой такой переезд на TypeScript? Сколько он нам денег принесёт в ближайшем квартале?
Есть компании, где главенствуют технари. Они занимают кресло наверху пищевой цепочки и, зачастую, непосредственно руководят платформенными командами. Быть разработчиком в таких компаниях одно удовольствие (пока у компании есть деньги, конечно же). Любые нововведения принимаются влёт, всё в таких компаниях на острие прогресса.
Вот только как бывает в компаниях второго типа. Презентует, например, платформенная команда переезд очередной части проекта на лямбды. Ну как переезд, просто упаковка кода из монолита в большой бандл и подвешивание кучи его копий слушать входящие запросы, каждой копии свой. Такой жирненький ёжик покрытый иголками хэндлеров. Точнее, армия ёжиков-клонов. Цель понятная — решение стратегической задачи переезда на лямбды. Зачем? Чтобы было. Лямбды лучше node.js-монолитов. Очевидно же?
Нет, не очевидно. Node.js монолит не имеет вендор-локов. Скейлинг его достаточно прост. Метрики понятные. Проблем холодного старта и бандлинга не существует. Node.js можно использовать любой, хоть вчерашнюю бету, если оно нужно. Кеши — да пожалуйста, кешируй в память, жить будет сколько тебе нужно. Вебсокеты работают без бубнов. И так далее.
Так чего же я хочу? Я хочу видеть обоснование и метрики. Немного здоровой бюрократии. Обоснования в миллисекундах. гигабайтах и долларах — какое решение лучше. Всё то, что нужно сделать в компании первого типа (см. первый абзац), чтобы разработка получила зелёный свет. Но работать хочу в компаниях второго типа 🙂
Есть компании, где главенствуют технари. Они занимают кресло наверху пищевой цепочки и, зачастую, непосредственно руководят платформенными командами. Быть разработчиком в таких компаниях одно удовольствие (пока у компании есть деньги, конечно же). Любые нововведения принимаются влёт, всё в таких компаниях на острие прогресса.
Вот только как бывает в компаниях второго типа. Презентует, например, платформенная команда переезд очередной части проекта на лямбды. Ну как переезд, просто упаковка кода из монолита в большой бандл и подвешивание кучи его копий слушать входящие запросы, каждой копии свой. Такой жирненький ёжик покрытый иголками хэндлеров. Точнее, армия ёжиков-клонов. Цель понятная — решение стратегической задачи переезда на лямбды. Зачем? Чтобы было. Лямбды лучше node.js-монолитов. Очевидно же?
Нет, не очевидно. Node.js монолит не имеет вендор-локов. Скейлинг его достаточно прост. Метрики понятные. Проблем холодного старта и бандлинга не существует. Node.js можно использовать любой, хоть вчерашнюю бету, если оно нужно. Кеши — да пожалуйста, кешируй в память, жить будет сколько тебе нужно. Вебсокеты работают без бубнов. И так далее.
Так чего же я хочу? Я хочу видеть обоснование и метрики. Немного здоровой бюрократии. Обоснования в миллисекундах. гигабайтах и долларах — какое решение лучше. Всё то, что нужно сделать в компании первого типа (см. первый абзац), чтобы разработка получила зелёный свет. Но работать хочу в компаниях второго типа 🙂
👍21
Ночью наткнулся на судно сейсморазведки и нахлынули воспоминания, как катался с геофизическими приборами, ноутбуком и паяльником от Сибири до Казахстана, сутками живя будках каротажных подъёмников. Как чинил под снегом оборудование, пытаясь на осциллографе поймать сигнал и переписывая код приёмного софта на ходу, чтобы обойти проблему.
И эта нищая, но интересная жизнь научила многому, и прежде всего, решать задачи теми ресурсами, что у нас есть. Не хватает питания, памяти, скорости передачи, некуда отводить температуру от чипа — всё решается, нужно только сесть, успокоиться и подумать, чем мы будем жертвовать.
Пусть навесным монтажом и кувалдой, но решается любая техническая проблема. Как говорят в США — все можно поправить, если есть WD40 и армированный скотч.
Плох и ненужен тот программист, который на задачу бизнеса отвечает — «это невозможно». Стив Джобс вот хорошо это понимал.
И эта нищая, но интересная жизнь научила многому, и прежде всего, решать задачи теми ресурсами, что у нас есть. Не хватает питания, памяти, скорости передачи, некуда отводить температуру от чипа — всё решается, нужно только сесть, успокоиться и подумать, чем мы будем жертвовать.
Пусть навесным монтажом и кувалдой, но решается любая техническая проблема. Как говорят в США — все можно поправить, если есть WD40 и армированный скотч.
Плох и ненужен тот программист, который на задачу бизнеса отвечает — «это невозможно». Стив Джобс вот хорошо это понимал.
❤20
Порылся в архиве, чтобы вы ощутили условия работы. После этого вообще ничего не страшно :)
🔥29
На rozetked вышел обзор Huawei MateView 28.2”. Сам сижу полгода на таком, жутко доволен и всем рекомендую. Соотношение сторон 3:2 просто идеально для работы в IDE. Цветопередача сравнима с макбуком. Дизайн — словно Джонни Айв лично подсказывал. Цена максимально приемлимая. А будете уезжать из страны — можете взять с собой, он лёгкий.
❤15👍1
Классическая проблема канбан-досок в разработке (upd речь о scrum и его доске спринта)— необходимость передать задачу в QA. Вот взял разработчик задачку в первом столбце бэклога, перевёл в столбец разработки, пожёг стори-поинты, а передвинуть в релиз не может. Задача уходит в столбец “Ready for QA” и висит там в очереди, иногда днями. Велосити страдает, сторипоинты не сгорают, не происходит вообще ничего. Дальше QA вынимает задачу из очереди, переводит на себя, тестирует неизвестно сколько (никто же не закладывает сторипоинты на тестирование), по итогам либо возвращает в разработку либо переводит в “Ready to merge” что и даёт возможность запустить автоматику релиза.
И как из этого всего делать аналитику? Вся красота системы ломается об бутылочное горлышко QA, да и в принципе система не работает, если движение задачи зависит больше, чем от одного человека. А ещё и веточки с задачами висят больше одного дня и никак не могут попасть в main, что прямо совсем несовременно и плохо.
И никто в целом мире не придумал, как эту проблему решить и заставить чудесный Agile Sprint работать, вот так вот, чтобы сколько напланировали — столько и сделали, и бёрндаун такой под 45 градусов вниз летел как паровоз, от спринта к спринту всё быстрей и мощней.
Единственное решение, которое мне кажется более-менее жизнеспособным — это убирать из процесса доставки задачи до релиза QA целиком и заменять его автоматикой. Разработчик пусть сам пишет автотесты для своей задачи по предоставленным QA сценариям, а QA достаточно валидировать их качество и заниматься общим набором E2E, гоняемым предрелизной автоматикой. Вот только в этом случае появится какая-то предсказуемость в оценке срока доставки задач.
Если же вам такая схема не нравится, то примите тот факт, что в любом другом случае канбан-достка отражает только текущее состояние задач и гадать о будущем по ней нельзя. А фича-ветки так и будут висеть днями.
И как из этого всего делать аналитику? Вся красота системы ломается об бутылочное горлышко QA, да и в принципе система не работает, если движение задачи зависит больше, чем от одного человека. А ещё и веточки с задачами висят больше одного дня и никак не могут попасть в main, что прямо совсем несовременно и плохо.
И никто в целом мире не придумал, как эту проблему решить и заставить чудесный Agile Sprint работать, вот так вот, чтобы сколько напланировали — столько и сделали, и бёрндаун такой под 45 градусов вниз летел как паровоз, от спринта к спринту всё быстрей и мощней.
Единственное решение, которое мне кажется более-менее жизнеспособным — это убирать из процесса доставки задачи до релиза QA целиком и заменять его автоматикой. Разработчик пусть сам пишет автотесты для своей задачи по предоставленным QA сценариям, а QA достаточно валидировать их качество и заниматься общим набором E2E, гоняемым предрелизной автоматикой. Вот только в этом случае появится какая-то предсказуемость в оценке срока доставки задач.
Если же вам такая схема не нравится, то примите тот факт, что в любом другом случае канбан-достка отражает только текущее состояние задач и гадать о будущем по ней нельзя. А фича-ветки так и будут висеть днями.
👍11
Так, возник вопрос говорю ли я о скраме или о канбане. Конечно же, я имел ввиду Скрам, который так же использует в своих целях канбан-доски. Вот даже Atalssian про это пишет
И весь мой наброс именно на доски в рамках одного Scrum-спринта — что смена владельца задачи с разработчика на QA ломает систему.
И весь мой наброс именно на доски в рамках одного Scrum-спринта — что смена владельца задачи с разработчика на QA ломает систему.
Forwarded from Веб-стандарты (Vadim Makeev)
Выпуск №323: Алексей Симоненко, Вадим Макеев, Андрей Мелихов про возвращение и смысл, Media Queries и Container Queries, релиз-ноуты V8, бету Safari 16, Telegram и веб, мир без паролей и IE, который снова всё.
Слушайте на Ютубе https://youtu.be/yc55iTIcVCc
Ссылки на сайте https://web-standards.ru/podcast/323/
Слушайте на Ютубе https://youtu.be/yc55iTIcVCc
Ссылки на сайте https://web-standards.ru/podcast/323/
🥰7
323. Возвращение и смысл, MQ и CQ, V8, бета Safari 16, Telegram…
Веб-стандарты
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 снова всё
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 снова всё
🔥9
Мы немножко воскресли, потому-что потому, там в начале выпуска всё сказано.
❤15
Утром выдвигаюсь на Holy.js. Посмотрим, кто тут ещё остался, кажется получается такой небольшой междусобойчик. К осени ещё меньше останется, кажется.
Есть план на лайтнингах утопить Nest.js
Есть план на лайтнингах утопить Nest.js
🔥12👍1