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

Следуя традиции древних видящих, статьи КЭИ (Клуб Электронных Игр) из журнала ТМ, фактически, содержали две части. «Обучение для правой стороны» давалось в виде повести Михаила Пухова «Путь к Земле» и серии «космических программ», позволявшим вместе с героями повести совершить перелёт с Луны на Землю. 

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

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

Настойчивые и неуклонные исследования советских видящих привели их к открытию «электронного океана».  Вот цитата из того памятного номера:

Когда у вас один‑два сервиса и несколько интеграций, внешний API легко держать под контролем. Но если их десятки и каждый хочет выставиться наружу, приходится придумывать свой велосипед.

Меня зовут Юрий Коберман, я технический продакт в Точка Банк. Мы в команде несколько раз меняли систему работы с API. Начинали с одной команды, которая писала всё вручную, и постепенно пришли к универсальному инструменту, с помощью которого сервисы могут выходить наружу самостоятельно без очереди и потери качества. Подробности — в этой статье.

Всем привет, я Артем Герасимов, владелец продукта SimpleOne SDLC. Чуть больше года назад я пришел в компанию в момент, когда продукт только прошел стадию MVP, которую мы делали быстро, чтобы проверить гипотезу. Гипотеза подтвердилась, появились клиенты, но вместе с ними пришел беспорядок: запросы терялись между почтой и чатами, сроки срывались, процессы перестали работать.

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

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

Можно? Наверное, но лучше сначала рассмотреть принципы владения данными, обеспечения передачи данных потребителям, поддержки версионирования контрактов данных.

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

Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Дмитрий Фатов (@FatOFF ) — руководитель разработки Газпромбанка с опытом разработки приложений более 13 лет. Дмитрий работал как backend-, так и fullstack-разработчиком на языках Java, Kotlin, JS, TS, 1С и имеет большой опыт работы с SQL-базами данных.

Недавно мы добавили в Lissa Health общую оценку состояния организма - индекс здоровья. Он агрегирует все загруженные анализы и выдает понятную картину: что в норме, что требует внимания, какие системы и органы просели. Логичным продолжением стал биологический возраст - показатель, который пытается ответить на вопрос, насколько реальный износ организма соответствует тому, что написано в паспорте.

При тщательном изучении стало понятно, что тема неоднозначная. С одной стороны - десятки приложений в App Store, которые за 5 минут расскажут, что вам "на самом деле 28". С другой - научные работы, где авторы осторожно пишут про генетику и "mortality risk prediction". Между этими полюсами - большая серая зона, в которой мы и попытались разобраться.

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

Проблема N+1 стара как мир. Инструментов много: Debugbar хорош локально, Telescope тяжеловат для продакшена. Мне хотелось решения, которое будет «стучать» в Slack или Telegram именно тогда, когда проблема случилась на проде, и при этом сразу показывать пальцем на виновную строку кода.

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

Всем привет! На связи Карпенко Савелий, специалист по тестированию на проникновение из группы по борьбе с уязвимостями в компании ТехВилл.

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

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

Каждый год Pinterest выкатывает отчёт Predicts, и каждый год я ловлю себя на мысли: ну ладно, опять набор красивых мудбордов. А потом проходит полгода, и я вижу эти же паттерны у клиентов, в лентах, в брифах. Совпадение? Восемь из десяти прогнозов Pinterest сбываются, и это уже не про удачу, а про данные.

Отчёт построен на анализе поисковых запросов за два года, с сентября 2023 по август 2025. Охвачены все возрастные когорты: Gen Z, миллениалы, Gen X и бумеры. И вот что важно - это не экспертное мнение одного редактора, а срез реального поведения сотен миллионов пользователей. Люди ищут, сохраняют и планируют. Pinterest видит это раньше, чем Instagram или TikTok.

* Организация Meta, а также её продукты Instagram и Facebook, признаны экстремистскими на территории РФ.

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для ИТ-команд.

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

Один из примеров такой документации — Architecture Decision Records — короткие структурированные документы, которые фиксируют одно конкретное архитектурное решение вместе с контекстом, рассмотренными альтернативами и принятыми trade-off'ами. Ключевое слово — конкретное. ADR — это не архитектурный обзор системы и не проектная документация. Это ответ на один вопрос: «почему мы решили именно так, а не иначе?»

