Бэкенд

Хеш-таблица с транзакциями на Go

Привет, продолжим удивительное. Смех смехом, но на Go стали доступны:

1. Хеш-таблица с транзакциями.

2. Структуры данных второго порядка.

И в отличие от C++, они еще не создают проблемы для Garbage Collector. Вы угадайте почему, а я немного процитирую:

------------------8<------------------

Все выглядит примерно так:

func NewMemDb() MemDb { /* ... */ }

type MemDb interface {
    Close() error
    StartTrn() Transaction
}

type Transaction interface {
    Close() error

    Get(key Ptrsz) (Ptrsz, bool)
    All(getKeys bool, getVals bool) (keys []Ptrsz, vals []Ptrsz)

    Set(key Ptrsz, val Ptrsz)
    Del(key Ptrsz)

    DependVal(key Ptrsz, val Ptrsz)
    DependDel(key Ptrsz)

    Commit() error
    Rollback() error
}

А именно:

• Объект MemDb создается с помощью функции NewMemDb().

• У MemDb есть функция Close() -- мы ОБЯЗАНЫ ее вызвать!!!

• Объект Transaction создается с помощью функции StartTrn().

• У Transaction тоже есть функция Close(). Да, мы ОБЯЗАНЫ!

• Transaction работает с данными через lib.Ptrsz. Точно также, как и mdb.BlobMap.

• Чтение данных выполняется посредством функций Get() и All(). Возвращаемые ими Ptrsz указывают на внутренние структуры MemDb. Они остаются валидными пока не завершена транзакция и не было вызовов Set() и Del(), инвалидирующих указатели.

• Изменение данных выполняется посредством функций Set() и Del(). MemDb копирует себе байты, на которые указывают key и val.

• Функции DependVal() и DependDel() устанавливают зависимости. Их проверяет Commit().

• Функции Commit() и Rollback() завершают транзакцию. Завершают, но не закрывают! Мы ОБЯЗАНЫ вызвать Close()!!

• Просто Close() означает Rollback().

------------------8<------------------

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

Игра с огнём, или нулевой байт

В одном проекте заказчик потребовалось различать (и делать поиск) по трем состояниям текстового поля в Lucene индексе:

1. непустое значение (работает из коробки)

2. пустая строка "" (не поддерживается люсин)

3. null (не поддерживается люсин)

Lucene не хранит null и пустые строки "" - значения просто не индексируется. Для бизнес-логики, где нужно различать все три состояния, стандартных механизмов Lucene недостаточно.

Создание "специальных" замен в виде комбинаций типа "_null_" текста и спецсимволов - ломается тестерами которые пропускали различный мусор через индекс.

Был выбран компромиссный подход:

• "\0" (строка из нулевого байта) используется как маркер null

• "\0\0" (строка из двух нулевых байтов) используется как маркер ""

Пробило в холодный пот? Правильно, и меня тоже. Тем не менее, это рабочий способ.

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

Плюсы:

• \0 — это валидный символ в Java-строке, который практически не встречается в реальных данных.

• Символ \0 невозможно ввести напрямую из внешних систем, редакторов или форм без явного кодирования. Это защищает от случайных коллизий, даже если тестировщики пробуют «мусорные» символы.

• Таким образом достигается стабильное различие между null, "" и содержимыми строками.

Риски:

• Утечки наружу. Маркеры \0 могут попасть в API-ответы, логи, сериализацию. В нашем случае lucene был в обертке и поиск напрямую не использовался внешними системами - обработчик вызовов был инкапсулирован в прокси сервис.

Использование \0 и \0\0 как маркеров — это баланс между «желанием клиента» и технической безопасностью. Работает, но требует дисциплины: любая утечка этих символов превращает решение в источник трудноуловимых багов снаружи индекса.

RFC 9828: стандарт, который, странным образом, опоздал лет на двадцать

