Привет! Меня зовут Александр Денисов, я из команды мобильного Яндекс.Браузера в Санкт-Петербурге. В этом посте расскажу вам, как мы справляемся с циклическими крешами на старте.
Каждый разработчик знает, насколько важна для пользователя надёжность продукта. В работе над стабильностью приложения могут помочь выстроенные процессы разработки и тестирования, продвинутые средства диагностики. Однако всё предусмотреть невозможно, особенно если ваш проект большой и сложный. И рано или поздно вы, скорее всего, столкнётесь с проблемой циклического креша на старте. Сейчас разберёмся, как можно обработать этот сценарий.
В качестве примера будет выступать приложение Яндекс.Браузер для iOS: более 100 тысяч исходных файлов, тысячи коммитов в год и около тысячи модулей без учёта ядра (Swift + Objective-C). Кстати, не так давно мы рассказывали, как помогли команде Swift ускорить отладчик.
Представьте, что в вашем приложении есть баг, приводящий к крешу. Несложно, правда? Причём возникает баг из-за редкого сочетания факторов, и происходит это на старте. С некоторой вероятностью баг останется незамеченным во время тестирования и попадёт в версию для App Store. А дальше пострадавшие пользователи столкнутся с приложением, которое крешится прямо на старте, и перезапуск уже не помогает — только переустановка.
Легко ли разработать новый API? На что обратить внимание, чтобы не ошибиться при реализации, и к каким компромиссам стоит быть готовым?
Привет, Хабр! Меня зовут Иван Ивашковский. Я руковожу группой разработки международных проектов в Яндекс Go. Этот пост — продолжение цикла историй о вымышленном стажёре Васе. Предыдущий материал, про идемпотентность, можно почитать здесь. В посте я расскажу, как Вася разрабатывал API для новой фичи и с какими проблемами он столкнулся в процессе. В конце приведу чеклист с советами, как проверить себя на каждом этапе разработки, если вы решаете похожую задачу.
operator[](int, int, int)std::optionalstd::move_only_functionstd::basic_string::resize_and_overwritestd::views::zip и zip_transform, adjacent, adjacent_transform
source.cpp:
#include <bits/stdc++.h>
using namespace std;
int main() {
int a, b;
cin >> a >> b;
cout << a + b << endl;
}
Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.
Меня зовут Денис Кореневский, я работаю в службе разработки внутреннего хранилища Яндекса, и сегодня я расскажу, как YARL устроен внутри, почему мы вообще написали своё решение и с какими трудностями нам пришлось столкнуться в процессе создания. Добро пожаловать под кат.
