Разработка

Стань спикером SOC Forum 2025 — сделай вклад в развитие безопасного цифрового общества

С 17 по 23 ноября состоится Российская неделя кибербезопасности — масштабная серия событий для обсуждения темы ИБ в государстве, бизнесе и граждан. Главная цель Недели — создание и развитие безопасного цифрового общества. Ее ядром станет ежегодный SOC Forum, который пройдет в Москве 19-20 ноября. Форум притянет еще больше профессионалов и лидеров отрасли для выстраивания стратегий защиты от самых актуальных киберугроз. Сбор докладов на форум уже открыт. ГК «Солар» — организатор Недели и соорганизатор форума.

SOC Forum 2025 – это:

• Новая масштабная площадка — «Тимирязев центр»;

• 9 тематических треков – о влиянии ИИ на киберугрозы и отражение атак, о поиске и удержании талантливых ИБ-специалистов, о преобразовании данных о кибератаках в конкретные меры защиты и другие;

• Больше форматов – от воркшопов и питч-сессий до персональных встреч.

Сбор докладов: без продаж и «воды»

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

При оценке докладов жюри будут учитывать: актуальность, новизну и практическую пользу. Жюри будет отклонять заявки с рекламой продуктов или услуг без уникальных кейсов, а также попытками «продать», а не поделиться экспертизой. Это означает, что на SOC Forum попадут только самые острые для ИБ-сообщества доклады, все они будут уникальны и полезны участникам отрасли. В прошлом году конкурсное жюри отобрало 151 заявку из 354 поданных.

Новые треки: ИИ и люди на защите от киберугроз

SOC Forum в 2025 году станет главным местом для построения эффективного диалога между регуляторами и представителями ведущих ИТ- и ИБ-компаний — от глав компаний, CISO и директоров финансовых и коммерческих подразделений до экспертов по кибербезопасности и молодых ИБ-специалистов. Каждый день будет посвящен новым тематическим трекам.

День 1 (19 ноября):

• AI & Cybersecurity: как искусственный интеллект меняет ландшафт киберугроз, инструменты защиты и ставит этические вопросы перед ИБ и ИТ- сообществом;

• Естественный интеллект: как искать талантливых ИБ-специалистов, грамотно оценивать их навыки и сохранять мотивацию;

• ИБ и бизнес: как CISO и ИБ команды могут не только защищать, но и помогать компаниям выигрывать у конкурентов и снижать риски простоя бизнес-процессов;

• Тренды и аналитика угроз: как превращать данные о киберугрозах в конкретные меры защиты, чтобы оставаться на шаг впереди хакеров;

• Многогранный кибербез: cамые нестандартные и экспериментальные темы отрасли.

День 2 (20 ноября):

• Offense: технические разборы и кейсы реальных кибератак от лучших ИБ-специалистов и пентестеров;

• Defense: разбор наиболее актуальных технологий защиты, реагирования и обнаружения киберугроз, а также закрытия уязвимостей, которые «невозможно исправить»;

• Архитектура ИТ и ИБ: как построить безопасную комплексную архитектуру для защиты не только «здесь и сейчас», но и на долгие годы вперед;

• SOC-практикум: обсуждения наиболее эффективных кейсов работы с NTA/EDR, SIEM и другими техническими средствами.

мои способы работы с AI контекстом (субъективное мнение):

1. пользоваться общеизвестными терминами которые точно есть в словарях

2. пользоваться только английским для кода, prd и дизайна

3. сокращать код - как показывает практика файлы больше 500-600 строк агенту труднее прочитать. Тут есть несколько стратегий:

• пользоваться препроцессорами, например можно сильно срезать времени если вместо JSX/TSX/html использовать pug

• пользоваться и писать библиотеки. есть проблема - оформляем в абстрактную библиотеку, пишем доку и readme

• предвидеть контекст - часть текста просто можно не писать, а просить догенерить, потому что получится эффект снежного кома, начинаем катить, смотрим куда катится - сокращаем

