Разработка

Что общего у массового применения конфигураций, встроенной поддержки OpenTelemetry и управления HA-кластерами в пару кликов? Всё это — части пазла, который мы собираем, чтобы сделать администрирование PostgreSQL по-настоящему удобным и безопасным. Выход версии Postgres Pro Enterprise Manager (PPEM) 2.3 стал важной вехой в развитии нашего графического интерфейса. Мы добавили поддержку пользовательских пресетов, переработали систему алертинга и усилили RBAC-модель управления доступом. Разбираем ключевые нововведения релиза, которые помогут навести порядок в зоопарке конфигураций и спать спокойно, зная, что система сама предупредит о проблемах.

Статей про Docker много не бывает.

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

Привет, Хабр! Мы — Дмитрий Дудов, руководитель разработки платформы T-Messenger, и Алексей Стрельников, Product Owner этой платформы. Мы считаем, что доступность — это история на пересечении бизнеса и техники.

В статье расскажем: 

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

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

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

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

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

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

Картинка — Youtube-каналы: Tobi, StuckAtPrototype

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

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

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

Недавно мы в Beeline Cloud рассказывали о необычных визитках, способных наглядно продемонстрировать инженерные навыки владельца и служить уникальной запоминающейся «раздаткой». Сегодня мы подобрали несколько аналогичных проектов — разумеется, open source. Это — LED-визитка с плещущимися огоньками, карточка-тренажёр для QA-инженеров и миниатюрная плата-визитка с ретроиграми.

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.

Всем привет! Наша группа занимается RISC-V Linux и загрузчиками в компании «Синтакор». Однажды перед нами возникла задача — реализовать поддержку аппаратных триггеров в ядре Linux и OpenSBI. Она стала началом исследования, в ходе которого я изучил смысл аппаратных триггеров с точки зрения отладчика, их устройство и использование для вотчпойнтов и брейкпойнтов, а также принял участие в совершенствовании поддержки аппаратных триггеров в RISC-V Linux и OpenSBI. 

Этими знаниями я хотел бы поделиться в статье. Покажу на примерах, как устроены брейкпойнты и вотчпойнты в отладчиках, сравню их программную и аппаратную реализации, покопаюсь в деталях их работы в ядре Linux. Начну с легкого способа сломать GDB, а к каким выводам он приведет, вы узнаете далее под катом.

Светодиодная лампа Osram Ultra, купленная по акционной цене 176 рублей. На коробке заявлены 12 Вт, «высокая стабильность», «качественный свет» и прочие обещания, которые производители любят печатать крупным шрифтом.

Я руководитель проектов, работаю с крупными корпоратами и банками первой пятёрки.

Самый ад — это когда проект на стыке двух таких банков. У меня есть живой пример )

На этом проекте:

На этом проекте:

— Юристы и безопасники из двух банков 4 месяца гоняли договор по кругу. Надо было как-то их договорить и всё-таки начать работать.

— Договор был рассчитан до 2026 года, а бюджет в системе был заложен только на 2025-й. Бухгалтерия возвращала ошибку Not defined и предлагала запланировать бюджет на 2026 год прямо сейчас.

— Уволился ключевой подписант.

— Это был ИТ-директор!

Так что у нас есть все виды бюрократии: комплаенс, Департамент кибербезопасности (ДКБ), риск-чемпионы и, конечно, юристы.

Как я уже говорила, это ад.

Но бюрократия всё же нужна. Потому что на больших проектах она означает стандартизацию.

Что бывает, когда такое не выполняется, мы отлично знаем по взломам доставки еды, например, когда стандарт был, но его не применили.

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

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

Сегодня поговорим о том, как на практике построить высоконагруженный обратный прокси-сервер на основе YARP, отличной библиотеки от Microsoft для .NET.

Quake, выпущенный в июне 1996 года, за срок своей жизни был вынужден оседлать три технологические волны. Наряду с появлением карт аппаратного 3D-ускорения и развитием Интернета, сложности у разработчиков игры вызвала и смена поколений операционных систем.

Стремясь к распространению Windows 95 и Windows NT, Microsoft начала процесс замены своей старой операционной системы MS-DOS. С 1996 по 1997 год доля DOS на рынке упала на 50%. Некоторые разработчики, например, Blizzard North, делали рискованный шаг и создавали игры наподобие Diablo только для Windows 95. Компания id Software же пошла на подвиг по созданию единого двоичного файла quake.exe, способного работать и в DOS, и в Windows.

