Connect with us

Разработка

Как мы за неделю сделали и запустили приложение для свиданий

Приложение получило множество позитивных отзывов на Reddit и мне задали много вопросов в /r/learnprogramming о технологиях, которые использовались для его написания, так что я написал короткий пост об этом.

Фото аватара

Опубликовано

/

     
     

С месяц назад мы запустили Color Dating для iOS и Android. Это как Tinder, только с прицелом на меньшинства и на тех, кто любит меньшинства.

Приложение получило множество позитивных отзывов на Reddit и мне задали много вопросов в /r/learnprogramming о технологиях, которые использовались для его создания, так что я написал целый пост об этом.

Стек технологий

Обзор приложения

В основе своей iOS приложение достаточно простое. MVP несет в себе лишь несколько функций:

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

Swift или Objective-C

Этот вопрос, который всегда задается в iOS проекте – писать на Swift или на Objective-C.

Если бы вы спросили меня год назад, то я бы склонялся больше к Objective-C, так как многие сторонние фреймворки только начинали разворачиваться на Github. Сейчас проектов, поддерживающих Swift, примерно столько же (если не больше), сколько и Objective-C.

Swift, судя по всем показателям, будет будущим iOS-разработки, так что вы не ошибетесь, если начнете учить его (если уже не начали). В конце концов весь вопрос сводится к тому, какой язык программирования вам комфортнее использовать и сколько времени вы хотите в него инвестировать .

Если вы пришли из мира C++/Java/C#, то, возможно, Objective-C будет вам проще использовать. Наоборот, если вы больше используете интерпретируемые языки, такие как JavaScript, Ruby или Python, то Swift может быть по вашей части.

1. Добавление карточек и свайпов

При программировании очень много времени уходит на переписывание той функциональности, что уже существует. Моя философия, когда речь идет о разработке мобильных приложений – зачем изобретать велосипед, если вы можете просто загрузить его из CocoaPods?

Для тех, кто не понял – CocoaPods это менеджер зависимостей для iOS. Раньше, если кто-то хотел использовать стороннюю библиотеку, надо было вручную загрузить архив, распаковать его и импортировать в проект, потом вручную сконфигурировать использование библиотеки и при этом попытаться не загубить рабочую сборку. CocoaPods решает эту проблему, делая все автоматически.

Я настоятельно рекомендую вам использовать CocoaPods для ваших проектов, поскольку это экономит много времени на решение конфликтов фреймворков и поддержание их в актуальном состоянии.

Мы, в конечном итоге, решили использовать Koloda для обработки свайпов. Но даже если вы не используете карточки и свайпы, то принцип остается тем же – не изобретайте велосипед. Идите на Github и ищите библиотеку, которая может вам помочь достичь тех результатов, которых вы хотите.

2. Раскручивая бэкенд

Мы использовали Ruby on Rails для бэкенда.

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

Я также всегда был поклонником Rails Composer для начала нового проекта. Он помогает мне справиться со всей начальной инфраструктурой, вроде почтовика, пользователей, распределении ролей пользователей и т.п. Независимо от того, что вы выберете, процесс создания бэкенда все равно будет таким же. У нас есть объект User с основной пользовательской информацией, такой как ник, имя, фотографии, возраст, две колонки для координат.

В принципе, все, что вам нужно — для модели User реализовать метод find_matches, который возвращает список всех потенциальных совпадений на основе предпочтений/локации.

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

Как я упоминал, мы используем Sidekiq, но другие говорят о Resque. Я пока недостаточно умен, чтобы понять разницу, так что я просто выбрал один из вариантов.

Что касается хранения данных, то мы, как и все остальные на планете, используем Paperclip и Amazon S3. У Paperclip есть прекрасный адаптер, уже встроенный в S3, который волшебно выполняет обработку, загрузку и получение изображений. Он также заботится об изменении размеров для миниатюр.

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

3. Соединение бэкенда с приложением

Я думаю, что все предпочитают JSON для обмена информацией между фронт и бэкендом.

К счастью, если вы на Rails, в него уже встроена сериализация JSON, а если вы используете Alamo Fire (моя любимая HTTP библиотека для Swift), то он также оснащен денейрализатором десериализатором JSON для Swift. если вы используете Objective-C, то для него есть библиотека ASIHTTP, работающая с сериализацией JSON.

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

Единственное, что вам нужно на стороне клиента – постоянное хранилище для вашего объекта User. У клиентского объекта User должны быть методы синхронизации для отправки новых POST данных на сервер и получения информации в приложение.

