Хорошая статья про DIP

1. Из нее можно понять, что такое зависимость
2. Что такое сам принцип DIP
3. Почему интерфейсы располагаются в месте использования, а не реализации

https://habr.com/ru/articles/872078/

#книги
Лю Цисинь - Задача трех тел (трилогия)
15.07.2024 - 02.01.2025

Все ищу что-то, что мне понравится также, как Азимов)
В целом неплохо, книги серии вообще не похожи друг на друга, видно, как автор экспериментировал. Моментами было скучно, например, в первой какое-то долгое описание культурной революции в Китае. В третей один герой рассказывал сказки другому, они важные для сюжета, но такие долгие и неинтересные, что хотелось пропустить.

Только в третей книге началось то, что мне нравится больше всего - космос, корабли, физика и т.п. Во второй тоже было, но не так много.

Третья книга с интересными идеями, иногда даже гуглил разное, чтобы разобраться, но это совершенно необязательно для чтения книги, скорее просто книга рождала ассоциацию и я шел гуглить. Надеюсь, когда-нибудь прочитаю книги по физике, чтобы лучше понимать, как работает этот мир :)

Чтобы еще про космос найти..

🌐 HTTP QUERY: новый метод для поисковых запросов

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

Можно использовать GET и передавать всё в URL:

GET /feed?q=foo&limit=10&sort=-published&filters[]=status:active&filters[]=type:post

Но URL дефакто имеет ограничения по длине, а кодирование сложных параметров становится громоздким.

Второй вариант — использовать POST и передавать параметры в теле запроса. Однако POST не предназначен для таких операций: он не кэшируется и не является идемпотентным, что усложняет работу с CDN и повторную отправку запросов.

Именно поэтому появился новый метод QUERY. Он позволяет отправлять поисковые параметры в теле запроса:

QUERY /feed
Content-Type: application/json

{
  "q": "foo",
  "limit": 10,
  "sort": "-published",
  "filters": ["status:active", "type:post"]
}

При этом QUERY сохраняет все преимущества GET: он безопасный, идемпотентный и кэшируемый. Cочетает поддержку тела запроса с возможностью кэширования.

Метод официально получил статус PROPOSED STANDARD, что означает скорое появление поддержки в браузерах и веб-фреймворках.

RFC: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/

#книги
Sam Newman - Building Microservices
02.01.2025 - 01.02.2025

Книга довольно поверхностная и скорее про общие идеи разработки, в том числе в микросервисах, а не про сами микросервисы. Конкретных деталей не так много, как хотелось бы. Когда я читал Chris Richardson - Microservices Patterns и у меня были к ней претензии, что ее можно было бы написать в лучших формулировках, и я думал, что Building Microservices будет как раз лучшей ее версией и больше про идеи, а не детали, но идеи оказались слишком общими и если выбирать книгу про микросервисы то сейчас я скажу, что это Microservices Patterns.

Не понравилась глава про Security. Хотя автор и сделал дисклеймер, что не является специалистом в этой области, всё равно создаётся впечатление, что тема раскрыта поверхностно. Зато понравились главы: Microservice Communication Styles и Scaling. Полезные и их можно прочитать даже в дополнение к Microservices Patterns, где глава, например, про сагу мне показалась слишком сложно сформулированной.

Каждая новая книга, которую я читаю, так или иначе пересекается с предыдущими, и это может влиять на степень моего интереса. Вероятно, это отразилось и на том, как мне читалась эта книга. Однако у нее и у книги Криса Ричардсона на Amazon и Goodreads примерно одинаковые рейтинги, так что, объективно, читатели оценивают их примерно одинаково.

Статья про НЕменеджерскую ветку развития разработчика

https://habr.com/ru/companies/kuper/articles/856224/

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

Но по порядку. Квантовые компьютеры делают из разных кубитов: некоторые используют сверхпроводящие микросхемы (как IBM и Google), некоторые — ионы (IonQ например), некоторые — фотоны (Xanadu). Ну и есть много других вариантов. Самая большая проблема с квантовыми компьютерами в том, что квантовая запутанность в них очень легко разрушается минимальным внешним воздействием. Поэтому эти комьютеры стараются изолировать от внешнего мира как можно лучше: засовывают в супер-криостаты, используют лучшие материалы и т.д.

