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

Сложный процент

Предположим, что мы кладем 100р на вклад на год со ставкой 12% годовых.

Интуитивно через год будет 112р т.к. процентов же 12. Так было бы, если проценты начислялись разово на всю сумму, но они начисляются каждый месяц. Рассчитаем.

12% за 12 месяцев - это 1% каждый месяц:

1-й месяц:  100.00 + 100.00 × 0.01 = 101.00
2-й месяц:  101.00 + 101.00 × 0.01 = 102.01
3-й месяц:  102.01 + 102.01 × 0.01 = 103.03
4-й месяц:  103.03 + 103.03 × 0.01 = 104.06
5-й месяц:  104.06 + 104.06 × 0.01 = 105.10
6-й месяц:  105.10 + 105.10 × 0.01 = 106.15
7-й месяц:  106.15 + 106.15 × 0.01 = 107.21
8-й месяц:  107.21 + 107.21 × 0.01 = 108.28
9-й месяц:  108.28 + 108.28 × 0.01 = 109.36
10-й месяц: 109.36 + 109.36 × 0.01 = 110.46
11-й месяц: 110.46 + 110.46 × 0.01 = 111.56
12-й месяц: 111.56 + 111.56 × 0.01 = 112.68

Таким образом, получилось больше, чем 12%. На горизонте одного года разница выглядит незначительной, но рост по сложному проценту происходит по экспоненте: чем больше проходит времени, тем быстрее увеличивается сумма.

Тут прошел год и разница с 12% вышла 0.68%, но если взять 30 лет, то интуитивно:

100р + (100р * 12%) * 30 = 100р + 360р = 460р

но из-за сложного процента будет 3595р! Огромная разница. Сложный процент на протяжении долгого периода работает очень хорошо. Поэтому люди и инвестируют.

Мои проекты

📦 go-clean-architecture (пост)
Шаблон проекта с чистой архитектурой и акцентом на корректную реализацию

🧹 golangci-lint-config (пост)
Строгий конфиг линтеров с расширенным набором включенных проверок и настроек

📜 open-api-101 (пост)
Базовый пример использования популярных библиотек для кодогенерации клиента и сервера по OpenAPI

🧬 slice-analyzer (пост)
Пакет для исследования поведения slice в Go с наглядным отображением указателей и underlying array.

⚙️ cleanconfig (пост)
Библиотека конфигурации для Go со строгой валидацией структуры конфига и возможностью задавать env-переменные в файле конфигурации. (Например, выдает ошибку, если в ямле нет поля, а в структуре есть и другие фичи)

💬 telegram-export-parser (пост)
Инструмент для парсинга JSON-экспорта Telegram-чата и преобразования его в удобную структуру для дальнейшего анализа.

Оглавление

О чем я тут пишу?
1. Набор чего-то, что встречается мне пока я сижу за компом
2. Посты, которые могут быть полезными (список ниже)
3. Отзывы на книги, которые читаю: #книги (общий список)
4. Мои проекты

Golang
- Чистая архитектура. Как изучать
- pkg directory considered harmful
- Почему в го "приняты" имена пакетов в одно слово и однобуквенные названия переменных

Книги
- Лучшие актуальные книги по Golang
- Книги по Concurrency в Golang
- Рейтинг книг Golang
- Где скачивать электронные книги

Остальное
- Алгоритм любой оптимизации
- Что происходит, когда вводишь URL и нажимаешь Enter
- До сих пор любимый текст про ИИ
- Звезды у rust репозиториев
- Что такое сложный процент

Выгрузка слов из Яндекс Переводчика

Когда я что-то читаю не в браузере, например, книгу, то перевожу незнакомые слова через яндекс переводчик. Слова там можно сохранять в так называемые Подборки, но к сожалению слова из этих подборок нельзя экспортировать в файл (Ctrl+A + Ctrl+C копирует только те слова, что в данный момент видны). Поэтому я сделал небольшой скрипт для этого:

https://gist.github.com/rostislaved/99a0e8608c5bf3ceb9de7981a9c36379
- Приводит к нижнему регистру
- Убирает дубли (Слово+Перевод)

Также прикрепил свой набор сохраненных слов за много лет - большую часть я до сих пор не знаю)

Проверь! Есть ли у тебя B1😁

Прогать с агентом зачастую выматывает сильнее, чем без него.

Сначала надо сгенерить код. Это кажется просто, но перед этим действием нужно уже провести много работы, продумать требования и нюансы (ибо магии нет: говно на входе = говно на выходе). План-хуян. Потом наконец генеришь и даёшь другому агенту на ревью. Если код сложный, то в 99% случаев что-то вылезает. Ладно, чинишь. Даёшь другому агенту посмотреть. Вылезает что-то странное, ты не понимаешь, он прав или нет. Начинаешь читать код вручную (это всё равно пришлось бы делать, но надеялся, что позже, когда основное будет пофикшено). Читать чужой код, написанный инопланетянамм (сам бы так не написал). Тратишь дофигища энергии, чтобы построить в голове ментальную модель высера. Просишь объяснить тестами. Понимаешь, что это нечитаемое говно, просишь агента переделать так-то и упростить тут-то. И всё равно - ну не то, блин. Нет удовольствия от хорошо сделанной раьоты.

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

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