Ещё более впечатляет то, что разработчикам удалось реализовать стек TCP/IP Quake лучше, чем у Windows 95. Давайте разберёмся, как им это удалось.

Привет, хабровчане! На связи руководитель проектов редакции компьютерной литературы издательства «БХВ» @Holmogorov Признаюсь честно: паять я люблю, но не сказать, что умею это делать профессионально. Так, в состоянии починить ёлочную гирлянду или водрузить на место отвалившийся конденсатор в блоке питания. Поэтому когда у нас в «БХВ» придумали детский набор «Паяем правильно и точно. Уроки мастера + 4 набора для пайки», я сразу решил взять его на тест-драйв. Благо, все необходимое для «ходовых испытаний» у меня в наличии имеется: ребенок мужского пола, никогда до этого не державший паяльник в руках, и я, который хотя бы приблизительно помнит, как этот самый паяльник выглядит. Тем более, набор изобретали совершенно другие люди в совершенно другом подразделении нашей компании, поэтому я могу без особых угрызений совести изучать его более-менее непредвзято и писать про него гадости обзоры.

Привет! Это новый выпуск «Нейро-дайджеста» — коротких и полезных обзоров ключевых событий в мире искусственного интеллекта и технологий.

Неделя выдалась насыщенной: OpenAI тихо обновили пятёрку до GPT-5.1, Google вытащили Gemini 3 Pro на первые места топовых бенчмарков, Anthropic заключили сделку с Microsoft и Nvidia на десятки миллиардов долларов. Измены с чат-ботами уже приводят к разводам, а в пакистанской газете засветилась подсказка от нейронки.

Всё самое важное — в одном месте. Поехали!

Рассказываем, почему главный инструмент дизайнера будущего — эмпатия 

Меня зовут Саша, и последние 12 лет моя жизнь — это дизайн. Сегодня я руковожу дизайн-командой в KISLOROD, а в прошлом — помогал крупным брендам и миллионным сервисам обрести их уникальный голос и форму.

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

О программировании с помощью AI-агентов трубят из-за каждого угла. Последнее время появилось достаточно много инструментов, которые буквально пишут код за разработчика. Наша команда следит за индустрией ИИ в разработке достаточно давно. Помимо внедрения ИИ в сам процесс разработки наших продуктов, мы активно занимаемся интеграцией Amplicode с современными AI-агентами и не только. И у нас есть свои мысли на этот счет :-)

Французская компания Linagora продвигает облачный сервис Twake Workplace как опенсорсную и безопасную альтернативу Google Workspace и прочим корпоративным платным облакам. В комплект с чатом и почтой входит Twake Drive — защищённое файлохранилище.

В Twake Workplace код открыт, используются защищённые протоколы JMAP и Matrix, шифрование по умолчанию. В публичном облаке бесплатно дают 5 ГБ на файлы. Но самое главное, что Twake Drive можно установить на собственном сервере, с неограниченным дисковым пространством.

Что такое код-гольф? Это соревнование, в котором надо решить задачу по программированию (как правило, несложную), используя наименьшее количество символов. Соревнование довольно известное. Можно поиграть, например, на одноимённом сайте, есть целая секция на CodinGame, иногда такие соревнования публикует kaggle, была такая секция на HackerRank (сейчас её я не нашёл).

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

Временами мы развлекаемся таким форматом. В какой-то момент на внутренних ивентах подняли свою платформу для соревнований, а потом она протекла и на внешние конференции.

Эта статья — смесь разбора задач и истории появления соревнования по код-гольфу на конференциях Яндекса.

Это перевод классической статьи 1995 года одного из титанов теории разработки программного обеспечения - профессора Никлауса Вирта (если найдется некто, кто не знает его, то можно ознакомится, не выходя с habr, со статьями о нем здесь и здесь а небольшая ретроспектива итогов предсказаний Вирта из этой статьи доступна здесь). Текст имеет больше историческое значение, но написан ясным и доступным языком, и, возможно, побудит кого-нибудь пересмотреть подходы к созданию программного обеспечения.

Я наблюдал, как мой опытный коллега-финансист целый час колупался в Excel. Он гуру экселя, работает с ним 20 лет. Но увидев, как он печатает формулы, я не выдержал и показал пару простых трюков, от которых он пришёл в восторг.

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

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