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

Такая ситуация может происходить по разным причинам. Однако, чаще всего на старте разработки, бэкэнд просто не написан и клиент начинает без него. В таком случае начало разработки затягивается на 2-4 месяца.

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

Сейчас все больше компаний готовы к найму удаленных сотрудников. Для работодателей это расширяет возможность выбора высококвалифицированных специалистов. В Surf найм удаленных сотрудников практикуется уже давно, на данный момент 40% работают дистанционно — разработчики и менеджеры. Удаленных QA мы не нанимаем из-за специфики мобильной разработки — нужен большой парк устройств, на которых проводится тестирование, и это сложно организовать дома. Процессы в Surf адаптировались к работе с удаленщиками в отлаженный механизм, который позволяет организовать эффективную работу над проектами.

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

Это первая часть из цикла статей о библиотеке ReactiveDataDisplayManager (RDDM) от команды iOS разработки Surf. В этой статье я опишу частые проблемы, с которыми приходится сталкиваться при работе с «обычными» таблицами, а также дам описание RDDM.

Прошедший Google I/O 2019 принёс массу нашумевших новинок, многие из которых будут влиять на индустрию мобильной разработки в ближайшие годы. Не менее интересно было следить за зарождающимися трендами. Сначала в историю ушли механические клавиши управления, экраны смартфонов становились всё больше, а боковые рамки всё незаметнее. На смену экранным системным кнопкам пришли жесты, оставляя всё больше пространства для потребления контента. Приложения отображаются на всей видимой поверхности дисплея, от нижней до верхней рамки, не стесняя себя условными границами статус-бара и навигационной панели. Мы на пороге эры Edge-to-Edge.

Разработка бэкенда — сложный и затратный процесс. При разработке мобильных приложений ему зачастую уделяется неоправданно больше внимания. Неоправданно, потому что каждый раз приходится реализовывать типичные для мобильных приложений сценарии: отправить push-уведомление, узнать сколько пользователей заинтересовались акцией и оформили заказ и т.п. Хочется решение, которое позволит сфокусироваться на важных для приложения вещах без потери качества и деталей в реализации второстепенных. И такие решения есть!

Подобные сервисы называются Mobile Backend-as-a-Service (MBaaS). Процессы создания бэкенда с их помощью упрощены, по сравнению с разработкой «вручную». Это экономия на найме отдельного backend-разработчика. А тот факт, что провайдер MBaaS берет на себя все вопросы, связанные со стабильностью серверов, балансировкой нагрузки, масштабируемостью и прочими инфраструктурами сложностями, придает уверенности в качестве полученного результата и является основным преимуществом таких сервисов.

В этой статье рассмотрим несколько крупных и зарекомендовавших себя сервисов: Microsoft Azure, AWS Amplify, Google Firebase, Kumulos.

ViewPager — один из самых известных и широко используемых компонентов Android Support Library. Все простейшие карусели, онбординги и слайдеры в мобильных приложениях для Android выполнены именно на нем. В феврале 2019 года команда разработки AndroidX выпустила ViewPager2. Давайте разберемся, какие у этого были предпосылки и какими преимуществами обладает обновленная версия компонента.

Не так давно на платформе Boosters прошел контест рекомендательных систем от онлайн-кинотеатра Okko — Rekko Challenge 2019. Для меня это был первый опыт участия в соревновании с лидербордом (ранее пробовал силы только в хакатоне). Задача интересная и знакома мне из практики, призовой фонд есть, а значит, был смысл участвовать. В итоге я занял 14 место, за что организаторы выдали памятную футболку. Приятно. Спасибо.

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

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

Вступление

За годы разработки ML- и DL-проектов у студии Surf накопились и большая кодовая база, и много опыта, и интересные инсайты и выводы. При старте нового проекта эти полезные знания помогают увереннее начать исследование, переиспользовать полезные методы и получить первые результаты быстрее.

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

Конечно, так было не всегда. Мы столкнулись с множеством проблем на первых этапах

• Каждый проект был организован по-разному, особенно если их инициировали разные люди.
• Недостаточно отслеживали, что делает код, как его запустить и кто его автор.
• Не использовали виртуализацию в должной степени, зачастую мешая своим коллегам установкой существующих библиотек другой версии.
• Забывались выводы, сделанные по графикам, которые осели и умерли в горé jupyter-тетрадок.
• Теряли отчеты по результатам и прогрессу в проекте.

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

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

В статье мы расскажем на маленьком искусственном примере, из каких частей состоит Ocean и как его использовать.