Подтверждение номера телефона, используя Ruby on rails и Twilio

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

Динамический высокоуровневый язык программирования



Сегодня мы хотим показать вам интервью с Zach Briggs, спикером предстоящей конференции.
Осень – отличное время для встречи со старыми друзьями, поездок на конференции, прогулок по паркам. Многие уже вернулись из отпусков с новыми впечатлениями, идеями, готовые делиться ими, общаться с окружающими. Наше сегодняшнее интервью не о путешествии, хотя, несомненно, погружение в мир Java тоже можно назвать таковым. Разговор пойдет о JVM. Наш собеседник – Charles Nutter, разработчик JVM в Red Hat, ведущий инженер проекта JRuby.Очень хотелось изучить Ruby получше, а рабочего проекта не было. И я попробовал написать gem для работы с Yandex Direct API.
Причин было несколько. Среди них: Yandex Direct API очень типичен для Яндекса и современных REST-сервисов вообще. Если разобраться и преодолеть типичные ошибки, то можно легко и быстро написать аналоги для прочих API Яндекса (и не только). И ещё: у всех аналогов, которые мне удалось найти, были проблемы с поддержкой версий Директа: одни были заточены под 4, другие под новую 5, и поддержке units я нигде не нашёл.
Основная идея gem-а — раз в языке вроде Ruby или Python можно создавать новые методы и JSON-подобные объекты на лету, то методы интерфейс для доступа к REST-сервису могут повторять функции самого Rest-сервиса. Чтобы можно было писать так:
request = {
"SelectionCriteria" => {
"Types" => ["TEXT_CAMPAIGN"]
},
"FieldNames" => ["Id", "Name"],
"TextCampaignFieldNames" => ["BiddingStrategy"]
}
options = { token: Token }
@direct = Ya::API::Direct::Client.new(options)
json = direct.campaigns.get(request)А вместо того, чтобы писать справку, отсылать пользователей к мануалам по указанному API.
Продолжаем выкладывать интервью с нашими докладчиками в подкасте RubyNoName. Сегодняшний разговор с Владимиром Дементьевым, разработчиком в Evil Martians.
«Питон или Руби» — это один из самых горячо обсуждаемых топиков в мире программирования. Впереди него только “emacs или vim” и “pro-skub или anti-skub” по важности и сложности. Сегодня мы изучим разницу и ответим на вопросы, а также объективно и окончательно решим, что лучше.
Питон это крупная змея, которая обитает в юго-восточных регионах планеты. Они не ядовитые и нейтрализуют врагов в основном удушением. Многие из сохранившихся видов находятся под угрозой исчезновения.
Руби (рубин) — это яркий, красный драгоценный камень. Его принято относить к группе четырех драгоценных камней, наряду с изумрудами, бриллиантами и сапфирами. Существует большой спор: рубины — это красные сапфиры или сапфиры — это голубые рубины.
Для незнакомого с темой человека рубин и питон могут показаться идентичными:
Ребята записали первый разговор, с Алексеем Тактаровым, фронтенд(!) разработчиком из These Guys. Алексей специализируется на разработке single-page приложений, пропагандирует чистоту и простоту дизайна и кода. Принимал участие в проектах Смартомато, ficus.io и resume.io, работал со Злыми марсианами; его основные инструменты — Ember.js, React и Ruby on Rails. В свободное время занимается южной около-фронтенд тусовкой Code Hipsters.
Многие пользуются Аксесом… даже в продакшене… даже по сей день. Посему, случаются моменты, когда кому-то захочется подключиться к этой БД из какого-нибудь неожиданного места. Например с юниксового сервера. Конечно же, подключиться захочется не просто так, а для использования данных из Аксеса в веб-приложении. И, без всякого сомнения, появится желание использовать эти данные совместно с информацией из других, более современных БД.
На Хабре уже была статья, посвящённая Dependency Injection в Ruby, но упор в ней был больше на использование паттерна IoC-container с помощью гемов dry-container и dry-auto_inject. А ведь для использования преимуществ внедрения зависимостей совершенно необязательно городить контейнеры или подключать библиотеки. Сегодня расскажу о том, как по-быстрому реализовать DI своими руками.

Это перевод статьи Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP", написанной 30 мая 2016, т.е. совсем недавно. Я полностью согласен с её автором, и сам давно горел желанием написать что-то подобное в последнее время, но у меня не так много опыта с Ruby, поэтому моя писанина не была бы настолько объективна, как писанина человека, который этот опыт имеет, и имеет его в хорошем количестве. А тут на тебе: всё в одном месте уже собрано, и мысли прямо один в один как у меня. Грех не перевести на русский. Также, статья вообще очень хороша как небольшой набор объективного и беспристрастного анализа двух языков современной веб-разработки. В общем, далее — перевод слов автора.
многобукв; нечитал;
В этой статье я рассказываю о некоторых фактах и персональном опыте для того чтобы доказать, что PHP в данный момент живее, конкурентоспособнее, а также имеет менее связанную экосистему, чем Ruby. Я говорю о Производительности, Синтаксисе и Аспектах кодинга, Сообществе и Инструментарии разработчика.
Так уж получилось, что появилась необходимость досрочно останавливать уже запущенный сайдкик-воркер. И, как уже всем причастным известно, запущенную задачу невозможно остановить штатными средствами — этого просто не предусмотрено архитектурой. И когда сайдкик-задача начала уже выполняться, то ее уже ничто не остановит. Конечно же, в интернетах тут же нашлось решение с убиением руби-процесса и с отменой перезапуска оного, но это решение по очевидным причинам не может устраивать ни разработчиков приложения, ни разработчиков сайдкика.

В итоге решение появилось откуда не ждали и оказалось крайне простым и очевидным.

Вам интересно, почему буквально все вокруг заговорили о языке Ruby? Спросите себя прямо: вам нравится работать эффективно? Неужели многочисленные компиляторы, библиотеки, классы, которыми грузят вас другие языки программирования, приближают вас к решению конкретной задачи, восхищению коллег и толпе счастливых заказчиков? Вы хотите, чтобы язык программирования занимался техническими подробностями вместо вас? Тогда бросайте рутинную работу и приступайте к решению конкретных задач, а язык Ruby сделает за вас все остальное.Наверняка вы сталкивались с ситуацией, когда есть достаточно жирный метод, и вам приходится вынести часть его кода в отдельный метод и ваш класс/модуль переполняется методами, которые относятся к одному единственному методу и нигде более не используется. Ужасный каламбур, правда?
Если вы просто хотите ознакомиться с реализацией класса, то эти самые вспомогательные методы очень сильно мозолят глаза, приходится прыгать по коду туда-сюда. Да, конечно, можно разнести их по отдельным модулям, но я считаю, что зачастую это слишком избыточно (я, например, не хочу создавать модуль, который, по сути, определяет только один метод, декомпозированный на n частей). Особенно неприятно, когда эти вспомогательные функции состоят из одной строки (например, метод, который выдергивает определенный элемент из распарсенного JSON).
Уже в эту пятницу сообщества Python, Go, Ruby, PHP, Javascript, MySQL, PostgreSQL,Tarantool встретятся на DevConf 2016 — остались последние 60 мест.