В каждом утюге новости то про то, что если не используешь ИИ, то тебя уволят, что ИИ решит все проблемы, но при этом лишит всех работы (кроме CEO, конечно). Ну и если ты не используешь ИИ, то ты лох (no FOMO).

При этом только 5% ИИ-проектов приносят какую-то прибыль. А если посмотреть с точки зрения экономики всего этого безобразия, то все еще грустнее: да, цена старых моделей становится ниже, но они никому особо и не нужны, потому что требования растут; подписки на ИИ убыточны для всех компаний, но повысить цены тоже не могут — все убегут к конкурентам; что они будут делать в будущем — неясно. Большинство бизнесов с ИИ нежизнеспособны: дохрена компаний — это просто обертки к LLM, которые можно завтра скопировать; даже у ChatGPT конверсия около 2%; многие стартапы даже не имеют какой-то бизнес модели. Многие сравнивают ситуацию с пузырем доткомов, и что-то в этом есть: сейчас, как и тогда, разрыв между суммарной стоимостью акции и стоимостью активов превышает 400%.

Разумеется, какая-то польза от LLM есть (знаете, я и сам своего рода генератор текстов). И знакомиться с новыми инструментами нужно: оценить, чем они отличаются от старых, понять границы применения, эффективность и т.п. Но намеренно заставлять всех пользоваться микроскопом, что бы не только забивать гвозди, но и блины печь — это просто тупо. Хороший работник — не тот, который использует все самое новое, а кто знает какие инструменты когда использовать (и как). Если бизнес можно навайбкодить, то и цена у него невелика.

Строить весь бизнес вокруг того, что у вас есть какой-то инструмент — сомнительная затея, и напоминает историю с блокчейном (однако у ИИ хотя бы больше возможностей). Хотя если цель — нагреть инвесторов, то ладно. Пользователям/бизнесам нужно решение их проблем и так-то им насрать, как они будут решены, хоть толпой индусов на удаленке, лишь бы это стоило того.

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

Современный CSS должен убить SPA с его джаваскиптами, провозглашает статья. Вау, круто, я тоже такого мнения, думаю я. Звучит очень интересно, молочные берега, кисельные реки, CSS может почти все! Просто добавь красивые переходы между страницами десятком строчек и у пользователя не будет ощущения, что он загружает новую страницу! Демки еще прикольные — прогресс же!

Пробую добавить на сайтик — не работает. Выясняется, что в Firefox поддержка не реализована. Пробуем в Chrome — все равно дергается при переходе на другую страницу. Может, дело в полосе прокрутки? В зависимости от ее наличия меню выравнивается по-разному. Лепим scrollbar-gutter — все равно все дергается. Отключаю полоску сверху — дергается, но поменьше.

Ладно, гулять так гулять — может, спекулятивную загрузку еще сделать, как в статье предлагалось? Добавляем в заголовок скрипт (фу, я же хотел меньше JS) и… ничего не поменялось. Ок, лезем в инструменты разработчика — “130 not triggered”. Спрашиваем GPT, получаем порцию газлайтинга, но в итоге после “глубокого анализа” получаем предложение в настройках хрома включить расширенную загрузку — ура, теперь инструменты разработчика светятся зелененьким, что страницы предзагружаются!

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

Хороший разбор про недавнюю историю с Bitnami. Кто не в курсе, они предоставляли довольно качественные VM-образы и докер-контейнеры для популярного ПО, и если у вас есть кубер, то с большой вероятностью, что-то от них используется (например, какой-нибудь helm-chart).

К ним пришел терминальный капитализм в лице Broadcom, который купил VMware, владеющую ими, в ноябре 2023. Broadcom — те самые ребята, которые пойдут на все ради 500% прибыли. И все, чего касается их рука, рано или поздно лишается бесплатного варианта. Эффект сравним с leftpad, только тут все осознанно — чтобы все пользователи платили большие бабки, потому что альтернатива (писать свое) еще дороже.

Джавистам стоит немного напрячься от этой новости, потому что Spring’ом сейчас владеет тот же Broadcom, и, судя по тому, как развиваются события, скоро он может перестать быть бесплатным. Да, можно форкнуть, но на поддержку и развитие что Bitnami, что Spring нужно будет много ресурсов.

Неплохой доклад про подход к внедрению изменений в компании.

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

Забавный термин, на который случайно наткнулся в вики Haskell (я туда попал по запросу “cons in Haskell”, который оператор для вставки в начало). Сама статья — про недостатки синтаксического сахара и опасность его чрезмерного использования: нужно помнить много конструкций; иногда не знаешь, во что транслируется выражение с сахаром; хуже ошибки компилятора; тяжело переписывать код, когда он не укладывается в “сахарный” сценарий; сложнее писать инструменты типа линтеров; разработчики “подсаживаются” на сахар, и просят добавить еще.

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