4. меняем JSON на YAML или что-то близкое - это срежет кууучу лишнего хлама в виде ; }{ "" и прочих символов

5. генерим code maps - mermaid и другие виды диаграм

6. ANSII - визуализация простых идей, но не все модели хорошо работают с этим форматом, есть проблемы с layout. например я пользуюсь gemini

7. подстраивать архитектуру и код под задачи и бизнес, не наоборот. Developer | Designer | AI as User.

8. разбивать на мелкие подприложения если нужно

Надеюсь, что пост окажется полезным :-)

Пожалуйста делитесь своими мыслями в комментариях :-) это поможет сделать эту статью видимой для других и будет здоровской поддержкой и мотивацией :-) 

Спасибо за ваше время и хорошего дня!

мои способы работы с AI контекстом (субъективное мнение):

1. пользоваться общеизвестными терминами которые точно есть в словарях

2. пользоваться только английским для кода, prd и дизайна

3. сокращать код - как показывает практика файлы больше 500-600 строк агенту труднее прочитать. Тут есть несколько стратегий:

• пользоваться препроцессорами, например можно сильно срезать времени если вместо JSX/TSX/html использовать pug

• пользоваться и писать библиотеки. есть проблема - оформляем в абстрактную библиотеку, пишем доку и readme

• предвидеть контекст - часть текста просто можно не писать, а просить догенерить, потому что получится эффект снежного кома, начинаем катить, смотрим куда катится - сокращаем

4. меняем JSON на YAML или что-то близкое - это срежет кууучу лишнего хлама в виде ; }{ "" и прочих символов

5. генерим code maps - mermaid и другие виды диаграм

6. ANSII - визуализация простых идей, но не модели хорошо работают с этим форматом, есть проблемы с layout

7. подстраивать архитектуру и код под задачи и бизнес, не наоборот. Developer | Designer | AI as User.

8. разбивать на мелкие подприложения если нужно

Надеюсь, что пост окажется полезным :-)

Пожалуйста делитесь своими мыслями в комментариях :-) это поможет сделать эту статью видимой для других и будет здоровской поддержкой и мотивацией :-) 

Спасибо за ваше время и хорошего дня!

Привет, смотрите че наговнокодил, вот такую вот проверку конфига для haproxy

if check '/etc/haproxy/haproxy.cfg'; then
red='\e[91m'
ylw='\e[93m'
DEF='\e[0m'
/usr/sbin/haproxy -c -f /etc/haproxy/haproxy.cfg || printf "
${red}WARNING!
${red}Haproxy config has errors!
${ylw} __
${ylw}|  \_____${red}︹${DEF}
${ylw}\        ${red}\ \ ${DEF}
${ylw}/  ______${red}/ / ${DEF}
${ylw}|__/     ${red}︺ ${DEF}
"
fi

Выглядит вот так:

Как вам?)

Творите, выдумывайте, пробуйте!)

SourceCraft поддержит опенсорс‑разработчиков: старт грантовой программы с 16 августа и новые возможности платформы

Платформа для разработчиков SourceCraft открывает приём заявок на участие в грантовой программе поддержки: гранты на облачные технологии Yandex Cloud в размере 600 тыс. рублей на год получат важные и интересные опенсорс‑проекты, отвечающие критериям отбора. Подать заявку можно с 16 августа на сайте программы.

Оценивать проекты будут эксперты Яндекса. Среди ключевых критериев оценки:

• активность репозитория,

• актуальность,

• практическая польза проекта,

• понятный вектор развития.

Дополнительно, будет учитываться позиция в общем рейтинге на платформе SourceCraft, которая также пополнилась новыми инструментами:

• интеллектуальным алгоритмом для оценки значимости репозитория,

• системой личных достижений в профилях разработчиков.

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

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

Кроме того, 16 августа на платформе стартует конкурс проектов для опенсорс‑сообщества. Авторы новых репозиториев на платформе, которые наберут наибольший рейтинг до 31 августа, получат наборы эксклюзивного мерча от SourceCraft.
Следить за новостями от разработчиков и архитекторов платформы — также можно в блоге SourceCraft.

