Хороший доклад про то, почему нельзя просто так взять и добавить зависимость от чего-то, чем отличается maven и gradle с точки зрения решения конфликтов, зачем нужны api и implementation, и как можно решить проблему с несколькими реализациями логгеров.

Мигрировал проект про статистику пулл-реквестов GitHub с Kotlin/JS на multiplatform. На удивление, сама миграция прошла довольно гладко — немного пошаманить с билд-скриптом, переименовать папочки и готово.

Решил заодно попробовать добавить native-реализацию. Проблем было меньше, чем я ожидал:

1. actual/expect использовал только для тестов: чтобы сделать обертку для запуска корутин и чтобы загрузить ресурсы. Вообще, по-хорошему, обе эти функции должны из коробки идти.
2. Для работы с файлами в стандартной библиотеке ничего нет. Есть kotlinx-io, но она нормально не завелась из-за проблемы с импортом AutoClosable. Ловя флешбеки от качества библиотек Jetbrains, я в итоге использовал Okio. Не могу сказать, что API великолепно, но хотя бы работает.
3. Называть платформу native — небольшое лукавство. Это скорее POSIX, если судить по поддерживаемым платформам, и это местами откровенно торчит.
4. Ktor клиент не смог сам подтянуть из зависимостей себе HttpClientEngine и кинул не очень помогающую ошибку. Оказалось, что для native есть несколько реализаций и надо явно указать нужную. Почему нельзя это сделать на этапе компиляции, не ясно.
5. Больше всего времени потратил на десериализацию JSON (sic!). Предыдущий костыль перестал работать с унылым ArrayIndexOutOfBoundsException. Я уже раз в четвертый пытался понять великую задумку kotlinx.serialization, даже пробовал сделать изолированный баг-репорт, но ничего толком не вышло. В итоге поменял один костыль на другой: избавился от шаблонных классов и сделал класс-композицию.
6. Старые проблемы остались по большей части в силе.
7. Наконец-то использовал по делу \r! Он весьма пригодился для простенького отображения прогресса.

Несмотря на проблемы, в целом получилось норм. Можно улучшить валидацию ввода и добавить альтернативные способы вывода результата, но решил, что там все понятно и не стоит тратить на это время.

На днях вышла занятная статья. Я надеюсь, многие помнят про adversarial атаки, когда на картинку панды накладывали шум и нейронка распознавала ее как гиббона или когда из-за наклейки банан распознавался как тостер. Так вот, в статье сделали что-то подобное для мультимодальных GPT (которые понимают не только текст, но и картинки): на изображение или звук накладывается наклейка или шум, и нейронка выполняет дополнительные действия: всегда упоминает корову, вставляет вредоносную ссылку в ответ, представляет себя пиратом и т.д. Рекомендую посмотреть хотя бы картинки с примерами.

Подкинули доклад про использование GraalVM в Akka-проекте.

Проблема поставлена хорошо (java жрет много “лишней” памяти), но ожидал больше практики и итогового сравнения продового кода. А так докладчик показал несколько проблем, с которыми столкнулся, когда запускал демо Akka HTTP: работа с ресурсами, рефлексия, sun.misc.Unsafe (внезапно, в GraalVM есть monkey-patching для решения подобной проблемы), инициализация, SSL. Под конец идет сравнение времени ответа native образа, обычной JVM и “прогретой”: результаты для “прогретой” JVM и native образа довольно схожи. JIT у GraalVM хуже в 65% случаев.

В целом немного противоречит моим недавним восторгам, но, справедливости ради, доклад немного старый, ну и использовать Akka сейчас для новых проектов — весьма маргинальное занятие. Однако он дает немного представления о том, чего стоит ожидать от GraalVM.

Вернулся недавно к своему пет-проекту по вычислению статистики времени принятия пулл-реквестов, который я сделал на Kotlin/JS пару лет назад. Добавил туда построение графа, где вершинами являются метки, а ребро говорит о том, что есть тикет, в котором есть обе метки.

К сожалению, взаимодействие с JS не стало лучше. Возможно частично из-за того, что рекомендуемый подход — использовать multiplatform. Планирую как-нибудь попробовать.

Из неприятного — в последней версии Kotlin сломали генерацию интерфейсов из типов .d.ts, потому что требуется npm install. Не стал разбираться детально с причинами, просто ругнулся из-за унылого решения и понизил версию платформы. Еще словил баг инкрементального компилятора, который вместо человеческой ошибки (я забыл передать требуемый аргумент) выдал мне хрень, но заводить баг посчитал излишним, т.к. скоро будет K2.

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