Среди этих подходов выделяется один: топологические квантовые компьютеры. Точную работу описать довольно сложно, но попробую такую аналогию. Представьте, что у вас есть железная дорога типа Brio и вы можете катать по ней туда-сюда вагончики. А еще можете пересекать пути, делать мосты и т.д. Общая структура вашей дороги (как именно они пересекаются, сколько пересечений и между какими путям и т.д.) является ее топологией. В этих пересечениях реализуются вентили компьютера (т.е. логические операции). Так вот, внешний мир действует на вагончики: они то тормозят, то ускоряются, то вибрируют, то вообще пропадают. В обычном квантовом компьютере это является основной проблемой: квантовые состояния (вагончики) разрушаются, появляются ошибки. Но в топологическом квантовом компьютере операции зависят не от одиночкых вагончиков, а от общей структуры путей, а она остается постоянной и не подвержена влиянию внешнего мира (почти). Потенциально это очень мощный инструмент для реализации квантовых компьютеров, так как ему не страшен внешний мир.

На практике никто не знает, как именно это сделать. Вагончики должны быть очень специальными, чтобы реализовать такой компьютер. Это должны быть квазичастицы, которые называются анионы и обладают очень необычными свойствами. Они существуют в определенных двумерных материалах в определенных условиях (возможно). Майорановские фермионы, о которых вы слышали в новостях про Майкрософт — пример таких частиц.

Ура, введение готово, пора перейти к драме. Пока IBM и Google соревнуются за количество кубитов и пытаются как-то найти способ увеличить их до полезной величины, Microsoft пошли другим путем и пытаются создать топологический квнатовый компьютер. Если у них это получится, они обойдут всех на повороте и унесутся за горизонт. Но пока попытки, мягко говоря, не внушают доверия.

Из года в год они публикуют результаты про открытие и изучение этих самых Майорановских фермионов в самых престижных журналах. Из года в год в этих результатах находят ошибки, неверную статистику и прямой подлог и статьи отзываются (таких статей уже набралось не одна и не две, можно вот тут эпичный тред посмотреть). Т.к. это майкрософт, публиковать данные они отказываются (NDA и все такое) и верифицировать никак не получается. Но на каждой статье они собирают хайп, лайки и инвестиции — что еще нужно. Вот и нынешние "новости" — ровно из той же оперы. Те же авторы, один из рецензентов — главный автор прошлых отозванных статей, те же проблемы с данными и их доступностью, и т.д. Нет никаких оснований доверять этому. В целом, научное комьюнити давно уже крутит пальцем у виска, и главной загадкой остается вопрос, почему их вообще продолжают публиковать (хотя это и не загадка никакая, всем все понятно, кто за этим стоит).

В общем, не верьте хайпу! Я нарочно не даю ссылки на новости или статью, чтобы не разгонять этот хайп дальше. В целом, любые новости про квантовые компьютеры всегда можно делить на 10-100, но в особенности когда говорят про "прорыв, которого еще никогда не было". Это уж почти наверняка какая-то лажа.

Почему в го "приняты" имена пакетов в одно слово и однобуквенные названия переменных

Судя по всему причина для этого - личные предпочтения Rob Pike, которые он описывает в своей заметке Notes on Programming in C от 1989г.

Мне нравится мысль, что длина имени переменной зависит от скоупа её использования. То есть, чем в большем числе мест используется переменная, тем более обоснованно ее длинное имя и наоборот, если это обычный цикл на пару строк, то имя должно быть короче.

Пайк тоже говорит об этом и приводит в пример цикл, где индекс обозначется буквой i. Как по мне это сразу некое исключение, ибо я бы назвал переменную i даже в большом цикле т.к. это устойчивое обозначение индекса в математике. И поэтому после i идет j, а потом k.

Дальше Пайк говорит, что ему больше нравится maxphysaddr, а не MaximumPhysicalAddress и причины для этого:
1. Второе название дольше печатать (Неактуально для современных редакторов кода)
2. Затрудняет восприятие вычислений (Вычислений в Си может быть и то спорно, но не энтерпрайзного кода точно)
3. Цитата: "Я избегаю встроенных заглавных букв в именах; для моего глаза, привыкшего к текстам, они слишком неудобны для чтения. Они режут взгляд." (Определение слова "вкусовщина")

Видимо поэтому мы имеем рекомендацию в го делать имена пакетов в одно слово, а не CamelCase или snake_case.

Возможно пакет с названием "strconv" еще читаем, но всякие veryimportantdocumentuploader - нет.

Также Пайку больше нравится название переменной np, а не NodePointer. И в целом это может быть нормально в приложении вся суть которого крутится вокруг связного списка или внутри либы для его реализации, но в чем-то большем это создаст трудности.

