Все статьи с тегом ”Программирование”

С Ruby on Rails в рунете сложилась непростая ситуация: вроде, есть блогеры, о нем пишущие, есть специализированные сайты, но почему-то людям, желающим попробовать рельсы и начинающим rails-разработчикам, найти полезную информацию по Rails крайне трудно.

Знаете, что происходит в итоге? Рождается масса заблуждений препятствующих распространению мощной технологии. Например:

• «Гибкая разработка веб-приложений в среде Rails» — лучшая книга для любого Rails-разработчика» — бред собачий! Это книга «для чайников», не отражающая реалий rails-разработки.
• «Rails — это вещь в себе» — еще больший бред. Rails, вообще-то, обладает мощной инфраструктурой, включающей множество сторонних сервисов и библиотек.

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

Развертывание приложения

В Ruby есть очень мощный инструмент для работы с удаленными unix-серверами — Capistrano. Он же является стандартом де-факто для развертывания рельсов на production/staging серверах.

Принцип работы Capistrano в контексте рельсов простой — разработчик с локальной машины запускает capistrano, который в свою очередь подсоединяется к удаленному серверу через SSH и выполняет ряд команд: вытягивает свежую версию приложения из репозитория, создает для нее отдельную директорию и устанавливает символические ссылки для директорий со статическим контентом, перегружает веб-сервер и другие сервера (например, сервер для полнотекстовой индексации и поиска данных). Большим плюсом Capistrano в сравнении с аналогичными инструментами является поддержка rollback’ов. То есть в случае неудачного развертывания проекта Capistrano откатит все в исходное состояние.

Выше описан простейший пример работы Capistrano, который обычно выполняется с помощью его стандартных рецептов (скриптов). Вообще же с помощью капистрано можно можно разворачивать приложения в нескольких окружениях, можно разворачивать приложения сразу на кластерах серверов, можно на этих кластерах удаленно чистить кеш и вообще выполнять любые команды, которые можно выполнить в консоли unix-сервера. Существуют отдельные наборы рецептов капистрано, например capistrano-ext, Dump или rubaidhstrano, позволяющие автоматизировать резервное копирование баз данных и синхронизировать статические файлы (как и базы данных) в локальном окружении разработчика с production’ом.

Кстати, capistrano совсем не обязательно использовать с рельсами, впервые я с ним столкнулся полтора года назад, тогда с помощью Capistrano мы разворачивали PHP(symfony)-приложения на кластерах серверов.

Нет предела совершенству. В след за Capistrano появились проекты Shadow Puppet и Moonshine. Shadow Puppet — это инструмент для автоматизации настройки самих unix-серверов, с его помощью можно автоматизировать установку всего софта, библиотек, создание пользователей, настройки безопасности — очень полезный инструмент системного администратора. Moonshine представляет собо надстройку над Capistrano и Shadow puppet, позволяющую автоматически настроить «голый» удаленный сервер и развернуть на нем Rails-приложение, имея на удаленном сервере всего лишь пользователя с sudo-правами. К сожалению, в настоящий момент Moonshine поддерживает только Ubuntu Server 8.10 и Git-репозитории.

Существует альтернатива Capistrano — Vlad the Deployer, он проще в использовании, но на фоне Capistrano функционал Влада кажется скудным.

Профилирование, мониторинг производительности, слежение за ошибками

Представим, что вы запустили свой rails-проект. Он оказался настолько удачным, что новость о нем появилась на главной странице Wired или Digg. После чего проект в лучшем случае стал работать очень-очень медленно, в худшем же просто повалился нахуй. После этого работа резко принимает авральный характер, вы анализируете тонны логов, заново прогоняете стресс-тесты и прочими способами пытаетесь найти узкие места в системе и устранить проблемы.

Задачу профилирования и мониторинга производительности решают такие сервисы, как Five Runs, New Relic и Scout. Функциональность у всех трех похожа, потому расскажу о таких средствах на примере NewRelic’а, являющегося лидером тройки.

Когда приложение развернуто в production-окружении, начинает работать специальный rails-плагин NewRelic RPM. Он собирает информацию о каждом запросе к приложению, о каждом запросе к базе данных, времени выполнения этих запросов (и, соответственно, времени загрузки страниц), нагрузке на процессор, вызванной этими запросами. Время от времени эти данные отправляются на сервер NewRelic фоновым процессом. После этого на сайте NewRelic’а можно посмотреть множество отчетов, показывающих, например, самые медленные контроллеры, самые медленные SQL-запросы и отдельные транзакции, причем, легко можно посмотреть использование индексов в запросах. Кроме того, NewRelic хранит статистику, потому можно отслеживать динамику нагрузок, удобно сгруппированные отчеты об ошибках (мы же не хотим читать длинные логи?) и многое другое.

