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

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

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

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

Волна паники захлестнула IT-сообщество. Гуру из Кремниевой долины наперебой объявляют о «смерти программирования». Стартапы хвастаются ИИ-инженерами, которые пишут код лучше людей. Новостные ленты пестрят заголовками о массовых увольнениях разработчиков. На этом фоне мы решили поговорить с теми, кто каждый день работает с кодом, — практикующими разработчиками, техлидами и архитекторами. Их откровения удивили. Оказалось, что между громкими заявлениями и реальностью — пропасть. ИИ действительно умеет писать код, но есть нюансы, о которых молчат в корпоративных презентациях. Разбираемся, где искусственный интеллект незаменим, а где он беспомощен как первокурсник, и почему программисты не торопятся переквалифицироваться в курьеров.

Обычно я пишу про статический анализ, баги и оформление кода. Однако сейчас меня притянуло к тематике РБПО (разработка безопасного программного обеспечения). Это связано с тем, что статический анализ является одним из основополагающих процессов безопасной разработки.

Всё началось с цикла публикаций про ГОСТ Р 56939-2024 в моём Telegram-канале "Бестиарий программирования". Мой внимательный читатель Виталий Пиков из УЦ МАСКОМ, увидев это, пришёл и сказал: "А давай больше!" Он предложил запустить целый цикл совместных вебинаров, где последовательно разобрать все 25 процессов, описываемых в ГОСТ Р 56939-2024. И идея мне понравилась.

Привет, Хабр! В данной статье хочу разобрать auditd - полезный инструмент аудита в Linux, который записывает каждое действие, а скрипт превратит логи в читаемые отчёты и алерты.

Linux-сервер без мониторинга активности пользователей — как дом с открытыми окнами. Проблемы, которые помогает решить auditd:

• Несанкционированный доступ (кто и когда использовать, например, sudo)
• Подозрительные команды (rm -rf, изменение прав, доступ к каким-либо файлам)
• Расследование инцидентов (кто что натыкал перед падением сервера)
• Соответствие корпоративным стандартам (возможно, ИБ требует логирования действий или вы любите контроль)

Решение: auditd + Python-скрипт для анализа и алертов.

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

— И это после всего, что я вам рассказал? — я, конечно, уже слышал подобные заявления от потенциальных клиентов, но каждый раз удивлялся.
— Ну да. Зачем нам эти прототипы и функциональные спецификации? Я уже несколько проектов запустил со своей командой и точно могу сказать: никто документацию не читает.
— А как же вы ставите задачу на разработку?
— Пишу небольшую вводную — и всё. В основном, на словах объясняю. Я же каждый день с разрабами общаюсь. Да и сам немного программист. Мы же с вами оба понимаем, что этап проектирования — это просто способ для вас заработать дополнительных денег.

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

— Ну что ж, понимаю. Тогда давайте попробую вам рассказать одну небольшую историю…

Каждый второй комментарий к новостям о российских дистрибутивах Linux можно сформулировать как "опять перерисовали шильдики".

Причем объяснить с чего перерисовали шильдики, комментаторы зачастую не могут. "Чувствую бесовщину, но доказать не могу!".

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

Но давайте поговорим про дистрибутивы.

Огромную часть жизни мы проводим на работе — и если она не приносит удовлетворения, чувствовать себя ценным и счастливым просто не получится. И это не только личная проблема. Представьте: ходить на работу больше не интересно, все валится из рук — о какой продуктивности может идти речь? К тому же, если ты недоволен работой, растет риск конфликтов с командой и торможения процесса в целом. Но это далеко не всегда значит, что работу нужно менять. Можно попробовать «пересобрать» ее под себя, чтобы она снова стала в радость.

Меня зовут Асия Морозова, я руковожу направлением по обучению и адаптации персонала в MWS и часто выступаю с докладами — например, о том, как бороться с выгоранием, выстроить карьерный трек или пройти программу ротации. Моя любимая тема в последнее время — джоб-крафтинг. Могу говорить об этом часами, практикую сама и другим советую. Сегодняшняя публикация как раз об этом. Давайте вместе разбираться, как взглянуть на рутинные задачи под новым углом и заново (ну или впервые) влюбиться в свою работу.

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

Как старейший «серверный» язык справляется с XXI веком, где безопасность и гибкость важнее вечной стабильности?

