Rails и Heroku.

Привет.

Облачные технологии приходят на помощь всем.
Для разработчиков Ruby on Rails (RoR) есть такой сервис как Heroku. Heroku это PaaS.

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

Что предлагает Heroku?
Первое предложение заключается в том, что предоставляется среда разработки проектов на RoR, для работы с которой вам понадобится лишь браузер.  Это избавляет от необходимости использования сторонних программных продуктов, предназначенных для программирования на RoR. Плюс этого в том, что в сравнении с другими языками, ограничения, накладываемые Ruby и RoR, могут быть сложнее, чем просто установка и настройка, использование предоставляемой среды разработки утраняет эти ограничения. Heroku хотят предоставить, как профессионалам, так и новичкам, возможность беспроблемной разработки с использованием лишь ПК с браузером.

Второе предложение Heroku позволяет разработчикам размещать (host) их, а так же масштабировать (scale). Heroku использует Amazon Web Services для масштабирования проектов размещающихся у них, и планируют в качестве дополнительной возможности взымать плату за кол-во потребляемых мощностей с платных пользователей, использующих данную услугу. Даже, если вы не желаете разрабатывать свое приложение с использованием Heroku, вы можете просто импортировать ваше приложение, чтобы ощутить всю мощь автоматической масштабируемости, предоставляемой этим сервисом.

Пробуйте.

Удачных выходных.

Как запомнить SQL JOINS.

Всем привет!

Для тех, кто забыл, а может и не знал как быстро запомнить различные JOIN, на помощь приходит вот такие картинки.
Источник

Источник

Все. =)

Удачи.

Типичный рабочий процесс при работе с SVN.

Привет.

Многие ипользуют различные системы контроля версий. У новичков всегда возникает вопрос, что делать и как комитеть, как работать с системой.

В документации по SVN представлен вот такой типичный рабочий процесс (Basic Work Cycle):

1. Обновляем свою рабочую копию проекта.
   • svn update
2. Добавляем свои изменения.
   • svn add
   • svn delete
   • svn copy
   • svn move
3. Проверяем добавленные изменения на корректность.
   • svn status
   • svn diff
4. Возможно отменяем некоторые изменения.
   • svn revert
5. Устраняем (резолвим) конфликты / применяем (мержим) изменения от других.
   • svn update
   • svn resolve
6. Коммитем свои изменения.
   • svn commit

Это можно взять за основу своего рабочего процесса работы с системой контроля версии.

Спасибо за внимание.

Удачи.

Немного про array и метод map в Ruby

В Ruby как и в других языках программирования есть массивы - класс Array.
Этот класс (Array) имеет много методов для работы с массивами раскажу об одном из этих методов map.
Поясню на примере:
Пусть есть массив arr1 = [4, 5, 6]
Мы можем создать новый массив arr2 на основе массива arr1 используя map.
arr2 = arr1.map { |a| a+6 } # [10, 11, 12]
Но есть особенность, мы хотим преобразовывать массив arr1 только для определенных элементов.
Например вот так: arr2 = arr1.map { |a| a+6 if (a > 4) } # [nil, 11, 12]
Как видно, если условие не выполнилось, то в новом массиве arr2 будут элементы nil. Для того, чтобы их не было можно воспользоваться методом compact.
arr2 = arr1.map { |a| a+6 if (a > 4) }.compact # [11, 12]
Во всех приведенных примерах методы map и compact создают ноые массивы.
Кто хочет может подумать, как оптимизировать работу с памятью.

Всем удачи.

Ключевые слова и идентификаторы в Ruby

Привет. Вот и пятница.

Сегодня в России официально начались продажи iPad2 =)

Но ... Приступим.

Ключевые (или зарезервированные) слова в Ruby обычно не применяются ни для каких иных целей. Вот их полный перечень, наверное =):

• BEGIN 
• END
• alias
• and
• begin
• break
• case
• class
• def
• defined?
• do
• else
• elsif
• end
• ensure
• false
• for
• if
• in
• module
• next
• nil
• not
• or
• redo
• rescue
• retry-
• return
• self
• super
• then
• true
• undef
• unless
• until
• when
• while
• yield