На мой взгляд, основная проблема некоторый языков в этом плане — консистентность и единообразность. В Scala 2 коде, написанном в Haskell-стиле, сахар превращается в то, что тебе нужно помнить отличия всяких +:+, ++: и прочих (_*_). Кроме того, не хватает единого стиля, в Scala 3 с этим стало в целом получше. А вот в Kotlin проблема с сахаром в том, что тебе нужно выбрать тот самый вспомогательный метод из миллиона других, который подходит именно под этот конкретный случай. “Практично”, но иногда безсистемно. В идеале должен быть хороший, но минимальный “фундамент” языка с хорошими возможностями для расширения.

А вообще стоит почитать оригинальную статью от 2005 года, где синтаксическим героином называют… перегрузку функций.

Узнал недавно о CSS свойстве hyphens, которое управляет переносами слов, и немного с ним поэкспериментировал на сайтике. Видимо, из-за того, что отвык от печатного книжного текста, переносы слов выглядели очень непривычно, даже немного отталкивающе. Не помню такого, когда, например, вычитывал свой диссер (там переносы есть и довольно много). Да даже по ссылке с документацией разметка с выравниванием по левому краю, а правый край — “рваный”, и уже не обращаешь на это внимания.

При этом выравнивание по ширине (text-align: justify;) таких чувств не вызывает и вроде смотрится прилично.

Я попробовал два инструмента для сабжа — esbuild и rollup.

esbuild типа быстрый, написан на Go и автономный, не нужен npm, чтобы его поставить. Еще импонирует, что проблемные импорты, ведущие в никуда, он рапортует и требует явно обозначить. Однако в итоге в итоге его побороть не получилось.

Итоговый JS-модуль для поиска, сгенерированный Koka, увы, был не очень высокого качества из-за того, как я понял, что у таргета нет четкого разделения между фронтом и бэком с нодой. Я пробовал пометить нодовские модули (os, fs) как внешние, пометить импорты Koka как внешние, выбрать platform=node и даже руками удалить “неправильные” импорты, но ничего не помогло: undefined в итоговом скрипте.

Rollup сработал с первого раза, и размер бандла получился меньше. Однако он менее строг, и что было ошибкой у esbuild, у него было просто предупреждением. И автономного варианта нет — только npm install (впрочем, распространенная проблема для JS экосистемы).

Окей, сделать релиз на GitHub оказалось проще, чем ожидалось.

Главное — выбрать правильно action :) Официальное — в архиве, одно из 4 рекомендованных — тоже, еще 2 имеют странные настройки по умолчанию, и методом исключение было выбрано softprops/action-gh-release.

И настраивать особо не понадобилось — самому действию нужен только список файлов для загрузки, а для workflow достаточно настроить права на запись и триггер на обновление тэгов.

Когда добавил на сайт поиск, скорость сборки, которая была подвергнута сумасшедшей оптимизации год назад, и занимала около 30 секунд (из них 6 секунд сама сборка сайта), просела до катастрофических 2,5 минут — из-за того, что теперь надо качать еще один репозиторий для поиска, собирать его и индексировать данные.

Решение — довольно очевидное: закэшировать все что можно! Для многих популярных языков/билд систем и т.п. уже скорее всего есть какие-то действия, где все подумали за вас. Например, у меня в сборке уже был ruby/setup-ruby, который использовал кэш.

Однако, если ваш стек технологий не очень зрелый и/или в нем есть экзотические шаги, то можно сделать все самому с помощью actions/cache. По сути, вас должны волновать две вещи: какую папку кэшируем и что будет ключом в кэше.

Однако есть и нюанс. Не получится закэшировать системные папки из-за проблемы с правами. Поэтому всякие установленные инструменты надо будет класть в “рабочую папку”. При этом для менеджера пакетов APT есть действие, которое помогает обойти это ограничение.

Разумеется, если у вас очень стабильное окружение для сборки, можно и докер-образ собрать. Но это уже более продвинутый уровень. Аналогично можно поиграться и с GitHub Releases.

Ну и ключи для кэша надо подбирать, хотя бы немного подумав.

В итоге у меня получилось вот такой workflow, который при горячих кэшах собирает сайт за те же 30 секунд что и раньше (опять оптимизация в 5 раз, кек), несмотря на добавленную функциональность.

Годная обзорная статья про метрики кода (всякие там цикломатические сложности и т.п.). Статья не претендует на полноту, а является скорее призывом к осознанному подходу в этой области.

Некоторые тезисы:

• Код сам по себе слабо влияет на “читаемость” — другие факторы, возможно, более важны.
• Метрики кода коррелируют с его сложностью, но довольно слабо.
• Одно из исследований показало, что ни одна из 121 метрик сложности кода не отражает сама по себе “простоты”/“понимаемости” кода.
• Процессные метрики лучше (и правда, если ваши процессы говеные, то качество кода не спасет разработку).
• Паттерны имеют большое значение: принцип наименьшего удивления, безобразно, но единообразно и т.п.
• Сложность/понятность кода зависит от контекста™ (причем в самом широком смысле).
• Неправильные имена переменных и типов хуже отсутствия имен. При этом “неправильные” имена переменных для одного разраба могут быть “правильными” для другого.
• Существующие метрики основаны на интуиции, а не на науке/нормальных эмпирических исследованиях.