Ruby *

На Ruby и многих других языках есть удобные ORM-решения для программного доступа к СУБД. Также есть фреймворки вроде RubyOnRails для простого и удобного создания web-приложений, работающих с базой данных. Простые соглашения позволяют писать мало кода и при этом создавать мощные интерфейсы.

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

Стандартные действия для получения возможности работы с сущностью в Rails — создать модель, создать контроллер, создать представление (а если у нас полный набор REST-действий, то два — на получение списка и на получение одной записи в случае работы через API). Действия простые, и файлы очень простые. И когда словарей много, то файлов получим также большое количество. Большое количество простых и однотипных файлов. И где-то среди них будут затеряны большие, нетипичные файлы. Кроме большого количества файлов, мы получаем проблемы с необходимостью прописывать маршруты. Даже тем, кто такие системы поддерживает не один год, ориентироваться в проекте будет тяжело, не то что новому разработчику.

Здесь на помощь приходит магия Rails.

Для простоты предположим, что мы строим JSON API. Хотя ничто не помешает нам добавить поддержку XML.

Итак, один файл и один класс, которые могут заменить очень большое количество мелких однотипных файлов и классов.

Всем привет!

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

Заявку подавал я 19 января этого года, а 5го октября ее одобрили. Радости, конечно же было много и пришла пора готовиться к докладу.

17 октября прошла ежегодная брутальная конференция Highload Dev Conf.
Участниками стали более 300 суровых разработчиков, которым интересны высоконагруженные проекты и BigData.

В этом посте я хотел бы рассказать о подходах, приемах и средствах подготовки тестов. Расскажу про то, как не писать лишнего, меньше дублировать код, писать тесты так, чтобы их было легко поддерживать, и как выигрывать в производительности в некоторых ситуациях.

Кому это будет интересно?

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

Предлагаю вашему вниманию перевод фрагмента книги Metaprogramming Ruby 2 за авторством Паоло Перротта (Paolo Perrotta).

Что такое method_missing?

В Руби мы можем вызывать методы которые не существуют, но это будет возвращать нам ошибку. Для примера:

class Lawyer; end
nick = Lawyer.new
nick.talk_simple

NoMethodError: undefined method 'talk_simple' for #<Lawyer:0x007f801aa81938>

Помните ли вы как работает поиск методов? Когда вы вызываете метод talk_simple, Ruby идет в класс объекта nick, и перебирает там методы. Если он не может найти метод там, он ищет его в родителей данного класса, потом в Object и наконец в BasicObject. Ну и поскольку Ruby не может нигде найти метод talk_simple, он запускает метод method_missing для nick’a. Ruby знает что этот метод есть, потому, что это приватный метод BasicObject от которого наследуются все объекты.

Были времена на Хабре, когда каждый уважающий (и не очень) себя рельсовик зачем-то выкладывал свои рецепты настройки боевого сервера и деплоя приложения на Ruby on Rails. Таких статей было 60% от всех статей в хабе Rails, и отголоски того времени до сих пор всплывают: так, например, за август я нашёл две статьи про деплой рельс.

Надоело.

$ gem install from-scratch
$ scratchify your_app_name your.host.com

Что это за магия, читайте под катом.

Недавно мы опубликовали гем RailsStuff. Это коллекция небольших модулей и утилит для выполнения самых разных частых задач: от организации контроллеров и генерации уникальных случайных значений до парсера параметров и хэлперов переводов. В этом посте я расскажу про некоторые из них:

• ResourcesController — облегчённая и современная версия InheritedResources;
• Трекер типов;
• Генератор уникальных случайных значений;
• Хэлперы переводов и основных ссылок.

«Жить захочешь — не так раскорячишься» © Особенности национальной охоты

Как часто Вам приходится заниматься «слаживанием» работы клиентской и серверной части приложения, организовывать обмен сообщениями, его своевременность, обеспечивать доступ к данным и их постоянную актуальность на клиенте?

Часто? Тогда возможно Вам будет интересна идея и реализация, описанные в этой статье.
Речь пойдет о Javascript, Ruby и Websockets.

Привет!

Сегодня представляем спикера RailsClub 2015 Николая Рыжикова. Николай технический лидер команды Health Samurai, активист питерского Ruby & Clojure сообществ и мета-сообщества Piter-united.
А до самой конференции меньше недели, успевайте присоединиться!

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

Сегодня мы хотим рассказать о партнере конференции RailsClub – стартапе Vexor.io. Это быстрое и дешёвое решение для автоматизированного тестирования (Continuous Integration). В этом посте: немного о Vexor, кейс о тестировании большого проекта и крутой конкурс, в котором можно выиграть квадрокоптер! Вот такой:

Привет!

