Ruby on Rails c нуля!

Давайте выделим несколько наиболее выразительных групп методов:

1. Методы проверки, они возвращают true или false (методы — предикаты).
2. Методы копирующие объект и возвращающие его копию предварительно выполнив на ней определенные действия.
3. Методы преобразования, они изменяют объект для которого применяются (bang!-методы, методы — мутаторы).
4. Методы основной смысл которых — что-то передать, (я их называю методы — ссылки, к ним относятся, например аксессоры) (методы доступа).
5. Методы, которые устанавливают значения свойств/переменных (setter’ы)

Чтобы было понятнее о чем я, представляю примеры всех 4 типов методов:

1. Методы проверки (предикаты)

[1, 2, 3].empty? # => false
nil.nil? # => true

Read the rest of this entry »

Primate say: «Если в приложении должны быть пользователи — начинайте разработку приложения именно с пользователей!»

Зачем? Почему?

Не раз сталкивался с разработкой приложений, в которых имелась модель User и регистрация пользователей. То есть это были не закрытые приложения с одним или несколькими администраторами, а приложения в которых могут регистрироваться различные пользователи, приложения, в которых у пользователей есть роли и права. Как правило, я всегда начинал работу над тем, что называется основным функционалом приложения, а пользователей пытался добавить где-то в средине процесса разработки. У меня всегда были сомнения по поводу правильности такого подхода, но привычка не давала мне возможности пересмотреть подход к разработке.

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

Поскольку все дейсвия в приложении выполняются не сами по себе, а от имени пользователя, то вполне логично, что сначала должен быть Большой Взрыв пользователь, а затем уже перечень его возможностей. В коде, где пользователям уделена центральная роль у вас значительно меньше вероятность запутаться с распределением привилегий, при этом объявление прав  на выполнение определенного действия должно предшествовать собственно реализации самого действия. Создание пользователей раньше остального функционала больше соответствует BDD и облегчает разработку по такому принципу; в случае, когда User создается после некоторого набора функций приложения,  у вас скорее всего возникнет необходимость переписывать спецификации для этих функций.

Мне на ум пришла такая идея (на оригинальность не претендую), что было бы хорошо организовывать «круговое поручительство» для разработчиков, которое заключается вот в чем:

• Группа программистов занятая в одном проекте выполняет проверку труда друг-друга.
• Круговое поручительство похоже на хоровод — тот, кто ведет тебя предоставляет тебе результаты своего труда для проверки, а ты сам предоставляешь свой код тому человеку, который идет за тобой.
• «Поручитель» не только изучает чужой код, но и делает его рефакторинг и оптимизацию производительности, там где узкие места очевидны.
• После полученных правок к своему коду каждый член команды должен изучить их и сделать соответствующие выводы.
• Через определенный промежуток времени все «перетасовываются» заново, так, чтобы у каждого появился новый «поручитель».

Что это дает?

• Улучшается качество кода за счет «мгновенного» рефакторинга.
• Ускоряется обучение начинающих разработчиков за счет осознания и исправления своих ошибок и изучения правильных техник.
• Разработчик разрабатывая определенную часть приложения не зацикливается на ней, а имеет возможность изучить все приложение целиком.

Недостатком является падение производительности в плане количество фич на человека за единицу времени.

Сейчас я хочу испытать эту идею в команде разработчиков Quasar CMS, а позже поделюсь впечатлениями и выводами. Будет интересно узнать мнение кого-то, кто уже работает с применением подобных техник и тех, кто попробует на практике то, что я здесь описал.

JavaScript имеет множество недостатков, но влияния многих из них можно избежать используя правильные практики и рекомендации бывалых разработчиков. Эта статья — это компиляция различных советов по улучшению кода и практик по его написанию. Большей своей частью статья опирается на рекомендации данные Дугласом Крокфордом, но содержит и много практик от других разработчиков.

1. Всегда используйте фигурные скобки.
JavaScript позволяет не писать фигурные скобки, однако то, что это позволено не означает, что это правильно. Во-первых ваш код выглядит не так очевидно, а во вторых он не будет работать после его минификации.

Не правильно

if (true)
  alert(true);

Правильно