Как мы ускорили проверку документации с помощью AI-агента: от боли к решению

Привет, Хабр! Я — Мила Муромцева, системный аналитик в Альфа-Банке. Эту статью мы подготовили вместе с нашим разработчиком Мишей Буториным. Написали ее, чтобы поделиться нашим опытом и рассказать, как мы научили LLM проверять документацию для платформы Альфа-Онлайн — переписывали стандарт, боролись с токенами и немного с хаосом.

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

Статья «Как мы ускорили проверку документации с помощью AI-агента: от боли к решению» будет полезна тем, кто автоматизирует проверки, работает с большими данными и хочет, чтобы нейросети давали точные и надёжные ответы — даже при работе с очень громоздкой документацией. Внутри разбираем кейс командной интеграции LLM: от первых ошибок до финального формата отчета, который реально экономит токены и нервы!

Мой способ именования переменных в 1С

В 1С при создании переменной, необходимо чтобы имя переменной было уникальным в пределах модуля, где пишешь код. Не совпадало с именем реквизита формы. Не совпадало с переменными в модуле приложения. Не совпадало с названием свойства. Не совпадало с названием встроенных методов языка. Из этого так же вытекает, что при анализе чужого кода, не просто понять, что за именованная сущность перед тобой. Эта проблема хорошо описана в книге "1С:Предприятие 8.3. Практическое пособие разработчика" на странице 177. Приведу отрывок из книги:

Допустим, в модуле формы нам встретилось выражение: СтрокаТабличнойЧасти = ЭлементыФормы.Материалы.ТекущиеДанные.

Как понять, что такое СтрокаТабличнойЧасти? Нужно вспомнить, из чего состоит контекст формы:

• локальный контекст самого модуля формы;

• реквизиты формы, которой «принадлежит» модуль;

• свойства и методы объекта УправляемаяФорма встроенного языка;

• свойства и методы расширения формы, определяемого типом того объекта, данные которого содержатся в основном реквизите формы;

• глобальный контекст, в том числе неглобальные общие модули и экспортируемые функции и процедуры глобальных общих модулей;

• экспортируемые переменные, процедуры и функции модуля управляемого приложения.

  Далее по порядку проверить:

• 1. Объявлена ли в модуле формы переменная СтрокаТабличнойЧасти? Нет.

• 2. Есть ли у формы реквизит СтрокаТабличнойЧасти? Нет.

• 3. Есть ли у объекта УправляемаяФорма свойство СтрокаТабличнойЧасти? Нет.

• 4. Есть ли у расширения формы свойство СтрокаТабличнойЧасти? Нет.

• 5. Есть ли свойство глобального контекста СтрокаТабличнойЧасти? Нет.

• 6. Есть ли в модуле управляемого приложения экспортная переменная СтрокаТабличнойЧасти? Нет.

• Значит СтрокаТабличнойЧасти – это локальная переменная, определяемая непосредственно в этом операторе присваивания.

Для упрощения себе жизни ввел такое правило именования:

• Параметрам процедур и функций добавляю префикс "п"

• Переменным внутри модуля добавляю префикс "л"

• Реквизиты формы без префикса

Пример

&НаСервере
Процедура ЗаписатьШаблонНаСервере(пСсылка) 
	
	лОбъект = пСсылка.ПолучитьОбъект();
	лОбъект.Шаблон.Очистить();
	
	Для каждого Стр Из Шаблон Цикл
	
		НовСтр = лОбъект.Шаблон.Добавить();
		ЗаполнитьЗначенияСвойств(НовСтр, Стр);	
	
	КонецЦикла;
	
	лОбъект.Записать();
	
КонецПроцедуры

Таким образом данная проблема решается радикально. И голова значительно разгружается.

А вы уже пробовали запустить свой проект с помощью бесплатного объема облачных ресурсов Evolution free tier?

