Про Hackathon

Краткий экскурс в то как это было на хакатоне

November 11, 2015 - 3 minute read -
web

Паша решил писать на ROR, потому что он может. Тут необходимо вставить картинку про велосипедиста и палки в колёса. Все дни я только и занимался тем, что выпиливал функциональность дико необходимую для “веб-обезьяны”, но избыточную для внешней работы с системой, то есть как с API.

Впервые заюзал Heroku. Тут костыль номер два. Heroku является по сути системой с чем-то вроде tmpfs, то есть все файлы существуют ровно до момента перезапуска инстанса, который по сути является подобием контейнера в Docker. Проблема на самом деле не столь в этом, сколь в том, что на каждый пулл, инстанс пересобирается и перезапускается. Решение для хранения файлов, вроде бы столь очевидное(google 5sec), принесло больше всего гемороя. Amazon S3. Он работает с двумя популярными библиотеками для работы с аттачами, обе создали больше проблем. Тем не менее, я видел даже те ошибки, которые загуглить проблема. Прежде всего выясняется(на самом деле нет), что последняя версия имеет проблемы с гемом aws-sdk, и нужно оказывается брать определенную ревизию, ОК пропишем это в гемфайл. Далее выясняется, что так бывает, но S3 может находится в разных локациях. Вроде бы ОК и не должно быть проблем, тем не менее, Amazon хочет, чтобы инстанс S3 в другой локации обрамлялся соответствующим endpoint-ом, что на самом деле является поддоменом, понадобилась недюжинная выдержка, чтобы найти соответствующее решение.

Как бы это не звучало, но в Ruby и Rails конкретно, легкие задачи решаются легко, сложные сложно. Очень легко обращаться со связями, но увы вызывать какие-то агрегатные функции по связям это лютый геморой, возможно я ошибаюсь, но это то что говорит официальная документация. Почти все проблемы решаются каким-либо из гемов, НО увы гемы подходят для 98% случаев и мы оказались именно в тех 2%, когда функционал был избыточен. Гораздо легче написать самому, нежели воспользоваться тем самым готовым решением, это беда.

Очень годная тема - PGSearch, формально просто обертка над встроенными в postgres штуками, но очень удобно. До этого пробовал бесплатный Elasticsearch, но он не особо себя показал, только word-wide поиск, без поиска посимвольно.

До хакатона придумал, как можно неплохо описывать API на чём-то похожем на Swift. Для тех, кто не вкурсе, в статических языках есть некоторые проблемы, когда API возвращает что попало. Один базовый объект, по сути дженерик(шаблонный класс), который имеет опционально ошибку и объект шаблонного класса. Очень классно это сделали в Telegram API, но там это скорее вынужденная мера. Было бы круто развить эту идею, чтобы можно было скормить API spec чему-нибудь и он бы выдал хидеры для разных языков и либ.

Набор того, что я юзал:

  • paperclip - делает львинную долю работы с изображениями
  • aws-sdk - SDK для работы с Amazon AWS, использовал конкретно для обертки над S3, поддерживается предыдущим гемом (! внимательно смотреть Issue на гитхабе)
  • pg_search - посимвольный поиск в postgres
  • roar - библиотека, которая добавляет обертку над моделями - репрезентации. Львинная доля работы над представлением данных
  • representable - то-же самое, что и вещь выше, но более базовая, использовал для создания базового объекта(+немного магии)
  • multi_json - две библиотеки выше + json
  • rails_param - говорят, как sinatra_param, но для рельсов, годная, но жутко не хватает разных эксепшнов на провал разных валидаций(на уровне кода почти есть)

Советы для тех, кто решил пойти тем-же путем:

  • Пересылать файлы, как Base64 строку. Я так и не понял, как разобраться с валидациями в случае если приходит файл.
  • Во всех API контроллерах сделать - skip_before_action :verify_authenticity_token иначе устанете искать проблему
  • Внимательно читайте то, что пишут про гемы и их работу друг с другом, в особенности paperclip и aws-sdk
  • Сделать базовый объект можно, например так

Благодарю за внимание!