#prog #web

Интерактивные графики БЕЗ JS 🎉

Рич Харрис — создатель svelte и rollup — пару дней назад рассказал про подход для создания js-free графиков, который был проверен в бою на сайте New York Times, — "A new technique for making responsive, JavaScript-free charts".

Идея состоит в том, чтобы генерировать svg-разметку диаграммы на сервере. Весь текст и оси создаются с помощью обычного css и html, для того чтобы избавиться от искажений при изменении размера контейнера. То есть окончательная диаграмма представляет из себя "бутерброд" из html и svg. Для упрощения создания подобных графиков Рич создал библиотеку Pancake, которая работает поверх Svelte. Благодаря ей создаваемые диаграммы можно прогрессивно улучшать, добавляя интерактивность после инициализации js.

Pancake не является серебряной пулей — при большом количестве отображаемых данных есть проблемы с производительностью. Рич пишет, что планирует добавить поддержку рендеринга с помощью <canvas>.

#chart #library #svg

https://dev.to/richharris/a-new-technique-for-making-responsive-javascript-free-charts-gmp

#science

Нашёл годный научно-популярный канал на YouTube. Ну или годное видео, все видео на канале я ещё не смотрел.

Оригинал: youtube.com/watch?v=ovJcsL7vyrk
Русская озвучка (да кому она нужна): youtube.com/watch?v=DH1cv0Rdf2w

#math

Ну и раз уж я начал... Есть потрясающий канал 3b1b, на котором выходят видео на математическую тему — редко, но метко. У некоторых есть субтитры на русском языке.

Лично меня в своё время поразило это видео: Fractals are typically not self-similar
Видео, из-за которого я узнал про канал: But what is a Neural Network? | Deep learning, chapter 1

А ещё автор канала делает свои видео при помощи собственного фреймворка на Python.

Киберпанк уже наступил

Как обмануть Google: берем тележку и 99 телефонов

Художник очистил улицу от машин, сымитировав пробку.

Немецкий художник взял 99 телефонов, включил в каждом режим навигатора и положил их в тележку. Затем прокатился с ней по берлинской улице. Карты Google решили, что там пробка, и покрасили дорогу в красный. В итоге: ни один водитель не рискнул построить маршрут через улицу с художником.

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

https://youtu.be/k5eL_al_m7Q

Тимбилдинг в СНГ, это когда ты подскальзываешься на ступеньках и падаешь, а дизайнер, идущая рядом, реагирует на это репликой, "опять бэкенд упал!"

#prog #article

Эмпирическое изучение отношения к gradual typing.

https://cs.brown.edu/~sk/Publications/Papers/Published/tgpk-beh-grad-types-user-study/paper.pdf

#prog #meme

#meme гифка про питон

#gif
Залипательно

Initial states:
m: 7.635 x: 5.078 y: -2.423 vx: 0.430 vy: -0.183
m: 2.292 x: 6.881 y: 2.700 vx: -0.596 vy: 0.957
m: 0.964 x: 9.030 y: 2.707 vx: -0.657 vy: 0.009
Interest-ness score: 72

Боюсь, я проведу тут много времени

#prog #rust #моё

Меня тут один Олег™ попросил коротко рассказать о афинных типах в Rust. Что ж, рассказываю.

Аффинные системы типов — это системы типов, в которых объявленные значения можно использовать не более одного раза. Как и прочие ти́повые навороты, это позволяет писать более корректные программы путём перекладывания бо́льшего числа проверок на компилятор.

Для демонстрации практической пользы приведу пару примеров из стандартной библиотеки Rust:

1. std::sync::Mutex. Для корректной работы многопоточной программы требуется, чтобы доступ к совместно разделяемым изменяемым данным был должным образом синхронизирован. Один из способов достичь его — это защитить изменяемое значение мьютексом. Простой способ, обладающий, однако, существенным недостатком: очень просто забыть захватить блокировку перед тем, как получить доступ к значению (особенно если мьютекс защищает несколько переменных). Какое решение предлагает Rust?

Посмотрим на то, как создать мьютекс. Единственный способ создать мьютекс — это передать ему защищаемое значение. После этого получить доступ к разделяемому значению можно, только попытавшись захватить блокировку или же разрушив мьютекс, причём последнее можно сделать только в том случае, если поток (в смысле thread) единолично владеет мьютексом. Таким образом, несинхронизированный доступ исключён.

Другая возможная проблема с мьютексом связана с тем, что в большинстве языков программирования значения неявно копируются: нужно прилагать специальные усилия для того, чтобы удостовериться, что каждый из thread-ов получает один и тот же мьютекс, а не свою собственную копию (тут была шутка про Go, но она была настолько толстой, что Telegram не давал загрузить пост). В Rust это получается автоматически: нет методов, позволяющих получить копию мьютекса, поэтому расшарить можно только тот или иной вид указателя на мьютекс.

2. std::fs::File. Сборщик мусора помогает освобождать занятую память, но он не очень помогает с внешними ресурсами, в частности, файлами: закрыть файл обычно нужно сразу после того, как работа с ним окончена, а сборщик мусора никаких гарантий по времени закрытий файла не даёт. В стандартной библиотеке большинства языков программирования (даже с GC) есть отдельная функция, которая закрывает файл. Тем не менее, присутствие этой функции обнажает серьёзный изъян в системе типов: файл невозможно использовать после закрытия (также, как и до открытия, но обычно это не является большой проблемой), но это состояние никак не отслеживается в системе типов. Более того, дважды закрывать файл может быть попросту опасно: например, на Linux файл описывается файловым дескриптором — фактически, просто числом. После закрытия файла это же числовое значение может быть переиспользованно для другого файла, поэтому второе закрытия того же файлового дескриптора может привести к закрытию файла в другой программе!

Как эти проблемы обходятся в Rust? Если вы проверите API File, то... Вы не найдёте там метода close! Когда File выходит из области видимости, для него вызывается деструктор, который и закрывает файл. Т. к. явного метода закрытия файла в публичном API нет, единственный способ форсировать закрытие файла — это дропнуть файл (например, вызовом std::mem::drop). В силу того, что после этого получить доступ к файлу нельзя, возможность двойного закрытия статически запрещается.

Очевидно, аффинные типы не являются серебряной пулей. Каковы же недостатки? Конкретно в случае с File недостаток очевиден: закрытие файла может завершиться ошибкой, но закрытие посредством вызова деструктора не позволяет об этом узнать. Более сильные линейные типы (в которых каждое значение используется ровно один раз) позволили бы решить эту проблему, требуя явно вызывать close и таким образом давать доступ к возможным ошибкам, но это уже тема для другого поста.

Другие статьи, раскрывающие эту тему:

habr.com/ru/post/324382
habr.com/ru/post/350372/

О, число подписчиков перевалило за сотню! Спасибо