Разработка

Привет! Меня зовут Анатолий, я ведущий разработчик в ITFB Group, и сегодня я хочу рассказать о том, как можно превратить скучные тесты в главного специалиста по продукту.

Знакомо: ваши JUnit-тесты проходят, CI/CD зелёный, все довольны. Но тут приходит бизнес-аналитик и спрашивает: "А этот сценарий проверяет, что будет, если клиент с рейтингом 700 запросит 10 миллионов?"

Вы начинаете лихорадочно копаться в коде, пытаясь найти тот самый @Test... А что если бы ответ на этот вопрос лежал не в глубинах Java-кода, а в красивом, читаемом файле, который понятен всем — от тимлида до заказчика?

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

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

Пошаговый разбор с метафорами, формулами и лайфхаками, которые спасут ваш fit()

Привет, хабровчане! В мире ML градиентный спуск это двигатель внутреннего сгорания: он везде, он работает, но мало кто заглядывает под капот, а ведь именно он превращает случайные веса в модель, которая угадывает котиков, переводит тексты и генерирует картинки.

Вы запускаете model.fit() - и через 100 эпох у вас есть результат, но как именно нейросеть «находит выход» из хаоса параметров? Почему иногда она перепрыгивает минимум, а иногда зависает в тупике? И как настроить learning_rate, чтобы не ждать до пенсии?

Полный разбор с нуля, с формулами и примерами. Давайте разберём по полочкам, чтобы было понятно даже новичку.

Привет, Хабр! Конструкции вроде 2>&1 и &> встречаются повсюду — в мануалах, скриптах, инструкциях. Их используют постоянно, но редко понимают до конца. Почему ошибки продолжают появляться в терминале, хотя, казалось бы, должны уходить в файл? Почему конвейер передаёт только часть вывода?

В статье разберём всё от базового синтаксиса до работы с tee и /dev/null - каждая часть будет разобрана и показана на практических примерах.

После первоначального доступа к Windows‑хосту (обычно это базовая shell/метерпитетер) злоумышленник или тестировщик (аха, то есть мы) часто ограничен правами. Чтобы повысить привилегии, требуется быстро перечислить файлы, директории, права, журналы и хранилища (SAM и др.). Объём артефактов в Windows огромен, и ручная проверка даже при хорошем опыте занимает много времени. Логичный путь — автоматизировать перечисление с помощью скриптов и чекеров. Тема незаменима на экзамене OSCP и при прохождении тачек на HTB.

«Эскалация привилегий» — стадия после компрометации, в рамках которой собирается критичная для системы информация: скрытые пароли, слабоконфигурированные службы/приложения, уязвимые политики, кривой доступ, лишние сервисы в RAM и т.д. Именно эти сведения позволяют выполнить пост‑эксплуатацию и получить более высокий уровень прав.

Я уволился из своей первой работы SRE‑инженером после особенно тяжелой недели дежурства. Семь ночей подряд я просыпался от PagerDuty. Семь ночей подряд я чинил одну и ту же проблему с памятью, которую никто не хотел исправлять «по‑настоящему», потому что «горячий фикс же работает». На восьмое утро я пришел в офис и положил заявление на стол.

Это было пять лет назад. С тех пор я прошел через четыре компании, построил on‑call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on‑call ротацию, которая не приведет к массовым увольнениям.

Мы побывали на презентации «Алиса, что нового?», на которой Яндекс представил новые нейросетевые функции. Показали универсальную нейросеть Алиса AI, которая доступна не только в чате, но и в браузере, и скоро появится в носимых устройствах. В этой статье рассказываем обо всех анонсах.

Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"

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

Поводом для написания этой заметки стало обсуждение на недавнем отраслевом мероприятии задач мультимодерации контента: как быстро и надёжно находить «взрослые» сцены в длинных видео и автоматически подсвечивать фрагменты для ручной проверки. Похожие кейсы регулярно встречаются и в открытых соревнованиях по ИИ (например, в подборке задач Wink AI Challenge на Codenrock).

