Kurgan-Telecom Ru | Информационные технологии

Нет лучше способа в чем-то разобраться, чем написать свою реализацию.

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

Много раз проскакивало желание у многих получить простой инструмент, позволяющий следить за истекающими сертификатами SSL. Ниже представляю инструмент для самостоятельного развертывания в среде docker.

Код написан для python14, но работать будет и на других версиях (12, 13, 14 и т.д.).

Что включает проект (все в одном):

Привет, я Максим Королев из Петрович-ТЕХа. В предыдущей статье рассказывал, как мы сделали семейство Telegram-ботов для ITSM. Один из ключевых - «Дежурный»: с ним администраторы фиксируют аварии, регламентные работы и прочее, создают задачи в Jira, публикуют уведомления в каналы и в интранет компании.

И тут Telegram ограничивают. Когда у дежурного в разгар аварии «не грузится телега» - это риск для бизнеса. Нужно было срочно решать проблему.

Единственной стабильной альтернативой оказался - да-да - MAX. У него есть Bot API, он не попадает под ограничения РКН и уверенно работает на территории РФ.

Задача не «сделать второго бота с нуля», а сохранить одного логического Дежурного и дать ему второй вход из MAX. В статье расскажу, как я изменил архитектуру: вынес всю бизнес-логику в отдельный слой CORE, а Telegram и MAX сделал вызовами команд этого ядра.

Компании ускоряют релизы, автоматизируют пайплайны, считают DORA-метрики. Но задачи всё равно висят неделями, релизы откатываются, а доработки съедают спринты.

Проблема часто не в Scrum и не в CI/CD.
Она в том, как устроена передача работы: аналитики пишут требования, разработка «реализует», QA проверяет, поддержка тушит пожары. За результат никто не отвечает целиком.

Каждая передача задачи — это пауза, пересказ контекста и новая точка разрыва. В проектной модели это нормально. В продуктовой — начинает дорого стоить.

В статье разберём:
• почему задачи «застревают» между командами;
• какие метрики первыми показывают проблему;
• чем отличаются команды с полной ответственностью за результат;
• и почему инструменты сами по себе ничего не решают.

Итак, спустя два месяца работы вышел релиз ядра Linux 6.19. В него вошло больше 15 тысяч исправлений от 2000 разработчиков. Патч получился солидным — больше 50 мегабайт, изменения затронули почти 14 тысяч файлов. Основная часть работы традиционно пришлась на драйверы устройств, архитектурный код и сетевой стек. А еще появилось несколько заметных изменений, которые касаются серверных нагрузок, виртуальных сред, сетей и встроенных девайсов. 

Кстати, сразу после этого анонса Линус Торвальдс объявил о переходе к ветке 7.0. Почему и зачем? Давайте разбираться. 

Основатель компании приборов освещения Brighter Саймон Беренс поделился опытом запуска собственного аппаратного продукта и теми уроками, которые он извлёк.

Питание для ЦНС вместо постоянной стимуляции. Создание режима дня с учетом приоритетов и пожеланий. Сокращение расстояния между реальным и идеальным образами себя, по заветам Тимоти. Эти три правила помогут если не отменить стресс, то снизить его степень к минимуму. И вот как это работает.

Эта история началась с исследования проблем производительности на высоконагруженной базе данных Postgres. Табличка, которая была предметом исследования, довольно небольшая (~100,000 записей), но очень активно используемая.

В процессе исследования я увидел, что Postgres использует индексный доступ по абсолютно неселективному критерию, фактически это был "INDEX FULL SCAN" в терминологии Oracle. Интуиция, наработанная на другой промышленной базе, вопила: "что-то здесь не так!"

Но что?

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

Можно, конечно, заранее срезать количество извлекаемых чанков, но это отразится на качестве ответов.

Можно настроить кэш, который экономит на обращениях к сервису, когда приходят одинаковые вопросы. Но когда пользователь спрашивает "How to get developer support?”, и тут же другой пользователь спрашивает "How to ask development-related questions?", ваш сервис каждый раз будет генерировать ответ заново, сжигая ваши токены и заставляя пользователя ждать. Обычный кэш тут бессилен: для него эти две фразы — абсолютно разные ключи. 

