Ruby *

Появилась у меня как-то идея (или расcчётка по мобильным платформам) написать приложения под android на своём любимом ruby. И тут я вспомнил про проект который несколько раз упоминался в RubyNoName подкасте, собственно речь пойдёт о Ruboto.

У нас тут в Rails комьюнити опять драма. Первоначальный репорт. Есть методы типа find_by_* которые проецируются на модели в find_by_title например и find_by_id.
Их можно использовать так
find_by_id(params[:id], select: «CUSTOM SQL»)
Но обычно их используют вот так
find_by_id(params[:id])
И происходит SQL Injection если в params[:id] лежит {:select => «CUSTOM SQL»} — опции могут быть и в первом аргументе.

Обратите внимание — :select это символ а не «select»(строка). Это значит что трюк ?id[select]=SQL не пройдет т.к. ключ окажется строкой. И вообще params это хеш типа HashWithIndifferentAccess. Те у него ВПРИНЦИПЕ не может быть символов в ключах т.к. они все уничтожаются при создании.

Есть такой gem authlogic, в общем виде он использует find_by_token(token) где token это объект из сессии(которая хранится в куках и подписана session_secret). Чтобы в него записать :select => «SQL» вам нужно знать session_secret, поэтому уязвимость крайне редкая.
Весь этот SQL Injection CVE не стоит выеденного яйца! И ради чего пост? DoS!

Всем доброго времени суток.
Я работаю системным администратором в небольшой компании myhotspot, занимающейся различными разработками в сфере IT, в том числе на ruby on rails. Естественно приходится часто устанавливать и администрировать виртуальные сервера, для чего мы с успехом используем Puppet. На Хабре уже писали про Puppet (Как стать кукловодом или Puppet для начинающих или Puppet под нагрузкой), но не описали того, о чем на мой взгляд очень важно сказать. Суть проблемы, которую я хочу описать в процессе перехода на автоматическую систему управления конфигурациями серверов под названием Puppet. О том как это проще сделать, чем нужно руководствоваться, чего стоит опасаться и как жить дальше.

В рамках создания фреймворка для некоторой системы Enterprise класса, у меня стояла задача создания утилиты для автоматизированной генерации кода по UML модели. Ничего наиболее подходящего для быстрого и эффективного решения задачи, кроме как использование Ruby, и встроенного шаблонизатора ERB, под руку не подвернулось.

Файл проекта из среды UML моделирования представлял собой базу данных формата SQLite3, однако некоторую часть информации в этой БД среда хранила в виде сериализованных в BLOB поля объектов. Формат сериализации был текстовый, но не совместимый ни с одним из известных, такими как XML, YAML, совсем отдаленно напоминал JSON. Использовать существующие в природе парсеры было невозможно.

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

Здравствуйте.

Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet.

Что такое система управления конфигурацией?

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

 

Всем привет!

Просим любить и жаловать: Джефф Морган, он же Cheezy (@chzy). Джефф дал нам подробное интервью о его новой книге «Cucumber & Cheese» и лучших методах тестирования, поэтому… довольно предисловий — читайте и знакомьтесь!

1. Здравствуйте, Джефф (Cheezy)! Спасибо, что нашли время поговорить с нами. Вы довольно известная личность, например, в мире Agile и ATDD. Но не могли бы Вы рассказать немного о себе для тех, кто еще Вас не знает?

Моя страсть – написание программ, чем я и занимаюсь почти тридцать лет. Восемь с лишним лет назад я решил покинуть «корпоративную машину» и основал компанию, которая впоследствии стала известна под названием LeanDog. С тех пор я путешествую по Соединенным Штатам и Канаде и помогаю группам разработчиков работать эффективнее, внедряя методики Agile и Lean.

thoughtbot (с маленькой буквы) — одна из ведущих американских консалтинговых фирм, ориентированных на веб разработку с помощью Ruby on Rails. thoughtbot эксплуатирует распространенную в этой среде бизнес-модель, и зарабатывает не только за счет консалтинга, но и за счет своих больших вкладов в Open Source, активного участия в жизни сообщества (например, подкаст Giant Robots Smashing into Other Giant Robots), образовательной деятельности (воркшопы, менторство), внутренних продуктов и литературы.

На их счету до сегодняшнего дня числилось две полноценных книги: The Playbook — исчерпывающий справочник по внутреннему распорядку и трудовым хитростям thoughtbot (бесплатна для изучения на их сайте), и Backbone.js on Rails — не менее исчерпывающее руководство по использованию JS фреймворка Backbone вместе с Ruby on Rails.

Интересна особенность их подхода к публикации книг. Это не статичный труд, написанный однажды, напечатанный на бумаге и устаревающий с годами, а продукт, поддерживающий версионность, развивающийся под влиянием читателей и сопровождающийся различными электронными плюшками, в том числе и готовым к использованию кодом примеров. «Исходники» книги хранятся на github, а это значит, что в любой момент читатель имеет возможность получить самый свежий релиз, сообщить о проблеме, обсудить какую-либо часть текста и т.п.