JPEG 2000, появившийся ещё в начале нулевых, давно используется в задачах, где требуется высокое качество изображения, а RTP как транспорт для данных реального времени уже более двадцати лет обеспечивает надёжность. Однако, и это удивительно, всё это время отсутствовал формализованный стандарт, позволяющий передавать JPEG 2000 с минимальной задержкой, по кускам кадра, не дожидаясь его полной готовности, — и лишь в 2025 году он был наконец принят. Можно только гадать, почему в мире, где запускают ракеты в космос по подписке, инженеры продолжали смиренно ждать, пока кадр целиком упадёт в буфер.

Теперь же, с появлением RFC 9828, ситуация меняется: простое на первый взгляд решение — передавать кадр частями, а не целиком, — становится официальной нормой. Как только кодер начинает производить данные, пакеты уже могут быть отправлены в сеть, а приёмник, не дожидаясь окончания всего кадра, начинает сборку изображения. И именно это означает, что впервые JPEG 2000 становится пригодным для таких сценариев, где маркетинговый термин «low latency» оборачивается критическим требованием: телевещание в прямом эфире, дистанционная хирургия или работа со сверхкачественным изображением в реальном времени.

Вместо прежнего порядка «сначала кадр, затем поток» появляется обратный — «сначала поток, затем кадр». Благодаря этому сеть получает ту самую гибкость, о которой раньше говорили как о недостижимой: лишние уровни разрешения и качества можно отбрасывать на лету, даже не вскрывая содержимое. Приёмник, в свою очередь, обретает resync-точки, благодаря которым потеря пары пакетов больше не превращается в катастрофу, а разработчики, наконец, могут избавиться от бесконечных костылей, изобретённых в обход RFC 5371.

Выгоды для бизнеса очевидны, хотя каждый сектор формулирует их по-своему. В телевидении по IP режиссёр теперь видит кадр практически сразу, а не спустя полсекунды, и значит — работа в реальном времени перестаёт быть фикцией. В медицине появляется возможность стримить эндоскопию или МРТ с качеством вплоть до lossless и при этом не терять драгоценные секунды, от которых зависит исход операции. Кинопроизводство перестаёт таскать гигабайты по дискам, потому что мастер-кадры наконец-то могут пересылаться по сети. Даже государственные сервисы, включая суды и видеоконференции, приобретают шанс выглядеть не как мем из 2008 года, а как инструмент XXI века.

Да, пока это лишь бумага. Но, как обычно бывает: сначала RFC, затем — первые SDK и FPGA-решения, а чуть позже — перепакованные в отраслевые документы SMPTE и ITU стандарты. В горизонте двух-трёх лет мы увидим первые реальные внедрения в телевидении и медицине, в горизонте пяти — широкое распространение. А дальше, возможно, даже lossless-видеозвонки без лагов перестанут казаться фантастикой.

RFC 9828 — это не просто ещё один формат. Это признание индустрии в том, что ждать конца кадра всё это время было, мягко говоря, глупо.

Ссылки, как обычно, в моём канале

——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура

Приглашаем на Java Jam — бесплатный митап ЮMoney для Java-разработчиков

Спикеры из ЮMoney и главный эксперт по технологиям Сбера расскажут о своём опыте и пообщаются с аудиторией. Вот какие темы будут на митапе:

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

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

🟣 Уязвимости не пройдут. Обсудим, как повысить безопасность разработки с помощью SAST и SCA.

25 сентября, в четверг, в 18:30 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн!

Подробности — на сайте митапа Java Jam 

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

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

Сетевая инфраструктура

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

Компьютерные сети

Пять статей помогут вам изучить основы компьютерных сетей. Они плавно, шаг за шагом, погрузят вас в тему. Сначала вы разберете ключевые понятия, чтобы говорить с сетевиками на одном языке. Затем — узнаете, какие бывают сети и из чего они состоят, что такое MAC- и IP-адреса. Далее — освоите две основные модели: OSI и TCP/IP — на конкретных примерах посмотрите, как работает каждый уровень.

CDN

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

Сетевая безопасность

Эта подборка сфокусирована на сетевой ИБ: межсетевые экраны и IDPS, средства шифрования трафика и DDoS-атаки. Теорию вы закрепите практикой, самостоятельно установив и настроив файрвол или проведя сканирование портов по инструкции.

Сетевые протоколы

