https://ruby-concurrency.github.io/concurrent-ruby/1.2.3/Concurrent/Promises.html Можно вечно смотреть на то, как скриптопетухи изобретают монады. (и истекать кровью из глаз)

Одно ебанутое ебланище коммитит в bundler 2.3.7 очень полезный код: https://github.com/rubygems/rubygems/commit/31bba752e712f13ad91cead739e7b96c720050ca Из-за этого половину рубишных проектов невозможно собрать при помощи bundler 2.3.7. Дальше bundler 2.3.7 становится единственным бандлером в Debian Bookworm. Конечно, в Debian Bookworm есть пакет ruby-bundler, в котором bundler 2.3.15. Но он, блять, не используется! А используется bundler 2.3.7 из пакета libruby3.1. Который нельзя снести, потому что без него половина системы ломается. Это пиздец. Это пиздец. Ты, блять, живешь, и думаешь, что когда-нибудь люди перестанут делать настолько ебланские вещи. Но нет, хуй там. Каждый раз что-то новое.

DEPRECATION WARNING: DeprecatedConstantAccessor.deprecate_constant without a deprecator is deprecated (called… У людей, которые такое пишут, не все в порядке с головой.

> require 'sanitize'; Sanitize.fragment("убери мне опасный юникод, ага") => "убери мне опасный юникод, ага"

https://ruby-doc.org/stdlib-3.1.0/libdoc/logger/rdoc/Logger.html#method-i-add > Bugs¶ ↑ > Logfile is not locked. Ебать добрый вечер. Пользовался этой поебенью с сотнями процессов, пишущих в один файл, годами — и ни разу ничего не пидорасило. Похоже, я чего-то не знаю про прыщавый write в файлы.

Обнаружил, что cочетание activerecord и тредов вредно для здоровья. В activerecord все взаимодействие с базой данных внутри процесса проходит через пятиэтажную систему блокировок. Они используются для кеша prepared statements и прочих вещей, которые тебе на хуй не обосрались. Неряшливый профайлинг показал, что в ожидании лока треды проводят по 5% времени. Но это ерунда. Беда в том, что эти блокировки иногда как-то так стакаются, что тред просыпается уже через 5-15 минут, когда соединение уже прибито по idle_in_transaction_timeout. У меня это происходит в 1 случае из 7 000 000 на сильно загруженном сервере. Activerecord — это безнадежно переусложненная хуйня. Не берите activerecord. Что брать — пока не знаю.

Как писать на сраном ruby чтобы не жрало память: — дергай GC.start full_mark:false после работы, либо перед тем, как поспать или послушать соскет; — ребутай свои процессы время от времени, чтобы убрать эффекты от фрагментации памяти, но желательно gracefully это делать, иначе граблей не оберешься; — плоди процессы при помощи fork(), он дает copy-on-write; — переделай параллельность с процессов на треды — это даст гораздо меньше выигрыша, чем кажется, и гораздо больше граблей, чем кажется, но все-таки работает; — выкинь activerecord, его писали жопой и не переделывают.

https://github.com/rubygems/bundler/issues/7135 сука блять ебаное говно заебался дебажить

поставил lolcat из aptitude на debian stable @ из коробки блюет трейсбеками

> nil || false => false Кто догадался, как это работает — тому я не завидую.

https://github.com/atipugin/telegram-bot-ruby/blob/master/lib/telegram/bot/client.rb#L24 Ничего особенного, просто библиотека перехватывает обработку сигнала. Не, ну нормальная практика. Я ничего против не имею. Я не имею в виду, что я чуть не ебнулся головой, пытаясь понять, почему мой код с обработкой сигнала не работает. Вовсе нет. Ничего подобного.

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

Тем временем в доебане поломатый бандлер: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955405

https://framagit.org/zoggy/ocaml-iri/-/blob/master/iri_lexer.ml#L142 Блядь, даже для обоссаного окамла есть библиоетка для парсинга ссылочек с юникодом, которая обрабатывает точки с запятыми нормально! Господи, блядь, за что?

addressable не понимает точки с запятой в query, потому что автор мудак: https://github.com/sporkmonger/addressable/issues/114#issuecomment-16338080 URI в стандартной библиотеке не понимает non-ascii вообще.

https://github.com/toland/patron/blob/1067878599e5ef76276a14d800cb6f9dd8cc4e9e/lib/patron/response.rb#L31 да мои вы заботливые

addressable писал еблан. Что еще взять для простой нормализации обоссаной http-ссылки в виде строки?

https://threatpost.com/bitcoin-stealers-700-ruby-developer-libraries/154937/ Рубрика «велосипедные пакетные менеджеры».

Ну вот такая вот история, например. Подключил модный гемчик. Сделал huita.try(:[], :wtf) А по-другому я нынче и не пишу уже — страшно. Для тех, кто современных рубей не видел — это абсолютно то же самое, что и huita[:wtf], но вызванное так, чтобы если вместо huita мне подсунут не хеш, а что-то другое, то в результате всего лишь будет nil, а не падение с эксепшоном. И все равно все ебнулось с undefined method `wtf' и совершенно невменяемым трейсбеком. Потому что huita принадлежит к классу из гемчика, который сделан через поебень под названием virtus. Этот ебаный virtus переопределил метод [] и заменил его на #send, потому что, э-э-э... Ну, чтобы пиздато было, наверное. Часа времени на дебаг как не бывало.

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