Из новых фреймворков, не указанных по первой ссылке, lotus выглядит очень многообещающе; а также roda от Jeremy Evans (автора Sequel), как утверждается, по бенчмаркам обходит даже синатру. Но это, конечно, не лучший выбор для новичков.
Медленнее — потому что Mina компилирует все необходимые команды в один shell-скрипт и выполняет на удаленном сервере за одно соединение; Ansible же (в нашей конфигурации) запускает команды по одной, каждый раз устанавливая новое соединение с сервером (аналогично Capistrano).
На уровне получения ссылки на страницу авторизации vkontakte_apiподдерживает. Но надо понимать, что без контроля над адресной строкой браузера это сделать технически невозможно (не прибегая к парсингу). В десктопных и мобильных приложениях этот контроль есть, в веб-приложениях — нет.
Когда я начинал писать vkontakte_api, vk-ruby не устраивал меня по разным причинам. Насколько я знаю, за последнее время этот проект тоже подтянулся, но все еще не поддерживает snake_case-названия методов и авторизацию standalone-приложений, плюс всякие мелочи вроде автоматического склеивания параметров-массивов через join(',').
Насколько я знаю, под виндой у всех проблемы с установкой Oj. Подменить парсер другим пока нельзя, ибо другие парсеры (как минимум все из комплекта multi_json) с вконтактовским JSON не справляются, см. 7even/vkontakte_api#1.
В планах на будущее — все-таки разобраться с проблемами парсинга, и я рассчитываю, что в итоге получится оставить выбор парсера программисту.
Если имеется в виду интеграция Devise с Omniauth, то да — нужно просто вытащить токен из request.env['omniauth.auth'] (если верить доке, токен должен лежать в request.env['omniauth.auth']['credentials']['token']). После этого можно создать клиент API как-то так:
После удаления приложения на странице http://vk.com/apps?act=settings токен протухает, но продолжает висеть в куке к vkontakte-on-rails.herokuapp.com. По хорошему надо было бы проверять работоспособность токена в приложении, но я этого не сделал, чтобы не усложнять пример.
Чтобы все снова заработало, нужно просто удалить эту куку.
В этом случае каждый мердж из фичи в основную ветку будет отдельным коммитом (добавляющим в основную ветку изменения, сделанные в фиче с момента последнего мерджа), и такие коммиты-мерджи будут лежать там вперемешку с другими коммитами.
Я бы не использовал такой workflow — какой смысл в ветке для фичи, если она регулярно мерджится в основную? Тогда уж проще делать все сразу в основной, заодно можно будет и исправлять последний коммит через git commit --amend.
Есть и другой способ решить проблему — использовать популярный workflow, при котором работа над фичей ведется в отдельной ветке, а потом мерджится в основную линию разработки с ключом --squash (все изменения ветки сплющиваются в один коммит). В этом случае можно не беспокоиться о чистоте истории — после мерджа ветка фичи все равно обычно удаляется.
Правда, если опечатка обнаружилась уже после мерджа в основную линию, тут уже ничего не поделаешь.
Вообще несколько коммитов можно слить в один с помощью git rebase -i — но в данном случае, когда коммиты уже запушены, так делать категорически не стоит. Ребэйс по сути создает новые коммиты вместо старых — а если старые уже лежат в центральном репозитории, и другие разработчики основывают свою работу на них, git push -f здорово усложнит им жизнь.
grape
пробовали, не очень понравился. В одном новом API-сервисе использовали lotusrb, впечатления положительные.А что не так с
faraday
?git stash
.Отпускаем сцепление —
git stash pop
.pluck
, можно упростить доvkontakte_api
поддерживает. Но надо понимать, что без контроля над адресной строкой браузера это сделать технически невозможно (не прибегая к парсингу). В десктопных и мобильных приложениях этот контроль есть, в веб-приложениях — нет.vkontakte_api
,vk-ruby
не устраивал меня по разным причинам. Насколько я знаю, за последнее время этот проект тоже подтянулся, но все еще не поддерживаетsnake_case
-названия методов и авторизацию standalone-приложений, плюс всякие мелочи вроде автоматического склеивания параметров-массивов черезjoin(',')
.Решать вам.
multi_json
) с вконтактовским JSON не справляются, см. 7even/vkontakte_api#1.В планах на будущее — все-таки разобраться с проблемами парсинга, и я рассчитываю, что в итоге получится оставить выбор парсера программисту.
По поводу сообщений — посмотрите пример с мессенджером, правда он устроен посложнее.
request.env['omniauth.auth']
(если верить доке, токен должен лежать вrequest.env['omniauth.auth']['credentials']['token']
). После этого можно создать клиент API как-то так:Чтобы все снова заработало, нужно просто удалить эту куку.
Object#singleton_class
.Диаграммы замечательные, спасибо.
Я бы не использовал такой workflow — какой смысл в ветке для фичи, если она регулярно мерджится в основную? Тогда уж проще делать все сразу в основной, заодно можно будет и исправлять последний коммит через
git commit --amend
.А под веткой я имею в виду branch. Клон — это уже отдельный репозиторий.
--squash
(все изменения ветки сплющиваются в один коммит). В этом случае можно не беспокоиться о чистоте истории — после мерджа ветка фичи все равно обычно удаляется.Правда, если опечатка обнаружилась уже после мерджа в основную линию, тут уже ничего не поделаешь.
git rebase -i
— но в данном случае, когда коммиты уже запушены, так делать категорически не стоит. Ребэйс по сути создает новые коммиты вместо старых — а если старые уже лежат в центральном репозитории, и другие разработчики основывают свою работу на них,git push -f
здорово усложнит им жизнь.