Хорошая мини-игрулька, в которой можно потренироваться не только в цветовосприятии, но и с бинарным поиском.

А отдельный лайк — за то, что это простая веб-страничка на 300 строк, без зависимостей, с CSS и ванильным JS прямо внутри HTML.

Неплохая статья, в которой сравниваются лонг-поллинг, веб-сокеты, server-side events и новый стандарт, WebTransport. Сравнение немного поверхностное, но хорошо рассказывает об основных плюсах и минусах этих технологий.

Делать что-то на винде в консоли — это пытка, особенно после долгих лет на Linux. Стольких базовых вещей нет, просто жуть. Самое отстойное, что нет даже простенького текстового редактора, а это было бы удобно в случае, если что-то заставили надо сделать по ssh. Однако если на машине стоит git, то в нем есть подарок — nano и vim. Т.е. можно редактировать файлы через

> "C:\Program Files\Git\usr\bin\nano.exe" filename.txt

В той же папке еще навалом линуксового добра: bash, cat, cp, grep, openssl, tar и т.п.

Интересная статья про frame pointer — указатель на верхушку стека вызовов. Недавно как раз обсуждал с коллегами, надо ли или не надо его использовать (в итоге положились на то, что в gcc по умолчанию он не добавляется), и нате.

Оказывается, наличие этого указателя довольно критично для многих профилировщиков. Занятно, что даже в java протекает. При этом какое-то влияние на производительность экономия одного регистра все-таки имеет, но оно меньше 1%, а если больше, то, скорее всего, вызвано проблемами с кэшем и расположением в памяти.

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

На маке страдаю от того, что нет нормальной программы для сравнения рандомных кусков текста или папок. На Linux использую Meld, он классный и в нем есть все что нужно, но его порт на Mac M2 работает отстойно: багает с копипастом и крашится. Чисто маковские альтернативы попробовал, одна мразотнее другой (если знаете что-то хорошее, посоветуйте, пожалуйста).

Коллеги подкинули фичу Intellij, о которой не знала даже автор книги про нее (sic!): “Open Blank Diff Window”. Самый быстрый способ, как до нее добраться, это нажать два шифта для меню действий + “OBD” или “ODW”. При этом если надо сравнить что-то с файлом или папкой проекта, то так извращаться не нужно: в контекстом меню файла есть “Compare With…” (Ctrl+D).

Мне пригодилось, когда консольная утилита что-то качала, но то соединение было хреновым.

В bash есть механизм подстановки истории, с помощью которого можно заменить, например, !3 на третью команду из истории. Когда есть Ctrl+r (поиск по истории) и банальные стрелочки — это довольно бесполезно, однако есть шаблон !!, который заменяется предыдущей командой.

!! очень удобен, например, для sudo !! (*блеать.jpg*). И пригодится для повтора:

while [ $? -ne 0 ]; do !!; done

Эта команда будет выполнять предыдущую, пока не будет успешный ответ. Можно завернуть в альяс.

Git — тот еще комбайн, про это полно мемчиков.

Я вообще редко из GUI интерфейса (в IDE) выхожу, потому что консольный — тот еще мрак с точки зрения UX. Но некоторые вещи даже через GUI делать неудобно, поэтому приходится использовать заклинания.

Одно из недавних, которое пригодилось — копирование файлов из другой ветки:

git checkout another_branch -- file_name_or_pattern

Есть небольшой подводный камень, что работает относительно текущей папки, а не корня репозитория, но в остальном довольно удобно.

Занятное исследование про улучшение процессов. Оно довольно старое (2001 год), но актуально до сих пор.

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

Что делать, кроме как повышать осознанность разными способами, особо не раскрывается. В одном примере помогло обучение в игровом формате, а в другом — изменение ментальной модели и просто выделение времени на вещи, давно требующие внимания. Очевидно, снизу так менеджмент не переубедишь :(

Я плохо понимаю электронику на уровне физических процессов. И об истории разработки транзисторов я имел очень смутные представления: вот где-то там в 50-е появился транзистор, потом на основе полупроводников в течение лет десяти появились все основные элементы “рассыпухи”.

Но, оказывается, хотя первые светодиоды появились в 60-е, нормальные синие и белые светодиоды — это уже 90-е.

Красивую историю я узнал из этого видоса. Там еще и рассказано, как вообще светодиоды работают — с движущимися картинками.

Одна из лучших книжек по алгоритмам, которые я когда-то либо читал. Избранные моменты:

• В во второй главе разобраны основные противоречия построения СД: чтение, обновление, компактность в памяти, а также точечные/интервальные запросы, вставка и удаление.
• Далее идет теория и практика, которые позволяют по характеру и последовательности операций выбрать СД. Например, когда нужно использовать B+-дерево, а когда префиксное? Полезен ли фильтр Блума для LSM-деревьев?
• В главе 4.11 приведены примеры продуктов, в которых используются “сложные” деревья — это не какая-то экзотика, а вполне популярные вещи.
• В главе 6.1 — чем отличаются традиционные от колоночных СУБД, и для каких сценариев какие лучше?
• В 6.2 — какие СД используются внутри файловых систем.
• В 6.3 — что там у ML?
• Новому времени — новые типы запросов: “глубокое” удаление для GDPR и какие это несет последствия для СД.
• Ну и железо не отстает, оно разумеется влияет на построение СД (правда тут скорее обзор статей на тему).

В конце сделан вывод, что создание СД — это искусство. Возможных структур данных — больше чем 10^100.

Рекомендую к прочтению тем, кто работает с большими данными/СУБД. Но вообще довольно познавательно для всех разработчиков.