Мысль, с который я 100% согласен - если переменная названа maxphysaddr не называйте её «соседа» lowestaddress. То есть консистентность должна быть.

В общем, после этой заметки мне будет легче не винить себя за то, что не пишу названия пакетов в го в одно слово т.к. хочу получить что-то более читаемое.

Про такие темы принято говорить, что это "вкусовщина", что от части так, но всё же не надо оправдывать этим словом отсутствие дисциплины. А чтобы посмотреть какие-то аргументированные мнения есть отличная книга Стива МакКоннелла - Совершенный Код (2004). Она конечно не самая новая и некоторые примеры будут неактуальны сегодня, но многие подходы применимы. Моя "вкусовщина" основана по большей части на этой книге.

Доли разных стран в общем мировом рынке акций

Реальные (после вычета инфляции) доходности разных классов активов.

- Данные по активам всего мира
- Периоды учтенных выборок разные, какие-то с 1800х, какие-то с 1900 годов.
- Доходность акций США ближе ко второму числу (6.7%)

TypeScript портируют на Go

Microsoft разрабатывает нативную версию компилятора TypeScript на языке Go. Это поможет уменьшить время компиляции в 10-15 раз и существенно снизить использование памяти

На вопрос Why not Rust? [1, 2] ответили следующее:
1. Код не пишут с нуля, а переписывают существующий
Rust потребовал бы кардинальной переработки.

2. Автоматическая сборка мусора
Rust требует явного управления памятью, что усложняет миграцию.

3. Циклические структуры данных
В Rust работать с ними сложнее из-за ограничений модели владения, тогда как Go поддерживает их нативно.

4. Конкурентность и разделяемая память
В Go удобная модель.

5. Проще для разработчиков JS
Go ближе к JavaScript, чем Rust.

Релиз Apache Kafka 4.0.0

Теперь без ZooKeeper!

link

📦 pkg directory considered harmful

🚫 Почему не стоит держать код приложения вне директории internal
Чтобы понять, в чём проблема, нужно разобраться с понятием «публичный интерфейс». Я уже писал статью, где постарался понятно объяснить, что это такое и почему термин «интерфейс» часто вызывает путаницу (из-за перегруженности термина). С ней можно ознакомиться тут. В этом тексте речь идёт именно о публичном интерфейсе, а не о типе данных interface!