В мире существует более 7 000 сетевых протоколов. В 12 материалах вы узнаете о самых популярных из них, а также о существующих сетевых моделях передачи данных.

Уже неоднократно и не только на Хабре жаловался на мелочность работодателей в объявлениях и ненужности указания всех библиотек, технологий и даже их версий. Сегодня в LinkedIn увидел предельный случай - ищут Java профессионала, который "strong in JSON,...". Факин JSON! Зa сколько учится этот формат? Секунд за 30? А если с возможностями формальной проверки на правильность содержания, то минут за 15? Зачем кто-то вообще указывает такие мелочи, как JSON, в описании требований к вакансии? И так со всем. Вместо принципиальных технологий пишут конкретные реализации и даже их версии. Зачем? Зачем?... Ничего не ответила золотая рыбка)

Какая должна быть длина у функций?

Щас скажу кое-что неочевидное. На эту проблему нельзя смотреть в статитке. Вот правильно 4 строки, 10, 100, поэтому разбиваем как-только доходим до предела. Я смотрю на это в динамике.

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

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

Есть такой архитектурный принцип, что принятие ключевых решений нужно откладывать как можно дольше (пока не накопится достаточно кейсов и понимания). Да, при этом надо учитывать, что можно слишком затянуть, но на уровне функций, все же сложно довести систему до состояния невозможности рефакторинга.

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

p.s. Смог тут загуглить исследование сотен миллионов строк на гитхабе: https://arxiv.org/pdf/1806.04556 (на скрине выдержка)

Больше про разработку в моем телеграм-канале Организованное программирование

Про сеть и инфраструктуру RUTUBE в подкасте linkmeup

В этом выпуске Эльдар Ниязов, директор департамента развития и эксплуатации ИТ-инфраструктуры RUTUBE, рассказывает об устройстве видеохостинга, ЦОДах, сетях и делится историями, которые не вошли в доклад об архитектуре.

Из видео узнаете:

• Сколько нужно серверов, чтобы построить национальный видеохостинг.

• Сколько легаси осталось от прошлых итераций (спойлер: совсем мало).

• Как пережить взрывной рост и с какими ещё вызовами сталкивается команда.

• Где живёт RUTUBE.

• Зачем понадобилось написать собственный S3 (а более подробно о том, как устроено хранилище — в этом видео).

• Как оптимизируется CDN и многое другое.

Как видно на превью, это интервью было записано на конференции HighLoad++. Следующая встреча разработчиков высоконагруженных систем уже не за горами и там снова выступят специалисты из RUTUBE — в этом году фокус на ML:

• «Как RAG ускоряет поддержку RUTUBE: от гибридного поиска до мониторинга галлюцинаций». Виктор Леньшин объяснит, как устроена архитектура системы, которая уже в 80% случаев генерирует готовый ответ на запрос в поддержку.

• «Платформа для создания субтитров на весь UGC в RUTUBE». Дмитрий Лукьянов расскажет, как платформа сейчас обрабатывает новые видео почти без задержек, справляется с экстремально длинными записями и не привирает на музыке, шумах и спецэффектах.

Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активов «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.

Вышла новая версия пакета easyjson - 0.9.1, содержит исправления выявленных ошибок.

Пакет easyjson предоставляет быстрый и простой способ маршалинга/демаршалинга структур Go в/из JSON без использования рефлексии. Фундамент - кодогенерация.

В тестах производительности easyjson превосходит стандартный пакет encoding/json в 4-5 раз, а другие пакеты работы с JSON — в 2-3 раза.

Easyjson стремится сделать сгенерированный код Go достаточно простым, чтобы его можно было легко оптимизировать или исправить. Вторая цель — предоставить пользователям возможность настраивать сгенерированный код, предоставляя функции, недоступные в стандартном пакете encoding/json, такие как генерация имён в формате «snake_case» или включение поведения omitempty по умолчанию.

GitHub: https://github.com/mailru/easyjson

Подробности исправления: https://github.com/mailru/easyjson/pull/423

20 вакансий у нас в SSP SOFT