В этой статье я расскажу, как развернуть мощный семантический кэш на базе AlloyDB Omni (PostgreSQL от Google), используя векторный поиск ScaNN, автоматическое партиционирование и планировщик задач. Мы пройдём путь от настройки Docker-контейнера до продакшн-архитектуры.

Я сейчас занимаюсь, пет-проектом: создаю систему контент-продвижения для начинающего коуча. Недавно написал промпт для создания постов в ТГ-канал. Результат – сверх всяких ожиданий.

Особенно тестировщиц привели в восторг посты на тему «Почему все мужики – козлы» и «Почему мужчина не любит ходить с женщиной по магазинам».

Промпт приведу чуть ниже, а сейчас о важном:

Я писал промпт не начиная с его функций. И даже не начиная с Роли из которой он должен работать.

Я писал промпт начиная с ответа на вопрос «Как нейросеть должна об этом думать».

Это называется «Культурно-когнитивный код».

Термин этот известен, погуглите. Но я еще не встречал, чтобы он использовался  применительно к промптам.

Умных людей много, подобные подходы используются.

Это Cultural prompting / cultural identity prompting, Cultural anchors и ментальные модели, Мета‑промптинг.

Но термин «культурно-когнитивный код» наиболее точно отражает смысл того чего мы хотим добиться.

Можно это называть «Код мышления», но это мало что объясняет. А у термина «Культурно-когнитивный код» есть устоявшееся понимание. Весь фокус – в применении именно к промптам.

Дальше по тексту я, для краткости, буду использовать аббревиатуру CCC.

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

Стабильность – не в том смысле, что все посты – «под одну гребенку», хотя явно читается, что они написаны ОДНОЙ ЛИЧНОСТЬЮ.

Стабильность в том что получаемый контент теперь весь в тему, весь интересный и глубокий, практически не требующий правки. Брака нет.

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

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

В этой статье — о том, что происходит с образовательным ИИ‑продуктом в условиях постоянных изменений рынка и технологий. Все выводы основаны на практическом опыте разработки и эксплуатации Кэмпа: от проектирования генерации до продуктовых решений.

Record-классы удобны, пока класс = «состояние, всё состояние и ничего кроме». Любое отклонение (API канонического конутруктора не равно внутреннему представлению, нужно наследование) ломает «автогенерацию» и паттерн-деструктурирование (destructuring).

В новом переводе от команды Spring АйО статьи Brian`а Goetz`а, архитектора Java Language, предлагается следующий шаг в направлении data-oriented programming in Java: классы-носители и интерфейсы-носители (они же Carrier classes & interfaces). Концептуально, carrier классы родились из record-ов путем ослабления части их ограничений.

Комментарий от Михаила Поливаха: Друзья, помните, пожалуйста, что данная статья по сути является суммированием обсуждения Carrier классов из JDK Project Amber Mailing List. Я это к тому, что пока непонятно, в какой версии языка carrier классы появятся, и появятся ли они в том виде, в котором представлены в статье. Статью стоит рассматривать как пищу для размышления.

Пока размышляла по теме нашла столько интересностей. Поэтому разобью статью на 2 части. Первая – страшилки, исследования, факты и прочие реалии.
Вторая – ответ по теме: Роль и влияние карьеры в жизни человека. Поехали!

Всем привет, меня зовут Диана Шигаева. Я основала своё бюро и руковожу крутой бандой международных консультантов. Эх, жаль, что тут нельзя произносить его название вслух! Но правила есть правила, к делу!

<...> причина, почему все эти скрам-атрибуты теоретически могут появиться в командах, — это если сами команды нуждались в этом и ввели все осознанно. Но это какая-то фантастика, такого не бывает. – Из статьи «Я убрал оценки задач, спринты, планирование и ретроспективы — и ничего не сломалось»

Или все-таки бывает?

Привет, меня зовут Рома. Я разработчик и последние 4 года я руковожу командами разработки в бигтехе и в пет проектах. Сегодня я хочу рассказать, как в моих командах появляются атрибуты Agile-методологий и почему часть из них я считаю необходимыми.

