evergreen браузерами называют те, которые обновляются самостоятельно в фоне. То есть - без явных просьб пользователя. Звучит хоть и не очень хорошо, но все же считается больше хорошим тоном, нежели наоборот. Например, из-за того, что обновления IE были привязаны к обновлению операционной системы, чисто вечнозелеными их назвать было сложно. Отсюда и пошла головная боль фронтэндеров, когда сайт нужно еще и под IE оптимизировать

Код Хаффмана и почему он такой классный

Жил-был Дэвид Хаффман. И вот подумал он: если у нас одни символы встречаются чаще других, то почему мы используем одинаковое количество бит для каждого?

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

Если мы пройдемся по такому дереву, и каждый раз, когда идем направо - добавляем единичку, а налево - нолик, то мы получим уникальную последовательность битов для каждого узла. А поскольку, как уже и было сказано, самые часто-встречаемые символы лежат ближе всего к корню дерева, эта последовательность для них будет самой короткой. Соответственно, для самых редко-встречающихся символов, последовательность будет длиннее. А иногда даже длиннее, чем если бы мы вовсе кодировку не использовали. Но в результате, за счет часто-встречающихся символов мы все равно в выигрыше.

Понятие "таблица Хаффмана" же - это просто соотношение символа к его коду Хаффмана, чтобы не нужно было для каждого символа перебирать все дерево в поисках. Обычно - простая хэшмапа, хоть в некоторых ситуациях и можно выдумать что-то поинтереснее (например - LUT, который имеют O(1) доступ, отлично применимы для ascii; где-то даже был пост об этом).

Конечно, отправляя сжатое таким образом сообщение, необходимо другой стороне еще и таблицу отправить, чтобы принимающий понимал, как мы то сообщение кодировали вообще. Иногда, сообщение+таблица могут в сумме нивелировать выигрыш от сжатия, хоть для достаточно больших сообщений (что случается чаще всего) разница не является столь великой.

Но у обычного кода Хаффмана есть и недостаток. Например, необходимо дважды пройтись по тексту, дабы в первый раз все символы посчитать. Поэтому существуют и вариации, в которых бинарное дерево перестраивается во время итерирования по тексту. Но тут уж не вникал, простите.

Хаффман, к слову, используется вообще много где. Начиная от jpeg, заканчивая hpack в http/2. В hpack ситуация вообще интересная: несмотря на то, что логичным было бы использовать как раз таки вариацию с динамической перестройкой дерева, они все же пошли по другому пути. Они взяли некое "большое число типичных запросов", и построили статическую таблицу уже на их основе

Всех подписчиков поздравляю с 8 марта

фанфакт: чем от 255 отнимать значение, по этому значению можно просто произвести побитовое отрицание

Вот вроде привыкли все. Выглядит логично и удобно. А почему? ЛЕВАЯ ПЯТКА

https://buttondown.email/hillelwayne/archive/why-do-regexes-use-and-as-line-anchors/

https://rationalnumbers.ru/?go=all/effekt-danninga-kryugera-avtokorrelyaciya/

Так любимый нами (несомненно, настоящими интеллектуалами 🧐) Эффект Даннинга-Крюгера оказался пустышкой из-за некомпетентности его авторов в вопросах статистического анализа. Что может быть более ироничным, точнее автоироничным?! 😅

#всяправда

В кукисы суют прям полноценную дату в Expiry атрибут. А что по поводу формата этой самой даты? Ну, того самого, с которым всегда и у всех была пизда. Ну, у нас их три. И все три эквивалентно валидны. Пони, блядь

Ладно, деды были молоды, горячи, глупы. Сейчас настойчиво склоняют к использованию только одного формата, остальные два признали устаревшими

https://sqlite.org/draft/whybytecode.html

Недавно у автора SQLite спросили: а почему у вас байткод? Остальные базы данных ведь преимущественно используют деревья для представления запроса. Ну а он не растерялся, и выкатил статью, где расписал, почему он думает, что байткод лучше.