Тогда поделитесь опытом и мнением — опрос займет не больше 5-7 минут.

Пройти опрос 👈

Так мы узнаем, что еще можно улучшить, чтобы free tier стал для вас еще удобнее и полезнее. А еще, в перспективе сможем подключить его и для других облачных сервисов 😉

Текущие условия:

• виртуальная машина в конфигурации 2vCPU, 4 ГБ RAM, диск 30 ГБ;

• ежемесячный объем хранилища S3 — 15 ГБ, 100 000 операций PUT/POST/LIST, 1 000 000 операций GET/HEAD, 10 ТБ исходящего трафика;

• ежемесячный объем ресурсов для запуска контейнеров — 120 vCPU x час, 480 ГБ RAM х час.

Этого хватит, чтобы хранить важные данные, развернуть сервер Minecraft, запустить умного Telegram-бота с AI, опубликовать персональный сайт или реализовать любые другие сценарии.

Узнать больше про free tier и попробовать 🕹️

Вынос тестов Zig в отдельные файлы

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

Выносить тесты в отдельные файлы — хорошая практика. Рассмотрим это на примере проекта https://github.com/ktarasov/zigrep.

Для начала создадим директорию tests в корне проекта и файл unit_tests.zig. Перенесем туда все тесты из src/main.zig. В список зависимостей добавим импорт главного модуля: const main_mod = @import("../src/main.zig");. Вызовы функций и структур в тестах модифицируем, добавив к ним модуль, например: main_mod.parseArgs.

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

Далее нужно сообщить компилятору, что тесты теперь находятся в другом месте. Для этого изменим файл build.zig. После строки run_step.dependOn(&run_cmd.step) добавим создание модуля с тестами:

const unit_test_mod = b.createModule({
  .root_source_file = b.path("tests/unit_tests.zig"),
  .target = target,
  .optimize = optimize,
});

Также изменим блок добавления константы exe_unit_tests, указав unit_test_mod в качестве root_module.

Вроде всё готово. Попробуем скомпилировать и запустить тесты...

О нет, ошибка: "error: import of file outside module path: './src/main.zig'". Компилятор не импортирует файлы за пределами модуля unit_tests.zig.

Придется явно добавить основной модуль в импорт test-модуля. Для этого вернемся в build.zig и добавим после создания exe_unit_tests следующую строку:

exe_unit_tests.root_module.addImport("zigrep", exe_mod);

Снова запустим тесты — и они успешно пройдут!

Итого: мы вынесли тесты в отдельный файл и создали иерархию директорий, разделив основной код и тесты.

Пошаговый гайд по работе с RabbitMQ

RabbitMQ — брокер распределенных сообщений, разработанный на основе стандарта AMQP (Advanced Message Queuing Protocol). Этот инструмент собирает потоковые данные из нескольких источников, после чего распределяет и маршрутизирует их для дальнейшей обработки. Выбираем брокер сообщений и подробнее знакомим с его возможностями.

Бенефиты RabbitMQ, которые выделяют его на фоне других похожих сервисов: 

• надежность — все сообщения в RabbitMQ будут доставлены с соблюдением порядка, даже в случае технический сбой;

• масштабируемость — может работать с большими объемами данных. Также его можно развернуть не только на отдельном сервере, но и в распределенной среде;

• гибкость — поддерживает большое количество сценариев для маршрутизации и распределения сообщений. Это позволяет сочетать программу со многими приложениями.

Как настроить RabbitMQ на трех операционных системах: Ubuntu, Debian и CentOS Stream, а также об основных принципах работы этой технологии — читайте в подробном гайде в базе знаний Рег.облака.

DUC meetup #2: узлы кластера, платформа на DKP CE, контроль архитектуры

Если вы работаете с Kubernetes или планируете начать, приходите 21 августа на второй митап Deckhouse User Community в Москве. Будут доклады спикеров из «Фланта», «КРОК» и «ДОМ.РФ», а ещё пицца и пиво. Регистрация — по ссылке. 