А как было раньше: моменты обдумывания чередовались моментами медитативного прописывания. Модель в мозгу выстраивалась постепенно и надолго. Было удовольствие от полученного кода.

эх

#книги
Andrew Tanenbaum - Modern Operating Systems
23.04.2026 - 24.07.2026

Уже пару книг я пишу эти комментарии по-новому: если во время чтения встречается какая-то мысль, то сразу открываю Obsidian и записываю ее в заметку про книгу. После прочтения всей книги компоную эти заметки во что-то более связанное и делаю какой-то вывод. Поэтому дальше могут быть, например, описания не всех глав, а только тех, где я оставлял какую-то заметку. В общем, я начинал читать с большим энтузиазмом, но к концу полностью разочаровался.

Часть 2. Processes and Threads
Некоторые объяснения не назвать простыми. Например, в процессах и тредах примеры не самые наглядные для того, у кого нет опыта программирования и понимания того, как могут переключаться разные параллельные задачи.
Очень громоздкое объяснение концепции data race. Тысяча лишних деталей...
Глава про синхронизацию идет со скрипом. Тема сложная, но я точно знаю, что можно написать проще, как в книге Three Easy Pieces. И на удивление в Three Easy Pieces более подробное и качественное рассмотрение возможных алгоритмов шедулера ОС.

Часть 3. Memory Management
Некоторые предложения главы про память - это прямо тест на advanced english с идиомами и просто редкими словами, хотя в целом книга в плане языка написана довольно доступно.
Глава про виртуальную память сложная, но, так как я не глупый и уже знаком с идеей, то делаю вывод, что это она плохо написана))

Часть 7 (Virtualization and the Cloud)
Очень сложно. Очень плохо написано. Процентов 20 пропустил. В главе про многопроцессорность начало казаться, что это графомания.

Часть 9 Security
В этой части мысль про графоманию только укрепилась и ушла куда-то очень далеко: 30 страниц забористой академической теории про безопасность - это вряд ли то, что ожидаешь от книги про ОС. Эта часть очень скучная в начале, но очень интересно про Meltdown и Spectre - я наконец-то понял, в чем их суть (в общих чертах, конечно).

После частей с общей теорией идут Case Studies: про Linux, Android и Windows. Только в case study по линуксу я начал читать то, что я ожидал от книги по ОС, но это воодушевление быстро угасло, и уже case study для Андроида и Windows я сильно пролистывал, читая только интересовавшие меня главы и абзацы.

Вспоминая другие книги Таненбаума, я понимаю, что мне определенно не нравится, как он пишет. Это неудовлетворение сложно формализовать, но факт его наличия я осознал. Не раз ловил себя на мысли, что какая-то идея уже объяснена в книге, но понимания не появилось. Странное свойство, я считаю, что проблема не во мне, так как во многих других книгах такого нет, а тут есть. Очень хорошо работает подход: прочитать главу, скормить ее LLM и попросить объяснить основную идею. LLM отлично справляется, и неясно, почему автор не формулирует основную идею так же - сначала.

Все-таки я считаю, что это плохо написанная книга. Ее трудно читать. Способ объяснения далеко не самый лучший. Часто после прочтения главы не понимаешь, как можно было такую простую идею так сложно объяснить. Чтение книги я воспринимал как "нахвататься фактов про операционные системы".

Все это я пишу, сравнивая её с бесконечно интересной и одной из моих любимых книг вообще - Three Easy Pieces. Если хочется почитать про ОС, то лучше начать (и возможно ограничиться) ей.

А с Таненбаумом я, пожалуй, закончил.

ZSH '=' expansion

Некоторые файлы в unix-like системах - это soft links на бинарники. Об этом говорит первая буква l выводе команды ls -l

 > ls -l /usr/bin/python
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

Чтобы узнать на что ссылается ссылка нужно ввести полный путь к ней, как в примере выше, но так как путь не всегда известен, то его сперва нужно узнать так:

 > which python
/usr/bin/python

и только потом передать в ls -l, что неудобно. Можно это объединить в одну команду, что я и делал всегда:

 > ls -l $(which python)
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

Но это тоже неудобно.

Сегодня узнал, что существует '=' expansion в zsh, что сильно всё упрощает:

 > ls -l =python        
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

Ну или если есть алиас на ls -l:

 > ll =python
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

https://zsh.sourceforge.io/Doc/Release/Expansion.html#g_t_0060_003d_0027-expansion-1