Осталась неделя до конференции RailsClub. Мы уже планируем, как будем встречать и развлекать приглашенных спикеров, печатаем для всех участников классные наклейки, вместе с докладчиками репетируем их выступления. Самое время зарегистрироваться, если вы вдруг еще не успели. Сделать это можно тут.
Сегодня новое интервью, на вопросы ответил наш коллега Александр Кириллов, Ruby-разработчик из Evrone, со-организатор конференции Юкон в Саратове.

Привет!

RailsClub уже в конце следующей недели, и мы плавно приближаемся к нашему рекорду — 400 участников со всей России и не только. Присоединяйтесь и вы! Регистрация — тут. А сегодня публикуем интервью с Иваном Немытченко. Иван разработчик на Ruby из Белграда, со-организатор конференции Хэппидев в Омске, был соучредителем небольшой аутсорсинговой компании Jazzcloud и компании побольше 7bits, недавно стартанул проект RailsHurts, а также проводит воркшоп LeanPoker везде, где бывает (и в Москве тоже).

Привет!

Сегодня новое интервью со спикером конференции RailsClub. На наши вопросы ответил Борис Горячев, бэкенд разработчик в Meduza.io. Сейчас он пишет различные проекты на rails, cuba, phoenix (elixir).

Привет!

Осталось 11 дней до конференции RailsClub! Сегодня мы публикуем интервью с техническим директором Cloud Castle Владимиром Ярцевым.

Привет!
На конференцию RailsClub, которая состоится 26 сентября уже сегодня зарегистрировалось 350 человек. Мы перерастаем собственные прогнозы, это круто! Новое интервью со спикером — Андреем Куманяевым, разработчиком COUB.

(Иллюстрации к статье А.П. Ершова «Программирование — вторая грамотность»)

Стив Джобс не написал ни строчки кода, Билл Гейтс — написал. Пол Грэм — первоклассный программист, Питер Тиль — юрист по образованию, сооснователь PayPal и владелец Palantir (написал ли он что-нибудь?), а Илон Маск в детстве написал свою игру и успешно её продал.

Никита truesnow из #tceh сказал мне, что на курсе «Врубаемся в Ruby» они научат программировать любого человека, даже с нуля. Я спросил его: «А с гуманитарием справитесь?» И мы задумались, были ли случаи, когда «гуманитарий» выучил язык программирования?

На ум сразу пришел бомж-программист, но после успеха с его приложением он предпочёл остаться «дзен-монахом». Есть ли еще примеры? Вдохновляющий пример, что научиться кодить может каждый — слепой программист. Когда я прочитал статью на Хабре «Смотря на код с закрытыми глазами», то понял, что нет преград, кроме собственных отмазок.

А у меня для вас есть три истории из моей жизни. Просто три истории.

История первая — ламер

Слово «ламер» я прочитал в «Компьютерре». Там давалось такое определение: «Ламер — отнюдь не безграмотный человек, не умеющий (как бы это помягче выразиться?) программировать». Окрылённый истиной я побежал и рассказал об этом друзьям-одноклассникам, но они предпочли поиграть в футбол, вместо того чтобы освоить суперспособности. Забавно, что потом все они зарабатывали программированием деньги, а я нет. Через неделю я записался в краевую станцию юных техников (КСЮТ), где был кружок по программированию. Там для новичков давали qbasic. А боги прогали на C.

Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.

Я отметил следующие недостатки:

• Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
• Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов (однако, можно настроить распараллеливание комманд явным образом).
• Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
• Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
• Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.

Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.

Привет!

Новая неделя и новое интервью со спикером конференции RailsClub 2015, которая пройдет 26 сентября в Москве. Сегодня на вопросы отвечает Кир Шатров — ведущий разработчик в Злых Марсианах, контрибьютор Rails и ведущий RubyNoname Podcast.

Привет!

Мы очень рады, что в нашем сообществе есть прекрасные девушки-программисты! Сегодня интервью со спикером конференции Анной Щербининой. Аня — лид веб-команды в Artec Group. А на конференции RailsClub 26 сентября она расскажет о языке Crystal и его возможностях.

Привет!

В этом году на конференции RailsClub 26 сентября будет целых 20 спикеров, это наш рекорд! Сегодня публикуем интервью с Тимофеем Цветковым.

Тимофей окончил факультет Вычислительной математики и кибернетики МГУ. В октябре 2009 стал одним из первых сотрудников Evil Martians. В 2012 ушел из Марсиан и вместе с партнером запустил свой проект: онлайн обучение и анализ данных в покере. К сожалению, компания не достигла своих финансовых целей и в 2015 была закрыта. В марте Тимофей присоединился к Toptal Core Team и теперь работает в отделении аналитики.

Тимофей — один из фаундеров и тимлид некоммерческого проекта Web-наблюдатель, в 2012 получившего награду The BOBS от Deutsche Welle в номинации Лучшее использование технологий на благо общества.

Не пьет кофе, любит чай и галстуки-бабочки.