Отличный доклад, в котором рассказана основная история вопроса от первого телеграфа до UTF, а также освещены основные моменты про управляющие символы, диакритику, виды нормализации, UTF-16 vs UTF-8, эмодзи, флаги и т.п. Подано хорошо и с юмором, рекомендуется к просмотру детям программистам всех возрастов.

SQL — это sequel, а PRQL — это prequel. Как и положено, второй появился позже первого и эксплуатирует его наследие:)

Довольно занятная штука. Писать что-то длинное в SQL не очень удобно из-за неестественного порядка записи — это как на питоне пробовать в функциональном стиле писать с filter и map (хотя можно привыкнуть). PQRL нацелен решить эту проблему и подобно тому, как TypeScript транслируется в JS, может быть транслирован в обычный SQL. Его даже в ClickHouse добавили.

Я немного попробовал PRQL в песочнице — не могу сказать, что это “вау”, но стоит попробовать. Правда сомневаюсь, что что-то совсем зубодробительное получится написать существенно проще чем в обычном SQL. Ну и разумеется, использовать это стоит только для “ручных” запросов, потому что так-то основную работу делают ORM ну или на крайний случай DSL.

Статические системы типов можно условно поделить на два вида: номинативные и структурные. В номинативных системах совместимость и равенство типов определяется по имени. Классический пример — java. Вот есть два класса:

class Duck {
	String quackSound;
	void quack();
}

class Quaker {
	String quackSound;
	void quack();
}

С точки зрения java — это два разных типа: имя разное, и пофиг, что начинка одинаковая. А вот в структурной системе типов это будет считаться одинаковым типом как раз потому что структура одинаковая. Структурную систему типов имеет TypeScript и этим он достаточно сильно отличается от других “мейнстримовых” языков. Джависты в шоке от того, что можно делать с помощью TypeScript, а кто-то даже предложил на нем тесты писать для java-проекта (sic!).

Еще есть утиная типизация — ее типы вообще не заботят, а только поведение. Вот такой класс

class McDuck {
	Int wealth;
	void quack();
}

ни по имени, ни по структуре не совпадает ни с одним из предыдущих. Но в Python все три класса будут совместимы, если от них нужен только quack.

Разумеется, почти все практические языки не на 100% строги. В какой-нибудь Scala вполне спокойно можно организовать структурную типизацию.

Чтобы быстро и без проблем скачать что-то из заблокированного интернета не надо ставить VPN и WireGuard, не надо форвардить порты, нужно всего лишь… читать далее

ssh -D 8080 -C -q -N name@server
...
curl -s -x socks5h://0:8080 https://some.shit/file

Хороший доклад про то, почему нельзя просто так взять и добавить зависимость от чего-то, чем отличается 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 надо немного поизвращаться (правда не так сильно, как для галереи), хотя решение получилось довольно короткое. Немного жаль, что код в итоге идет в помойку этот блог, потому что я передумал делать вкладки там, где изначально хотел.