Ruby on Rails c нуля!

Добрый день ув. читатели RubyDev! Сегодня в нашей виртуальной студии Акжан Абдулин — Ruby разработчик из известной в русскоязычном Rails сообществе компании Undev. Сегодня мы поговорим об интересных и полезных инструментах для веб разработчика, в создании которых принимает участие Акжан.

Акжан, здравствуй! Расскажи немного о себе читателям RubyDev.

Привет всем! Меня зовут Акжан Абдулин, я работаю программистом в — самой крутой компании мира, мы разрабатываем различные интересные веб приложения. Живу в Москве. Свободное время посвящаю мотоциклам и кошкам.

 

 

В комментарии к посту о предложении попиарить интересные проекты на rubydev, ты упомянул о разработке runit-man, Git Commit Notifier и bluepill. Раccкажи пожалуйста что это за проэкты.

: В нашей компании для обеспечения надежности в работе сервисов мы используем пакет runit, поэтому для удобства управления сервисами был создан дополнительный сервис, который позволяет управлять всеми runit-сервисами конкретной машины, а также вести наблюдение через Web-интерфейс. Он и получил название runit-man. В дальнейшем данный проект было решено опубликовать на GitHub.

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

: Этот гем позволяет присылать на почту уведомления о коммитах в Git-репозитории посредством установки обработчика событий Git. Создан он был не мной, я всего лишь существенно его переработал и стал одним из контрибуторов/авторов проекта.

: Один из популярных инструментов для мониторинга и автоматического реагирования на предопределенные ситуации (например, сильное потребление CPU или памяти процессом приложения или отсутствие отклика по HTTP). Наиболее известными альтернативами являются monit и God. Опять-таки, я в случае с bluepill являюсь лишь сопроводителем и контрибутором проекта. Авторы давно не имеют времени на поддержку, так что последнее время все тикеты, запросы на внесение изменений и выпуск версий проходят через меня.

А как популярен runit-man в других компаниях, кто-то кроме Undev уже добавил runit-man в свой арсенал?

Пока не задавался целью выяснить, кто использует этот проект.
Репозиторий runit-man находится под наблюдением разработчиков из России, Белоруссии, Канады и США.

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

Фактически именно так. Я думаю, простой конфиг ответит на этот вопрос подробнее:

Bluepill.application("app_name") do |app|
  app.process("process_name") do |process|
    process.start_command = "/usr/bin/some_start_command"
    process.pid_file = "/tmp/some_pid_file.pid"
    process.start_grace_time = 3.seconds
    process.stop_grace_time = 5.seconds
    process.restart_grace_time = 8.seconds

    process.checks :cpu_usage, :every => 10.seconds, :below => 5, :times => 3
    process.checks :mem_usage, :every => 10.seconds, :below => 100.megabytes, :times => [3,5]
  end
end

Расскажи, пожалуйста, подробнее о git-commit-notifier. Как он вообще упрощает рабочий процесс?

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

Что вообще такое web monitoring?

Мне знакомо другое понятие, — system management and monitoring. Дело в том, что любое «железное» и программное обеспечение склонно к сбоям. В таких условиях для обеспечения высокой надежности наших сервисов нужно применять средства мониторинга, автоматического реагирования и управления системой. Что не отменяет необходимости наличия дежурных, но существенно уменьшает количество ситуаций, где требуется реагирование со стороны персонала. Автоматическое реагирование увеличивает надежность за счет своей быстроты и снижает нагрузку на людей.

Неужели для веб мониторинга не существует других решений, почему потребовалось написать свое?

Для управления и мониторинга сервисов runit никакого иного решения, кроме runit-man, пока не существует. Для мониторинга и автоматического реагирования известных альтернативных решений всего два. monit неудобно конфигурировать, God кушает память со временем. bluepill был создан, чтобы избежать недостатков monit и God.

Акжан, я знаю, ты работаешь в компании Undev, расскажи где в Undev используется runit-man?

Практически везде, где используется Linux. Большая часть наших сервисов как минимум на трех основных проектах реализованы как сервисы runit (включая демоны memcached, solr, couchdb, chef, и иные сторонние и наши сервисы), и, следовательно, на большинстве серверов установлен runit-man.

Расскажи о работе в Undev, я знаю, что это одна из лучших русских компаний занимающихся разработкой на Ruby/Rails с эффектным сайтом, однако это все, что все известно.

Мы занимаемся различными интернет-проектами. В частности это системы внутреннего вещания и обеспечиваем интернет-трансляции различных событий, например, недавней конференции RailsClub. Информация о большинстве проектов конфиденциальна, но я могу поделиться двумя ссылками на наши проекты, которые есть на нашем сайте,это:   и .