На эту статью меня вдохновил испанский ИИ-слоп и тред на Hacker News вокруг вопроса «как вы фиксируете ПОЧЕМУ инженерных решений, а не только ЧТО?». В статье напомню, зачем нужен ADR и какие есть стандартные проблемы. Также приведу выжимки из кейсов, в которых описаны любопытные ИИ-автоматизации.

Знаете это чувство, когда сидишь на очередном спринт-планировании, команда пытается оценить таски, а планинг покер тормозит так, что успеваешь кофе сварить, пока карточка загрузится?

Вот у меня в AGG TEAM такая же история была. Мы пробовали:

Роботы создают эмбрионы. ИИ научился читать ДНК. Клетки мозга пилотируют дроны. Кажется, мы пересекли какую-то черту, но об этом никто особо не объявлял Это свежие заметки о жизни на пороге сингулярности.

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

Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна.

Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке. В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.

Чувак, уже есть Pinia, Pinia Colada, TanStack Query для Vue, зачем ещё один способ управлять состоянием во Vue?

Меня просто задолбало писать везде флаги отслеживания состояния для действий и делать store через фабричную функцию, как это делали наши праотцы в начале 2000-х. Запоминать зоопарк из разных composable-функций и хуков. Изучать какую-то другую систему реактивности, типа MobX, тоже не хочу. Это какой-то зашквар.

Я хочу использовать то, что есть: реактивность Vue везде, классы, методы. Хочу использовать классические шаблоны: SOLID, DDD и т.п. Хочу, чтобы Действие или запрос сами отслеживали и сообщали своё состояние. Хочу сконцентрироваться на бизнес-логике и писать меньше шаблонного кода.

И это возможно, покажу, как это работает на примере.

14 марта не стало философа и социолога Юргена Хабермаса. Ему было 96 лет. Он прожил насыщенную жизнь и оставил многотомное наследие, его труды проходят в вузах по всему миру. 

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

Канбан — это прекрасное изобретение. Большинство жизненных ситуаций не предполагают сложного процессного подхода и доска с карточками просто идеально помогает упорядочить реальность, сделать ее понятной и избавиться от лишнего. Цветные карточки и механика понятны даже детям.

Да Канбан не поддерживает сложных зависимостей и ветвления логики. Но реально... в 90% случаев — накладываешь этот метод на рабочую ситуацию и жизнь очевидно налаживается!

И проблема не в том, что Канбан имеет недостатки. Проблема в том, что за неимением нужных инструментов или в связи с незнанием, Канбан начинают применять там, где он не предназначен для использования. У людей загорается творческий огонек в глазах, берутся в руки палки, изолента и происходит победное натяжение совы на глобус. А потом такие художники еще и хвастаются на конференциях о том, как они внедрили CRM для управления производственными потоками...

Давайте пройдем по шагам, чтобы разобраться где, что и как происходит.

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

Добро пожаловать в чистилище препроцессора — место, где здравый смысл уступает место макросам. Сегодня мы заставим C++ притвориться Haskell-ем и внедрим do-нотацию, за которую любой адепт «чистого языка» предаст нас анафеме.

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

Сегодня мы перейдем черту. Функциональное программирование манит своими абстракциями, но когда дело доходит до цепочек вычислений в монадах, C++ встречает нас бесконечными лямбдами и вложенностью, от которой рябит в глазах. В Haskell эта проблема решена элегантным do-синтаксисом. А что, если я скажу, что мы можем получить то же самое в C++, используя лишь тёмную магию макросов, простые шаблоны и полное пренебрежение здравым смыслом?

Приготовьтесь: мы будем дорабатывать парсер и превращать ваш код в нечто, что заставит коллег вызвать экзорциста. Это история о том, как затащить чистую красоту монад в суровый мир C++.

Да, «Критика чистого разума“ Канта — книга, которую стоит читать сегодня. Не из почтения к классике, а потому, что она помогает понять, почему современная наука упирается в те же эпистемологические пределы, которые Кант обозначил два с половиной века назад. Если вы когда‑нибудь задавались вопросом, почему квантовая механика «странная», почему математика так эффективно описывает реальность или где проходит граница между тем, что мы можем познать, и тем, что остаётся за горизонтом, — Кант говорит именно об этом же.

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

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

Разберем реальный кейс, где попытка сделать «идеальное» техническое задание привела к увеличению сроков проекта почти в два раза.