Отладка больших CMake-проектов часто превращается в боль. Уходит не один час на то, чтобы с помощью message() и бубна найти проблему. Но существуют более удобные и эффективные способы. Например, отладчик, который позволяет пошагово пройтись по CMake-скриптам и посмотреть значение переменных. Или профилировщик, показывающий последовательность вызовов и время их выполнения. Как их использовать? Читайте в статье.
Проблема ценообразования на ИТ-услуги и, в частности, вопрос об определении оптимальных ставок на работы по T&M напрямую влияет на бизнес многих ИТ-компаний. Тут есть множество интересных нюансов. Предлагаю рассмотреть их в данной статье. Возможно, это поможет осознанно выбирать лучшие варианты, когда придется принимать очередное решение на эту тему.
Разговор о собственном PostgreSQL-кластере обычно начинается с фразы: «Да там поставить — день работы». Технически это правда. Установка PostgreSQL на два сервера в разных ЦОДах действительно занимает несколько часов. Проблема в том, что установка — это меньше 10% работы до Production-ready-состояния.
В этой статье мы декомпозируем все задачи, которые стоят между идеей развертывания и работающим кластером с отказоустойчивостью между ЦОДами. Все с оценками в человеко-часах, чтобы можно было собрать для себя TCO и сопоставить свои затраты. Учтите, что если все это вы делаете в первый раз, то по всем шагам время увеличивается втрое.
Параллельно покажем те же временные и трудозатраты при выборе Managed-решения, DBaaS (базы данных как сервис), чтобы вы могли сравнить и выбрать — делать дальше самим или передать это на аутсорс.
Кажется, что оборачивать BigDecimal и String в отдельные классы — это overengineering и преждевременный DDD. Но именно из-за этих «лишних» типов в прод не пролезают посылки в ПВЗ, проценты внезапно превращаются из 0.8 в 80, а деньги теряют валюту и смысл. В статье на реальном примере логистики разбираем, как один небольшой record Weight и несколько аккуратных Value Object’ов наводят порядок в бизнес-логике: инварианты перестают жить в комментариях, проверки перестают дублироваться, а код начинает читаться как текст предметной области. Без внедрения полного DDD, без религиозного фанатизма — только практические шаги.
Работа команды производственных айтишников на металлургическом производстве иногда тесно сплетается с командой технологической автоматизации и электрооборудования: устанавливаем датчики уровня, нужные для детального анализа технологического процесса
С точки зрения ИТ доменная печь — это огромный «чёрный ящик». Вы кладёте сырьё и топливо, получая на выходе чугун и шлак. Измерить внутри все можно почти ничего нельзя: датчики просто «умирают» от температуры, воздействия шихты и прочих условий. Измерить снаружи тоже сложно (да и нужно ли?): большие печи имеют диаметр порядка 15 метров и высоту 35 метров, — что нам дадут граничные условия для таких размеров?! По опыту на малых печах можно измерять уровень расплава (без разделения на шлак и чугун) по ЭДС внешними датчиками, но у нас так не выйдет, и нам пришлось провести целое исследование, чтобы понять, почему.
Как операционный персонал управлял процессом последние 47 лет? На базе своего производственного опыта, данных по загруженному сырью, параметров прошлых выпусков чугуна и шлака, а также косвенных параметров предполагал, как поведёт себя печь. Но управлять процессами внутри надо, поэтому остаётся только моделирование процессов по данным входа и выхода, базируясь на принципах материального баланса и используя математические ухищрения.
Если коротко, то мы те самые энтузиасты, которые «доставляют» данные, создают алгоритмы и вместе с производством добиваются эффекта. Собственно, мы оптимизируем всё что можем, и вот наконец добрались до самого нетронутого, сакрального и неизвестного легаси, вызванного «чернотой» ящика. Десятилетиями ограниченность данных воспринималась как неизбежность.
Но цифровые возможности развиваются, и мы пробуем применить самые современные цифровые решения, даже если они на грани возможного.
Некоторые уязвимости, связанные с повреждением памяти, невероятно сложны для эксплуатации. Они могут вызывать состояния гонки, приводить к сбоям системы и накладывать разные ограничения, которые усложняют жизнь исследователя. Работа с такими «хрупкими» багами требует значительно больше времени и усилий. CVE-2024-50264 в ядре Linux — как раз одна из таких сложных уязвимостей, которая получила премию Pwnie Award 2025 в категории «Лучшее повышение привилегий» (Best Privilege Escalation). В этой статье я представлю свой проект kernel-hack-drill и покажу, как он помог мне разработать прототип эксплойта для уязвимости CVE-2024-50264.
Привет! Я Рома, бэкендер-питонист в KTS.
Это вторая статья в моем цикле об алгоритме архивации bzip2. Первую можно прочитать здесь, но для понимания сегодняшней темы она необязательна. Ниже я разберу преобразование Барроуза-Уилера — ключевой этап сжатия bzip2.
Привет! Я Тимур, разработчик мобильных приложений в KTS.
В прошлом году мы решали любопытную задачу. Нам нужно было вдвоем за одну рабочую неделю собрать прототип мобильного приложения для сервиса бронирования отелей.
Задача осложнялась тем, что заказчик рассматривал не только нашу команду на роль подрядчика. Мы не могли отдать сырой черновик, в котором просто нажимаются нужные кнопки и работают ключевые сценарии — мы должны были превзойти конкурентов-флаттеристов. И нам удалось это сделать с помощью KMP.
Да, тема довольно холиварная, и в статье я не заявляю, что KMP лучше Flutter’а во всем. Каждая технология хороша под свои задачи. Вместо этого я расскажу о конкретном проекте, на котором KMP оказался более удачным выбором. Также коснусь вопросов архитектуры и миграции Android-приложения на iOS с помощью CMP, а заодно подсвечу подводные камни, с которыми пришлось разбираться в процессе.
Бизнес Додо активно масштабируется. Уже сейчас Dodo IS круглосуточно работает в двух облаках, более чем в 25 странах и практически во всех часовых поясах. В таких условиях важно знать, что вся система действительно работает хорошо, а не просто «не горит» прямо сейчас.
Чтобы это знание обрести, мы привезли в нашу инженерную савану SLO'на — неповоротливое, но умное существо. Он наводит порядок в хаосе метрик и алёртов, и отличает реальную проблему от мнимой. А ещё он требует внимания, точных чисел и ясных целей. Поначалу мы его боялись, но позже поняли: если его приручить, он защитит нас от ночных звонков и научит бизнес говорить на языке надёжности.
Сегодня мы расскажем, как приручили своего SLO'на и прошли путь от первых экспериментов с нагрузочным тестированием до построения культуры надёжности.
Это очередная статья на тему «как прокачаться продакту». Однако рекомендовать в ней книги, подкасты или «100% работающие» фреймворки я не буду.
Привет, меня зовут Юля! В этой статье я поделюсь навыками, которые стоит развивать всем желающим качаться в продукте.
Мы живём во времена AI-бума. ИИ упрощает ресёрч информации, визуализирует первые идеи дизайнеров, которые попадают в референсы, и пишет код. Некоторые даже говорят: «скоро разработчики станут не нужны», а «ИИ-агенты будут идеально писать код по промпту «хочу красиво» и т.д.
До этого «скоро» ещё далеко, но это не повод не использовать ИИ-агентов в автоматизации различной рутины. Например, в написании платёжных интеграций для POS-терминалов в разных странах. Передать ИИ-агентам такую задачку — не очень просто, но у нас получилось! Сегодня расскажем, как мы это сделали.
Почему даже самая мощная LLM иногда выдаёт бессмысленные фразы и противоречия? Всё дело в экспоненциальном росте вариантов (N^M) и свободном копировании человеческих ошибок. Читайте статью, чтобы узнать, как мы с помощью формальных грамматик превращаем хаотичную генерацию в управляемый синтез, усиливая роль семантики и соблюдая структурные правила.
Представьте: ваш Python-код работает на 30% быстрее благодаря JIT-компиляции, обработка запросов масштабируется на все ядра процессора без ограничений GIL, а отладка высоконагруженных систем происходит в реальном времени, без остановки продакшена. Это не футуристический сценарий “what-if” — это реальность Python 3.14, релиза, который переосмысливает саму природу разработки с высокой производительностью на Python.
К середине 80х рынок 8-битных ПК типа Commodore 64 и ZX Spectrum достиг насыщения. Новые задачи (современная графика, плавная анимация в играх, софт для бизнеса, «взрослая» компьютерная музыка) уже не укладывались в их возможности.
Ответом на вызов стали две «машинки», ставшие символами новой эпохи — Commodore Amiga и Atari ST. Это прямо quantum leap (но не от Синклера), который похоронил собственных 8-битных предков.
В этой истории главный парадокс в том, что технологическую революцию сделали именно Commodore и Atari, но оба бренда упустили массовый сегмент, и уступили место «серому ящику» от IBM.
Под катом поговорим не столько о железе и мегагерцах, сколько о войне философий, стратегических ошибках и беспощадной логике рынка.
Мы опросили ИТ-специалистов из бигтеха и промышленного ИТ, почему они выбирают одну сферу и что отталкивает их от другой.
Делимся результатами с вами. Спойлер: ключевые различия двух сфер лежат в ценностях, мотивации и профессиональных установках.
Результаты исследования помогут вам увидеть, как устроены эти сферы изнутри и где вам комфортнее расти и работать.
Теперь у нас есть имена для различных практик Use-case, с учётом уровня их детализации.
В рамках текущей статьи, приведено основное, краткое содержание руководства Use-case 3.0 — без отступлений, и дополнительных пояснений по тому или иному пункту.
«Через год дизайнеры будут не нужны» — в конце 2023 года эту фразу мы слышали постоянно. В новостях, в чатах. Midjourney, Stable Diffusion, Кандинский — все это выглядело как начало конца профессии. Прошел год. И реальность, как это часто бывает, оказалась менее громкой, но гораздо интереснее. Сегодня я Дарина Костина, дизайнер с 10 летним опытом, практикующий преподаватель поделюсь с вами опытом использования нейросетей в нашей студии karma.web.
Добрый день, уважаемые подписчики Хабра! Сегодня, 12 апреля, в День космонавтики с вами снова команда студенческого проекта по верификации информации СМИ и социальных медиа #СТУДФАКТЧЕК.
С мечтой о звездах расскажем о том, как исследовали такую спорную и, возможно, провокационную тему, как феномен НЛО.
В телеграм-канале «НЛО: атака инопланетян» 13 февраля 2025 года была опубликована новость с ссылкой на испанский портал «MysteryPlanet» с громким названием: «Шведский университет объявил о запуске первого университетского предмета по феномену под названием «НЛО: от заговора к науке».
Вас спрашивали «Кем Вы видите себя через 5 лет»? Меня тоже. За двадцать пять лет в IT я понял, зачем они так делают. Понял – это значит, что я «привык и научился пользоваться» (С). Но «неприятно удивлять» они меня не перестали.
Публикую свой личный русско-HRский разговорник. Он вряд ли поменяет ваше отношение к HRскому языку, но проходить собеседования вы будете проще и эффективнее.
Дисклеймер:
Я не призываю врать или «играть по правилам» HR. Я делюсь практической схемой подачи опыта и скиллов, чтобы минимизировать отказы «по софтам». В моем случае она работает.
Распознавание рукописного текста — задача, которая остаётся болезненной даже в 2025 году. Именно это не позволяет оцифровать многие архивы и документы, а также является камнем преткновения в разной бизнес деятельности.
Производители заявляют, что модели вроде GPT-5, Gemini 2.5 Pro и Claude Sonnet 4.5 способны не просто распознать почерк, но и догадаться, что автор имел в виду: исправить пунктуацию, восстановить сокращения, даже понять, что стоит за пометками на полях.
Звучит красиво. Но работает ли это на реальных документах? Чтобы ответить, мы провели исследование и сравнили, как три топ-LLM обрабатывают рукописные и смешанные документы — с точки зрения точности, структурной консистентности и понимания контекста.