Ruby on Rails *

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

В ходе обработки ордер меняет свое состояние от нового до выполненного, при этом создаются несколько сервисов (в зависимости от данных) и они должны быть запущенны и работать к концу обработки заказа. Простой пример — вы оформляете себе симку для сотового. К этой симке «подключаются» сервисы голосовой связи, СМС-ок и ММС-ок, мобильного интернета (у которого свои тарифы), автоответчик, определитель номера и т.д. К окончанию обработки вашего договора (заказа) все эти сервисы должны быть запущены и работать. Далее вы можете заключить доп. договор и переключиться на др. тариф мобильного интернета и т.д. Это просто пример логики, на который я буду ссылаться для наглядности.

Абсолютное большинство программистов начнет делать такое приложение на колбэках или тригерах. Создан новый ордер — ставим ему состояние new — и вешаем колбэк который начинает создавать сервисы и т.д. Далее я постараюсь объяснить, почему это абсолютное зло.

Всем доброго времени суток!

Позвольте представиться.
Я CEO/CTO/CIO/итд VPN сервиса SmartVPN.biz.
Можно называть меня Виктор Иванов, так как таков был мой псевдоним в службе поддержки клиентов SmartVPN.biz.

Пару лет назад я решил создать свой первый стартап — VPN сервис.
Идея нагрянула после того как около 5 друзей попросили у меня VPN на моем личном сервачке.
Естественно, никакого анализа рынка, конкурентов и написания бизнес плана не было. Я просто сел и начал кодить.
Спустя какое-то время проектом стало можно пользоваться — и он увидел свет.

В данной статье я бы хотел показать как настроить MySQL для дальнейшего использования gem'a octopus, который используется для шардинга и репликации в Rails — приложениях.
Итак, представим, что перед нами стоит задача развернуть три сервера(на первом крутится Rails — приложение, второй нужен для Master'a, третий будет выступать в качестве Slave'a), настроить репликацию между серверами и сделать так, чтобы octopus работал.

Наверняка многие сталкиваются с проблемой, когда есть несколько моделей, скажем, Client, Manager и User – у которых ряд полей – к примеру, name, email, position – одинаковые. При этом каждая из моделей обладает также уникальными полями и методами. В данном случае (рассуждая абстрактно) логично было бы общие поля с соответствующими валидациями вынести в отдельную таблицу people (модель Person), оставив в Client, Manager и User только специфику.

Ряд примеров можно продолжать: Product – Fridge, Phone, Toaster; Vehicle – Car, Truck, Motorcycle и так далее. Проблема довольно общая – какие варианты решения есть для Rails?

Коллеги — до конференции DevConf 2015 осталось меньше 2-х недель — помогите выбрать достойные доклады.

В этом году у нас добавилась секция DevOps — было много заявок на нее — решили вынести в отдельный поток.

Список секций: DevOps, Storage, PHP, Python, Ruby, Javascript, Common
ГОЛОСУЕМ ЗА ДОКЛАДЫ ДО 8 ИЮНЯ!

Краткое содержание первой части

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

Эрик — Ruby-герой 2014 года, популярный ментор среди разных Ruby-сообществ (Ruby Summer of Code, Google Summer of Code и Rails Girls Summer of Code) и просто интересный человек. Изначально интервью должно было выглядеть в стиле «коротко продолжи фразу», но Эрик подошел к делу творчески, поэтому публикую его полностью.

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

Итак, приступим.

Создаем хэш из массива

Проще простого. Ставим команду Hash перед любым массивом и получаем готовые пары ключ/значение:

Hash['key1', 'value1', 'key2', 'value2']

# => {"key1"=>"value1", "key2"=>"value2"}

Я не так давно обновил один из проектов до Rails 4.2 и заметил интересный эффект: кодировка обработанных html файлов в ассетах меняется на ISO-8859-1.

Данная проблема актуальна для Sprockets 3.0.0 и 3.0.1.

Проблема

Было приложение, использующее Ruby on Rails, и стандартный набор гемов (вроде devise). На одной из страниц необходимо было выводить информацию о текущих активных пользователях.

Решение

Первой же мыслью было при каждом запросе записывать в текущего юзера время этого самого запроса и, таким образом, зная таймаут сессии, можно было вычислить, кто активен, а кто нет. Но таймаут стоял порядка 15 минут, поэтому если вкладку просто закрыли — то он все еще будет «активным» на протяжении этого времени. Уменьшать таймаут сессии было нельзя. Да и вариант каждый раз обновлять запись в базе выглядел немного костыльно, учитывая, что одновременных активных юзеров было порядка 2к. Из самых быстрых и простых вариантов — реализация используя вебсокеты + redis.

Faye vs WebsocketRails

tldr; В итоге был выбран faye.

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

Плюсов у websocket-rails я не нашел, зато минусы были очевидные: последнее обновление было довольно давно, на каждое подключение открывался отдельный поток, что потенциально могло заддосить наш и так не очень мощный сервер. Faye в свою очередь работает через event machine и полностью асинхронный, плюс постоянно обновляется.

Привет, Хабр!

Вот весна и перевалила через свою середину, к концу подходит апрель. Этот месяц был богат на хорошие новости от JetBrains: обновление ReSharper Ultimate, выпуск ReSharper C++ и CLion 1.0. А сегодня мы надеемся порадовать и Ruby-разработчиков. В среду, 15 апреля, вышло обновление нашей интеллектуальной среды для разработки на Ruby и Rails — RubyMine 7.1. Прежде всего, в новой версии мы усовершенствовали поддержку Puppet, кроме того уделили много внимания JavaScript и CoffeeScript, постарались привнести еще больше удобства и эффективности в процесс написания кода.

