Полный зал в бэкенде. Спикер из Марсиан «Кто ещё на Руби пишет?» В зале 0 рук. «Да ладно :( )»

.net разработчик убеждал меня, что handler лучше сервиса, потому что handler всегда принимает на вход объект, а добавление параметра в публичный сервис это боль, ломается сигнатура по всей кодовой базе. Что же, очень жаль ребят, что им приходится создавать класс для объекта входящих параметров 😄 (Сравниваем с нашим, джаваскриптовым копеечным созданием объекта через литерал)
С другой стороны они могут делать (и делают) честный DI на абстракциях, так что туше.

Тут Артём развивает мысль, что оптимизации зачастую это попытка лечить последствия, а не причины. Если бы писали нормально, то никакие супер-пупер кэши и не понадобились бы (а как мы помним, кэши это вторая главная проблема программирования).

А вот вам интересный факт — декларативное программирование позволяет отдать оптимизации на откуп интерпретатору/компилятору в наилучшем виде. Что сейчас пытается сделать условный V8? Он пытается понять, что за ерунду вы написали в императивном коде, вычленить эвристикой знакомые паттерны и применить встроенные оптимизации. Отсюда возникают советы «не пытайтесь писать оптимально, пытайтесь писать понятно для интерпретатора. Используйте самые свежие инструкции ECMAScript потому что они упрощают чтение кода движком. Не основывайте код на знаниях внутренней работы движка — завтра она может изменится и все оптимизации рухнут» И так далее. В декларативном же программировании мы вообще не говорим КАК выполнить нашу задачу, мы говорим ЧТО мы хотим сделать. И дальше движок сам решает, как он будет оптимизировать этот наш запрос. Никакие эвристики, чтобы понять что мы хотели тут сделать уже не нужны — движок изначально знает, что это за инструкции и как с ними поступить.

И вот потому декларативные CSS и HTML выполняются браузером молниеносно, а от императивного динамического рендера реакта да с «классическим» css-in-js меняющим параметры в лоб ноут орёт кулером и жрёт батарею как не в себя. Потому что в декларативном программировании, мы говорим «Эй браузер, поменяй у всех неактивных кнопок цвет на серый». И браузер прекрасно знает как это сделать без квадратичной сложности.

Полностью и безоговорочно согласен.

А вот что пишет Клеппман

«Декларативные языки запросов весьма привлекательны … но что важнее, они скрывают подробности реализации ядра базы данных, благодаря чему у СУБД появляется возможность повышать производительность без необходимости вносить изменения в запросы.

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

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

Наконец, декларативные языки часто хорошо подходят для параллельного выполнения. Сегодня ускорение CPU происходит за счет добавления дополнительных ядер, а не повышения тактовой частоты. Распараллелить императивный код по нескольким ядрам и нескольким машинам очень непросто, поскольку в нем задается определенный порядок выполнения команд. Шансы декларативных языков на ускорение за счет параллельного выполнения выше, поскольку они задают лишь шаблон результатов, а не используемый для их получения алгоритм. База данных при желании может задействовать параллельную реализацию языка запросов »

Терпел полтора месяца, но нет, лучше носить в кармане банковскую карточку, чем страдать с Android. (А можно карту положить в китайский MagSafe кошелёк, прилепить магнитом к спинке и платить «как раньше»).

Плюсы Pixel 5A
- Цена
- Мир Pay
- Классный корпус (никакого стекла сзади)
- Батарейка моё почтение
- type-c
- Можно ставить что хочешь откуда хочешь

Минусы 5a (и Android)
- Слишком большой
- Нет Qi
- Ложные срабатывания при касании граней экрана просто выбешивают после iPhone
- Жесты работают через раз
- Мир Pay работает через раз
- Интерфейс лагает, откровенно глючит и зависает
- В Chrome нельзя устанавливать расширения, с адблокерами всё сложно (нужно пускать трафик через прокси)
- Ломаный YouTube Vanced хуже по функциональности ломанного YouTube++ для iPhone :)

Одна из самых явных вещей, на которые я триггерюсь в PR это as. Обычно (я сейчас говорю о бэкенде) оказывается примерно такая ситуация — функция возвращает широкий тип (какой-нибудь union), но разработчик гарантирует, что вот в этом конкретном случае вернётся только нужный и потому кастует к нему, сужая тип.
Не надо так. Сегодня ты гарантируешь, а завтра меняются входные условия и вот она потенциальная проблема в ближайшем будущем. Не нужно мешать статическому анализатору делать его работу. Если функция говорит, что возвращает широкий тип, то мы обязательно должны это учитывать (либо сделать другую функцию, SIP тоже вещь полезная).
Потому только тайпгарды, или проверки через `in`с корректным обработчиком негативного сценария. И никаких as.

Лето, санкции, мир (да не тот)

Тем временем у Lerna вышла версия 5.0.0. Практически никаких изменений, отстрелили поддержку древней ноды, обновили зависимости. Что мертво — умереть не может.
UPD
Роадмап на 2022

Есть компании, где разработка полностью подчинена бизнесу. Каждый лишний чих должен проходить защиту перед топ-менеджерами. Платформенная команда если и существует (что для таких компаний удивительно. Как это так, целая команда высокогрейдовых специалистов не направлена напрямую на генерацию прибыли!), то испытывает постоянные проблемы с обоснованием необходимости решаемых задач. Какой такой переезд на TypeScript? Сколько он нам денег принесёт в ближайшем квартале?

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

Вот только как бывает в компаниях второго типа. Презентует, например, платформенная команда переезд очередной части проекта на лямбды. Ну как переезд, просто упаковка кода из монолита в большой бандл и подвешивание кучи его копий слушать входящие запросы, каждой копии свой. Такой жирненький ёжик покрытый иголками хэндлеров. Точнее, армия ёжиков-клонов. Цель понятная — решение стратегической задачи переезда на лямбды. Зачем? Чтобы было. Лямбды лучше node.js-монолитов. Очевидно же?

Нет, не очевидно. Node.js монолит не имеет вендор-локов. Скейлинг его достаточно прост. Метрики понятные. Проблем холодного старта и бандлинга не существует. Node.js можно использовать любой, хоть вчерашнюю бету, если оно нужно. Кеши — да пожалуйста, кешируй в память, жить будет сколько тебе нужно. Вебсокеты работают без бубнов. И так далее.

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

Ночью наткнулся на судно сейсморазведки и нахлынули воспоминания, как катался с геофизическими приборами, ноутбуком и паяльником от Сибири до Казахстана, сутками живя будках каротажных подъёмников. Как чинил под снегом оборудование, пытаясь на осциллографе поймать сигнал и переписывая код приёмного софта на ходу, чтобы обойти проблему.

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

Пусть навесным монтажом и кувалдой, но решается любая техническая проблема. Как говорят в США — все можно поправить, если есть WD40 и армированный скотч.

Плох и ненужен тот программист, который на задачу бизнеса отвечает — «это невозможно». Стив Джобс вот хорошо это понимал.

На 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, гоняемым предрелизной автоматикой. Вот только в этом случае появится какая-то предсказуемость в оценке срока доставки задач.

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