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

К системе управления сборкой проекта выдвигаются следующие требования:

1. Компиляция из coffescript в javascript. Если в файле coffeescript содержится ошибка, то в консоли должны отобразиться название файла и сообщение об ошибке.
2. Сборка проекта в один javascript файл должна производится с учетом зависимостей.
3. Возможность собрать все приложение целиком в один файл в нескольких видах (с комментариями, минимизированный). При этом само приложение может состоять из нескольких модулей.
4. Сборка тестовых файлов и их выполнение в консоли (да, разрабатываем для веба, при этом не притрагиваемся к мышке и вообще не вылазим из любимого vim'a).
5. Конечно же все это должно быть удобно в использовании.

В данной статье я не буду затрагивать вопрос тестирования, а рассмотрю вариант системы управления сборкой javascript/coffescript проекта (и саму структуру проекта) с использованием rake и Rake::Pipeline (git).

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

Предположим, что единственный способ представления кода — лямбда-выражение, а единственная доступная структура данных — массив:

square = ->(x) { x * x }
square.(4) # => 16

person = ["Dave",:male]
print_person = ->((name,gender)) {
  puts "#{name} is a #{gender}"
}
print_person.(person)

Это самые основы функционального программирования: функции — единственное, что у нас есть. Давайте попробуем написать что-то более похожее на реальный код в таком же стиле. Посмотрим, как далеко мы сможем зайти без особых мучений.

Компания JetBrains рада сообщить о выходе RubyMine 4.5 — новой версии интеллектуальной интегрированной среды разработки для Ruby on Rails, которую можно загрузить с нашего сайта

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

Прим. переводчика — пост про интеграцию Robokassa и Rails уже был, но способ, предоставленый там, полагаю, многих не устроит.

Когда у вас есть приложение, написанное на Ruby on Rails и вы планируете добавить какую-нибудь платежную систему (например PayPal, Moneybookers или Robokassa, как в нашем случае), то первый гем о котором вы должны подумать — это active_merchant от Shopify.

ActiveMerchant — простая абстрактная платежная библиотека используемая и спонсируемая компанией Shopify.

Поэтому когда мне понадобилось добавить платежи через Robokassa в наш проект, я открыл список поддержеваемых платежных систем и был немного разачарован, потому что Robokassa туда не входила. Чуть позже я нашел форк, который добавлял её поддержку, но он уже устарел, поэтому некоторые тесты падали ec801d3d4f8. Таким образом я решил глянуть на этот код и исправить его, а не писать всё с чистого листа.

Хочу поделиться в вами несколькими трюками, которые помогут сделать работу с Ruby on Rails лучше, быстрее, а также позволят вам много зарабатывать и более лучше одеваться.

Подкаст

http://ruby.rpod.ru/278465.html

Новости

• Бесплатные рускоязычные скринкасты по Ruby
• Новые свежие рельсы 3.2.6, 3.1.6 и 3.0.14
• Новый инструмент для быстрого деплоя — mina
• Вышел gem RubyMass, который позволяет смотреть, какие объекты есть в текущем процессе
  Evan Phoenix о RubyMass
• Grocer и urbanairship
• Evented Ruby vs Node.js
• Techniques to Secure Your Website with Ruby On Rails: part1 and part2
• RSpec's New Expectation Syntax
• Вышла web-книжка Стива Клабника по конструированию Hypermedia (formerly AKA REST) APIs.
• Близится выход 2.0.0 гема Couchrest::Model. Сейчас в «репе» проекта на GitHub'е доступна
  вполне рабочая бета.

В ECMAScript пока отсутствует понятие «класс», в классическом понимании этого термина, однако, в CoffeeScript такое понятие есть, поэтому сегодня мы рассмотрим этот вопрос очень подробно.

Содержание:

1. Основные понятия
2. Члены класса
   2.1. Метод constructor
   2.2. Открытые члены класса
   2.3. Закрытые члены класса
   2.4. Защищенные члены класса
   2.5. Статические члены класса
   2.6. Оператор => (fat arrow)
3. Наследование
4. Дополнительная литература

На хабре уже есть несколько статей о rbenv (раз, два, три), но ни в одной не упомянут очень удобный инструмент rbenv-installer. Этой статьёй я и заполню этот пробел.

Прежде чем начну описывать установку, хочу сказать чем меня порадовал rbenv и почему я перешёл на него с RVM.

В одном из моих проектов мне понадобилось периодически запускать задачи (rake tasks) с помощью cron. Задачи для cron-а я формировал и записывал в crontab с помощью гема whenewer. Тогда я ещё пользовался RVM и cron в лог писал что-то вроде:
bundle: command not found

Искал решение с помощью гугла и нашёл в issues whenewer-а упоминание о такой же проблеме. Тикет был закрытым и упоминалось что в rbenv всё работает. Установил я rbenv и без каких-либо дополнительных настроек мои cron-задачи стали работать так как я и хотел. С того дня в новых проектах я только rbenv использую.

Подкаст

http://ruby.rpod.ru/277590.html

Новости

• Зарелизились версии 3.0.13,
  3.1.5 и
  3.2.5 Rails
• Online routes
• James Golick выпустил фреймворк
  Objectify.
• Русский скринкаст о Руби
• 100-ый коммит Алексея Вахова в rails.
• ActiveSupport::Configurable
• Разработчки JRuby ушли в RedHat, русский
  перевод
• Замена стандартному OptionParser
• Зарелизился фреймворк от рельсоводов для рельсоводов — Joosy
  пост на хабре
• JRuby performance
• Yet another debug for ruby

Видимо, только второй пост на хабре с участием Padrino за 2 года ;)



