Вчера я говорил о паузе в публикациях, но жизнь внесла коррективы.
Вместе с DeepSeek мы нашли идеальную тему для статьи, которая, думаю, будет полезна многим разработчикам.
О чём будет статья:
Честный разбор причин провала одного из моих ключевых проектов
Фокус на архитектурных ошибках, а не на предметной области
Анализ того, как over-engineering может убить даже перспективную идею
Конкретные примеры и выводы, которые помогут избежать подобных ошибок
Важный момент: хотя проект связан с Фидонетом, статья будет исключительно о технических решениях и их последствиях. Фидонет здесь — лишь контекст, а не основная тема.
Когда ждать: сегодня в 10:00 по московскому времени.
Не пропустите — обещаю, будет интересно и максимально полезно с практической точки зрения!
Давайте честно: каждый хоть раз мечтал о работе из дома. Никаких пробок, можно самостоятельно выстраивать график и работать прямо в пижаме (пока никто не видит).
Хорошие новости: для IT-специалистов это не мечта, а обычная практика. А у нас тут как раз есть крутая подборка профессий: выбирайте, чему хотите научиться, и вперёд — к удалёнке.
Английский язык один, а вот цели его изучения — разные: кому для рабочих переговоров, кому — сериальчики смотреть в оригинальной озвучке. Мы это учли и собрали курсы под самые разные задачи, чтобы вы могли прокачать именно тот навык, который вам нужен.
Короче, учиться — это классно, главное — курс выбрать толковый. Особенно когда речь идёт о сфере, которая в топе востребованных профессий — DevOps. А чтобы было проще стартануть, держите список самых нужных инструментов для изучения.
— Docker. Упаковываем приложения в контейнеры и запускаем их где угодно.
— Kubernetes. Управляем кластерами контейнеров и автоматизируем их работу.
— CI/CD. Обеспечиваем быстрые и стабильные релизы с помощью автоматизированных пайплайнов.
Новый поток DevOps Upgrade стартует в понедельник. Рассказываем про ключевое обновление курса
Рынок DevOps продолжает активно расти, а требования к специалистам — повышаться. Чтобы оставаться востребованным, важно постоянно актуализировать свои знания. Почему сейчас — лучшее время для этого?
В понедельник стартует новый поток DevOps Upgrade, и вот, какое обновление мы внедрили на курсе:
У каждого, кто присоединится к тарифу «Комфорт» до 29 сентября, будет свой личный консультант. Это персональный наставник, который фокусируется на образовательной стратегии студента. Его ключевые задачи:
✅ Индивидуальный подход Помощь в постановке персональных учебных целей и контроль их достижения.
✅ Мониторинг прогресса Тьютор следит за соблюдением дедлайнов и помогает сохранить мотивацию на протяжении всего курса.
✅ Разработка карьерной стратегии Совместно со студентом он выстраивает план развития в DevOps с учетом личных амбиций и целей.
✅ Всесторонняя поддержка Проведение 2-4 индивидуальных встреч для рефлексии и корректировки учебного процесса под ритм жизни студента.
Дополнительный бонус: для всех, кто выберет тариф «Комфорт» до старта потока в понедельник, мы предоставляем возможность бесплатного перехода на следующий поток в случае непредвиденных обстоятельств.
DevOps Upgrade — это инвестиция в карьеру, которая теперь включает не только актуальные технические знания, но и персональную поддержку на всех этапах обучения.
Старт потока — уже в понедельник. Успейте присоединиться!
⏩ Узнать подробности о курсе и зарегистрироваться можно на сайте
Немного лекций с нашего митапа питонистов в Новосибирске - PythoNSK (https://t.me/python_in_nsk приходите, в ноябре планируем вторую встречу организовать).
Привет, Хабр! На связи Ольга, в Хайстекс я занимаюсь развитием бизнеса и корпоративных связей. В блоге компании мы опубликовали перевод статьи с отличным примером того, как управляемые облачные сервисы перестают быть только техническим инструментом и становятся стратегическим фактором даже там, где главная ценность бизнеса — люди и их экспертиза.
В статье рассматривается кейс SkillGigs, сервиса для подбора специалистов в сфере здравоохранения и технологий. Управляемые облачные сервисы позволили внедрить 3D-резюме, выстроить мультиоблачную архитектуру, обеспечить безопасность и упростить интерфейс для пользователей. Результат: поиск стал быстрее, рекомендации — точнее, а процесс найма удобнее. Этот пример хорошо показывает, что облако — это уже не просто «поддержка инфраструктуры», а реальный драйвер бизнеса.
Статья не перегружена кейсами, в ней собраны ключевые выводы и один практический пример. Хороший повод пересмотреть своё отношение к облачным сервисам и понять, где они реально дают бизнес-эффект.
# transform.py
def calculate_age(birth_date, row_data, table):
from datetime import datetime
if not birth_date:
return None
birth = datetime.strptime(birth_date, '%Y-%m-%d')
return (datetime.now() - birth).days // 365
def format_phone(phone, row_data, table):
if not phone:
return None
# 79991234567 -> +7 (999) 123-45-67
return f"+7 ({phone[1:4]}) {phone[4:7]}-{phone[7:9]}-{phone[9:11]}"
Запуск
# Установка с GitHub
pip install git+https://github.com/tumurzakov/myrepetl.git
# Или клонировать и установить локально
git clone https://github.com/tumurzakov/myrepetl.git
cd myrepetl
pip install -e .
# Запуск с конфигом
myrepetl run config.json
# Или через Docker
docker run -v ./config.json:/app/config.json myrepetl:latest
Чтение данных выполняется посредством функций Get() и All(). Возвращаемые ими Ptrsz указывают на внутренние структуры MemDb. Они остаются валидными пока не завершена транзакция и не было вызовов Set() и Del(), инвалидирующих указатели.
Изменение данных выполняется посредством функций Set() и Del(). MemDb копирует себе байты, на которые указывают key и val.
Функции DependVal() и DependDel() устанавливают зависимости. Их проверяет Commit().
Функции Commit() и Rollback() завершают транзакцию. Завершают, но не закрывают! Мы ОБЯЗАНЫ вызвать Close()!!
Просто Close() означает Rollback().
------------------8<------------------
Вот, кстати, полный текст статьи, но там почти что невозможно обнаружить ссылку на исходники... Ага, не раз такое видел в комментариях!
В одном проекте заказчик потребовалось различать (и делать поиск) по трем состояниям текстового поля в Lucene индексе:
непустое значение (работает из коробки)
пустая строка "" (не поддерживается люсин)
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 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн!
Подборка бесплатных обучающих материалов для тех, кто хочет разобраться в сетях
Привет, Хабр! Я снова с подборкой статей, которые могут пригодиться начинающим специалистам. На этот раз будем разбираться в сетях. Как обычно, все материалы в подборке доступны бесплатно, никакими данными делиться тоже не нужно. Просто читайте и осваивайте новое. Поехали!
Сетевая инфраструктура
Эта подборка — практическое погружение в мир сетей и облачной инфраструктуры. Вы научитесь настраивать базовые сетевые схемы, поднимать выделенные и облачные серверы, разбираться в связанности, публичных 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, поэтому разбиваем как-только доходим до предела. Я смотрю на это в динамике.
Когда мы только что-то пишем и это не очевидная абстракция вроде проверки числа на простоту, то разбивать на функции не надо, до тех пор пока вы не начнете упираться во что-то начиная от необходимости повторного использования (а значит выделения доп абстракций) до большого количества состояний, которые делают анализ функции слишком сложным. Какой при этом получится размер? Да хрен его знает, в реальной жизни функции бывают очень разные, это легко проверить если походить по опенсорсу на гитхабе. И мы говорим про очень успешные продукты и проекты.
Главное здесь не размер, а то что существует закон распределения, который звучит так: не распределяй. Рефакторить монолит в подавляющем большинстве случаев проще, чем рефакторить распределенную систему будь то функции, компоненты реакта или микросервисы. И когда мы пишем что-то новое, не важно это либа с функциями внутри или сервис с возможными микросервисами внутри, мы изначально не знаем во что это выродится и с какими проблемами мы столкнемся. И слишком ранее разбиение может привести к тому, что придется переписывать все, либо будем страдать, потому что уже поздно.
Есть такой архитектурный принцип, что принятие ключевых решений нужно откладывать как можно дольше (пока не накопится достаточно кейсов и понимания). Да, при этом надо учитывать, что можно слишком затянуть, но на уровне функций, все же сложно довести систему до состояния невозможности рефакторинга.
Поэтому если мы пишем что-то новое, где мы не до конца понимаем все текущие или будущие кейсы, лучше не пытаться все разносить до минимума, достаточно выносить только самые больные очевидные технические элементы. А вот дальше, в процессе работы, доуточнения и отработке пограничных случаев, пожалуйста, мы можем разбивать и разбивать в соответствии с получаемыми смыслами.
Про сеть и инфраструктуру RUTUBE в подкасте linkmeup
В этом выпуске Эльдар Ниязов, директор департамента развития и эксплуатации ИТ-инфраструктуры RUTUBE, рассказывает об устройстве видеохостинга, ЦОДах, сетях и делится историями, которые не вошли в доклад об архитектуре.
Из видео узнаете:
Сколько нужно серверов, чтобы построить национальный видеохостинг.
Сколько легаси осталось от прошлых итераций (спойлер: совсем мало).
Как пережить взрывной рост и с какими ещё вызовами сталкивается команда.
Где живёт RUTUBE.
Зачем понадобилось написать собственный S3 (а более подробно о том, как устроено хранилище — в этом видео).
Как видно на превью, это интервью было записано на конференции 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 по умолчанию.
Привет всем хабровцам! Мы регулярно публикуем посты о наших вакансиях, включая 1С и DevOps.
Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224. Но откликаться на портале хх необязательно — внизу дадим прямые контакты с нашим HR.
Рабочие места в офисах в Москве (топ локация в ЦАО у Красной площади) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
Вот примеры вакансий 1С и девопс — остальные 20 штук на см. на хх.ру:
В прошлой заметке я писал про сервер и клиент, а теперь хочу копнуть глубже и пройтись по составу протокола. Это будет чуть упрощённая версия, чтобы не утонуть в спеке, но картинка станет понятнее.
На самом дне MCP — транспорт. Тут нет никакой магии: JSONRPC. Его работа — просто донести пакет от клиента до сервера и обратно. Запросы, ответы, нотификации, ошибки — всё аккуратно упаковано, но без бизнес-смысла.
Дальше идут данные. Со стороны сервера это Resources, Prompts, Tools. Resources управляют файлами, базой, API-ответами и прочим контекстом, который нужен ИИ-приложениям. Внутри этого — Content: текст, картинки, аудио, бинарь, блоки. Prompts описывают доступные подсказки и параметры. Tools — это исполняемые функции, которыми сервер делится с клиентом, от файловых операций до API вызовов.
Со стороны клиента данные другие. Sampling.Complete позволяет серверу дёрнуть LLM клиента без встроенного SDK. Elicit даёт возможность уточнить что-то у пользователя: параметры, подтверждения, ввод. Logging отправляет обратно логи и диагностику.
Есть и служебный слой: Initialize для рукопожатия, Capabilities для описания возможностей сторон, плюс сервисные штуки вроде уведомлений о прогрессе, подписок/отписок и отмен операций.
В итоге MCP — это не просто «реестр» инструментов, а полноценный протокольный шлюз. Сервер экспонирует ресурсы и инструменты, клиент решает, что из этого реально использовать. Баланс тот же: удобство для разработчиков серверов и полный контроль у пользователя.
В следующей заметке можно будет разобрать, как все эти части складываются в реальную работу: от того, как сервер отдаёт ресурсы, до того, как клиент подтверждает вызовы LLM.
Ну а чтобы вам не было скучно, я приложу сравнение протоколов, дабы можно было понять роль MCP относительно других