Темы докладов и спикеры:

• От рассвета до заката, или Как Deckhouse Kubernetes Platform управляет жизненным циклом узлов кластера — Николай Митрофанов, «Флант»

• Разработка платформы для обучения K8s на основе DKP CE — Кирилл Харитонов, «КРОК»

• Архитектура под контролем: фиксируем изменения с помощью AaC и фитнес-функций — Антон Сафронов, «ДОМ.РФ Технологии»

Встречаемся 21 августа в «Событие Лофт» по адресу: Николоямская улица, 28. Ближайшая станция метро — «Таганская» Кольцевой линии. Программа стартует в 19:00, приходите чуть пораньше. Больше подробностей о докладах и регистрация — на страничке митапа. 

Красные флаги в код-ревью: перегибы, которых лучше избегать

1. Фокус на мелочах. Если уделять много внимания опечаткам и код-стайлу, то времени уйдет много, а реальных результатов будет мало. Главное — это всё-таки архитектура, алгоритмы и производительность, а косметика только на втором плане. Зачем портить настроение себе и команде, если можно ничего никому не портить?

2. Поверхностный анализ. Забивать на проверку кода — тоже плохая идея. И дело даже не в багах, их отловит тестировщик. Дело в безопасности всей системы. Если какой-нибудь хакер найдет уязвимость, которую QA не нашел, — жди беды. Ну и техдолг никто не отменял: если не делать сразу хорошо, однажды придется переделывать.

3. Токсичность. Во время код-ревью лучше всё-таки искать потенциальные проблемы с кодом, а не учить коллег работать. То есть фокус внимания — не на поиске недостатков в чужой работе, а на самом коде. А личные предпочтения и вкусы относительно кода лучше обсуждать отдельно.

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

А каким должен быть хорошее код-ревью — в нашем блоге.

Что такое мнемотехники и как их использовать программистам

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

Как это относится к IT-специальностям? Также, как и к любому другому обучению новому. Возьмём для примера изучение языку JavaScript, где будущему программисту нужно понять, чем отличаются методы call, apply и bind. 

Для запоминания можно использовать мнемотехники:

• Call. Коля звонит другу напрямую — передаёт параметры через запятую: call (a, b).

• Apply. Аня присылает список задач — параметры передаются массивом: apply ([a, b]).

• Bind. Бен привязывает себя к таске — создаёт новую функцию с привязанным контекстом, которую можно вызывать позже.

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

Популярные мнемотехнические приёмы

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

2. Аббревиатуры и акронимы. Составьте из первых букв слов новые слова или фразы. Именно благодаря этой мнемотехнике программисты могут припомнить, что такое KISS, SOLID и DRY.

3. Рифмы и ритмы. Зарифмуйте информацию в стишок, можно самый примитивный. Как пример, стих для запоминания числа Пи (π = 3,1415926): «Чтобы нам не ошибиться, надо правильно прочесть: три, четырнадцать, пятнадцать, девяносто два и шесть».

4. Образные связки. Соедините элементы в единый яркий образ. Допустим, французское слово pomme — «яблоко» — можно связать с таким образом: на помятом яблоке сидит крошечный гном с флагом Франции.

→ Подробнее рассказываем о теме в блоге на сайте.

Почему мы подключаем QA с первого дня проекта

И как это экономит ресурсы, улучшает продукт и снижает количество переделок

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

Команда Doubletapp приняла решение: QA подключаются к проекту на этапе первого ознакомления с ТЗ от заказчика, ещё до оценки, дизайна и начала разработки. Этот подход сильно влияет на качество итогового продукта и помогает заказчику получить то, что действительно нужно — без множества итераций «переделать» и «добавить, потому что забыли».

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

Роль QA в нашей команде: не только тестирование

Наши QA участвуют в проекте с первых дней.

• Структурируют поступившее от заказчика ТЗ

• Выделяют функциональные блоки

• Формируют уточняющие вопросы

• Работают над схемами и диаграммами логики