Естественно, можно использовать NewRelic и в development-окружении, в этом случае он является больше инструментом профилирования, нежели мониторинга и статистики.

Для тех, кому не нужна настолько подробная (и дорогая) статистика, которую дает NewRelic, но нужно удобно отслеживать ошибки, происходящие на production-серверах, есть простой сервис — HopToad. Можно, конечно, для этой цели пользоваться rails-плагином с говорящим именем «Exception Notifier», но он может в определенных ситуациях может неприятно заспамить ваш почтовый ящик.

Тестирование, проверка качества кода

Честно говоря, автоматическое тестирование — один из моих любимых аспектов Rails, такое обилие разнообразных крутых инструментов тестирования я видел, пожалуй, только в Java.

По умолчанию рельсы используют стандартный рубишный Test::Unit в качестве тест-фреймворка. Однако, в последнее время все более модным становится т.н. Behavior Driven Development, и в руби появился свой BDD-фреймворк — RSpec, который плотно интегрируется с рельсами. Судя по коду разных современных проектов, RSpec в ruby-мире сейчас даже более популярен, чем Test::Unit.

В RSpec входит собственное средство для создания mock-объектов (необходимых, например, при тестировании контроллеров), однако вместо него можно использовать более развитые Mocha и Flex Mock.

С целью минимизации времени, затрачиваемого на рутинное написание тестов, был разработан Shoulda — набор макросов для совместного использования Rails и Test::Unit. Посмотрите, насколько более простым и читабельным он делает код тестов. Специально для людей, предпочитающих RSpec был выпущен аналог Shoulda под названием Remarkable.

Для заполнения приложения тестовыми данными в рельсах по умолчанию применяется механизм fixtures, однако это не всегда удобно, например, в случаях, когда нужно сгенерировать много сущностей, — в таких случаях на помощь приходит генерация через фабрики объектов, наиболее известным средством для этого в рельсах является factory_girl.

Хотите «настоящего» BDD, чтобы можно было описывать требования к будущему функционалу простым языком и в итоге превращать их в функциональные/интеграционные тесты? — попробуйте Cucumber. Если вам, как и мне, Cucumber кажется излишеством, существует другой мощный инструмент — WebRat. Задача «крысы» — интеграционное тестирование, то есть пройтись по страницам сайта, прокликать формы, убедиться в том, что сервер вернул ожидаемый результат. Сценарии WebRat писать очень просто и он интегрируется с любыми тест-фреймворками для Ruby. В обычном режиме работы WebRat’у даже не нужен броузер для прогона тестов. Однако бывают ситуации, когда нам необходимо тестировать операции, выполняемые JavaScript’ом, в этом случае WebRat можно запустить в другом режиме работы: он будет использовать Selenium(который, в свою очередь, использует броузер) для прогона тестов. Поддерживать же подобные webrat-тесты ощутимо проще, чем чистые Selenium-тесты.

Специально для проверки уровня покрытия кода тестами существует инструмент RCov. Кроме RCov, существуют инструменты для автоматической проверки сложности кода и просто «детекторы говнокода». Их можно запускать по отдельности, а можно воспользоваться metric_fu, включающим в себя все эти проверки вместе с rcov.

Непрерывная интеграция

При работе над масштабным проектом, или просто в случае распределенной разработки часто возникают проблемы из серии «Петя, после твоего коммита опять сломался билд, срочно чини!» или более характерное для славянских программистов «Ебаный в рот! Кто сломал билд?». Одним из очевидных спобов решения таких проблем является «непрерывная интеграция». Для Ruby в целом и рельсов в частности существует своя версия известного CI-средства — CruiseControl.rb. Существует также альтернатива — Integrity, но ее я ни разу не пробовал.

Сервера приложений

Стандартным сервером приложений Rails является однопоточный Mongrel. Как правило, его запускают кластером из нескольких серверов, после чего балансируют нагрузку между ними при помощи apache или nginx. Такой способ запуска Rails-приложений является наименее эффективным (с точки зрения потребления ресурсов) из всех возможных.