Используйте HAML для генерации HTML



Используйте SASS для генерации CSS



Используйте Coffee Script для генерации JS



Скачайте шаблонное приложение, установите инструментарий и начните разработку немедленно.

10 минут и все работает даже под Windows.

Подкаст

http://ruby.rpod.ru/276289.html

Новости

• Libskypekit and Skypekit – C and Ruby interface for Skype
• Gem для работы с Google spreadsheet
• Поддержка PostgreSQL datatypes в Rails 4
• Ruby 2.0 roadmap
• The Bastards Book of Ruby
• Continuos deployment for ruby gems
• Ruboto 0.6.0
• Mechanize 2.5
• Гем для асинхронной отсылки почты из devise - devise-async
• Глава из книги Ruby Under a Microscope
• Последняя попытка попасть на devConf

В начале месяца появились новости о том, что Red Hat открыла код своей PaaS OpenShift. Те, кто следит за развитием этого проекта, наверное уже заметили, что в Red Hat уделяют OpenShift очень большое внимание. Помимо добавление нового функционала (из недавнего — поддержка Node.js) постоянно происходит и улучшение уже существующего. К последнему можно отнести и новость о переходе в Red Hat двух ключевых разработчиков JRuby.

В первой части статьи мы написали REST приложение и на 1/3 настроили Redactor.js. Сегодня мы закончим наше изобретение, написав интерфейс управления загруженными изображениями, и обеспечим загрузку файлов. При загрузке файлов мы не будем использовать CarrierWave, а пойдем обычным путем Ruby.

Данная статья рассчитана первым делом на новичков, которые только начинают изучать Ruby. После 3 недель изучения этого замечательного языка, накопились некоторые знания, которыми хочется поделиться.

Sinatra — бесплатный и открытый программный каркас написанный на языке Ruby, предназначенный для разработки веб-приложений. (ru.wikipedia.org)

Redactor — достаточно мощный и в тоже время простой и красивый в использовании wysiwyg редактор (ссылка на хабре)

Итак, у нас есть существующее приложение Ruby on Rails, работающее под ruby 1.8.7. Казалось бы, “работает — не трогай”! Однако, переход на ruby 1.9.x для приложения, которое мы планируем развивать и поддерживать в будущем, неизбежен

Опубликовано сообщение о массовой уязвимости в проектах на Ruby. Речь идёт об использовании ^ в начале строки и $ в конце строки регулярных выражений вместо \A и \z.

Дело в том, что ^ и $ в таких случаях воспринимается Ruby как новые строки (\n), что открывает двери для инъекций.

Примечание переводчика: данный пост является логическим развитием, а точнее «предысторией» поста Вникаем в include и extend и был подсказан в комментариях к нему пользователем murr, за что ему большое спасибо.

Классы и объекты в Ruby связаны между собой достаточно затейливо и не сразу можно понять что к чему. Из-за особого назначения классов очень легко потерять из вида тот факт, что классы — это тоже объекты Ruby. От «обычных» объектов их отличает два вещи: они служат образцом для создания новых объектов и они являются частью иерархии классов. Все верно, классы могут иметь экземпляры себя (объекты), суперклассы (родителей) и подклассы (детей).

Если классы — это объекты, то у них должен быть свой собственный класс. Классом всех классов (как объектов) в Ruby является класс Class:

# один из способов создать новый класс
Dog = Class.new
    
# общепринятый способ создания класса
class Dog
    # какая-то реализация собачьего поведения
end

Dog.class
=> Class

Подкаст

ruby.rpod.ru/275445.html

Новости

• Rails for API applications (rails-api)
• Проекту Rusrails исполнилось 2 года
• Инсталятор rails для OS X RailsOneClick
• И еще один инсталятор для OS X — Railscar
• Инструмент для разработки на Ruby под iOS RubyMotion, и куча обзоров на него. Обзор от
  Matt Aimonetti (merbist), от
  PragmaticStudio
• Funny Falcon выпустил свой патч для Ruby 1.9.3-p194
• Вникаем в include и extend
• What is the Ruby Top-Level?
• Метаклассы в Ruby
• Отличный рассказ про DRb на Хабре

Недавно вышла книга The dRuby book — distributed and parallel computing with Ruby (перевод японской книги, написанной автором самой библиотеки). В этой статье я попытаюсь дать обзор глав книги, касающихся библиотеки DRb. Если вам захочется ознакомиться с темой более подробно, книгу можно купить или скачать. Сразу скажу, что я не буду говорить в этом посте ни о синхронизации потоков, ни о библиотеке Rinda.

Предположим, что вы пишите систему, которая работает с более чем одним процессом. Например, у вас есть веб-сервер, который в фоновом режиме запускает задачи, работающие долгое время. Или вам просто нужно обеспечить пересылку данных из одного процесса в другой и координировать их. Для таких ситуаций и нужна библиотека DRb. Она написана целиком на Ruby и включена в стандартную библиотеку, поэтому начать работать с ней можно моментально. Для её подключения достаточно написать require 'drb'

Достоинства библиотеки DRb большей частью проистекают из динамичности самого языка Ruby.
Во-первых, при затрате минимальных усилий на подготовительном этапе, дальше вы работаете с объектами не задумываясь, где они расположены: в одном процессе или в другом. Библиотека полностью маскирует от вас все технические детали.
Во-вторых, вы не обязаны жестко прописывать интерфейс. Любой руби-объект может выставить свой интерфейс наружу — таким образом вы можете как воспользоваться функциональностью одного из стандартных классов типа Hash или Queue, а можете сделать свой класс с любым интерфейсом. Кроме того вам ничто не мешает менять интерфейс прямо в процессе исполнения, и даже использовать method_missing для обработки любых запросов. И уж разумеется, обновление интерфейса сервера вообще никак не влияет на клиента, если тот не вызывает методы, которые изменили сигнатуру или поведение. Таким образом сервер и клиент максимально независимы.
И наконец, клиент даже не обязан знать классы объектов, которые ему возвращает сервер, он может их использовать и без этого. Таким образом сервер волен скрыть столько много деталей, сколько ему угодно.
Но, конечно, есть и подводные камни, и их предостаточно. К счастью, dRuby несложен в понимании, ну а понимание его устройства позволяет большей части проблем просто не допускать. Документация к этой библиотеке, к сожалению, не проясняет множества моментов, поэтому статья будет интересна и новичкам, и людям уже поработавшим с библиотекой.

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

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