При проектировании публичных интерфейсов важно понимать:
🔒их нельзя менять без необходимости — иначе сломаются клиенты, которые от них зависят (комикс на тему). То есть нужно сохранять обратную совместимость. По этой причине приложения версионируют (см. https://semver.org/lang/ru/) и ломают обратную совместимость только в мажорных релизах (MAJOR.minor.patch), которые выходят намного реже, чем minor и patch. Чтобы не приходилось часто выпускать мажорные релизы, интерфейс нужно тщательно продумывать и делать минимальным (минимально необходимым).

📌 Например, в HTTP API это означает, что не стоит создавать несколько эндпоинтов для похожих действий. Вместо /users/active и /users/inactive лучше сделать один — /users?status=active|inactive.

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

🚧 Защита кода с помощью internal
Чтобы исключить возможность того, что другие приложения будут зависеть от нашего кода, нужно запретить этот код импортировать. Для этих целей в Go 1.4 появилась директория internal, которая запрещает импортировать то, что внутри нее любому коду на уровень выше (в том числе из другого репозитория).
📖 Подробнее про internal - в документации.

🤡 Но часто этой директории придают другие значения — например, «в internal кладём бизнес-логику, а в pkg — библиотеки». Это ошибочное представление, которое возникло из-за исторических причин, а сейчас распространено т.к. бездумно копируется. На самом деле любые трактовки internal, отличные от официальной, понятны только тем, кто их придумал. Если использовать internal по назначению, то в нее попадает код, который мы запрещаем импортировать, а вне internal остается код, который разрешаем импортировать, а никакой не "бизнес код", не "код, который должен стать библиотекой в дальнейшем" и т.д. Если есть код, который планируется в будущем сделать библиотекой, но сейчас еще не пришло время для этого, то можно его поместить внутри internal, например, создав уже там директорию pkg.

Часто в pkg хранят "клиенты" от http или gRPC API приложения, и хоть это удобно, но архитектурно это уязвимо. Внутри этих клиентов код часто использует пакеты самого приложения (со структурами например), поэтому импортируя этот клиент, неявно импортируются и другие пакеты. Правильнее хранить клиенты в отдельном репозитории и использовать "свои" структуры (определенные в репозитории клиента). А не свои и не получится т.к. в основном приложении они будут лежать в internal!

🔗 Полезные ссылки:
- https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/ (последний абзац)
- https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2
- https://go.dev/doc/modules/layout — хорошая статья от команды Go про структуру проектов. Я считаю, что она должна быть основой, которую надо читать на эту тему, а не распиаренный golang-standards/project-layout (который, вопреки названию, не является стандартом).

🗂 Какую структуру использовать
В большинстве случаев Go-проект содержит всего две директории с го кодом:
- cmd с main.go
- internal - со всем остальным кодом

Как организовать содержимое внутри internal — зависит от многого. Я считаю идеи чистой архитектуры полезными и делаю свой репозиторий, где стараюсь следовать этим принципам:
📎 https://github.com/rostislaved/go-clean-architecture

Если бы мне дали ОС и стояла задача делать для нее всё самое худшее, то я бы делал именно то, что делает Microsoft всегда.

Менял бы пуск по много раз
Перемещал его
Добавлял рекламу
Менял интерфейс настроек каждый раз
Встраивая одно поколение интерфейсов в другое
Запрещал создавать аккаунт без необходимости залогиниться
Автоматически включал отлючённое пользователем автообновление через какое-то время
Добавлял по умолчанию включённую телеметрию
Перезатирал загрузчил уже установленного линукса
Добавлял шифрование битлокера - 48 символов которые надо вводить руками

Феерические решения..

Windows 11 is closing a loophole that let you skip making a Microsoft account
Article, Comments

#книги
Дмитрий Никитенко - Речь о миллионах
15.02.2025 - 06.04.2025

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

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

Выводы, которые я делаю на текущем своем уровне понимания инвестиций:
1. Если обобщать и упрощать, то реальная (после вычета инфляции) доходность инвестиций - 5% годовых
2. Инвестиции - это не способ разбогатеть, это способ качественно откладывать
3. Исходя из п. 2 основным источником дохода может являться только что-то другое.
4. Даже учитывая небольшую доходность в п.1 это все равно лучшая из альтернатив. И вариант не инвестировать, а просто "откладывать" гораздо хуже - примерно на 8% (нет роста в 5%, и есть инфляция в 3%). Что учитывая механизм работы сложного процента - значительная разница между двумя подходами.
5. В портфеле должны быть разные классы активов. Добавляя облигации к акциям немного снижается доходность, но сильно снижается риск. Также становится возможен "эффект ребалансировки" ("портфельный эффект")
6. Узнал термин "человеческий капитал". Это совокупность знаний, навыков, умений, опыта, здоровья и других качеств человека, которые влияют на его производительность и способность приносить экономическую выгоду (в частности себе). Его можно выразить в деньгах, сложив все ожидаемые будущие доходы человека. Современем человеческий капитал уменьшается, потому что мы не можем работать вечно и приближается время, когда человек перестанет получать доход от трудовой деятельности, а значит с каждым годом в нашем распоряжении остается всё меньше будущих доходов. Доходы однажды заканчиваются, а расходы всегда остаются. Поэтому важно как можно раньше начать эффективно переводить человеческий капитал в финансовый, а не тратить всё и сразу.
7. Если есть много денег, то лучше на них сразу купить бумаги, а не делать это постепенно (есть исследования, что в среднем это эффективнее)

В общем неплохо. Узнал новое. Смирился, что на инвестициях миллиардером не стать и надо искать что-то другое, но это и не повод ими не заниматься!

Официальный бот Perplexity

CEO Perplexity объявил в твиттере, что теперь в телеграме есть официальный бот: @askplexbot

Можно писать боту, а можно добавить в группу и там с ним общаться или призывать реплаем на сообщение с вопросом

📚 Почему я читаю книги

Ну, во-первых, потому что это интересно.

💡 А во-вторых — вот почему.
Недавно мне пришла в голову мысль: в чём же причина этого и что именно я пытаюсь получить, читая книги? И я вспомнил такую цитату:

«Есть вещи, о которых мы знаем, что знаем.
Есть вещи, о которых мы знаем, что не знаем.
А есть и такие, о которых мы даже не знаем, что не знаем.»

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

📖 И вот книги — это способ перевести знания из категории «я не знаю, что не знаю» в категорию «я знаю, что знаю». Это помогает иметь представление о чём-то, видеть большую картину. И даже если все прочитанные детали из книги забудутся, знания всё равно не вернутся в категорию «я не знаю, что не знаю», а останутся хотя бы в категории «я знаю, что не знаю» — а это уже лучше.

#книги
Gwen Shapira - Kafka The Definitive Guide
06.04.2025 - 26.04.2025

Самая популярная книга по кафке мне не очень понравилась. Оказалось, что она всё же больше для администраторов и местами напоминает справочник, где приводятся параметры конфига с описанием большим, чем хотелось бы.

Что не понравилось:
1. Некоторые термины начинают использовать до их определения. Например Kafka Streams и Kafka Connect. То есть сперва в главах они упоминаются, а только потом объясняется, а что это всё же такое и зачем оно нужно. Kafka Stream упоминался в середине книги, а глава про него в конце. И даже в самой главе про Kafka Stream такое ощущалось. Например, сперва примеры "топологий", а к концу определение что такое топология..

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

3. Большая часть книги про администрирование кафки

Пора выпускать новую редакцию, где не будет речи про ZooKeeper, которого уже нет в кафке, да и с момента публикации текущего (второго издания) прошло уже почти столько, сколько между первым и вторым.

В общем книгу я бы поделил на две части, вторая для администраторов, а первая, которая меньше размером подойдет для разработчика. В ней главы про Producers, Consumers, Internals. Кстати, главу про internals я бы не назвал прямо internals, как-то поверхностно было.

На амазоне у книги довольно хороший рейтинг (4.6 - это прям хорошо) и у всех других книг по кафке он меньше, поэтому неясно, что можно выбрать вместо этой книги.

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

Для разработчиков я бы посоветовал вот это отличное видео:
https://www.youtube.com/watch?v=-AZOi3kP9Js (и тут больше internals, чем в главе книги!)

Новый метод в Go 1.25

В Go 1.25 для WaitGroup добавят метод Go, чтобы упростить распространённый паттерн:

func (wg *WaitGroup) Go(f func()) {
  wg.Add(1)
  go func() {
    defer wg.Done()
    f()
  }()
}

В РФ сейчас достаточно популярна тема со SBOM и вообще контролем зависимостей, потому что много каких зависимостей из open source оказывали и могут оказать деструктивное влияние так сказатб 🌝

Но тут случилось ВНЕЗАПНОЕ1!11!. Hunted Labs озаботились зависимостями, которые тянутся в проекты и обнаружили российский след (полный PDF-отчёт скину в комменты). Более того, как они пишут, отказаться от этой зависимости сложно. Речь о easyjson (https://github.com/mailru/easyjson)

What is easyjson?

Easyjson is a Go package designed to optimize JSON serialization and deserialization processes by generating Go code for JSON encoding and decoding. Widely adopted across cloud-native ecosystems, it is a critical dependency for numerous open source and enterprise projects. This includes high-performance JSON handling in distributed systems, real-time data serialization for financial and analytics platforms, and optimization of cloud-native applications.

Who maintains easyjson?

A group of developers from VK, an entity with leadership that is under active U.S. and E.U. sanctions and has connections to Russian security services.

Who is impacted?

Cornerstones of the modern software supply chain and cloud-native tools have dependencies on easyjson, and all applications that pull in these dependencies could potentially be impacted, including, but not limited to:

- Helm
- Istio
- Kubernetes

How could this be weaponized or exploited?

Russia doesn’t need to attack directly. By influencing state-sponsored hackers to embed a seemingly innocuous OSS project deep in the American tech stack, they can wait, watch, and pull strings when it counts.

The Russian Open Source Project That We Can’t Live Without
https://huntedlabs.com/the-russian-open-source-project-that-we-cant-live-without/

По ссылке подробно расписано как и зачем они занимались исследованием зависимостей и к чему пришли

Hunted Labs has provided exhaustive evidence regarding this advisory to the U.S. government and relevant stakeholders. So, what’s next? 

The widespread use of easyjson makes finding a solution challenging. However, we cannot continue to blindly rely on this package due to the state of the current threats to our increasingly fragile software supply chain.

Мне понравилась заключительная фраза в статье

> Oh, and we haven’t even talked about China…yet.

Сколько же их ещё открытий ждёт 🌝

GPT-4.1 доступна в ChatGPT — это ведущая модель в кодинге.

Модель превосходит GPT-4o по всем направлениям, особенно в кодинге. Плюс у нее более крупное контекстное окно — до 1 миллиона токенов.

«Это прекрасная альтернатива OpenAI o3 и o4-mini для повседневных задач программирования», - пишет OpenAI

Доступ уже раскатывают для всех платных подписчиков.

@xor_journal