Лучшим решением запуска rails-приложений является Phusion Passenger (также известный как mod_rack и mod_rails). Passenger встраивается модулем в веб-серверы Apache и Nginx и динамически выделяет ресурсы рельсам, подобно mod_wsgi для python и mod_php для PHP. Естественно, это позволяет экономнее расходовать ресурсы сервера и упрощает развертывание приложений.

Для полноты картины стоит отметить Thin. Это сервер, работающий аналогично Mongrel’у, но быстрее и потребляя при этом меньше ресурсов.

Асинхронное выполнение задач

Существует ряд задач, которые выполняются сравнительно долго, например, конвертация видео или загрузка файлов на Amazon S3. Такие задачи желательно (а во многих случаях — обязательно) выполнять в фоне. Долгое время наиболее распространенным инструментом асинхронного выполнения задач в рельсах был BackgroundRB, однако brb потребляет неприлично-много ресурсов, потому рекомендую альтернативный инструмент — Workling.

По умолчанию Workling работает в паре с message queue сервером Starling, разработаным изначально для Twitter’а, однако не советую использовать Starling в production’е. Вместо старлинга можно использовать любой amqp-совместимый сервер, например, RabbitMQ или ActiveMQ.

Мониторинг процессов

Одним из главных недостатков Ruby являются утечки памяти. В Ruby Enterprise Edition и Ruby 1.9 эту проблему частично решили. Но в суровые времена, когда все гоняли рельсы сугубо на Mongrel’ах и Ruby 1.8.6, проблема стояла значительно серьезнее, чем сейчас, потому необходимым было средство, которое следило бы за процессами Mongrel’а и перегружало его при достижении лимита потребляемой памяти. Чаще всего для этих целей использовали совсем не рубишный Monit и его Ruby-аналог — God (который, на мой взгляд, значительно удобней и гибче в конфигурации). Доходило даже до того, что все процессы мониторили God’ом, а сам God — Monit’ом.

К счастью, ситуация стала лучше, но God и Monit (который использовался и используется для мониторинга баз данных, веб-серверов и многих других вещей в unix-системах) все еще остаются простыми и удобными средствами мониторинга процессов, сфера применения которых выходит далеко за рамки перегрузки Mongrel’а при достижении лимита памяти.

Запуск консольных команд

Давно уже для Ruby разработали Rake — инструмент для автоматизации сборки программного кода по типу GNU Make или Apache ANT. Но, в отличие от Make и ANT, Rake-скрипты пишутся на самом Ruby, что сделало их легко расширяемыми и более удобными в написании. В итоге в Rails стали использовать Rake для выполнениях любых консольных команд, например, для запуска тестов, миграций или обновления Rails.

Также существуют дополнительные наборы Rake-задач, выполняющие рутинные операции, например: создание резервных копий базы данных и статических файлов rails-приложения, отображение информации о внешних ключах в базе данных, для которых нет индексов, и многие другие. Отличные примеры дополнительных rake-задач для Rails — limerick_rake и dump.

Визуализация объектной модели

В данном случае лучше один раз увидеть. RailRoad рисует диаграммы объектной модели ваших Rails-приложений. Посмотрите примеры моделей и контроллеров.

Специализированый хостинг

Большинство коммерческих Rails-проектов хостятся на VPS’ах, выделенных серверах и cloud-хостингах вроде Amazon EC2. Однако существуют и специализированные Rails-хостинги (большая их часть — это все те же VPS’ы и надстройки над EC2, куда уже установлены популярные ruby/rails библиотеки, apache с passenger’ом и.т.п.).

• Heroku
• Engineyard
• Rails Machine
• Brightbox

Среды разработки

Существует стереотип, будто все rails-разработчики используют для разработки либо TextMate на маке, либо юниксовые vim/emacs/gedit, и для Ruby/Rails нет «взрослых» IDE.

Отчасти это правда, действительно подавляющее большинство Rails-разработчиков не пользуются IDE, но далеко не все! Качественные IDE для Ruby существуют: Aptana RadRails на основе Eclipse, JetBrains RubyMine на основе IntelliJ Idea, NetBeans (который мне не удалось запустить на маке). Лично я предпочитаю RubyMine за его отслеживание ошибок в коде, автодополнение, удобный поиск внутри проекта, отладку кода прямо в IDE и автоматизацию рефакторинга.

В целом, как мне кажется, ситуация с IDE для Ruby хуже чем у Java и .NET, но лучше, чем у Python и PHP.

Вместо заключения

При желании о каждом из описанных выше инструментов можно написать отдельную статью, как и о преимуществах и недостатках Rails. Целью же этой статьи было показать, что Rails и его инфраструктура развиты гораздо сильней, чем кажется на первый взгляд. Надеюсь, у меня получилось.

Статья написана для сайта developers.org.ua

Приходит Петька к Василию Ивановичу: «Васильываныч, хочу быть тимлидом!..»

Неоднократно мне приходилось читать (например, на DOU), как при обсуждении той или иной IT-компании, люди хвалят или ругают работодателей за их отношение к профессиональному росту персонала: «Отличная компания, я пришел сюда разработчиком, а недавно стал тимлидом!» или «Лучше сюда не идите, в компании стараются брать руководящие кадры со стороны вместо того, чтобы повышать своих рядовых сотрудников».
Я успел побывать как в роли повышаемого, так и в роли повышающего. Потому уверен, что подобные заявления достаточно наивны. На самом деле, в большинстве IT-компаний (кроме самых маленьких) проблема состоит не в том, что расти программисту некуда, а в том, что «двигать» некого.

Работодатели

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

Что делать?

Итак, вы все-таки хотите стать тимлидом:

1. Для начала подумайте, нужно ли вам это? Если вы очень любите программировать — знайте, что на программирование у вас останется гораздо меньше времени. С расширением полномочий уровень ответственности тоже увеличится: придется отвечать не только за себя, но и за всех членов своей команды. Стрессов станет побольше, особенно, в первое время и при сдаче проектов. А зарплаты тимлидов, замечу, не выше обычно, чем у ведущих специалистов.
2. Вам придется научиться говорить «нет», проявлять твердость характера: кому нужен тимлид, которому сотрудники «садятся на голову»?
3. Беритесь за организационную деятельность: неважно — будет ли это нечто связанное с текущими проектами, общим рабочим процессом компании или банальной организацией «пьянок» для сотрудников. Главное — чтобы это приносило пользу компании.
4. Необходимо не только проявлять активность, но и брать на себя ответственность: подход «все пидорасы — один я д’Артаньян» вряд ли приблизит вас к поставленной цели.
5. Помните, что ваше руководство — не телепаты: сообщите им о своем желании стать тимлидом. В этом нет ничего зазорного или унизительного. Зато руководство будет знать о вашей цели и может посодействовать — подсказать, чему стоит подучиться.
6. Необходимо качественно выполнять свою текущую работу: если вы регулярно нарушаете дисциплину, срываете сроки и недобросовестны — вас скорее уволят, чем повысят.
7. Постарайтесь заслужить уважение коллектива: если «коллеги по цеху» не считают вас профессионалом и приятным человеком — не воспримут и как реального руководителя.
8. Очень важно хорошо говорить и писать. Как правило, в полемике выигрывает лучший оратор. Руководитель, слабый в дискуссиях и спорах, легко может растерять авторитет.
9. Учитесь не только программированию, но и методам управления. Для этого придется штудировать, кроме книг по «паттернам» проектирования и языкам программирования, также книги и статьи по менеджменту, методологиям разработки, работе с рисками, несомненно, по человеческому фактору…
10. Тимлиду в аутсорсинговой компании может понадобиться и свободное владение английским.

Такого набора качеств и действий, в принципе, достаточно, чтобы вас заметили и повысили.
 Дерзайте!

О книге «Building Scalable Websites» Кэла Хендерсона (ведущий разработчик Flickr) я узнал из рецензии на сайте developers.org.ua. Сразу загорелся и, спустя несколько месяцев, достал и прочитал книгу.
Впечатлений от книги осталось много, в основном — плохих. Кэл, похоже, не знает о существовании технологий вне PHP-мира, да и писатель из него странный. Давайте рассмотрим книгу по главам.

Краткое содержание книги

• Глава об архитектуре приложений свелась к тому, что приложение должно иметь слои, а логика представления должна отделяться от логики приложения. В этой же главе рассказано, что «взрослые системы» работают, как правило, в условиях сильно отличающихся от большинства shared hosting’ов. При этом, о шаблонах проектирования таких приложений не сказано вообще. А очень стоило бы сослаться на Мартина Фаулера.
• В главе 3 (Development Environments) рассказывается, для чего нужна система контроля версий (говорится о них очень мало, недостаточно для нормальной работы, о распределенных системах контроля версиями не сказано вовсе), система сборки проекта (в один шаг) и система учета задач. Также сказно, что без общих конвенций кодирования далеко не уедешь. И все!
  У Джоэля Спольски эти же вещи описаны значительно лучше, без воды и, всего, в нескольких параграфах!
  Убивает рассказ о юнит-тестах, сводящийся к тому, что тесты существуют в природе. Масштабные интернет-системы делаются, как правило, не маленькими командами, потому я бы в главу добавил информации про Continuous Integration. Без CI-систем довольно быстро разработка превращается в вопли разработчиков «Бляяядь, после апдейта снова все сломано!»… С CI же на смену такому режиму приходит «Блядь, я сломал билд, надо срочно откатить код, пока никто не заметил!». Но, ведь, в PHP нету своих CI-систем (на самом деле можно использовать джавовский CruiseControl с PHP-проектами), откуда же о них знать Кэлу Хендерсону?
  Удивительно, как можно писать о стандартах кодирования, в то время как книга кишит примерами кода вроде этого:

  
  function store_file_2($host, $filename){
          ...
          if ($connection_failed){
                  return 0;
          }
          ...
          if ($operation_failed){
                  return 0;
           }
           return $result;
  }
  

  Что такое store_file_2()? За такие имена методов, вообще-то нужно по рукам бить. Делать логику метода нечеткой и отдавать либо результат операции, либо ноль (хотя операция совсем не обязательно должна возвращать Integer) — один из любимых приемов быдлокодеров. Как правило, он лечится, когда такой разработчик сталкивается со строгой типизацией в других языках, либо с веб-сервисами.
• Главу об интернационализации и юникоде безболезненно можно ужать до одной страницы, где будет сказано, что может быть одна кодировка — UTF-8 и будет рассказано, как с ней работать в PHP и MySQL, а также в JavaScript и при отправке писем. Автор ухитрился растянуть эту информацию на 20 страниц.
• В главе о безопасности написано о всяких разных XSS-хаках, SQL-injection’ах и способах фильтрации контента. В общем, о том, чем кишат всякие говнограммы вроде PHPBB, Joomla, PHPNuke. Я считаю, разработчик масштабных интернет-систем заведомо обязан это знать. В книге о масштабировании подобная тема нужна, явно, с одной целью — набить килобайтов текста, за которые автору платит издатель.
• Глава об электронной почте — самое ценное, что есть в книге, говорю это без всякого сарказма. На тему мобильной загрузки, мобильного постинга в блоги и методов разбора электронных писем толковых материалов существует не так уж много. Уверен, эту часть Flickr’а Хендерсон сам и разрабатывал… иначе, почему в этой главе много полезной информации и мало воды, а не как в остальных?
• Глава про «remote services», естественно, свелась к перечислению реализаций этих самых сервисов (старичка CORBA, конечно же, не упомянули… ведь в PHP нету его реализаций). Какой-то аналитики на тему «чем сервис X лучше сервиса Y в условиях Z» ожидать не стоит.
• Глава «bottlenecks» написана неплохо, однако ее практическая часть полезна исключительно PHP-разработчикам.
  В то же время, презентация Бреда Фицпатрика «Inside LiveJournal’s Backend» гораздо лучше отображает проблему «узких мест».
• Главу «Scaling Web Applications» можно считать в книге главной и написана она вполне прилично: тут и теория и практика с примерами из жизни. Нареканий только два: во-первых мало, а во-вторых описан, опять же, исключительно LAMP-стек.
• Затем идут водянистые главы про мониторинг серверов и построение API (эту главу можно рассматривать как продолжение главы о remoting’е).. все, Книга окончена!

Подводя итоги

Книга рассчитана на специалистов интернет-разработок настолько же, насколько книги Дейла Карнеги рассчитаны на профессиональных психологов, а книга «бизнес в стиле фанк» — на бизнесменов… то есть, вообще ни разу не рассчитан! Профессионалы, скорее всего, не найдут в книге ничего нового.

Новичкам книгу тоже не порекомендуешь: общие темы рассмотрены поверхностно(зато впечатляет их количество: тут упомянули использование wiki для документации и, даже, итеративные методологии разработки), наверняка, о них уже написано в более простых книгах. А на основной вопрос «Как строить масштабируемые веб-приложения?» книга так и не отвечает.

Впрочем, книга не такая плохая, как могло показаться из моего описания. Она тянет на уверенную троечку по пятибалльной системе. От того что почитаете эту книгу хуже наверняка не станет, просто, то же время можно потратить с куда большей пользой и почитать High Scalability.
Книгу стоило бы переименовать, скажем, в «Scaling PHP applications in a nutshell» и сократить в 3 раза, стало бы значительно честнее, но за что тогда брать $26.39?