Немного интересного узнал с точки зрения фронта — как скопировать в буфер обмена, как сделать ссылку на скачивание файла “из памяти” и как сделать вкладки на CSS (которые не пригодились в итоге).

Думал еще сделать какую-нибудь визуализацию графа с автоматической укладкой, но всякие force-layout мне не понравились. На парочке интересующих меня репозиториев все выглядело просто как комок вершин без выраженной структуры. Попробовал force-graph (быстро, просто, негибко), d3 (быстро, очень гибко, хрен настроишь) и vivagraph (вроде работает, но куча сломанных ссылок на доки напрягла). Cytoscape не стал пробовать, воспоминаний с работы было достаточно, чтобы сделать это неинтересным. В итоге решил сделать просто экспорт в .dot — если кто вдруг будет пользоваться (кек), сам разберется.

В целом как пет-проект мне эта фигня нравится. Делает что-то не совсем бесполезное, можно потрогать фронт, котлиновские корутины, GraphQL и всякую мелочевку попутно.

Это оказалось достаточно интересной задачей, если знания о CSS близки к нулевым. С JS любой дурак может — шлепнул вызов на элемент, чтобы переключить видимость и/или подменить текст, вот и все. А вот с CSS надо немного поизвращаться (правда не так сильно, как для галереи), хотя решение получилось довольно короткое. Немного жаль, что код в итоге идет в помойку этот блог, потому что я передумал делать вкладки там, где изначально хотел.

Оказывается, в java строки не потокобезопасны, и можно получить весьма прикольное поведение, используя “нормальный” код.

Не очень новый (2018), но занятный доклад про то, стоит ли писать ОС на Rust.

Начинается с вопроса, а что такое ОС? (“если бы мы знали что это такое, мы не знаем что это такое”). Потом приводится краткая, но весьма познавательная историческая справка про историю развития ОС, в частности Mutics и Unix.

Затем обсуждаются C, другие языки, операционные системы на них (например, ОС на java, sic!). В частности, почему какой-нибудь Go не предназначен для написания ОС (кроме “idiosyncrasies” еще мешает сборщик мусора). Ну и что C++ — хороший язык, но можно нинада.

Наконец, обсуждение переходит к Rust, его преимуществам и проблемам подхода “давайте все перепишем на Rust” в контексте ОС. Одна из основных проблем — памятью все-таки надо управлять и в Rust это тяжело сделать. Альтернатива — использовать гибридный подход: писать модули и системное ПО на Rust. В итоге в Linux так и сделали в конце прошлого года.

Иногда докладчик отвлекается ради баек. Например, рассказал историю, почему в C нет логического XOR: потому что для его вычисления нужны оба операнда и нельзя остановить вычисление условия раньше, как это можно сделать с логическим И или ИЛИ. Или про то, что замена AVL на B-дерево дает преимущество Rust против С, но просто так на C упорешься его писать.

Классический способ: приложение выставляет URL /metrics, prometheus забирает оттуда их в простом текстовом формате.

Однако не все сервисы — это HTTP-серверы, да и не все живут достаточно долго. Поэтому второй способ — сделать прокси, PushGateway. Приложение запихивает метрики в PushGateway, а он уже отдает классическим способом.

Но, увы, этот PushGateway надо разворачивать, и если Grafana облачная, то там его нет. Чтобы запихать метрики в ее Prometheus, необходимо зайти через Mimir — это распределенный Prometheus такой. И вот тут уже нельзя простой формат, а обязательно Protobuf, который использует устаревшие зависимости, да еще при этом завернутый в Snappy и с особым заголовком :harold:

Очень вводный доклад про то, что надо хоть немного думать о безопасности API. В основном состоит из показательных примеров, как не надо делать, но ничего космического, топ-10 OWASP.

Некоторые интересные идеи:

• Делать все проверки не только на бэке (где они обязательны), но и на клиенте. Если какой-то запрос вызвал ошибку бэка, то это либо баг фронта, либо кто-то пытается ломать API.
• Явно помечать публичные API, чтобы не гадать ничего (“явное лучше неявного”).
• Вынести проверку авторизации в отдельный слой, чтобы не дублировать код и мониторить изменения политик.

В конце докладчик немного прошелся по токенам (упомянув убогость JWT) и гейтвеи.