От себя докину: с компиляцией в байткод можно очень много приколях придумать. Самое банальное - jit, который ложится идеально при наличии своей ВМ. Опционально можно в самом фронтэнде "запекать" квери - компилировать раз, и дальше использовать из кэша, подставляя значения

Я вам запрещаю х87

Во-первых, оказывается, современные компиляторы С используют для умножения двух флоатов SSE вместо х87. SSE, если что - набор инструкций для SIMD операций. Мол, оно и работает шустрее, и умножает более предсказуемо (х87 под капотом для операций расширяет флоаты до 80-битных, отсюда и вытекают ошибки округления), да и для компилятора проще - консистентнее, авось еще между делом чего векторизировать удастся. Да и куча других нюансов (как будто и без того мало).

А во-вторых, эти самые флоаты почему-то со стэка берутся. Вот почему так - вопрос хороший

героев нужно знать в лицо

https://github.com/golang/go/blob/master/src/runtime/slice.go#L165

Там ниже, кстати, есть весьма занимательный ишшуй: github.com/golang/go/issues/67401

tl;dr всякие неприятные личности слинковались с интерналами стд либы, из-за чего изменение в них ведет к сломанной обратной совместимости. goccy/go-json, например, так сломался, а от него сам кубернетес зависит. В общем, один негодяй где-то в самом внизу пищевой цепочки ломает добрый пласт всей экосистемы просто из-за того, что в рантайме компилятора где-то что-то немного поменялось.

Поэтому, линкнейм будут потихоньку сворачивать. Оставят возможность для существующих функций (и заморозят их сигнатуры), но не дадут опираться на это для всех последующих. Список имен, доступных для linkname'a, кстати, будет выбран весьма интересным способом: rsc планирует пройтись по ВСЕМ опенсорс проектам на го (неужели даже на индигу взор обратят), и грепнуть все линкнеймы. Это и будет вайтлист (который может расширяться по индивидуальным запросам, но должен быть из списка тех, которые существовали еще до такого решения).

Надо будет вообще со всем слинковаться в индиге, что ли. Пусть попотеют

Ну нихуя себе

На удивление, на С очень легко пересесть. Накодил пока всего 35 часов (что на 5 часов больше раста, хы), но успел сорвать бинго: сегфолт, ошибка арифметики, память повреждал (пытался деаллоцировать буфер на стэке), даже в глибц маллок паниковал (ассерт проваливался). Никакие строки тебе не пишут, где это произошло, просто грустный Segmentation fault (core dumped). Ну, поплачь, мол. Но у тебя всегда есть valgrind, который тебе даст полный расклад таро: и утечки (даже расскажет, что еще можно спасти, а что уже навечно проебано), и сколько байт суммарно аллоцировано было, и где у тебя аномальное поведение (чтения out of bounds, откуда seg* прилетают - вот тут уже с файлами и строчками!), что спасает примерно всегда. CMake так и не осилил, зато есть прекрасный meson, в котором и тесты есть (в тестах тащу ассерты из unity нет, не тот, что игровой движок). Нюансы, конечно, остаются с внешними зависимостями - я пока обхожусь .wrap-файлами месона (по сути, в файлик кидаешь линк на репозиторий, и при билде тебе его склонируют и докинут к компиляции). И, собственно... А жить-то можно!

Да, еще остаются УБ, которые так с первого взгляда и не назовешь. Приколы препроцессора, от которых даже варнингов нет, и которые нужно просто понимать. Не очень удобно с отсутствием неймспейсов, у тебя по итогу вырабатывается жава-стиль с длинными именами. Но это и правда простой язык. Он учится за пару дней, и ты можешь просто сесть, и начать на нем программировать. Из нюансов, правда, я часа 2 над месоном сидел, пытался заставить его работать, но это, по сути, единоразовая инвестиция.

А вот интеграция с ИДЕ хуйня - цлион регулярно перезапускать приходится, потому что этот гидроцефал в очередной раз не может понять, откуда берется юнити в тестах.

Правда, как писать бенчмарки - я пока не разобрался. Думаю, придет еще пора плакаться, как все хуево и кислорода не дают