Немного про 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

На этом все.

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

Удачи.

Кое-что о Garbage Collector в Ruby

Garbage Collection (GC) в Ruby отличается от сборщиков мусора в Java, C# и некоторых других языков программирования. И отличает его то, что в Ruby GC не generational, т.е. non-generational. Это значит, что GC в Ruby не делит объекты на поколения. Суть использование «поколений объектов» (GC в Java, к примеру) сводится к тому, что вновь созданные объекты гораздо чаще становятся недостижимыми, чем те объекты, время жизни которых велико (поколений объектов - штука сама по себе не простая). Соответственно, GC, который учитывает поколения, сильно сокращает время выполнения сборки мусора, посколько количество просматриваемых объектов в ходе сборки не так уж и велико, поскольку сборщик обращает внимание только на «молодое» поколение, будучи уверенный в том, что остальные поколения он на славу почистил (существуют и другие поведенческие модели, но эта — основная). Такое деление на поколения и называется generational GC. Таким образом, GC в Ruby очень дорогая операция, потому что ему приходится просматривать все объекты в памяти, каждый раз, когда GC будет вызван.

В Ruby интересная модель управления памятью (How Ruby Manages Memory and Garbage Collection).


На этом все.
Удачной недели.

Технология cookie. Недостатки.

Cookie, на русском говорят куки.

Для начала вот какое определение. 

Куки (от англ. cookie — печенье) — небольшой фрагмент данных, созданный веб-сервером или веб-страницей и хранимый на компьютере пользователя в виде файла, который веб-клиент (обычно веб-браузер) каждый раз пересылает веб-серверу в HTTP-запросе при попытке открыть страницу соответствующего сайта. Применяется для сохранения данных на стороне пользователя, на практике обычно используется для:
- аутентификации пользователя;
- хранения персональных предпочтений и настроек пользователя;
- отслеживания состояния сессии доступа пользователя;
- ведения статистики о пользователях.

Это wiki_ru или можно на wiki_eng.

При всей универсальности файлов cookie (они поддерживаются производителями браузеров с незапамятных времен), им присущи серьезные (с современной точки зрения) недостатки:
- ограниченный, и очень маленький размер файлов. Обычно не более 4 Кбайт;
- передача от браузера к серверу и обратно при каждом запросе;
- проблем конфиденциальности;
- технические недостатки. В частности, они не всегда точно идентифицируют пользователя и
  могут быть причиной атак злоумышленников;
- если на компьютере используется более одного браузера, то, как правило, каждый имеет 

  отдельное хранилище для куки;

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

Можно отметить, что как развитие технологии cookie, обычно рассматривают Web Storage.

Возвращение и обращение к читателям.

Всем, Привет!
Я вернулся. Прошел целый месяц, но время не прошло зря. Благодоря вашим отзывам и рекомендация от друзей сложилось более понимающее отношение к ведению блога.

Кратко о том, что вас ждет.

Во-первых про сами статьи.
Статьи будут представлять собой описание чего-либо или решение какой-либо проблемы.
Постораюсь быть как можно информативнее и кратким.

Во-вторых про переодичность.
Статьи будут выходить два раза в неделю. Скорее всего дни следующие: 1 раз - понедельник или вторник, 2 раз - четверг или пятница.

Спасибо. До новых встреч.