Знаете, что я делал вчера с 10 до 12 утра? Деплоил новую версию на production. Вручную. На 15 серверов. По SSH. В 2024 году. И это не самое грустное. Самое грустное — что я делаю это каждую неделю. И каждый раз обещаю себе, что вот на следующей неделе точно автоматизирую. Но следующая неделя наступает, и я снова сижу и копипащу команды в терминал.

Если вы узнали себя — добро пожаловать в клуб анонимных toil-оголиков. Давайте поговорим о том, почему мы все еще делаем руками то, что должны были автоматизировать еще вчера.

ИИ давно обещает ускорить работу разработчиков — но что, если в реальных условиях он делает обратное? Команда исследователей провела рандомизированное контролируемое испытание с опытными контрибьюторами крупных open source проектов, чтобы понять, как современные инструменты вроде Cursor и Claude влияют на скорость и качество разработки. Результат оказался неожиданным: при работе с ИИ программисты тратили больше времени, хотя были уверены, что работают быстрее. Разбираемся, почему эффект ускорения может быть иллюзией, и какие факторы превращают помощника в тормоз.

Всем привет! Я Алексей Босенко, DevOps-инженер в компании KTS. В этой статье я покажу, как комплексно настроить быструю и эффективную сборку проектов в Kubernetes с использованием BuildKit, которая учитывает не только производительность, но и стоимость ресурсов.

Под этой громкой фразой я подразумеваю целый комплекс решений: как создать и настроить экономичный кластер Kubernetes для сборок (ведь цена вопроса всегда важна), как настроить GitLab Runners и как сделать эффективное масштабирование сборок. Особый акцент будет на том, почему мы выбрали BuildKit, какие варианты использования он предлагает, и как непосредственно настроить один из них.

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

Здраствуйте дорогие коллеги, сегодня с вами будет изучать тему HA Paloalto. Для этого нам понадобится 2 paloalto.

Как всегда будем все реализовать на практике, и буквально чутка теории)

HA = дублирование двух (или до 16) Palo Alto для отказоустойчивости. Один работает (Active), второй пассивный ждет... (Passive). Если активный падает , то пассивный мгновенно берёт на себя сессии и конфигурацию, если конечно же настрое преемтинг!

Синхронизируется:

Привет, Хабр! Меня зовут Мария Рачева, я ведущий аналитик процессов безопасной разработки в Swordfish Security.

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

Всем привет! В этой коротенькой статье я попытаюсь вам доказать, что внешние ключи (foreign keys) в СУБД — не нужны и только вредны.

Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.

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

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

Бывает, разработчик завершил задачу, выполнил все по ТЗ. Но заказчик просит все переделать. Можно сколько угодно ворчать или брать оплату за работу, которая не попала в прод. Но ситуацию это не меняет: сырые задачи будут приходить, результат будет уходить в стол. 

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

Команда проекта Valhalla выпустила early-access сборку JDK с полной реализацией JEP 401 — value-классы и объекты теперь можно попробовать в действии! В новом переводе от команды Spring АйО — примеры использования, объяснение концепции, сравнение производительности с обычными объектами и практические советы для разработчиков.

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

Привет Хабр! Меня зовут Алексей и я занимаюсь беспроводными технологиями. На написание этой статьи меня сподвиг комментарий уважаемого @NightFlight который обратил внимание, что многие пользователи ориентируют антенны у роутеров по типу ориентации «заячьи уши» \/ так, как это делали для комнатных телевизионных антенн. В этой статье вспомню немного теории, расскажу о разных типах антенн, поляризации, и о том как лучше ориентировать антенны у бытовых роутеров в зависимости от их количества и как ориентация может повлиять на beamforming.

Правильная ориентация антенн Wi-Fi роутера может существенно улучшить качество беспроводного соединения, увеличить скорость передачи данных и расширить зону покрытия сети. Согласно моим тестам, оптимизация расположения антенн способна повысить скорость соединения на 50-300%, а в некоторых случаях улучшить уровень сигнала на 2-4 дБ, что критически важно для устройств, находящихся на границе зоны покрытия. При неправильной ориентации, особенно при несовпадении поляризации передающей и приемной антенн, потери сигнала могут достигать 20 дБ, что фактически делает соединение невозможным.