4. Добавление сообщений

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

В конце концов, мы просто выбросили 2-3 дня работы и решили сделать собственное решение. К счастью, с Rails это оказалось сделать не так уж и трудно.

Такого рода моменты подчеркивают то, почему даже при использовании многих других веб фреймворков до того, я всегда возвращаюсь к Rails. Когда Rails работает, они работают здорово. До тех пор, пока вы делаете вещи в пределах ожидаемых соглашений, по-моему, это самый быстрый способ создать и запустить что-то, а для всего остального есть Gem.

Я нашел один для передачи сообщений на Github под названием «acts-as-messageable» и он работал просто добавлением двух строчек в модель активной записи User. Он не только позволил пользовательским объектам посылать и получать сообщения, но и позаботился о построении модели разговора. Единственная проблема была в том, что это не live чат, и он требует периодического опроса, а не работает в publish/subscription парадигме с уведомлением UI для мгновенного обновления. Это также означает отсутствие такой вещи как индикатор печати.

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

На iOS клиенте мы использовали под JSQMessageViewController, который дал нам все необходимые UI элементы и прекрасно заработал прямо из коробки.

5. Развертывание

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

С одной стороны, у вас есть PaaS (platforms as a service) типа Heroku. Проблема с Heroku в том, что он может быть очень дорогим для того объема оборудования, что вы получаете. С другой стороны, есть другие варианты, типа AWS EC2, где вы можете свободно устанавливать собственные виртуальные машины и получать практически полный контроль над настройками, но на это нужно больше времени и энергии.

В зависимости от того, где вы решили запустить свой EC2 инстанс, размера и условий соглашения, вы можете сэкономить в 4-5 раз по сравнению с производительностью железного Heroku.

Тем не менее, выгоды Heroku в том, что он может сэкономить вам много времени и сил. Я сам в первую очередь являюсь разработчиком, а не сисадмином. Поэтому работа в терминале и отладка проблем с помощью черно-белого текста в Unix это, на самом деле, не мое.

Для меня преимущества значительно перевешивают стоимость владения при выборе Heroku в качестве платформы. Тем не менее, если вы более опытный в администрировании человек, вам стоит обратить внимание на развертывание инстанса в EC2 ради экономии или подумать о гибридной модели, вроде собственной open source платформы с Dokku.

Например, DigitalOcean это облачная вычислительная платформа, которую я часто использовал в прошлом. У них есть готовые образы, поднимающиеся за секунды, в том числе Dokku, если вы захотите нечто подобное Heroku, но дешевле.

phones-fa4805f00d59e2abe8480c3a523ff30d9a2679a40319e52b23a60ecac9bf2be9

6. Разные администраторские вещи

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

Для простого HTTP мониторинга мне в наследство достался бесплатный план Pingdom, так что использовал его. Я также слышал хорошие отзывы про StatusCake, который рекламирует себя как вечно бесплатный. Такой тип мониторинга просто дает вам знать, когда приложение упало и не отвечает.

Для отслеживания производительности мы используем New Relic, но вы можете попробовать и другие платформы. Контроль позволяет вам копаться в разных параметрах производительности, таких как время отклика, объем потребляемой памяти и т.п. Это позволяет вам видеть где все замедляется, где утекает память и что вы можете оптимизировать.

Для отслеживания ошибок, мы используем Rollbar, но единственная причина этого – он был первым, что выдал поиск Google. Возможно, вы захотите проверить Airbrake или подобные сервисы. Отслеживание позволяет вам отлавливать ошибки, происходящие в приложении, и записывать их в более понимаемом человеком формате. Например, если вы захотите отслеживать частоту определенного сбоя и пометить его как исправленный.

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

Резюме

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

При определении ваших планов убедитесь, что они касаются 3-5 важных функций или даже меньше. Если у вас есть целая доска с фичамии, то определенно вы что-то делает не так. Хорошо знать о том, какие функции у вас впереди в роадмепе, но необходимо отложить их до лучших времен, так как мы здесь говорим о MVP.

Когда речь идет о создании вашего проекта, я настоятельно рекомендую вам выбрать стек, который имеет большую поддержку сообщества. Это позволит вам просто искать на Github и добавлять вещи в ваш проект. Просто будьте внимательны с лицензиями.

Если вы дочитали до конца и все еще не решились начать кодить, просто идите и СДЕЛАЙТЕ ЭТО.

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Наши партнеры:

LEGALBET

Мобильные приложения для ставок на спорт
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: