Об именах методов

июля 21, 2012  |  Published in Ruby, Основы

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

  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 »

Tags: , ,

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

апреля 22, 2012  |  Published in Примат - советчик

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

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

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

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

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

Tags: ,

Круговое поручительство

февраля 16, 2012  |  Published in Development Processes

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

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

круговое поручительство

Что это дает?

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

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

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

Tags: ,

Замечательный JavaScript ч.2: Хорошие практики

декабря 9, 2011  |  Published in ClientSide, JavaScript

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 »

Tags: ,

Ruby и красивый код: Рефаторинг поиска палиндромов

августа 27, 2011  |  Published in Ruby, Основы

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

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

#Создаем массив чисел
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 »

Tags: ,

Термоядерное вооружение на службе добру

августа 10, 2011  |  Published in Уголок философа

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

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

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

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

Tags: ,

Динамические свойства в Ruby

апреля 16, 2011  |  Published in Ruby, Основы

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

Tags: , ,

Ruby и крассивый код #5: Рекомендации по стилю

февраля 24, 2011  |  Published in Ruby, Основы

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

Tags: , ,

Ruby и красивый код #4

декабря 7, 2010  |  Published in Ruby, Основы

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

ruby

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

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

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

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

Tags: , ,

Ruby и красивый код #3

ноября 20, 2010  |  Published in Ruby

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

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

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

Read the rest of this entry »

Tags: , ,