Приветствую всех, кто заглянул на огонек! Меня зовут Роман, и я занимаюсь исследованием безопасности Linux (и всякого другого, связанного с ним) в экспертном центре безопасности в Positive Technologies.

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

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

В сфере IT есть сильное профессиональное искажение. Айтишникам кажется, что продукт, который они продают это код. Но в головах их клиентов мир выглядит иначе. Заказчики покупают у айтишников не репозиторий на гитхабе или докер-образ, поднятый на VPS-ке. Они покупают решение своих бизнес-задач. Причём, заметьте, что в этой покупке весь риск лежит на стороне того, кто платит за работу. Потому что гарантия айтишника, что он качественно справится со своей задачей вовсе не гарантирует клиенту, что его бюджет будет потрачен эффективно и его проблема будет решена. Решена именно как бизнес-задача, а не как какая-то другая. То есть, что на выходе от всех затеянных телодвижений будет получен ощутимый положительный финансовый результат.

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

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

В данное статье рассматривается порядок развертывания системы сбора резервных конфигураций сетевых устройств производства Cisco Systems и Juniper Networks, посредством применения «Ansible» и «GitLab». Подробно описан процесс развертывания данных инструментов с помощью docker‑compose.

Всем привет. Я сетевой инженер в интернет провайдере. В данном посте я расскажу, как я сделал для техподдержки инструмент, для мониторинга абонентских ONU на Python. И избавился от кучи ручной работы.

Это статья в формате вольного пересказа более чем сорокалетнего периода работы с разными ОС, главным образом с ОС мейнфрейм, и размышлениями об их сходстве и различиях (в большей степени о различиях, конечно).

Многие популярные ОС выполняются на серверах (речь в статье пойдет исключительно про серверные ОС) х86 (Intel, AMD). Это Линукс разных мастей и названий, и Windows. В силу уклона российского образования в сторону инфраструктур на основе х86 у многих айтишников есть твердое убеждение, что то, как написаны известные ОС, это единственный вариант, как ОС и могут быть написаны. Попытки писать свою, российскую, ОС сводятся к написанию очередного Линукса.

Но есть и другие, современные ОС, выполняющиеся не на х86 платформе. Это одна из ОС IBM мейнфрейм (МФ), называемая z/OS. IBM МФ — тоже весьма современная техническая платформа. В апреле этого года IBM анонсировали новое поколение z17, т. е. семнадцатое поколение, начавшее свою историю в далеком 1964 году.

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

В данной статье разберем:

- Важность подбора правильного шрифта

- Как выбрать шрифты?

- Где искать шрифты?

- Размер и расстояние – основа удобства

- Контраст и цвет текста

- Ошибки, которые портят типографику и как их избежать

Суворов Александр Васильевич сказал: «Каждый солдат должен знать свой маневр». Эти слова идеально подходят и для корпоративного управления. Чтобы побеждать в конкурентной борьбе, важно не просто следовать строгим приказам и схемам, а давать сотрудникам возможность действовать гибко и самостоятельно, понимая свои задачи и условия их выполнения.

В этом контексте традиционные инструменты, такие как BPMN, начинают терять свою привлекательность, уступая место более продвинутым технологиям, таким как DMN.

Как получить прозрачность в бизнес-процессах, если архитектура строится на микросервисах и событийных потоках? В своей статье Бернд Рюкер, сооснователь Camunda, делится практическими подходами к отслеживанию и управлению процессами в распределённых системах. Он объясняет, как переход от простого мониторинга событий к полноценной оркестрации помогает лучше понимать происходящее, своевременно реагировать на инциденты и сохранять контроль над сложными бизнес-операциями. В статье разбираются плюсы и минусы различных подходов — от Elastic-подобного мониторинга до использования движков рабочих процессов, а также рассматривается важность баланса между оркестрацией и хореографией.

Спрос на клининговые услуги в корпоративном секторе в 2025 году вырос на 20%, а дефицит сотрудников достиг 30%. Вручную управлять персоналом в таких условиях крайне сложно. Для эффективной работы даже с десятком объектов потребуется автоматизация.

На примере клининговой компании покажу, как решение на базе low-code BPM-платформы автоматизирует полный цикл работы с персоналом: поиск, приём, онбординг и увольнение, контроль смен и исполнительской дисциплины, начисление зарплат, учет больничных и отгулов. Оно также подойдёт для курьерских служб, доставки еды, управляющих компаний ЖКХ и других сервисных организаций.