10-11 апреля в Ульяновске состоится крупнейшая в регионах России IT-конференция «Стачка». Coub ходил на Стачку в прошлом году, не смог пропустить ее и в этом. Мы не только будем на ней присутствовать, но и привезем с собой несколько докладов.

Привет, Хабр!



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

Напомню, Хекслет — это платформа для создания практических уроков по программированию в настоящей среде разработки. Под настоящей средой разработки мы подразумеваем полноценную машину, подключенную к сети. Эта важная деталь отличает Хекслет от других образовательных проектов (например, Codecademy или CodeSchool) — у нас нет симуляторов, все по-настоящему. Это позволяет обучать и обучаться не только программированию, но и работе с базами данных, серверами, сетью, фреймворками и так далее. В целом, если это запускается на Unix-машине — этому можно обучать на Хекслете. При этом, понимая это или нет, пользователи используют Test-Driven Development (TDD), потому что их решения проверяются юнит-тестами.

В этом посте я расскажу про архитектуру платформы Хекслет и инструменты, которые мы используем. О том, как на этой платформе создавать практически уроки — в следующей статье.

Где обычно вы верстаете страницы сайта для последующей интеграции с rails приложением? В отдельном репозитории с html файлами или сразу в rails — в каком-нибудь специально отведенном месте? Тестируете ли верстку длинными словами и текстами? Проверяете ли различные варианты отображения элементов верстки с помощью длинного текста? Попробую кратко осветить эти вопросы, рассказав о геме rails_ui_kit — небольшом инструменте для организации верстки в rails приложениях и о том, как его приходилось использовать при разработке реальных production-приложений.

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

Ruby Together — некоммерческая организация, занятая привлечением и распределением денег на развитие инфраструктуры языка Ruby. Уже сейчас под крылом организации находятся столпы экосистемы Ruby: гем bundler, репозиторий rubygems.org и сам проект rubygems. Организация управляется советом директоров, который состоит из хорошо знакомых всем рубистам имен: André Arko, Aaron Patterson (интервью для хабра), Steve Klabnik (интервью для хабра, «Как я нахожу время?»), Sarah Mei, Terence Lee, Ines Sombra, Joel Watson.

Индивидуальное членство в организации стоит $40 в месяц, корпоративное членство – $800. Взносы дают право голоса и ряд бонусов, о которых под катом. Для тех, кто просто хочет помочь проекту деньгами, существует статус «друга», без доступа к внутренним ресурсам и права голоса, с ежемесячным взносом $10, либо разовым взносом произвольной суммы. На текущий момент к проекту присоединились компании Stripe и Engine Yard, а также более 30 индивидуальных участников.

Принять участие.

Рельсы знамениты своим правилом «соглашения преобладают над конфигурацией» (Convention over Сonfiguration). Однако иногда, очень редко, некоторые вещи приходится делать по-другому. Одним из таких случаев я хочу поделиться в статье. Расскажу, как сделать свой первичный ключ в таблице (использую Rails 4.2.0). Ничего сложного, по сути, но вопросы о том, как это сделать, время от времени задают, а ответы не всегда хорошие.

Предисловие

Побегав по Хабру, я на удивление не нашел ни одной статьи про полноценный team workflow с использованием различных магических причуд в духе Continuous Integration & Continuous delivery, различные интеграции Github — HipChat(Slack) — CI — Staging and Production via Continuous Delivery, и прочего, хотя я может просто искать не умею.



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

Итак, под катом — разбор CI сервиса SemaphoreApp, немножко про интеграцию с другими сервисами и прочие радости, которые упрощают нам жизнь.

Привет, Хабр!

Уже в это воскресенье, 22 марта, в Минске пройдет однодневная конференция RubyConfBY, и наши докладчики уже пакуют чемоданы. В этот раз два Андрея, Андрей Вокин и Андрей Власовских, расскажут об инструментах, позволяющих находить ошибки в Ruby-коде без его выполнения. При этом, представляя команды RubyMine и PyCharm, они также попробуют сравнить Ruby и Python, чтобы понять, как стиль программирования влияет на статический анализ кода.

И немного о самой конференции со слов ее организаторов:

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

Наш стартап Olery был основан почти 5 лет назад. Мы начали с единственного продукта, Olery Reputation, который был создан агентством, занимавшимся разработкой на Ruby. Всё это выросло в набор различных продуктов. Сегодня у нас есть ещё Olery Feedback, API для Hotel Review Data, виджеты для вставки на сайты и многое другое.

Всего у нас работает 25 приложений (все на Ruby) – некоторые из них в вебе (Rails или Sinatra), но в основном это фоновые приложения для обработки данных.

Хотя нам есть, чем гордиться, есть у нас одна проблема, которая всё время висела где-то в фоне – база данных. Изначально мы использовали MySQL для важных данных (пользователи, контракты, и т.д.) и MongoDB для хранения обзоров и других данных, которые легко можно было бы восстановить в случае утери. Сначала всё работало неплохо, но по мере роста мы начали испытывать проблемы, в особенности с MongoDB. Некоторые из них возникали в сфере взаимодействия БД с приложениями, некоторые – непосредственно у самой БД.

К примеру, в какой-то момент нам надо было удалить миллион документов из MongoDB, а позже вставить. В результате работа базы застопорилась на несколько часов. Потом нам пришлось запускать repairDatabase. И сама починка тоже заняла несколько часов.