Привет всем хабровцам! Мы регулярно публикуем посты о наших вакансиях, включая 1С и DevOps.

Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224.
Но откликаться на портале хх необязательно — внизу дадим прямые контакты с нашим HR.

Рабочие места в офисах в Москве (топ локация в ЦАО у Красной площади) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.

Вот примеры вакансий 1С и девопс — остальные 20 штук на см. на хх.ру:

1️⃣ Разработчик 1С (https://vk.cc/cPyro8)
2️⃣ Ведущего разработчик 1С (ERP, УХ) (https://vk.cc/cPyroI)
3️⃣ DevOps-инженер (https://vk.cc/cPyrpq)

👉 В SSP SOFT мы рассматриваем найм с прицелом на долгосрочную совместную работу. Многие сотрудники у нас работают по 5 лет и более.

Резюме можно направить нам напрямую в Telegram или на почту job@ssp-soft.com.

А для ускоренного рассмотрения пож-та отправляйте резюме HR-ру в Телеграм с пометкой "Нашел(ла) вас на Хабре", приложив сопроводительное письмо.

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

На самом дне MCP — транспорт. Тут нет никакой магии: JSONRPC. Его работа — просто донести пакет от клиента до сервера и обратно. Запросы, ответы, нотификации, ошибки — всё аккуратно упаковано, но без бизнес-смысла.

Дальше идут данные. Со стороны сервера это Resources, Prompts, Tools. Resources управляют файлами, базой, API-ответами и прочим контекстом, который нужен ИИ-приложениям. Внутри этого — Content: текст, картинки, аудио, бинарь, блоки. Prompts описывают доступные подсказки и параметры. Tools — это исполняемые функции, которыми сервер делится с клиентом, от файловых операций до API вызовов.

Со стороны клиента данные другие. Sampling.Complete позволяет серверу дёрнуть LLM клиента без встроенного SDK. Elicit даёт возможность уточнить что-то у пользователя: параметры, подтверждения, ввод. Logging отправляет обратно логи и диагностику.

Есть и служебный слой: Initialize для рукопожатия, Capabilities для описания возможностей сторон, плюс сервисные штуки вроде уведомлений о прогрессе, подписок/отписок и отмен операций.

В итоге MCP — это не просто «реестр» инструментов, а полноценный протокольный шлюз. Сервер экспонирует ресурсы и инструменты, клиент решает, что из этого реально использовать. Баланс тот же: удобство для разработчиков серверов и полный контроль у пользователя.

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

Ну а чтобы вам не было скучно, я приложу сравнение протоколов, дабы можно было понять роль MCP относительно других

Про вайб и прочих ИИ агентов в ретроспективе "лихих 90-х"

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

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

Будучи разработчиком одной из небрендовых ERP-систем, приходилось участвовать в предпродажных сессиях. Ярким воспоминанием остались контакты с "девопсом" потенциальных клиентов. Никаких "девопсов", конечно, тогда не было: инфраструктурой или, как иногда говорят, "ландшафтом" занимались системные администраторы, инженеры и ДБА.

Приходишь на презентацию, и видишь суровые скептические лица сисадминов, которые, не скрывая чувств, заявляют нечто вроде: "Жаль, времени нет, а то мы бы сами на Delphi за выходные написали бы, то что вы нам за деньги предлагаете..."

Когда сейчас натыкаешься на очередную "джинсу" по вайбкодингу и прочему агентскому клепанию "типа софта", нередко выясняется, что авторы - спецы в инфраструктуре. И тогда сразу становится ясен смысл написанного: "Да мы сами на выходных на Delphi сделаем, то что вы нам за немереные деньги пытаетесь впаривать".

Почему корпоративы не оплачиваются как сверхурочная работа?

Товарищи. Снова эксплуатируют - но уже не нас, а наши страсти, чтобы потом эксплуатировать и нас. Давайте разбираться.

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

Что остается корпорациям, как не прибегнуть к страстям? У нас у всех есть свои интересы: кто-то любит играть в настолки, кто-то - на музыкальных инструментах или на басу, кто-то - бокал вина. И корпоративная мысль ловко этим пользуется, превращая личные увлечения в инструмент сближения. Они устраивают корпоративы - "хлеба и зрелищ" в миниатюре.

Но давайте вспомним, сколько сил наши предшественники потратили на то, чтобы у нас был восьмичасовой рабочий день и оплачиваемые переработки. И вот мы снова тратим личное время - теперь на корпоратив. Чтобы через наши же страсти уменьшать трение и создавать иллюзию близости. Этакая социальная смазка. Только вот смазка какая-то сомнительная... На деле это просто плевок. И если вам говорят, что это ради команды, помните: это ваше личное время. А личное время стоит денег. А сверхурочное время двойных денег!

Конкурс open source проектов, которые способны изменить мир 🌏🖥️

Зовем вас на «Код без границ» — грантовую программу для развития open source проектов, которую совместно с Cloud.ru и Хабром подготовили GitVerse. Поделитесь своими разработками на GitVerse, получите шанс выиграть 💸💸💸 и получить поддержку в масштабировании идеи.

Номинации конкурса:

• AI-инновации.

• Наука и образование без границ.

• Для всех и каждого (приложения и сервисы).

• Разработка для разработчиков — инструменты и библиотеки.

Как участвовать? Рассказываем:

1. Разместите репозиторий вашего проекта на GitVerse или импортируйте его с другой git-площадки.

2. Подайте заявку до 31 октября. В ней должна быть ссылка на уже размещенный конкурсный проект.

3. Подождите, пока жюри — опытные спецы из СберТеха (GitVerse), Сбера, Cloud.ru и лидеры отрасли — посмотрят работы и выберут финалистов.

4. Узнайте результаты в декабре.

Что по призам и плюшкам?

• Гранты 150, 100 и 50 тысяч рублей — для первого, второго и третьего места.

• Облачные ресурсы Cloud.ru для реализации ваших масштабных идей.

• Помощь с масштабированием проекта, поддержка экспертов и нетворкинг.

Регистрируйтесь, принимайте участие и покажите силу открытого кода 💪

Парсинг чатов Телеграм

Всем привет. Позвольте показать вам как скачать содержимое чата Телеграм к себе на ПК, включая сообщения.

Нам понадобится скачать программу OpenTgResearcher. Исходные коды лежат на ГитХаб. Комьюнити лицензию можно получить бесплатно в автоматическом режиме через меню программы. Скачать можно стабильный релиз, либо самую новую превью версию в разделе релизов. Есть несколько вариантов установки: консольная версия (кроссплатформенная), докер версия (для продвинутых), десктоп версия (под Windows).

Установим десктоп версию. Для этого нам понадобится дистрибутив. В списке файлов релиза найдите OpenTgResearcherDesktop‑win‑x64-Setup.exe (64-разрядная архитектура ПО). Браузер может запросить разрешение на скачивание и сохранение файла, а также предупредить, что файлы редко скачиваются. После чего, Windows предупредит вас, что файл скачан из интернета и спросит разрешение на установку. Для проверки дистрибутива на вирусы можете воспользоваться онлайн сервисом проверки VirusTotal. По завершении установки ПО вы должны увидеть загрузочную страницу. Из которой вы можете попасть на главную страницу.

Поздравляю, вы справились! Теперь необходимо настроить локальные каталоги. В главном меню слева выбираем Settings. В них вы можете задать путь к хранилищу (Storage: c:\OpenTgResearcher\TgStorage\TgStorage.db) и путь к файлу сессии(Session: C:\Users\<userName>\AppData\Local\OpenTgResearcherDesktop\current\OpenTgResearcher.session). После чего, сохраняем настройки и закрываем ПО, запускаем заново.

Итак, у нас есть локальное хранилище и путь к файлу сессии. Теперь нам необходимо получить авторизацию от самого Телеграм и сохранить сессию. Для этого, в главном меню слева открываем Client connection. Кликаем по ссылке my.telegram.org, в открывшейся странице браузера, вводим свой номер телефона, код авторизации получаем в боте Telegram Service Notifications. Далее, мы заполняем поля App title, Short name. Выписываем поля App api_id, App api_hash. Переходим обратно в OpenTgResearcher и заполняем поля API hash, API ID, Phone number. Эти данные сохранятся в локальном хранилище в таблице APPS. Если вы используете пароль, то заполните поле Password (это поле не сохраняется в таблице, если сессия протухнет, придётся вводить заново). После чего нажмите кнопку Connect to TG server. Возможно, к вам снова придёт код авторизации, в таком случае, его необходимо скопировать и вставить в поле Login code. После чего снова нажать Connect to TG server. В случае успеха — поле Connection state изменит своё положение на крайнее правое и описание рядом Client is connected, а также заполнятся остальные поля блока Settings without saving. В случае ошибок, смотрим содержимое поля Data request и запрашиваем помощь в Телеграм группе.

Что дальше? Просканируем доступные каналы и группы. Для этого в главном меню слева кликнем по меню Chats. Изначально список будет пуст. Заполним его, кликнув по кнопке Online update. Вы увидите прогресс парсинга ваших чатов. Сверху отображается текущий статус чтения, сколько чатов всего. Снизу отображается защитный механизм Телеграм — Flood Control. После определённой порции данных, Телеграм просит подождать несколько секунд, эта информация обновляется автоматически. По завершении парсинга, можно открыть любой чат, дважды кликнув по строке с именем. В открывшейся странице деталей чата настроим каталог для сохранения медиа (Directory). Если чат содержит темы, то можете включить переключатель Creating subdirectories. Если нам нужны комментарии - включите переключатель Parsing comments. Далее сохраним настройки — Save chat settings. Поздравляю, всё готово для скачивания — жмём кнопку Online update. Запустится процесс скачивания медиа и парсинга сообщений. В случае отмены — нажмите кнопку Stop download. Прогресс отображается в строках Message и Media.

Это мой первый пост на хабре. Оставляйте свои комментарии и пожелания.

Как обещал, написал простой, но легко расширяемый торговый бот, использующий ML-сигналы от API AIgnal.tech.

Репозиторий: aignal-trading-bot

Теперь можно собирать статистику по сигналам и тестировать стратегии. Участвовать в реальной торговле, конечно же, не обязательно.

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

А я продолжаю допиливать API для доставки следующих инструментов.

Go + Windows = deadlock. Свет в конце тоннеля.

В прошлой статье я рассказывал о редком, но весьма опасном баге: поток под Windows зависал в вызове CancelIoEx, хотя документация Microsoft утверждает обратное. Суть проблемы — в пересечении синхронного и асинхронного ввода-вывода, где ядро Windows блокирует доставку APC, и поток остаётся навсегда «висящим».

История получила развитие не сама по себе: мы целенаправленно поднимали эту тему через support-кейс в Microsoft. В результате удалось подключить и Escalation Team, и разработчиков Go, ответственных за Windows-порт.

Финальный вывод: стандартная библиотека Go действительно использует неправильный API для отмены синхронных операций. Вместо CancelSynchronousIo, рекомендованного самой Microsoft, в коде до сих пор вызывается CancelIoEx.

👀 Сам проблемный вызов:
https://github.com/golang/go/blob/77f911e31c243a8302c086d64dbef340b0c999b8/src/internal/poll/fd_windows.go#L461

Хорошая новость: у команды уже есть рабочий proof-of-concept фикса:
https://go-review.googlesource.com/c/go/+/691395

Менее радостная часть: из-за сложности изменений и их влияния на рантайм правка запланирована только в Go 1.26 (февраль 2026). Бэкпорт в предыдущие версии практически исключён.

Что это значит для разработчиков

• Если ваш сервис на Go под Windows внезапно «зависает» в CancelIoEx — это следствие бага в стандартной библиотеке, а не ваша ошибка.

• До релиза Go 1.26 остаются обходные варианты:

  • не вызывать CancelIoEx для синхронных дескрипторов,

  • использовать CancelSynchronousIo, если есть возможность управлять потоками,

  • минимизировать использование пайпов в критичных местах.

Итог

Редкий flaky-тест Go (TestPipeIOCloseRace) оказался симптомом реальной и серьёзной проблемы. Благодаря эскалации через Microsoft Support и совместному разбору мы получили подтверждение, понятное объяснение и официальный фикс в планах.

⚡️ Если ваш Go-код на Windows зависает в CancelIoEx, теперь вы знаете: проблема признана и исправление уже в пути.

Посткапитализм и open source: как свободный код меняет экономику

Пол Мейсон в книге «Посткапитализм: путеводитель по нашему будущему» выдвигает радикальную мысль: информационные технологии не просто трансформируют капитализм, они постепенно подрывают его изнутри. В центре этой трансформации - феномен open source и совместного производства.

Нулевая стоимость копирования

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

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

Википедия, Linux, Firefox

Мейсон иллюстрирует свои тезисы примерами:

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

• Linux показал, что даже сложнейшие операционные системы можно развивать децентрализованно, без корпоративной иерархии.

• Firefox доказал, что независимые сообщества способны конкурировать с монополистами вроде Microsoft.

Даже Android, который Google и Samsung коммерциализировали, остаётся вынужденно открытым в своей основе, иначе он потерял бы ту самую энергию сообществ, которая сделала его популярным.

Производство «на равных»

Открытый код - это не благотворительность, а новая форма организации труда. Мейсон называет её «одноранговым производством на равных». Люди участвуют в проектах не ради зарплаты, а потому что хотят сотрудничать, обмениваться знаниями, решать задачи и оставлять след в истории. Здесь мотивация выходит за пределы классического «экономического эгоизма», а деньги перестают быть главной мерой ценности.

Это уже сегодня создаёт «островки посткапитализма» внутри старой системы. Там, где действуют сообщества разработчиков, привычные границы между трудом и хобби, бизнесом и добровольчеством размываются.

Конфликт с капитализмом

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

И даже корпорации вынуждены адаптироваться. Microsoft, когда-то называвшая Linux «раком», сегодня является одним из крупнейших контрибьюторов в open source и владельцем GitHub. Google построила свою мобильную империю на открытом ядре Linux. Это не благотворительность, а прагматизм: чтобы оставаться конкурентоспособными, они вынуждены взаимодействовать с «всеобщим интеллектом», используя его и внося свой вклад. Тем самым, даже против своей воли, они легитимизируют и усиливают нерыночные принципы.

«Всеобщий интеллект» и новая экономика

Здесь Мейсон обращается к Марксу и его «Отрывку о машинах». Маркс ещё в XIX веке писал, что по мере развития индустрии главным производительным фактором становится не труд отдельного рабочего, а знание. Коллективное знание, или «всеобщий интеллект», невозможно адекватно оценить в рыночных терминах. Оно разрушает сам фундамент капитализма, который строится на частной собственности и измеримой стоимости.

Вместо итога

Книга Мейсона предлагает интересную перспективу: рассматривать свою деятельность в open source не просто как хобби или способ профессионального развития, а как участие в формировании принципиально нового типа экономических отношений.

Автор: Михаил Шардин
🔗 Моя онлайн‑визитка
📢 Telegram «Умный Дом Инвестора»

13 сентября 2025

Привет, Хабр!

Я навайбкодил Вам систему управления отчетами на 100500 Jupyter ноутбуков

Расскажу историю о том, как я решил проблему с хаосом в Jupyter-отчетах и создал систему juport (Jupyter Report System) ссылка на GitHub. А заодно поделюсь мыслями о том, как меняется разработка в эпоху AI-ассистентов.

Проблема: 100500 отчетов и никакого порядка

У меня накопилось огромное количество отчетов, сделанных в Jupyter Lab. Каждый — отдельный файл с кодом, паролями и прочей «кухней».

Главные проблемы:

• Безопасность. Нельзя просто так поделиться отчетом с руководством или бухгалтерией, потому что там есть доступы к базам и код.

• Рутина. Нет централизованного места для запуска отчетов, автоматизации по расписанию и единого интерфейса для просмотра.

• Хаос. Все результаты разбросаны по папкам, и чтобы найти нужный Excel-файл, приходилось долго копаться.

Концепция решения

Нужно было что-то, что позволит разрабатывать отчеты в привычном Jupyter Lab, а потом автоматически запускать их, генерировать чистые HTML-версии без кода и собирать все артефакты в одном месте.

Решение: juport — система управления отчетами

Я создал систему (ну как сам, навайбкодил), состоящую из двух компонентов:

1. Jupyter Lab Sidecar. Это обычный Jupyter Lab в Docker-контейнере. Здесь разработчики пишут и тестируют отчеты, как привыкли.

2. juport — система управления. Веб-приложение на Python, которое сканирует папку с ноутбуками. Оно позволяет запускать отчеты вручную или по расписанию, выполняет их в изолированном окружении, генерирует HTML-версии без лишней информации, собирает все артефакты (Excel, картинки) в одну табличку и предоставляет удобный веб-интерфейс. Авторизация — через LDAP.

Как это работает

Разработка отчета:

1. Вы создаете ноутбук в Jupyter Lab.

2. Пишете код, тестируете, сохраняете.

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

Запуск отчета:

1. Заходите в веб-интерфейс juport.

2. Видите список всех ноутбуков.

3. Нажимаете «Запустить» или настраиваете расписание.

4. Система выполняет ноутбук и собирает результаты.

Результат:

• Чистый HTML-отчет без кода и паролей, доступный для просмотра.

• Все Excel-файлы, картинки и PDF собраны в одном месте.

• Удобный интерфейс для скачивания.

• История выполнений и логи.

Как это сделано

Я не написал ни одной строчки кода сам. Все навайбкодил через Cursor с помощью промптов.

Да, именно так. Привыкайте. Такова реальность.

Андрея Карпатый говорил о том, что скоро разработка будет выглядеть совсем иначе. И он прав.

Мы, миллениалы, единственное поколение, которое разбиралось, как собрать компьютер с нуля. Бумеры были до бума ПК, а зумеры уже родились, когда все было готово. С кодом происходит то же самое. Через N лет опытные разработчики будут получать отличные результаты через промпты, потому что у них есть 20 лет опыта. Этот опыт — не знание синтаксиса, а понимание:

• Архитектурных паттернов

• Принципов проектирования

• Торговых компромиссов

• Потенциальных проблем

Именно поэтому те, кто шарит, получат отличный результат, а те, кто не шарит, получат «коричневую субстанцию».

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

Выводы

1. AI-ассистенты — это не замена, а инструмент.

2. Опыт и понимание архитектуры становятся критически важными.

3. Скорость разработки для опытных специалистов вырастет в разы.

4. Новичкам придется приложить больше усилий для освоения профессии.

А как вы видите будущее разработки с AI? Делитесь в комментариях!

CI/CD — это не больно! Разбираем 5 шагов к эффективности

Знакомо чувство, когда пайплайн ломается в самый неподходящий момент, а процесс поставки кода больше напоминает полосу препятствий? Мы в Слёрме знаем, что эффективный CI/CD — это не про количество стадий в Jenkins, а про выстроенную систему. Она экономит время, нервы и делает ваш продукт значительно лучше.

Мы разработали чёткий план из 5 ключевых шагов для построения таких процессов, и приглашаем вас на бесплатный вебинар, где разберём каждый из них.

На вебинаре вы получите практический план действий по каждому этапу:

• Осознание. Покажем, как правильно собрать запрос с разработчиков и сформулировать — «а что нам, собственно, нужно от этого чудо-пайплайна?»

• Создание. Обсудим, на чём можно строить и как избежать типичных архитектурных костылей

• Безопасность. Разберём, как «зашить» проверки безопасности на всех этапах, не превратив его в неподъёмного монстра

• Шаблонизация. Расскажем, как создавать процесс для упрощения поддержки и масштабирования через шаблоны. Вы забудете про копипасту и рутину

• Пайплайн как сервис. Вечный процесс улучшения и адаптации, а не ваша личная головная боль

Когда: 17 сентября в 19:00 мск

Спикеры — менторы курса «DevOps Upgrade»:

⚡️Вячеслав Федосеев, TeamLead DevOps в «Честном Знаке»

⚡️ Евгений Федосеев, DevOps-инженер в «Пульс АЙТИМ»

Занять место на вебинаре — через бота. Ждём вас!