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

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

Ответить на эти вопросы помогают нагрузочные тесты. В статье рассмотрены ключевые идеи подхода к их реализации: какие тесты запускать, когда и где это делать, кто несёт ответственность за их написание и на что стоит обратить внимание при анализе результатов.

Привет! Меня зовут Анна и я QA-инженер в Банки.ру. В этой статье я расскажу о том, как мы сделали инструмент нагрузочного тестирования доступным для каждого инженера в компании.

Представьте: команда запускает новый микросервис, который будет отдавать информацию о банковских продуктах. Сервис покрыт автотестами, билды зеленые, все работает штатно. Но через пару часов после деплоя в прод сервис начинает падать под наплывом пользователей, время ответа превышает 10 секунд, разделы лежат, ПАНИКА!

Знакомо? У нас было подобное. В статье расскажу подробно про наш опыт!

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

У меня двадцать лет в IT. Большую часть этого времени я проектировал и эксплуатировал инфраструктуру на PostgreSQL. Сейчас работаю архитектором: Go, Python, Postgres, Redis, ClickHouse, мониторинг на десятки тысяч баз. До этого писал на Ruby, пробовал Rust. Классический бэкенд-инженер со всеми вытекающими привычками: императивный код, мутабельное состояние, постоянные if err != nil { return err }.

А потом я начал писать бэкенд на Gleam — молодом функциональном языке на BEAM (Erlang VM), который появился в стабильной версии только в 2024 году. Навык ещё в разработке, но бэкенд уже работает, и я не жалею. Путь был... познавательным.

Эта статья — не туториал и не рекламный буклет. Это честный рассказ о том, почему я выбрал Gleam, какие шишки набил, что мне понравилось настолько, что я не хочу возвращаться, и что до сих пор бесит.

Привет! Меня зовут Анна Ахлёстова, я Flutter-разработчик в Friflex. Мы разрабатываем мобильные приложения для бизнеса и специализируемся на Flutter. В статье я расскажу о том, как мы решаем основные задачи бизнеса с использованием возможностей Яндекс Карт на Flutter.

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

Под катом рассказываем, с чем мы столкнулись при подготовке первого внутреннего митапа МойОфис, что у нас в итоге получилось и какие мы сделали выводы.

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

Рассказываем про нейросети в Android-приложениях: какие есть инструменты для внедрения, как создавать свои модели и использовать готовые.

В один из зимних вечеров я сидел дома, читал замечательную книжку «Android-программирование для профессионалов» и наткнулся на главу про Accessibility. Раньше я об этой теме не задумывался: клал null в поле contentDescription и жил себе спокойно. Но когда узнал, как слабовидящие люди пользуются смартфоном, у меня появилось желание погрузиться в тему доступности глубже.

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

О том, как распутать джунгли MVI, используя Джунгли собственного производства, и получить простое и структурированное архитектурное решение.

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

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

Если вы стали лидом и первоначальная эйфория сменилась небольшим горением и унынием, то пара советов не будет лишней.

Ваши пользователи жалуются на то, что приложение очень быстро сажает заряд телефона? Запущенный фоновый сервис внезапно останавливается? Сообщения от FCM не доходят до пользователя? Что связывает эти три серьезных вопроса? Ответ прост — неверно выстроенная работа с энергопотреблением приложения.

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

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

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

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

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

«Замедление программ происходит куда быстрее, чем ускорение компьютеров»

«Около 25 лет назад интерактивный текстовый редактор умещался всего в 8000 байт, а компилятор в 32 килобайта, тогда как их современные потомки требуют мегабайтов. Стало ли всё это раздутое программное обеспечение быстрее? Нет, совсем наоборот. Если бы не в тысячу раз более быстрое железо, то современное программное обеспечение было бы совершенно непригодным».