Сегодня они объявили о начале работы над новой книгой, под названием «Ruby Science. The reference for writing fantastic Rails applications». Более того, начать чтение книги и принять участие в её развитии можно уже сейчас.

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

Все ближе тот момент, когда выйдет четвертый порядковый релиз фреймворка Ruby on Rails. Доступно уже довольно много информации, и большой частью нового функционала можно начать пользоваться уже сейчас, чтобы массовый исход на новую версию не стал слишком болезненным (хотя политика версионности рельсы делает все, чтобы этот процесс был максимально гладким).

Самое время пробовать новинку на вкус. Ребята из Remarkable Labs пообещали выпускать для Вас по статье в день до самого нового года, освещая различные аспекты желанной четвертой рельсы.

Привет хабраписателям!

По рекомендации Хабрахабра многие пользуются сервисом habrastorage.org для хостинга картинок. Да, загрузка многих изображений через веб страничку это может и удобно, но не очень.

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

Появилась идея модифицировать клиент Gyazo, чтобы сразу отправлять скриншоты в хабрасторадж. И знаете, всё получилось!

scribd.com — многие знают что Scribd позволяет загружать до 50 000 файлов бесплатно и преобразует их в pdf + предостваляет неплохой виджет для показа файлов.

Но как сделать так, что бы, документ был виден только части пользователей, а другая часть могла видеть лишь небольшой кусок документа? Конечно все предельно просто, как это почти всегда и бывает с Ruby и Rails.

В некоторых проектах требуется дать возможность пользователю настроить правила для повторяющихся событий. Иногда правила событий могут быть достаточно сложными, к примеру, “каждый предпоследний день месяца” или “каждую вторую пятницу месяца до определенной даты“. Для решения подобных задач можно успешно применять gem ice_cube.

DRY(Don’t Repeat Yourself) — один из краеугольных принципов современной разработки, а особенно в среде ruby-программистов. Но если при написании обычного кода повторяющиеся фрагменты обычно легко можно сгруппировать в методы или отдельные модули, то при написании тестов, где повторяющегося кода порой еще больше, это сделать не всегда просто. В данной статье содержится небольшой обзор средств решения подобных проблем при использовании BDD-фреймворка RSpec.

RefineryCMS — это еще одна RoR CMS. Поддерживает Rails3.2, удобна. Я не стану тут заниматься пересказом пресс-релизов, если интересно — на сайте можно поиграться в демо. Поскольку родилась она не вчера, из коробки поддерживать Twitter Bootstrap не умеет. Есть костыль refinerycms-bootstrap, но меня он не впечатлил. Поэтому я расскажу, как быстро прикрутить bootstrap самому. NB! Эта заметка не предполагает, что вы уже видели RefineryCMS, но и не рассказывает именно о ней: рассказ пойдет строго о прикручивании TB.

ActiveSupport::Notifications – это встроенная в рельсы система уведомлений. Вы можете подписаться на определенные уведомления в Rails и вызывать свой код когда они будут посланы. Это чем-то похоже на ActiveSupport::Callbacks, но работают во всем проекте и события не нужно заранее объявлять.

Самый простой способ наступить на грабли — использовать асинхронность. Я знаком с программистами, зарекомендовавшими себя как крепкие профессионалы, которые буквально пасовали перед многопоточностью. Для затравки расскажу мою любимую историю про deadlock (прошу прощения за боян, но уж больно хорош). Лет десять назад Associated Press поведало миру, как в аэропорту шведского города Крисианстад пилот пытался посадить пассажирский самолет, однако никто из диспетчеров не ответил на его запрос. Оказалось, что диспетчер еще не вернулся из отпуска. В итоге самолет кружил над аэропортом, пока срочно не вызвали запасного диспетчера, который и
посадил самолет через полчаса. Разбор полетов показал, что причиной стало опоздание самолета. На борту которого и находился тот самый диспетчер, спешивший на работу из отпуска.

Итак, когда мы сталкиваемся с асинхронностью, нам приходится ломать привычную картину в голове: субъективно окружающий нас мир однопоточен. Если мы послали письмо, а через неделю получили ответ, для нас все происходит в пределах одного потока; нам не приходится отвечать за действия респондента и почтальона. А нашему коду — приходится.
Чтобы упростить жизнь программиста, можно использовать паттерн Реактор. Лучшая (на мой взгляд) его имплементация для руби — EventMachine. Но и с ней бывают не очевидные моменты. Об одном из них я и планирую вкратце рассказать.

Просматривая сегодня «Ruby Inside», наткнулся на статью Justin Kulesza Is Your Application Running with Ruby – Slow?. Статья от 6 ноября, но на Хабре об этой ситуации ни слова. А суть статьи вот в чем: ребята переносили свое приложение с сервера на Solaris на сервер с Ubuntu и использовали RVM для компиляции Ruby. Однако после переноса они заметили, что приложение стало как-будто бы тормознутее. Сначала погрешили на железо, но быстро выяснили, что дело в RVM, а именно в том, что RVM совершенно не использует оптимизацию при компиляции.

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

class User
  @var = 1
end

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