• Проверяют, насколько требования реализуемы и согласованы между собой.

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

QA плотно взаимодействуют с селлерами и лидами разработки и помогают им формализовать требования. Это снижает нагрузку на менеджеров и ускоряет проработку проекта.

Как это работает на практике

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

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

2. Составляют вопросы, которые передаются в команду, ответственную за коммуникацию с заказчиком.

3. Параллельно разработчики начинают верхнеуровневую оценку трудозатрат. Они тоже собирают вопросы, если логика не до конца ясна.

4. Все вопросы объединяются, уточняются и через менеджеров идут в диалог с заказчиком.

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

Когда это спасло проект

Один из проектов, с которым мы работали, сопровождался очень подробным бизнес-ТЗ — документ содержал более 70 страниц описания сервиса. Всё выглядело детально и проработанно.

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

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

Внутренние процессы: как это устроено

Мы работаем по agile: QA входят в спринты наравне с разработкой. Внутри спринта QA выполняют не только тестирование, но и работу, близкую к системной аналитике:
анализ, структурирование, детализация, согласование требований, построение логики.

Тест-кейсы и баг-репорты ведём в YouTrack и Qase, используем CI/CD, чтобы как можно раньше получать обратную связь по стабильности продукта.

Зачем это заказчику

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

• Прозрачную архитектуру с понятной логикой

• Согласованные требования, переведённые в схемы

• Минимум доработок в процессе разработки

• Экономию времени — на исправление неочевидных ошибок

• Повышенное доверие команды к требованиям — все понимают, что делают и зачем

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

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

Почему недостаточно Unit тестов и нужны Интеграционные?

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

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

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

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

Почему я больше никогда не буду использовать сервис bitly?

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

Long story short: помогают тут ребятам с одним оффлайн проектом, нужно было быстро сделать QR код для флайеров, google выдает миллион сервисов для генерации, выбрал первый попавшийся “Create Your Free QR Codes”.  Удачно все сделал, заказали флаеры, не смотря на то, что по пути на каждому этапе было Free через 2 недели (когда уже все напечатано) прилетает вежливое “Oh no! Your Dynamic QR Codes will expire in 3 days”. И конечно же он перестанет работать если не заплатить ($20/month). 

Масштаб “потерь” - $40, но я готов заплатить $200 чтобы объяснить они строян бизнес на скаме и для кармы это вредно. 

Конечно же я не один такой, и большинство “сжимают зубы” и платят.  Например на редите 230 комментариев. 

Как вы поступаете в такой сиутации?  Я как-то с детства считаю что нельзя потокать и платить. 

Мои действия:

✅ никогда в жизни ни на одном из моих проектов не будет использоваться сокращалка Bitly

✅ написал далобу в FTC

✅ написал отзыв на Google Maps (там таких много)

☑️ найду и напишу отзывы на других сервисах

✅ попрошу вас помочь мне и присоединиться

P.S. Ресеч показал, что это не просто какие-то горе стартаперы, а проект компании Bitly (рейтинг 1.6 на Trustpilot).

Если вам нечем заняться и вам не сложно уделить 2-5 минут своего времени. 

Промпт для генерации отзыва:

Write a concise, neutral review of qr-code-generator.com (Bitly) in plain, easy-to-read language, 80-120 words. Context: It appears in Google for queries like "free qr code generator." During setup, the process is presented as free; any expiration notice, if present, seems absent or buried in terms. About 14 days later, the QR may be deactivated behind a paywall, leaving printed materials unusable unless payment is made to reactivate. The system does not allow converting that now paid QR to a free static code or redirecting it without payment. Many users report similar experiences online, including numerous Reddit comments. Keep the tone calm, factual, and non-accusatory. Do not include personal info or insults. Write in your own words.

Места куда стоит запостить отзыв:

- Google Maps (Bitly Office Google Maps)

- Trust Pilot

- G2

- Capterra

P.P.S. Есть кто-то из СМИ хочет изучить эту историю и написать подробнее - я буду рад ответить на вопросы и предоставить материалы. 

