Подкинули доклад про использование 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) и гейтвеи.

Если вы думаете, что на сайте %X% дурацкие правила паролей, то эта игра для вас.

Очень классно, что задания довольно разнообразны и заставят хоть немного подумать. Я сдался на 35 уровне. Самым напряжным заданием, наверно, было совмещение 24-го правила с 9-м и 18-м. И немного жаль, что поле ввода пароля не закрыто звездочками и не требует повторного ввода, так было бы еще веселее:)

У автора есть и [другие]((https://neal.fun/) игры/интерактивы, например, про проблему вагонетки.

В продолжение попыток использовать AI. Я попросил написать пост для канала, описал формат и дал теги.

ChatGPT сгенерировал воду про метрики разработки. Попросил писать более емко и более технично — получил еще воды про git, а потом воды про AI vs Deep Learning. Попросил написать разницу между связностью и зацеплением — опять вода. 3 раза просил короче, в итоге все равно чушь.

Попросил рассказать про какую-нибудь интересную консольную команду Linux. Опять вода про find, dd, lsof (“Просто запустите ‘lsof’ в терминале и впечатлитесь информацией, которую она раскроет о системе.”). Но последний пост был хотя бы нормальной длины (после 7 просьб! И это я еще явно в первом сообщении указал, что это микроблог). Попросил в таком же объеме рассказать про другую команду. Получил опять воду про rename, но это хотя бы можно было читать. Бот предлагал chattr и mtr, но текст мне не нравился.

• Ладно, с командами что-то не клеится, давай на другую тему что-нибудь
• %Вода про МКС%.
• Это не соответствует тематике моего микроблога. И укладывайся в 50 слов, пожалуйста
• %Печать на 3D-принтере органов человека%

Попросил подвести итоги нашего разговора, чтобы получить текст выше, и акцентировать внимание на моих реакциях. Лучшая попытка:

В нашем разговоре вы просили меня создать посты для вашего микроблога. В первом задании вы предоставили список тегов и попросили написать пост. Я предложил вам пост о разнице между связностью и зацеплением, но он оказался слишком длинным для ваших требований. Затем вы попросили сократить его до 100 слов, и я представил более краткую версию. Однако, вы просили еще более краткий пост в 50 слов, и я предложил новую тему про команды Linux. В дальнейшем вы запросили более интересную и редкую команду, а также пост не длиннее 50 слов. Я предложил команду ‘rename’, но она оказалась известной вам и не подходила. В следующем задании вы просили описать интересную и редкую команду, но не более чем в 50 слов. Я предложил команду ‘mtr’, но она также не соответствовала вашим ожиданиям. В конечном итоге, вы просили подвести краткие итоги нашего разговора, описав ваши предпочтения и ошибки, которые я допустил. Вы также просили более подробное описание нашего разговора, где я предлагал варианты и вы оценивали их соответствие вашим требованиям.

Поражаюсь терпению студентов, которые с помощь этой хрени дипломы сдают:)

Карта репозиториев GitHub с ручным ChatGPT разделением на “страны” типа Big Datia или Vuestan. Процесс создания тоже довольно занятный.