Привет, Хабр! На связи команда «Исходного Кода».

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

Но на практике мы редко ограничиваемся простым cache->get() и базовым TTL, особенно когда приложение крутится не на одном сервере, а в Kubernetes-кластере с пачкой внешних API и жесткой конкуренцией запросов. В таких условиях кэш - это уже не только про скорость, но и про синхронизацию состояния между процессами и pod'ами.

Привет, Хабр! На связи «Исходный Код». Сегодня разбираем инструмент, который мы все запускаем по сто раз на дню, но часто воспринимаем как черный ящик. Без него мы бы до сих пор собирали проекты руками, писали скрипты на bash и страдали от вечного «у меня собирается, а у тебя нет».

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

Спойлер: оба, но по-разному - и это важно понимать.

Каждый раз, когда слышим «у нас все нормально с безопасностью, мы же не банк», что-то внутри сжимается. За этой фразой обычно стоят токены аутентификации в SharedPreferences, SQL-запросы без параметризации и Firebase без правил доступа. Эта статья - попытка честно сравнить два мира, найти точки пересечения и разобраться, почему одни проблемы одинаковые, а другие - принципиально разные.

Исходные данные: OWASP Top 10 Web 2025, OWASP Mobile Top 10 2024, статистика NVD/CVE-базы, данные реальных пентестов, IBM Cost of a Data Breach 2024.

Привет, коллеги! 

Сегодня мы копнем в самую суть инженерного подхода. На повестке дня - сравнение двух кардинально разных философий создания сложного UI-компонента. Это не просто рассказ о DatePicker, это анализ стратегического выбора, который каждая команда делает каждый день: скорость в ущерб предсказуемости или наоборот?

Исходный код доступен по ссылке: https://github.com/Codesrc-public-ru/ralf-datapicker

За основу мы возьмем два реальных кейса. Первый - «AI-драфтинг», отлично описанный нашей статье "Создаем WCAG-доступный DatePicker на React: как Claude пишет основу, а мы доводим до ума". Идея: получить 80% кода от нейросети, а остальное довести вручную. Это путь быстрых итераций и реактивного решения проблем.

Второй - «Системный инжиниринг», подход описан в этой документации к инструменту https://github.com/snarktank/ralph. Идея: сначала детальное проектирование, потом итеративная работа модели. Это путь проактивного управления сложностью.

Оба приводят к результату. Но какой ценой? И что скрывается под капотом каждого из них? Давайте разберем.

Привет, коллеги! Сегодня делимся историей, которая отлично показывает, как AI ускоряет старт, но человеческий опыт и внимание к деталям делают продукт по-настоящему крутым.

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

Так вот, казалось бы, компонент простой, но мы решили не просто взять готовую библиотеку. Во-первых, хотелось понять «а как там внутри», а во-вторых - поставить себе планку: сделать его по-настоящему доступным по всем канонам WCAG. Ну и, конечно, не без эксперимента: «А что, если Claude напишет основу?»

Так началось наше приключение с созданием полностью доступного компонента выбора даты с использованием React и Typescript, следуя строгому паттерну WAI-ARIA APG «Date Picker Dialog»

Приготовьтесь к инсайтам, багам и победам!

Привет, хабровчане!

Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. 

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

Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.