P.P.P.S. Особенно иронично выглядит позиция “Head of Happiness” в подписи письма

#justice 

CSI-драйвер и Swordfish API: как заставить Kubernetes дружить с любым хранилищем

В современных enterprise-средах важно обеспечить стандартизированный доступ к системам хранения данных (СХД) от разных производителей, избегая жесткой привязки к конкретному вендору. Одним из решений этой задачи является использование CSI-драйвера, который взаимодействует с Swordfish API. Такая интеграция позволяет Kubernetes автоматически создавать, подключать и удалять тома, избавляя команды от множества ручных операций.

Процесс выглядит так: когда приложение в Kubernetes запрашивает постоянное хранилище, оркестратор формирует PersistentVolumeClaim (PVC) с нужными параметрами — размером, типом и характеристиками. Kubernetes определяет, что создание тома должно выполняться через CSI-драйвер, и передает запрос в эмулятор Swordfish API. Тот создает том, а в случае работы с файловыми системами (например, NFS) дополнительно настраивает подключение к серверу и возвращает CSI-драйверу сведения о готовом ресурсе.

Дальше Kubernetes связывает созданный том с заявкой PVC, после чего CSI-драйвер монтирует его на рабочий узел к нужному контейнеру или поду. Эмулятор Swordfish API при этом добавляет путь к каталогу в конфигурацию NFS (/etc/exports), что позволяет клиентам подключаться к сетевому хранилищу.

Когда хранилище больше не нужно:

• DevOps удаляет PVC.

• Kubernetes вызывает NodeUnpublishVolume для размонтирования тома с узла.

• CSI-драйвер передает команду Swordfish API.

• API удаляет том и освобождает ресурсы (в случае NFS — удаляет запись из /etc/exports и каталог).

• Kubernetes удаляет объект PV, завершая процесс.

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

Если интересно, как самостоятельно разработать CSI-драйвер с поддержкой Swordfish API и запустить его даже без реального оборудования, то об этом — в статье, где пошагово показано, как реализовать и протестировать решение.

Что общего между Индией и Standoff Bug Bounty?

Standoff Hacks пройдет в Индии, и ты можешь полететь туда вместе с нами!

→ Во-первых, на нашей платформе активно багхантят ребята из Индии.
→ Во-вторых, наш следующий ивент Standoff Hacks пройдет 13 сентября в Ахмадабаде.
→ А в-третьих — у тебя есть шанс попасть на него за наш счет!

🔎 Для этого тебе нужно... Багхантить (surprise)! И набрать с момента публикации этого поста до 18 августа как можно больше баллов по этим публичным программам:

🔹 Timeweb

🔹 Rambler&Co

🔹 Инфосистемы Джет

🔹 Купер

🔹 Т-Банк

🔹 Wildberries

🔹 VK

🔹 Ozon

🔹 Мегамаркет

🔹 Craftum

Баллы по программам суммируются. Трех самых активных багхантеров мы возьмем с собой в Индию 🇮🇳

А дальше на Standoff Hacks тебя будут ждать:

• Эксклюзивный доступ к новому скоупу с огромными выплатами.

• Новые знакомства, крутая атмосфера и яркие впечатления.

• И бонусом — участие в конференции BSides Ahmedabad.

शुभकामनाएं। 🙏

P.S.: багхантеры, которые сдадут хорошие отчеты в Wildberries, получат приглашение в приватную программу от маркетплейса с эксклюзивным скоупом.

Да, это Артем. Хорошо живет, купается в бассейне, пьет джус 🧃

И запускает Кубер за рубль, чтобы вы смогли его затестить.

Подробности по тарифу:

➖ Полный доступ к интеграциям: внешний балансировщик, сетевые диски, S3 и др.
➖ Без ограничений внутреннего функционала
➖ Можно создать до 3 тестовых кластеров и в каждом до 10 воркер-нод

Запустить кластер за 1 ₽ →