Блог*

Собственная Фудзи должна быть у каждого японского школьника - об этом позаботилась компания PLUS Stationery. Она продает стирательные резинки, которые поначалу выглядят обычно (слева на фото), но постепенно превращаются в Фудзи со снежной шапкой. Изобретательно! Линейка таких резинок постоянно обновляется, и сейчас в продажу поступил осенний вариант с кленовыми листьями.

#prog #article Статья (и продолжение) о дизайне hypothesis — библиотеки для property-based тестирования (вообще для Python, но с портами на другие языки, включая Rust). В отличие от родоначальника подхода QuickCheck, в котором для генерирования произвольных значений опирается на классы типов (и, следовательно, типы), hypothesis опирается на явные генераторы значений, которые, в отличие от генераторов QuickCheck, могут иметь состояние. В статьях убедительно аргументируется, что это позволяет сделать минификацию тест-кейсов значительно более эффективной, как в смысле райнтайм-производительности, так и в смысле снижения числа отбрасываемых тест-кейсов. А вообще советую почитать остальные статьи в блоге, там много интересных.

#prog #rust #article #abnormalprogramming Статья о том, как сделать в Rust свои примитивные численные типы. Ну, почти.

Кажется, я теперь буду скупать все призмы и похожие штуки. Посередине кубик со световыми фильтрами.

#article А раньше мемы были проще. И теперь это доказали. (thanks @psilon)

Всё в этой жизни уравновешано: если сегодня ты стукнулся правой коленкой, то завтра стукнешься левой

#prog #article Статья про паттерн для работы с IO. "There’s a pattern that I keep recommending to teams over and over again, because it helps separate concerns around I/O; sending and receiving things over a network, interacting with AWS, saving and loading things from data stores. It’s an old idea; you’ll find it filed under “Decorator” in your Gang of Four book. <...> Decorators are a great compositional pattern allowing the different concerns that inevitably cluster around I/O boundaries to be neatly separated and recombined. This opportunity presents itself several times in every app we write, and does not require any fancy language, type system, or framework."

Как перестать забывать обедать на работе

#prog #rust #article Статья о распространённых плохих практиках новичков в Rust

> Footnotes now supported in Markdown fields YES YES YES <source>

По :debian: в Телеграме выползает эмодзи 🍥 теперь.

#prog #rust #моё Тут Даня рассказывает о том, как можно уменьшить время на критические секции с мапой в многопоточном контексте, расчитывая хэш для поиска ключа заранее. Бенчмарк, который он сделал, показывает, что CPU time от подобных манипуляций остаётся практически то же, а вот wall time становится меньше, что в итоге уменьшает задержку (в смысле latency). Советую почитать, пост неплохой. Но я несколько отвлёкся. В том же посте Даниил сокрушается, что подобная операция (поиск при помощи хэша) есть в коллекциях Abseil, но не в различных стандартных библиотеках языков, в том числе C++ и Rust. И вот тут Даня не совсем прав. У HashMap из стандартной библиотеки Rust есть методы raw_entry{, mut}, которые предоставляют API для низкоуровневого манипулирования мапой, в том числе и поиск при помощи предвычисленного хэша. Единственная проблема заключаются в том, что эти методы... Ещё не стабилизированы. И, насколько я могу понять по обсуждениям в tracking issue, сейчас там обсуждается вопрос, должно ли это API вообще существовать в том виде, в котором оно есть сейчас. С другой стороны, HashMap из стандартной библиотеки сейчас не более, чем обёртка над hashbrown::HashMap, у которой эти методы есть, так что мы можем построить поверх неё аналог LockedHashMap из оригинального поста, а заодно осветить парочку моментов из стандартной библиотеки Rust, которые незаслуженно обделяют вниманием. Для начала запишем определение: use hashbrown::HashMap; use std::{borrow::Borrow, hash::{BuildHasher, Hash, Hasher}, sync::{Mutex, MutexGuard, PoisonError}}; struct LockedHashMap<K, V, S> { inner: Mutex<HashMap<K, V, S>>, } Расписывать конструкторы я не буду, они тривиальны. Методы LockedHashMap будут начинать свою работу со взятия блокировки на inner, но... Метод .lock() возвращает Result. Что с этим делать? И почему мы импортируем PoisonError? Для начала разберёмся, почему Mutex::lock в принципе возвращает Result. Дело в том, что обычно программисты, пишущие код с блокировками, не пытаются расчитать поведение кода в том случае, если код запаникует, пока блокировка удерживается. С safe Rust это не может привести к проблемам с памятью, но прерывание обычного потока управления может оставить значение, защищаемое блокировкой, в логически неконсистентном состоянии. Если программист рассчитывает на то, что какие-то инварианты могут поддерживаться, но при этом временно их нарушает во время блокировок, то паника во время удерживания блокировки может эти логические инварианты сломать. Дизайнеры стандартной библиотеки Rust решили, что это достаточно распространённая и при этом неочевидная ошибка, чтобы ограждать от неё в стандартной библиотеке. В итоге мьютекс из стандартной библиотеки может находиться не только в состоянии "разблокирован" или "заблокирован", но и в состоянии "отравлен". Когда MutexGuard (то, что реально возвращается в Ok-варианте из Mutex::lock) дропается, он не только разблокировывает связанный мьютекс, но и проверяет, паникует ли текущий поток. Если это так, то он помечает мьютекс как отравленный. Вызов Mutex::lock проверяет, является ли мьютекс отравленным, и если это так, то возвращает Err(PoisonError). Так как самое ленивое, что может сделать программист с результатом вызова .lock() — это вызвать .unwrap(), то в случае, если один из потоков, работающий с мьютексом, запаниковал — и, возможно, оставил защищённый мьютексом объект в логически неконсистентном состоянии — остальные потоки, использующие этот же мьютекс, также паникуют и, таким образом, не имеют возможности наблюдать состояние со сломанными инвариантами.

Ворую чужие #prog #meme-ы

Наконец-то дошли руки пройти Serena, которую я запускал в последний раз... 6 лет назад. И знаете что? Я обескуражен. Весьма.

Скачивание веб-страниц в один HTML файл. #решения Нашёл такое расширение для браузера. Стили, скрипты, шрифты, картинки, видео тупо инлайнятся в html через data:image + base64 или напрямую через <style>, <script>. Теперь можно перестать делать скриншоты всей страницы или скачивать её в pdf. Так же это расширение позволяет скачивать только выделенную часть страницы. Расширение: https://github.com/gildas-lormeau/SingleFile (там нормальное описание и ссылка на версию для каждого браузера). Оригинальные настройки удаляют со страницы JS, скрытые элементы, неиспользуемые стили, не скачивают видео итд. Так что покопайтесь в настройках чтобы получать нужный вам результат. Я проверил на своей последней статье, работает отлично, в комментах приложу html файл, он работает даже на телефоне. Вдохновлено https://t.me/bpblog/1219

Чёртов Proton

Коллега, находясь в отпуске, помогает в рабочем чате. xxx: Имярек, выйди и зайди в отпуск нормально #трудовыебудни