Расскажи свою историю становления как Ruby/Rails программиста. До Ruby/Rails какими технологиями пользовался? Какие впечатления от Ruby/Rails?

Я фактически не использую Rails в повседневной работе. В основном я пишу на Ruby, Perl и JavaScript.
История становления короткая: На работе использовали Ruby, поэтому пришлось в короткие сроки изучить Ruby, благо язык очень красивый и немного похож на Perl с которым я хорошо знаком.

А свои какие-нибудь веб-проекты на Rails или Sinatra, имеются, те, что разрабатываются в качестве отдыха от основной работы?

Все проекты созданы для решения конкретных задач. Разве что jwysiwyg — этот WYSIWYG-редактор был мною тотально переработан, когда разрабатывал сайт не по работе (конкретнее, для получения редактора новостей, удобного для себя). В настоящее время им занимаются другие люди (@frost-nczr4, @Tudmotu, @alecgorge, @brentkirby), у меня сейчас нет связанных с ним задач, поэтому я участия в разработке практически не принимаю.

Я знаю, что ты работаешь с Node.js. Можешь рассказать, что это такое, чем Node.js отличается от EventMachine, написанного на Ruby, и почему в последнее время достаточно часто к Ruby-программистам предоставляется требование иметь опыт с Node.js?

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

Event machine на Ruby до недавнего времени обладала значительным количеством недоработок, что, при большей сложности отладки таких приложений, приводило к более значительным затратам на разработку и поддержку приложений с её использованием.

На самом деле в России вакансий, требующих знание Node.JS наряду с Ruby, пока очень мало.

Что вообще такое evented — программирование? Я примерно понимаю, что есть предопределенные события и коллбеки для их обработки, но в чем преимущество таких программ и где вся эта магия используется?

Для обработки запросов на сегодня наиболее известны три подхода: Обработка каждого запроса в отдельном процессе (Apache 1.x, FCGI), обработка каждого запроса в отдельном потоке выполнения (один из режимов Apache 2.x), и асинхронная обработка всех запросов в одном потоке (nginx, Node.JS).

Последний вариант, с использованием событийно-управляемого программирования, считается наиболее масштабируемым по количеству одновременно обрабатываемых соединений (проблема 10K).

При этом каждое событие («получен запрос», «получен пакет данных», «получен ответ», «открыт файл» и другие) обрабатывается за малое время, и сервер в основном пассивно ждёт наступления новых событий. В нужный момент его разбудит операционная система.

Акжан, а что ты думаешь о таком распространенном мнении об evented-программировании, как: «Его вообще необходимо избегать, код становится практически нечитабельным и сложным для тестирования.»?

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

Я знаю, ты также используешь замечательный фреймворк Sinatra. По каким критериям следует выбирать для разработки Rails, а по каким Sinatra? Как относишся к потомку Sinatra — Padrino?

Если нужно написать сервис, а не сайт, то чаще всего Rails является ненужным довеском, к тому же уменьшающим читаемость кода и производительность сервиса. В некоторых случаях даже Sinatra бесполезен, достаточно написать чистый обработчик http-запросов для Rack.

Padrino — очень нравится, там есть нужные мне вещи. Жду возможности его опробовать. Пока есть только одна низкоприоритетная задача под него, так что в течение месяца что-нибудь напишу с его использованием (возможно, и runit-man затем на него переведу).

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

Рабочая среда — консоль. Использую macvim/vim с конфигами dotvim. Для тестирования предпочитаю RSpec 2 + RR, webrat, Jasmine. Если проект нацелен на несколько окружений, или большая команда, то нужна система непрерывной интеграции (в настоящее время используются Jenkins, Travis).

СУБД обычно зависит от требований к проекту. У нас используется в основном MySQL. Очень интенсивно используются очереди сообщений (RabbitMQ, 0MQ).

Какие вообще впечатления от работы с Ruby и Rails? По истине ли Ruby — programmer’s best friend?

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

Как думаешь, сможет ли Ruby оторвать у PHP более-менее значительную долю рынка, например разработку различных веб сервисов и т.д.? Сможет ли Ruby стать на замену PHP в сфере разработки различных CMS?

Вряд ли. Сервисы на Ruby кушают слишком много оперативной памяти, да и для массового виртуального хостинга экосистема Ruby пока фактически непригодна. Каждому своё.

Есть на ближайшее будущее планы или идеи по разработке каких-нибудь собственных проектов?

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

Традиционный вопрос для интервью, чего пожелаешь читателям RubyDev, преимущественно новичкам веб разработки и разработки на Ruby и Rails?

Побольше вам принятых pull requests ;)

Спасибо за интервью, Акжан!

Кстати, компании нужны разработчики, администраторы и дизайнеры. О вакансиях можно узнать прям на .