На дворе 2026 год, вы открываете глаза утром, зеваете и наливаете себе чашку ароматного кофе. Затем вы достаете кусок хлеба и кладете его в тостер. Вместо того чтобы крутить механический таймер наобум, он за секунду сканирует кусок: «Ржаной, вчерашний, толщина 18 мм, слегка подсушен на воздухе. Рекомендую режим 3 - хрустящая корочка с сохранением влаги внутри». Он не подключен к облаку. Весь его интеллект живёт в чипе размером с рисовое зерно где-то на его плате. Это и есть главный тренд 2026 года: нейропроцессоры (NPU) массово перекочевали из флагманских гаджетов в обычную бытовую технику.

Согласно прогнозам ABI Research, к 2026 году более 70% продаваемой мелкой бытовой техники среднего и высшего ценового сегмента будут иметь специализированный AI-ускоритель. И речь не о голосовом помощнике, который тупит, если пропал Wi-Fi. Речь о локальном ИИ, который мгновенно и без интернета распознаёт образы, звуки, текстуры и адаптирует работу устройства под конкретную ситуацию. Ваш пылесос будет отличать рассыпанный сахар от шерсти кота, а стиральная машина - анализировать степень загруженности барабана и тип пятен на лету.

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

Приятного прочтения!

Пролог: Почему бизнесу нужна эволюция, а не революция

Представьте сцену: Вы запускаете первый ИИ-агент для поддержки клиентов. Первые две недели — восторг. "Он отвечает! Он работает!" Месяц спустя — разочарование. "Он повторяет одни и те же ошибки. Не умеет работать со сложными запросами. Требует постоянного контроля".

Знакомо? Это классическая история "пилотного проекта, который не масштабируется".

Моя команда прошла этот путь. Мы потратили 18 месяцев на эволюцию от примитивного бота до системы, которая:

Самостоятельно обрабатывает 85% сложных запросов

Снизила операционные затраты на 40%

Еженедельно улучшает свои показатели на 3-5% без вмешательства разработчиков

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

Привет, Хабр! Меня зовут Аскар Мусаев, я эксперт по непрерывности бизнеса в «Инфосистемы Джет». В статье я разберу, как системно проверить готовность компании не к предотвращению атак, а к действиям после успешного взлома, когда критические системы остановлены, а время на восстановление ограничено.

При создании киберустойчивой инфраструктуры много внимания уделяется проверкам защищённости: пентестам, Red/Purple Teaming, программам Bug Bounty и кибериспытаниям. Оценка часто сводится к бинарному вопросу «Взломали / Не взломали?». Однако, даже если взломать пока не удалось, это ещё не говорит об устойчивом к атакам бизнесе, ведь в тени остается вопрос: «А что будем делать, когда всё-таки взломают?».

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

Микросервисы на схемах выглядят стройно, но в проде часто вырождаются в распределённый монолит: общая БД, синхронные цепочки вызовов и каскадные падения. В этой статье разберемся, как проводить границы сервисов так, чтобы система оставалась автономной — почему декомпозиция по слоям ломает независимость, как опираться на bounded context и бизнес-возможности, как аккуратно выводить legacy через Strangler, и где на практике помогают Database per Service, CQRS и Saga.

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

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

Движение FIRE (Financial Independence, Retire Early — финансовая независимость, ранний выход на пенсию) стало популярным в 2010-е, особенно среди людей из digital-индустрии. В западных блогах FIRE выглядит как понятная формула: сократил расходы, накопил сбережения, инвестировал и больше не работаешь. Но в российском контексте FIRE почти никогда не работает как история про раннюю пенсию. 

Всем привет! Меня зовут Алексей, я тимлид команды разработки в SENSE. Помимо работы мне интересна тема финансовой независимости и управления личными финансами. В этой статье разберём:

— что такое классическая модель FIRE;
— почему она плохо переносится на российские реалии;
— какие факторы сильнее всего ломают расчёты;
— и чем подход полезен, даже если не достижим в России. 

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

Поехали!