Ruby *

С развитием браузерных MVC-фреймворков, Rails очень часто стали упоминать в контексте удобного фреймворка для REST-провайдеров. Мы тоже используем Rails для этой цели и достаточно долго. Есть, однако, очень большая проблема: представления. Вьюшки, которые описывают структуру JSON для ответа.

На первый взгляд, все просто отлично. Ничего кроме .to_json или RABL, в некоторых сложных случаях, не требуется. Но затем ситуация выходи из под контроля. И идут бесконечные циклы перебора JSON-билдеров в поисках лучшей жизни.

Проблема

Давайте возьмем для примера банковский сервис. Он состоит из 30 моделей. Каждая модель представлена CRUD-реурсом (в каждом по 3-4 расширяющих метода). В каждой модели 10-12 полей и это обычно длинные строки. И, конечно, все они связаны. Вплоть до 4-5 уровней belongs_to.

При этом важно помнить, что в реальной жизни JSON ответа – это не просто прямой дамп структуры модели. В нем постоянно встречаются условия (какой атрибут должен попасть в ответ? Зависит от другого атрибута) и кастомные методы.

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

Недавно мой патч Enumerable::Lazy был принят в ruby trunk. А это значит что в ruby 2.0 мы сможем:

a = [1,2,3,4,2,5].lazy.map { |x| x * 10 }.select { |x| x > 30 } #=> вычисление не происходит
a.to_a #=> [40, 50], объект вычисляется за один проход.

Наверняка все слышали шумиху вокруг проекта travis-ci.org. Я не являюсь исключением и учитывая, что один из его разработчиков, Джош Калдеримис (Josh Kalderimis), выступивший на прошедшей конференции toster.ru, разжег мой интерес еще больше, то я решил окончательно разобраться, что такое travis-ci и с чем его едят. После прочтения вы узнаете как данный сервис может помочь ruby-разработчикам, а также как ему могут помочь они. Располагайтесь поудобнее, начнем…

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

Введение

На написание этого поста меня сподвигло слишком малое количество материала о sinatra, и тем более о данной связке. Надеюсь для кого то этот пост будет полезен. Ниже я опишу как можно совместно использовать sinatra, mongodb и carrierwave, на примере создания простой фотогалереи. Для общения между sinatra и mongodb мы будем использовать отличный gem — mongoid. По умолчанию предполагается что у вас уже установлен ruby и mongodb. Приступим.

Использовался набор бенчмарков из ruby-1.9.3-p125. Все тесты запускались на:

ОС: OSX Lion 10.7.3
Процессор: 2.3ГГц i5
Память: 8Гб 1333 MHz DDR3
SSD: OCZ Vertex 3 Max IOPS SATA III 2.5" 120Гб

Реализации:
— ruby 1.8.7p249 (системный ruby)
— ruby 1.9.3p125
— ruby 2.0.0dev (2012-02-25 trunk 34796)
— MacRuby 0.12 (ruby 1.9.2) (Nightly build)
— maglev 1.0.0 (ruby 1.8.7)
— rubinius 1.2.4 (1.8.7 release 2011-07-05 JI)
— rubinius 2.0.0dev (1.9.3 e22ed173 JI)
— jruby 1.7.0.dev (ruby-1.9.3-p28) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_04-ea)
— jruby 1.6.7 (ruby-1.8.7-p357) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_04-ea)

Хотя на Хабре уже проскакивали статьи о создании гемов, они либо содержат устаревшую, либо неполную информацию.

Как же на самом деле надо создавать, развивать и публиковать свои гемы?

Современный подход заключается в использовании Bundler совместно с другими инструментами, такими, как Git, YARD и RSpec-2.

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

Что такое Sinatra

Sinatra — маленький, но довольно интересный DSL (Domain-specific language) фреймворк, написанный на Ruby. В отличие от Ruby on Rails он не следует типичному паттерну MVC (Model — View — Controlller). Sinatra создавался для того, чтобы «программист смог быстро создать веб приложение, написанное на Ruby с минимальными усилиями.

Для того, чтобы воспользоваться Sinatra нам неорбходимо его установить. Сделать это можно следующей командой в RubyGems:

gem install sinatra

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

gem install shotgun

Ну вот и всё! Всё необходимое для работы у нас есть. Настал момент для творчества. Приступим…

Сегодня мы рады сообщить о выпуске RubyMine 4.0 — новой версии интегрированной среды разработки для Ruby on Rails от JetBrains. Основной темой релиза стала производительность. Были значительно ускорены функции индексации и анализа кода, и, как следствие, сократилось время отклика приложения при любой работе с ним.

В данной статье я не буду вдаваться в подробности работы RVM и rbenv. Информации по данным штуковинам хватает на просторах интернета. Здесь же я хочу попытаться раскрыть вопрос: когда стоит использовать rbenv, а когда нет?

Цель

Для этого давайте для начала разберемся для чего же создавался RVM, а для чего rbenv. Для этого достаточно взглянуть на возможности обоих систем.

