Вставай, Андрей, мы там прод уронили. Вообще весь

Не выдержал сычевать-горевать, взял билеты на Dump. Попробую поискать новую жизненную цель, да и в целом оценить, как ощущают себя другие разрабы, что думают. Так что 27 мая в Екатеринбурге. Может голова хоть болеть перестанет на пару дней.

Потрясающая штука шагает (именно шагает, посмотрите на x2) за окном —сваевдавливающая установка. Почти бесшумно загоняет сваи в грунт, никакой долбёжки, никаких вибро-нагрузок на соседние дома.
В бытность мою разработчиком геофизического оборудования мы использовали полную противоположность этой машине — самоходные вибраторы, которые долбили бетонной плитой землю со страшной силой. Но только там, где нельзя было просто взорвать тротиловую шашку в скважине.

Можно долго спорить, что лучше — веб или нативка. Сам я безумно люблю хорошие нативные приложения на iOS и macOS (и с удивлением смотрю на качество приложений в экосистеме Android). Одновременно испытываю боль от невозможности релизить нативку каждый день и гарантировать наличие свежей версии у всех клиентов. Но вот есть одно важное «но», которое не затронул Артём и которое является сейчас основополагающим при обосновании необходимости иметь максимально полноценную веб-версию (привет тебе, Сбер, «забывший» про СБП на вебе). И это «но» прекрасно ощутили на себе российские санкционные банки и их дочки (а ещё раньше ощутила оппозиция) — веб является сейчас единственной независимой платформой, ограничить которую возможно только на сетевом уровне.
Так что, при всей своей безумной любви к идеальным нативным приложениям, выверенным до дюйма по гайдлайнам платформы — я двумя руками голосую за развитие веба.

Не прошло и года от релиза LTS node.js 16 как она стала доступна в AWS-лямбдах. Трижды вот подумаешь — а оправдан ли этот вендор-лок ради обманчивой простоты лямбд?

Предварительно в августе вернусь к докладам (если конечно мир не станет ещё хуже). План хорошенько поругать AWS Lambda. Да и в общем-то любые лямбды. Не совершайте ошибку, лучше Express/Fastify пока ничего нам для node.js не сделали.

Обожаю когда с очередным обновлением какой-нибудь библиотеки прилетает unknown там, где был any. Прямо вскрытый нарыв. И больно и сказать нечего против правды.

Позвали выступить в Ленинке с лекцией (под запись) для библиотекарей всей страны. Рассказать, что такое IT и какие книги и сайты читателям советовать, которые решили в то самое IT погрузиться. Сказать, что я польщён — ничего не сказать.
Все не зря!

Помни про архитектурные границы и не допускай протечек абстракций

Полный зал в бэкенде. Спикер из Марсиан «Кто ещё на Руби пишет?» В зале 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.

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