Выводы

Кэл чем-то напоминает плохого журналиста, ну знаете, такого специалиста широкого профиля, который легко пишет и о политике и о культуре и о нано-технологиях: рядовой обыватель это успешно хавает, а специалисты любой из этих областей плюются. Забавно, книга понравилась многим уважаемым мною людям и на Amazon у нее рейтинг тоже высокий.

Для себя я сделал следующие выводы:

• Для желающих разобраться в масштабировании веб-приложений лучшими вариантами остаются High Scalability, общение с коллегами, посещение семинаров вроде Exception и практика-практика-практика.
• Издательство O’Reilly менее добросовестное чем Addison Wesley. Оно вполне может выпускать низкокачественные книги, потому что их раскупят благодаря имени автора.
• Многие готовы купить книгу просто из-за ходового названия и приписки «От создателя Фликра». Мало кто знает, что Flickr не блестал изяществом архитектуры и с машстабированием у него были серьезные проблемы перед продажей гиганту Yahoo.

В некоторых языках программирования (Python, Ruby, JavaScript и некоторые другие) есть возможность переопределять атрибуты и методы классов во время исполнения программы. На этой возможности была построена целая техника программирования, она называется Monkey Patching.

Откуда взялось такое название?

Изначально термин назывался guerilla patch (партизанский патч): разработчик незаметно добирался до чужого кода, изменял на лету поведение этого кода, не заботясь о соблюдении каких-либо правил, установленных создателем, а потом так же незаметно исчезал, оставив создателю порцию говна, в виде кода не работающего, как надо, без видимых на то причин. Поскольку, слова Guerilla и Gorilla звучат очень похоже — вскоре эту технику стали называть «горилла патч», что в конце концов трансформировалось в monkey patch. Именно этот термин прижился, поскольку лишен негативной окраски предшественников.

Практическое применение

Думаю, главное практическое применение техники обезьяних патчей — расширение функционала чужих продуктов (фреймворков, библиотек) без непосредственного вмешательства в их код, а также, т.н. security patches. Хотя, как инструмент террора, эта техника не менее хороша.

Пример из жизни

Существует замечательный, но не лишенный недостатков, фреймворк для веб-приложений — Django. В нем уже существует модель пользователя (User), используемая для авторизации, разграничения прав доступ, хранения самих пользователей… Естественно, эту модель нужно использовать. На практике оказывается, что у пользователя могут быть дополнительные атрибуты (не предусмотренные фреймворком), например, пол или телефон. Первое, что хочет сделать здравомыслящий разработчик, — написать новый класс пользователя, унаследовав его от джанговского. Увы, один из главных минусов django — его ORM не поддерживает наследование моделей, то есть модель то создастся… но она всего лишь продублирует все поля родителя в новую таблицу базы данных, создав тем самым избыточность.
В нашем случае можно сделать дополнительный класс UserProfile для дополнительных полей и связать его с классом User отношением один-к-одном,. но признайтесь, это, явно, не самое красивое решение, тем более, когда-нибудь в django доработают ORM. Патчить исходные коды django — вариант еще хуже, так как все нормальные разработчики пользуются его версией из репозитория (SVN), которая обновляется почти каждый день… выход один — monkey patching!
В любом файле (желательно в моделях) пишем слудующее:

from django.contrib.auth.models import User

GENDER_CHOICES = (
        ('M', 'Male'),
        ('F', 'Female'),
)
User.add_to_class('gender', models.CharField(max_length=1, choices=GENDER_CHOICES))
#Вцелом, этого уже достаточно, но для самой админки django добавим следующее:
User._meta.admin.fields += (
('Additional', {'fields': ('gender',)}),
)
User._meta.admin.list_display = User._meta.admin.list_display + ('gender', )

Все, отныне, никаких бесполых пользователей!Точно так же можно расширять функционал встроенного в django модуля FlatPages, представляющего из себя простейшую CMS-систему и многое-многое другое.

Меры предосторожности

Не стоит забывать, что monkey patching — это именно хак, а не нормальное поведение программы и применять его стоит только в тех случаях, когда иначе ситуацию решить нельзя. Будьте уверены, если такой патч, в будущем, вызовет ошибки в коде — наверняка, после многочасовых поисков причины, кто-нибудь захочет вас больно побить. Избежать этого довольно просто: всякий раз, когда применяете monkey patching, заботьтесь о том, чтобы этот код был покрыт автоматическими тестами.