I18n.locale = :ru — это новости о Ruby/Rails и связанных технологиях на Google+.

UPDATE: черзе год после вышеописанных событий, мы открыли (в дополнение к G+) и рассылку CodingDead. И вот зачем.

Из описания:
1-3 сообщения в день, безопасная для просмотра в офисе информация, не исползуется для рекламы или спама *.
* Оставляем за собой право на нецензурную брань в комментарих к статьям типа: ‘Why Ruby / Rails / #{your_favorite_gem} sucks‘, a также право на рекламу опенсорс технологий и событий Rails-собщества

Продолжаем серию статей, в которой мы знакомим читателей с различными веб фреймворками. И сегодня позвольте представить Goliath (Голиаф, http://postrank-labs.github.com/goliath/) — асинхронный веб фреймворк на Ruby, созданный компанией PostRank (http://postrank.com/), ныне купленной Google.

Главной особенностью Голиафа является применение модели событий для ввода-вывода, посредством библиотеки EventMachine, а также механизма волокон (fibers), появившегося в Ruby 1.9. Его можно считать аналогом столь модного сегодня Node.js, только на Ruby.

В статье мы рассмотрим такие вопросы:

• волокна и события;
• установка Goliath;
• написание простого чата с применением механизма long-polling;

В заключении вы найдете традиционные тесты производительности.

Gary Bernhardt рассказывает о Ruby и JS

Интересный факт: в Ruby 1.9.3 с 64-битным интерпретатором обработка строк длиной 23 и менее символов происходит почти вдвое быстрее, чем строк длиной 24 и более символов. Другими словами, этот код Ruby:

str = "1234567890123456789012" + "x"

… будет обработан в 1,92 раза быстрее, чем этот:

str = "12345678901234567890123" + "x"

Для 32-битного интерпретатора Ruby граница производительности находится в районе 11/12 символов.

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

 

Среди преподавателей сложилось мнение, что Ruby — наиболее подходящий язык для изучения программирования. Первый в жизни ЯП должен быть максимально простым в использовании и, разумеется, объектно-ориентированным. В нём не должно быть каких-то двусмысленных концепций или странных особенностей синтаксиса. В общем, Ruby подходит идеально, решили ребята из компании The Hybrid Group и выпустили приложение KidsRuby (код на github) — уроки Ruby для детей.

После вот этого поста, сообщающего о сногсшибательном увеличении производительности JRuby в версии 1.7 при работе на OpenJDK 7u2 в 3 раза относительно предыдущих релизов.

Припоминая относительную тормознутость и прожорливость JRuby в 2009м, и вот такую статистику от Programming languages shootout, я решил дать JRuby очередной шанс.

Сравнение не претендует ни на точность измерений, ни на всеобъемлемость тестов, а лишь призвано выяснить, догнал ли JRuby YARV по производительности, или нет. На старт, внимание,

Команда разработчиков JRuby настоятельно рекомендует всем установить последнюю версию OpenJDK 7u2 (OpenJDK 7 update 2), которая значительно доработана по сравнению с июльским релизом JDK 7 GA (General Availability). Среди прочего, сделана важная оптимизация в подсистеме invokedynamic. Поскольку JRuby 1.7 активно использует эту подсистему, то разработчики специально придерживали выпуск 1.7, дожидаясь этого апдейта. Собственно, официальный релиз 1.7 не произошёл до сих пор, но предварительную сборку для тестирования можно скачать здесь.

При использовании JRuby 1.6.x после апгрейда с Java 6 на Java 7 вы увидите прирост скорости JRuby-приложений примерно на 10-30%, а в случае с JRuby 1.7 — примерно в три раза!

Разработчики просят тех, кто не заметил никакой разницы в производительности, зарегистрировать сообщение в баг-трекере. Очевидно, это какой-то баг, который постараются исправить к официальному релизу JRuby 1.7.

Это ещё не всё. Для будущего OpenJDK 7u4 запланирован новый оптимизатор invokedynamic, и ребята из OpenJDK говорят о возможности ещё большего увеличения производительности.

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

Вместо введения

Наконец-то я нашёл немного времени для того, чтобы продолжить своё повествование о разнообразных чудесах в Ruby. Как вы помните, в прошлой части мы познакомились с основами написания своего гема. Мы узнали, какой минимальный набор файлов должен быть для того, чтобы его собрать. Также мы узнали как мы можем опубликовать своё творение в RubyGems. В тот же день (после написания первой части) в RubyGems неожиданно проявился всплеск гемов под названием hello-world. Причём я застал довольно много вариаций оного. Некоторые даже не удосужились поменять строку, где указывается автор гема.

g.author = "krovatti"

Некоторые вовсе задавали гему следующие значения версий:

g.version = "666"
g.version = "111"
g.version = "911"

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

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

Введение

Каждый рубист, да и вообще программист, рано или поздно начинает задумываться о написании своих библиотек. Ему начинает надоедать перетаскивание одних и тех же кусков кода в другие проекты. В Ruby лекарством от данного заболевания являются gem'ы. Итак, давайте познакомимся с ним поближе.