ноября 18, 2012 | Published in Best Practices, Уголок философа
Не раз ко мне обращались с какими-то вопросами, вроде помоги найти ошибку или что-то вроде того, когда я находил в годе копрокод, точнее, когда я находил, что весь код в целом — копрокод, то мне в лицо бросались ссылкой на ставшую популярной книгу Майкла Хартла. Последний такой случай сподвиг меня на написание этой философской статьи, которую многие по праву могут назвать водой, а автора которой мудаком, который должен облить себя бензином и поджечь.
Собственно из-за того бросания в меня ссылками на Хартла и родилось это название <irony>Майкл Хартл — самый ужасный программист в мире!</irony>. Я надеюсь, что использование тега <irony></irony> спасет меня от «Ты сам мудак! Хартл — няша!» ибо, как показывает практика, людей обидчивых и не понимающих иронию очень много. К Майклу Хартлу я отношусь очень хорошо, он написал хорошую книгу, которую я рекомендовал бы к прочтению всем и хотя у меня есть несколько мелких разногласий с автором, я все же считаю его отличным программистом, а его книгу обязательной для прочтения. Read the rest of this entry »
июля 21, 2012 | Published in Model, Ruby on Rails, Ruby on Rails 3
Статья будет иметь несколько хаотичной. В ней я приведу несколько примеров того, что я считаю неправильной работой с ActiveRecord. Что-то в статье — истина последней инстанции, а что-то — субъективное и, возможно, ошибочное мнение автора. Статья ориентирована на тех, кто хоть немного знаком с Ruby on Rails.
Очень популярная ошибка — не использование limit(1) для выборки одиночной записи с использованием where и других методов Quering API. Суть ошибки в том, что Rails не может за вас подумать о том, что вам необходима одна единственная запись, а не все удовлетворяющие условию. В случае, когда вы не используете limit(1) будет выполняться поиск по всей таблице, а не только до первой соответствующей условию записи.
Word.where(word: 'cat')
# Word Load (0.9ms) SELECT "words".* FROM "words" WHERE "words"."word" = 'cat'
# => [records]
Word.where(word: 'cat').limit(1)
# Word Load (0.7ms) SELECT "words".* FROM "words" WHERE "words"."word" = 'cat' LIMIT 1
# => [record]
UPD Вообще не пользуйтесь .limit(1), вместо .limit(1) используйте first, если вам действительно необходим лишь один элемент. Дело в том, что limit(1) возвращает массив с одним единственным элементом, чтобы получить этот элемент нам необходимо вызывать еще один метод — first (Array#first), или обращаться к элементу через индекс — Model.limit(1)[0].
Tag.limit(1).first
# Tag Load (1.6ms) SELECT "tags".* FROM "tags" LIMIT 1
Tag.first
# Tag Load (0.8ms) SELECT "tags".* FROM "tags" LIMIT 1
Read the rest of this entry »
июля 3, 2012 | Published in Ruby on Rails, Ruby on Rails 3
Всего 5 дней назад DHH добавил новый репозиторий организации Rails на Github. представляет собой расширение Rails проверенное на работоспособность только с Rails 3.2 и предназначенное для выDRYивания кода маршрутизации.
Принцип работы плагина простой, вы объявляете concern’ы, а в них помещаете код общий для нескольких ресурсов.
Read the rest of this entry »
февраля 16, 2012 | Published in Development Processes
Мне на ум пришла такая идея (на оригинальность не претендую), что было бы хорошо организовывать «круговое поручительство» для разработчиков, которое заключается вот в чем:
- Группа программистов занятая в одном проекте выполняет проверку труда друг-друга.
- Круговое поручительство похоже на хоровод — тот, кто ведет тебя предоставляет тебе результаты своего труда для проверки, а ты сам предоставляешь свой код тому человеку, который идет за тобой.
- «Поручитель» не только изучает чужой код, но и делает его рефакторинг и оптимизацию производительности, там где узкие места очевидны.
- После полученных правок к своему коду каждый член команды должен изучить их и сделать соответствующие выводы.
- Через определенный промежуток времени все «перетасовываются» заново, так, чтобы у каждого появился новый «поручитель».
Что это дает?
- Улучшается качество кода за счет «мгновенного» рефакторинга.
- Ускоряется обучение начинающих разработчиков за счет осознания и исправления своих ошибок и изучения правильных техник.
- Разработчик разрабатывая определенную часть приложения не зацикливается на ней, а имеет возможность изучить все приложение целиком.
Недостатком является падение производительности в плане количество фич на человека за единицу времени.
Сейчас я хочу испытать эту идею в команде разработчиков Quasar CMS, а позже поделюсь впечатлениями и выводами. Будет интересно узнать мнение кого-то, кто уже работает с применением подобных техник и тех, кто попробует на практике то, что я здесь описал.