if (true){ alert(true); }

2. Всегда ставьте точку с запятой.
В JavaScript ставить точку с запятой в конце каждой строки является необязательным, однако, что произойдет если мы минифицируем код? — Правильно, код поломается.

Неправильно

function myFunction(a,b) {
  var sum = a + b
  alert(sum)
}

Правильно

function myFunction(a,b) {
  var sum = a + b;
  alert(sum);
}

3. Всегда используйте var для объявления переменных и избегайте глобальных переменных.
Если вы не используете var для объявления переменных, то такие переменные объявляются как глобальные переменные. Глобальные переменные несут различные опасности связанные с некорректной работой кода.

Read the rest of this entry »

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

Задача состоит вот в чем:
Необходимо найти числа-палиндромы (которые при чтении слева и справа выглядят одинаково). Автор (к сожалению имени не знаю) предлагает следующее решение:

#Создаем массив чисел
numbers = []
(100).step(999,1) do |first|
  (100).step(999,1) do |second|
    numbers.push first * second
  end
end

#находим палиндром
polinoms = []
numbers.map do |subnumber|
  polinoms << subnumber if subnumber.to_s == subnumber.to_s.reverse
end

#максимальный палиндром
puts polinoms.max

Совет: Оборачивайте код в методы.
Read the rest of this entry »

Вы можете поймать муху палочками для еды?
Вы можете простоять в позе журавля трое суток?
А отжаться стоя на мизинцах?

Правдивый ответ: не могу! А вот великие учителя, далее по тексту мы будем называть их гуру, — могут.

Вполне закономерный вопрос: Зачем мне ловить муху палочками?

В ответе гуру на ваш вопрос будет говориться о совершенствовании души и тела, о бесконечном светлом стремлении к совершенству, о величестве духа человека ловящего мух палочками для еды, об очищении кармы и т.д., но толком ответа не даст, а ответ таков: ловить палочками для еды мух необходимо только для того, чтобы стать гуру, зачем — это уже другой вопрос.
Read the rest of this entry »

Я работал над приложением написанным на Rails 3, в котором пользователи могли объявлять собственные свойства экземпляра модели, которые могли им понадобится. Проблема тогда состояла в том, как динамически создавать свойства объекта?
Read the rest of this entry »

Сегодня немного налажал с кодом и решил написать статью так сказать для закрепления представлений о хорошем коде в голове, ну и разумеется для того, чтобы поделиться имеющимися бедными познаниями с другими новичками. Более-менее опытным разработчикам все это уже, наверняка, известно, поэтому, если вы себя таковым считаете — можете не читать.
Read the rest of this entry »

Это относительно вольный перевод с английского статьи

Предыдущие статьи из рубрики:
Ruby и красивый код #1
Ruby и красивый код #2
Ruby и красивый код #3

Что же такое идиома?
Идиома — это что-то специфическое в языке. Идиомы Ruby — это программистские техники которые специфичны для Ruby и позволяют писать на Ruby небольшие фрагменты кода, которые, если попытаться переписать на менее лаконичном языке, потеряют свою красоту и могут превратиться во что-то монструозное.

Зачем изучать идиомы в Ruby, если можно писать код и без них?

Во-первых идиомы — это лаконичный код, а во-вторых вы ведь не сплошь и рядом пользуетесь своими велосипедами? Вы наверняка используете чужие библиотеки и rubygem’ы и плагины и читая чужой код вы наверняка наткнетесь на идиомы и техники метапрограммирования, таким образом без знания идиом языка Ruby и техник метапрограммирования вы не сможете понять чужого кода.
Read the rest of this entry »

Предыдущие статьи из рубрики:
Ruby и красивый код #1
Ruby и красивый код #2

Исходя из активности комментирования последнего поста Ruby и крассивый код #2 делаю вывод о том, что рубрика действительно интересна и стоет ее развивать. По сему представляю еще 2 задачи:

Задача #1
Дан массив целых чисел. Вывести напечатать номер последнего его элемента, который удовлетворяет двойному неравенству A[0] < A[i] < A[-1]. Если такого элемента не найдено, то напечатать «[ ]«.

Read the rest of this entry »