Имена переменных и других идентификаторов обычно начинаются с букв или специального модификатора. Основные правила таковы:

• имена локальных переменных (и таких псевдопеременных, как self и nil начинаются со строчной буквы или знака подчеркивания _;
• имена глобальных переменных начинаются со знака доллара $;
• имена переменных экземпляра (принадлежащих инстанцированному объекту)  начинаются с знака «собачки» @;
• имена переменных класса (принадлежащих классу) предваряются двум: знаками @ (@@);
• имена констант начинаются с прописной буквы;
• в именах идентификаторов знак подчеркивания _ можно использовать наравне со строчными буквами;
• имена специальных переменных, начинающиеся со знака доллара (например, $1 и $/), здесь не рассматриваются.

Приведу некоторые примеры:

• локальные переменные alpha, _ident, some_var;
• псевдопеременные self, nil,__file__;
• константы K6chip, Length, LENGTH;
• переменные экземпляра @foobar, @thxll38, @not_const; 
• переменные класса @@phydeaux, @@my_var, @@nOT_const;
• глобальные переменные $beta, $B12vitamin, $not_CONst.

На этом все.

Удачи.

Концепция баррикады

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

Захотелось поговорить о чем-то высоком, для этого блога это значит о проектировании и архитектуре ПО =)

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

Суть концепции заключается в следующем:
Все окружение программы разделяется на два - кому можно доверять (ближний круг) и кому нет (дальний круг).

Ближнему кругу можно относиться спокойно, там нет (точнее не должно быть) неверных объектов и ошибок.

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

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

Часть сущностей (назовем их «забаррикадные») — живут в активной и агрессивной среде, взаимодействуют с внешним миром, вызываются сторонними классами и им может быть передана любая чушь. Начинаться они должны со всех необходимых проверок и никому не доверять. Невалидность входных данных должна рассматриваться как штатный режим работы. Он не должен валить программу. В зависимости от принятой в проекте идеологии, при приходе невалидных данных можно написать сообщение в лог, выдать сообщение пользователю или вообще молча исправить данные на валидные и продолжить работу.

Следующая группа объектов — это сама «баррикада». Роль баррикады — гарантировать всем, кто находится внутри безопасность. Ничто не должно проникнуть внутрь баррикады непроверенным, несконвертированным во внутренние форматы, невалидным и т.д. Сюда входят разнообразные конверторы, валидаторы, вропперы и прочие аналогичные вещи.

И последняя часть концепции — это «внутрибаррикадные» жители. Они и есть тем, ради чего вся эта затея начиналась. Метод, находящийся внутри баррикады может не проверять входные параметры или текущее состояние объекта, к которому он принадлежит! За него это уже гарантированно сделала баррикада. Во всех внутрибаррикадных методах обязаны стоять ASSERTы, поскольку невалидность чего-нибудь является уже не проблемой взаимодействия с внешней средой, а конкретной ошибкой в баррикаде. Её в дебаг-версии нужно обнаружить и исправить. А в релизе ASSERTы будут выброшены компилятором и не будут никому мешать.

Конечно, в баррикадах есть недостатки — нужно чётко разграничивать вещи относительно баррикады по уровням доверия к ним, проверки внутри баррикады все-равно иногда нужны (ASSERTы), хоть их и значительно меньше. Всё это решает где-то полторы-две из трех описанных в начале статьи проблем, так что иногда может пригодиться.

Вот такая вот концепция.

Всем удачной недели.

Магические имена в Rails.

Привет, друзья!

Уже пятница и не загорами веселье, отдых и магия, но перейдем к тебе поста.

В Ruby on Rails есть список магических слов (Magic Field Names), которые используются системой для определенных нужд. Использование таких же названий может привести к проблемам вида WARNING: Can't mass-assign protected attributes: type.

Вот список этих зарезервированных слов и имен (List of Magic Field Names):

• created_at
• created_on
• updated_at
• updated_on
• lock_version
• type
• id
• #{table_name}_count
• position
• parent_id
• lft
• rgt
• quote_value (is used for quoting)
• template

На этом все.

Желаю всем приятных выходных.

Удачи.