для чего нужен фреймворк джанго
Когда использовать Django?
Три примера и преимущества для различных отраслей индустрии
Django один из самых популярных фреймворков для разработки веб-приложений на сегодняшний день. Рассматриваемый удобный фреймворк с открытым исходным кодом обеспечивает быструю разработку. Также, предлагает поддержку большого и активного сообщества разработчиков и упрощает процесс разработки. помочь командам сосредоточиться на более уникальных особенностях продукта.
Одним из факторов его успеха является растущая популярность языка Python. Согласно индексу theTIOBE, Python является одним из самых популярных языков программирования. Его использование становится все более распространенным, поскольку организации используют Python для проектов в таких сложных областях, как data science.
Задаетесь ли вы вопросом о том, где можно использовать Django, чтобы иметь наибольшее преимущество?
Вот 3 примера успешных стартапов, которые делают упор на этот фреймворк с самого начала.
Но прежде всего, что такое Django?
Django — это веб-фреймворк с открытым исходным кодом, написанный на языке программирования Python. Фреймворк предлагает большую ценность для любого проекта веб-разработки. Данная технология поставляется с набором готовых компонентов, которые помогают ускорить и упростить процесс создания веб-приложений.
Фреймворк содержит удобные компоненты, реализующие наиболее распространенные функции, которые мы находим в веб-приложениях. Например, аутентификацию пользователей, панель управления, загрузку файлов и многое другое.
Тем не менее, используя эту технологию, веб-разработчикам не нужно каждый раз заново изобретать колесо. Не нужно создавать эти компоненты с нуля. Фреймворк помогает им сэкономить время, ускорить процесс разработки программного обеспечения и сосредоточиться на аспектах. Все это делает веб-приложение уникальным на рынке.
Ключевые преимущества Django
Фреймворк стал ключевой технологией веб-разработки по целому ряду причин.
Язык программирования Python
Python — одна из самых популярных технологий разработки программного обеспечения в мире. Найти талантливых разработчиков Python легко. Дело в том, что этот язык преподается в университетах, будучи полезным академическим и научным сообществам.
Python окружен большой экосистемой инструментов, библиотек, фреймворков и плагинов. Разработчики могут воспользоваться огромным количеством библиотек для Python /Django для быстро сборки функциональных особенностей.
Вот что говорит о себе Python: «разработка программ с использованием Python происходит в 5-10 раз быстрее, чем с использованием C/C++, и в 3-5 раз быстрее с использованием Java. Во многих случаях прототип приложения может быть написан на Python без написания какого-либо кода C/C++/Java. Часто прототип является достаточно функциональным и крайне хорошо работает, чтобы быть поставленным в качестве конечного продукта, экономя значительное время на разработку.”
Структура
Вдобавок, еще одним ключевым преимуществом фреймворка Django является то, что он предлагает правильную структуру проекта. Эта структура, в свою очередь, помогает разработчикам разобраться в потоке и в том, где реализовать любую новую функцию.
Стартапы говорят, что фреймворк настолько велик именно потому, что позволяет пропустить этап разработки структуры и все вопросы, связанные с пользовательскими структурами. В начале стартапы могут беспокоиться только о фактическом коде, а не о потенциальных структурных проблемах, которые могут возникнуть позже.
Кроме того, наличие структуры проекта, похожей на многие другие проекты, помогает, когда вам нужно обратиться за помощью к сообществу. Велика вероятность, что есть кто-то, кто сумел решить данную проблему и показывает вам, как это сделать в вашем проекте. Или вы можете столкнуться с помогающими разработчиками, которым вы можете легко объяснить наболевшую проблему.
Философия «batteries included»
Вы можете рассчитывать на то, что все основные веб-функции уже включены. Команды разработчиков программного обеспечения, разрабатывающие веб-приложения, могут воспользоваться преимуществами бесплатной аутентификации, панели администратора или полуавтоматической миграции БД из кода Python, облегченного веб-сервера разработки и т.д.
Этот аспект ускоряет работу разработчиков — им просто не нужно реализовывать этот базовый материал. Кроме того, если какая-либо нужная вам функция отсутствует, вы можете быть уверены, что активное сообщество уже разработало пакет, который ее предоставляет. Информация о доступных пакетах легко доступна в интернете.
Удивительное сообщество
Мы уже упоминали об этих преимуществах в двух пунктах выше. Фреймворк окружен живым сообществом увлеченных разработчиков, которые помогут вам решить любую проблему, с которой вы можете столкнуться. Они также стоят за многими полезными пакетами, которые расширяют его возможности.
Благодаря всем этим преимуществам, несомненно, фреймворк стал критически важной технологией для тех, кто хочет запустить успешное веб-приложение. Неудивительно, что стартапы со всего мира начали использовать Django именно в своих продуктах сразу после его появления.
Следующие 3 примера это стартапы, которые выросли в технологических гигантов, используя Django в качестве своей основной технологии.
Лучшие стартапы, использующие Django
Нет лучшего способа оценить фреймворк, чем спрашивать древнейшие стартапы, которые его использовали.
Примечание: древний стартап — это компания, созданная как стартап более 8 лет назад.
Disqus
Disqus — это всемирная служба размещения комментариев в блогах для сайтов и онлайн-сообществ, использующих сетевую платформу. Начатый 30 октября 2007 года, Disqus с самого начала использует Django.
Disqus преуспевает с 17 миллиардами ежемесячных просмотров страниц. Разработчики имеют хороший опыт работы с фреймворком Django и не планируют менять его в будущем. Это просто работает на них. Команда Disqus даже разработала Sentry, который позволяет ловить все виды ошибок в рамках фреймворка.
«Медленные запросы к базе данных и сетевая задержка обычно перевешивают накладные расходы на производительность надежного фреймворка, такого как Django”, – сказал Мэтт Робенолт из Disqus несколько лет назад, и похоже, что его мнение с тех пор не изменилось.
Инстаграм — это социальная сеть для обмена фотографиями и видео. Instagram был запущен в 2010 году примерно через две недели после того, как его соучредители Кевин Систром и Майк Кригер Кевин начали создавать свою первую версию. Они признались, в благодарности Django: «это была очень простая установка с одним способом делать вещи».
Компания была создана в темные времена Django v1.3 и ранее. В то время как, Django ORM страдал от проблемы оптимизации. Эти проблемы ORM не были заметны до июня 2011 года, когда компания поразила 5 миллионов пользователей. Сейчас все работает нормально. Однако, чтобы обезопасить приложение на будущее, разработчики Instagram начали исправлять Django v1.3 и в конечном итоге переписали ORM Django.
До сих пор платформа использовала Django без каких-либо проблем. Более того, данная социальная сеть в настоящее время является одним из двух платиновых корпоративных членов, поддерживающих Django (другой — JetBrains). Все сотрудники в этой компании (и Facebook, которой принадлежит платформа) разрешается вносить код непосредственно в Django. Это самое высокое достижение поддержки, и оно определенно показывает сильные отношения между Instagram и Django.
Pinterest — это социальная медиа-платформа, которая опирается на кураторство изображений с помощью сложных алгоритмов. Его разработка началась в декабре 2009 года, а закрытая бета-версия была запущена в марте 2010 года.
Все стартапы в нашем списке используют Django с самого начала стадии разработки. К сожалению, по мере того, как Pinterest становился все более заметным, он начал страдать от проблем Django ORM, таких как Instagram. Его ORM был просто недостаточно быстр. Например, делая двойные и тройные вызовы к базе данных (во время одной из Python конференции разработчики платформы подтвердили, что эти проблемы были исправлены в Django 1.6).
По мере роста Pinterest сначала переместил большую часть логики в базу данных, а затем изменил свою структуру с Django на Flask. С конца 2011 года Pinterest использует Flask. С января 2012 года comScore сообщила, что сайт имеет 11,7 миллиона уникальных посетителей в США. Это делает его самым быстрым сайтом, когда-либо преодолевшим отметку в 10 миллионов уникальных посетителей.
Итак, когда вы должны использовать Django?
Суть использования Django заключается в том, что вы можете быстро разработать свой продукт. Продукт, у которого нет шансов стать крупным. Все три рассмотренных выше удивительных стартапа были построены с использованием этой технологии. Именно так они могли быстро подготовить и затем развернуть свои продукты благодаря Django.
Кейсы компаний
Disqus быстро рос без каких-либо проблем и получил миллионы пользователей благодаря быстрому процессу разработки с Django. Это позволило быстро добавлять новые функции и поддерживать интерес пользователей.
Instagram благодарен сообществу фреймворка, которое в настоящее время поддерживает фреймворк, внося в него свой вклад. Если бы не это сообщество, которое так усердно работало, чтобы сделать Django быстрее, возможно, платформа развалилася бы. Разработчики платформы один раз за 10 месяцев обновили свои версии с Python 2.7, Django 1.3 до Python 3.5, Django 1.8. Это показывает ценность новых обновлений, поступающих от сообщества Django.
И, наконец, Pinterest тоже получил свой шанс благодаря Django. Если бы не быстрый процесс разработки, высоко оцененный разработчиками, Pinterest потребовалось бы больше времени для запуска на рынок. А что, если Pinterest начнет с Flask? У Django есть все, что нужно веб-стартапу, благодаря его подходу «batteries included». Это делает создание веб-приложения с нуля просто намного быстрее.
Вывод
Теперь вы должны знать, почему Django является таким популярным фреймворком, который организации используют для быстрого и плавного создания веб-приложений. Здесь три примера, демонстрирующие ключевые сильные стороны Django: ускорение процесса разработки с богатым выбором готовых компонентов и невероятная преданность своему сообществу.
Что такое Django REST Framework?
Я написал эту статью, чтобы рассказать в ней теорию, которая будет необходима для изучения Django REST Framework. Информация, изложенная в этой статье, не является исчерпывающей в данной теме и показывает историю развития веб-приложений лишь отчасти. Я просто постараюсь объяснить, почему этот фреймворк — часть естественной эволюции веб-технологий, и как при помощи него мы можем по-новому решать старые задачи веб-разработки.
Чтобы ответить на вопрос, что же такое Django REST Framework, нужно разобраться со всей необходимой терминологией.
Framework
Создавая приложение или любой другой программный продукт, мы хотим делать это быстро и качественно. Проще этого добиться, используя опыт и наработки других разработчиков, ведь многие задачи, которые мы встречаем в процессе работы, уже были кем-то решены. По сути, использование фреймворка позволяет сосредоточится на задачах бизнеса и не задумываться над техническими деталями там, где это возможно. Нужно отрисовать кнопку на сайте? Сделать авторизацию или сброс пароля? Сохранить данные пользователя из формы на сайте в базу данных? Для этого всё уже готово — бери и пользуйся!
Также важно понимать отличия Framework от библиотеки. Это похожие вещи. В обоих случаях в Python вы должны установить нужный пакет, импортировать и пользоваться им. Разница в том, что библиотеку в проекте вы используете там, где нужно, и так, как вы хотите, а фреймворк сам определяет способ разработки приложения, то есть не только предоставляет удобные инструменты разработки в виде вспомогательных функций и классов, но и непосредственно формирует архитектуру проекта, создает структуру кода, проще говоря, определяет путь, по которому вы будете создавать свое приложение.
Django
На сегодняшний день наиболее функциональным фреймворком для создания веб-приложений на языке Python является фреймворк Django. Django можно назвать MVC-фреймворком, так он реализует взаимодействие пользователя и системы:
Model (хранит данные пользователя)
View (отображает данные пользователя)
Controller (принимает изменения данных от пользователя).
Внутри Django эта терминология звучит немного иначе, но суть остается той же.
Разработка Django началась в 2003 году программистами Adrian Holovaty и Simon Willison, а публичный релиз состоялся в 2005 году. Функционал фреймворка хорошо отвечал требованиям в веб-разработке того времени. Он активно развивается и до сих пор. Хотя этот фреймворк и считается довольно крупным и многофункциональным, сам по себе он не мог удовлетворить все запросы веб-разработчиков. За время его существования сторонними разработчиками было создано огромное множество библиотек и фреймворков в качестве дополнений к Django, которые упрощают реализацию тех или иных задач: аутентификация через социальные сети, кеширование данных, хранение файлов в облаке и многое другое. Некоторые из дополнений со временем сами стали частью проекта Django, как это произошло с библиотекой South, управляющей миграциями базы данных. Но большинство дополнений так и остались независимыми пакетами. Одним из них и является Django REST Framework, при помощи которого мы можем создавать Web API на основе Django.
Web API
Сегодня сеть интернет построена по принципу Клиент-Серверного взаимодействия. Клиент посылает запрос — Сервер ему отвечает. В случае, когда между собой общаются два Сервера, мы условно называем Клиентом того, который отправил запрос и ожидает ответ, а Сервером будет тот, кто принимает запрос и отвечает не него. Взаимодействие браузеров и веб-сайтов (первые выступают в роли Клиента, а вторые в роли Сервера) традиционно делалось при помощи технологии html-рендеринга, именно так изначально это делал Django. Чтобы получить данные с веб-сайта, браузер отправляет запрос GET к Серверу. Сервер формирует ответ в виде html-страницы и передает ее браузеру. Так Сервер передает данные браузеру, но как браузер может передать данные Серверу? В этой самой html-странице Сервер заложил все необходимые веб-формы, заполнив которые, пользователь мог бы передать свои данные обратно на сервер. Когда вы ввели свои данные в форму на сайте, бразуер отправляет Серверу запрос POST, в котором содержатся ваши данные, а Сервер обрабатывает их и записывает в базу данных.
Все это отлично работало, но уже в середине нулевых такой подход перестал удовлетворять возрастающим требования в веб-разработке. Появлялись мобильные приложения, различные гаджеты с доступом в интернет, и для них уже не подходил стандартный способ html-рендеринга на сервере, ведь теперь каждому клиенту нужно было отрисовать данные по-своему. Постоянно увеличивалось взаимодействие серверов друг с другом, и html-формат уже не подходил. Для всех этих задач есть другой способ обмена данными — Web API. Смысл этого способа в том, что Сервер передает Клиенту не html-страницу, а непосредственно данные, никак не влияя на то, как эти данные будут в итоге представлены. Наиболее популярными форматами для передачи данных становятся XML и JSON. Таким образом Сервер полностью избавляется от задачи отрисовки данных. Какое-то время длился переходный период, когда разработчикам веб-приложений на Сервере приходилось поддерживать оба способа одновременно: html рендерился на Сервере для браузеров, а Web API использовался для мобильных приложений и интеграции с другими серверами. Понятно, что разработчикам приложений на Сервере приходилось делать двойную работу. Но в начале десятых ситуация стала меняться в пользу Web API. Этому способствовало молниеносное развитие инструментов на языке JavaScript, а также появление различных веб-фреймворков, одним из которых и является предмет данной статьи.
Браузерные приложения быстро научились отрисовывать веб-страницы самостоятельно, получая чистые данные с Сервера. Веб-приложения на сервере научились создавать API быстро и легко. Так сформировалась четкое разделение на Backend и Frontend разработку: тех, кто поддерживает приложение на Сервере, и тех, кто делает браузерные (клиентские) приложения. А Web API стал универсальным способом общения для Сервера и всех его клиентов (браузеров, мобильных приложений, других Серверов). Конечно, это не могло не привести к развитию стандартов в общении между системами. И Клиенту, и Серверу необходимо знать каким образом общаться с друг с другом, как передавать данные, как сообщать об ошибках. Разработчики всегда могли договориться о том, как взаимодействовать их приложениям, но наличие некоего стандарта в веб-разработке позволило бы эту задачу облегчить. И вот в начале десятых таким стандартом стала концепция REST.
В 2000 году Рой Филдинг написал докторскую диссертацию, где изложил концепцию REST. Там были рекомендации о том, как спроектировать Сервер, чтобы ему было удобно общаться с Клиентами. Выделю два главных принципа создания приложений в стиле REST:
На данный момент мы можем найти фреймворк для создания приложений в стиле REST практически для каждого языка программирования, используемого в веб-разработке. Логика построения Web API на Сервере в этих фреймворках реализована одинаково.
Действия для управления данными привязаны к определенным HTTP-методам. Существует несколько стандартных действий для работы с данными — это Create, Read, Update, Delete. Часто их обобщают как CRUD.
У нас есть объект Кошка, и мы хотим создать запись о кошке на Сервере. Для этого мы отправляем запрос на сервер:
С данными в теле запроса
Плюс к этому запросу (и все другим) будет добавлен ключ аутентификации.
Ключ будет нужен, чтобы Сервер понял, что запрос происходит от авторизованного Клиента. Как мы помним из правила REST, каждый запрос от Клиента должен содержать всю необходимую информацию для обработки этого запроса Сервером. Здесь это правило работает: Сервер ничего не знает о Клиенте до запроса, но сам запрос содержит ключ авторизации, по которому Сервер определяет, что это за Клиент.
Сервер ответит на этот запрос вот таким сообщением:
Сервер взял все поля, переданные клиентом, и добавил к ним поле Id. Здесь работает правило REST, согласно которому каждый ресурс должен иметь уникальный идентификатор и быть доступным по определенному URL. Сервер создал ресурс и вернул нам его Id.
Теперь мы можем получить данную запись по URL
Что, если Клиент хочет изменить созданные им данные на сервере?
Метод PUT используется для изменения данных. Номер 21 в URL говорит о том, какой именно объект нужно изменить. Теперь наша кошка имеет цвет “Black”.
Для удаления записи на Сервере достаточно отправить запрос:
Тут также мы указываем в Id объекта в URL, но передавать никаких данных в теле запроса для удаления объекта уже не требуется.
Django REST Framework
Наконец, мы добрались до главной темы этой статьи. Мы вкратце разобрали каждый компонент этого словосочетания и теперь сможем понять, зачем использовать этот фреймворк, и какие задачи он решает.
Тут я бы хотел процитировать слова Тома Кристи, создателя Django REST Framework.
“Неудивительно, что Django REST framework — это API фреймворк для Django. И он пытается заполнить все пробелы в том, как исторически был спроектирован веб-фреймворк Django”.
И действительно, пусть Django был спроектирован давно, он до сих отлично решает свои задачи. Однако с появлением новых требований в веб-разработке, отсутствие компонентов для создания Web API воспринимается как пробел.
Django REST framework способен этот пробел заполнить.
А мы уже заполнили все пробелы в теории и терминологии и готовы перейти к практике!
Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!
Эффективный Django. Часть 1
Оглавление
Введение ⇧
«Связный» код — это код, который сосредоточен на выполнении одной вещи, только одной единственной вещи. Это значит, что когда вы пишете функцию или метод — написанный вами код должен делать что-то одно и делать это хорошо.
Это непосредственно относится к написанию тестируемого кода: код, который делает много вещей, достаточно часто является чересчур сложным для тестирования. Когда я ловлю себя на мысли: «Хорошо, этот кусок кода слишком сложен, чтобы писать для него тесты — это просто не стоит потраченных усилий» — вот сигнал к тому, чтобы вернутся назад и сосредоточиться на упрощении. Тестируемый код — такой код, который позволяет просто писать для него тесты; код, в котором легко найти проблемы.
И наконец, мы хотим писать масштабируемый код. Это означает не просто масштабировать его в терминах исполнения, но так же увеличивать в терминах команды и командного понимания. Хорошо протестированные приложения проще для понимания другими (и проще для изменения ими), что подразумевает большую возможность улучшить ваше приложение, путем добавления новых инженеров.
Моя цель — убедить вас в важности этих принципов, и предоставить примеры того, как следуя им, построить более стойкое Django-приложение. Я собираюсь последовательно пройти через процесс построения приложения для управления контактами, рассказывая про решения и стратегию тестирования, которые я использую.
Эти документы являются сочетанием заметок и примеров подготовленных для PyCon 2012, PyOhio 2012, и PyCon 2013, а также для web-разработки Eventbrite. Я все еще работаю над объединением их в один документ, но надеюсь вы найдете их полезными.
Примеры кода для этого руководства доступны на github’е. Отзывы, предложения и вопросы можете присылать на nathan@yergler.net.
Этот документ доступен на сайте, а также в форматах PDF и EPub.
Видео этого руководства с PyCon можно посмотреть на YouTube.
Глава 1. Приступая к работе ⇧
1.1. Ваша среда разработки
Изоляция означает, что вы не сможете случайно воспользоватся инструментами или пакетами установленными вне вашего окружения. Это особенно важно, когда подобное происходит с чем-то, похожим на пакеты Python с расширениями написанными на C: если вы используете что-то установленное на системном уровне и не знаете об этом, то при развертывании или распространении своего кода вы можете обнаружить, что он работает не так как предполагалось. Инструменты наподобие virtualenv могут помочь создать нечто похожее на изолированную среду.
Ваша среда предопределена, если вы уверены в том, на какую версию ваших зависимостей вы полагаетесь и сможете ли вы наверняка воспроизвести системное окружение.
1.1.1. Изоляция
1.1.2. Предопределенность
1.1.3. Сходство
1.2. Настройка вашего окружения
1.2.1. Создание чистого рабочего пространства
Примечание переводчика:
Для начала создадим каталог ( tutorial ), в котором будем работать:
В каталоге venv будет находится наше виртуальное окружение, а в каталоге project — Django-проект
1.2.2. Создание файла зависимостей
Создайте файл requirements.txt в директории tutorial с единственной строкой (зависимостью) в нем:
Примечание переводчика:
В случае, если вы хотите использовать последнюю версию Django (1.7 — на момент написания перевода) — вместо строки Django==1.6.7 оставьте просто Django — pip установит последнюю доступную версию.
1.2.3. Установка зависимостей
А теперь мы можем использовать pip для установки зависимостей:
1.3. Начало проекта Django
Когда здание находится в процессе постройки, строительные леса часто используются для поддержания структуры до того как строительство будет завершено. Строительные леса могут быть временными или они могут служить частью фундамента здания, но несмотря на это, они представляют некоторую поддержку когда вы только начинаете работу.
Django, как и многие web-фреймворки, представляет скаффолдинг для вашей разработки. Это происходит при помощи принятия решений и предоставления отправной точки для вашего кода, что позволяет вам сосредоточится на проблеме, которую вы пытаетесь решить, а не на том, как разобрать HTTP-запрос. Django предоставляет скаффолдинг как для работы с HTTP, так и для работы с файловой системой.
1.3.1. Создание проекта
Созданный проект имеет следующую структуру
1.3.2. Скаффолдинг проекта
1.3.3. Создание приложения
Созданное приложение имеет следующую структуру:
Примечание переводчика:
На текущий момент наша директория
/tutorial/ содержит файл зависимостей ( requirements.txt ), директорию с виртуальным окружением ( venv/ ), один проект ( project/addressbook ), одно приложение ( project/contacts ) и имеет следующее содержание:
Глава 2. Используем модель ⇧
2.1. Конфигурирование базы данных
Для использования SQLite нам нужно указать движок ( ENGINE ) и имя базы ( NAME ). SQLite интерпертирует имя базы как имя файла для базы данных:
2.2. Создание модели
Модели Django отображают (грубо говоря) таблицы базы данных, и предоставляют место для инкапсулирования бизнес-логики. Все модели являются наследниками базового класса Model и содержат поля определений. Давайте создадим простую модель Contacts для нашего приложения в файле contacts/models.py :
После того, как вы создали модель, необходимо дополнить вашу базу данных новыми таблицами. Команда Django syncdb смотрит установленные модели и создает (если нужно) таблицы для них:
Примечание переводчика:
Django предложит создать суперпользователя для андминки, которая включена в этой версии по умолчанию. Воспользуйтесь его предложением.
Примечание переводчика:
Если вы используете Django версии 1.7 и выше — вывод будет следующий:
Однако нашей таблицы с контактами нигде не видно. Причина этого состоит в том, что нам нужно еще указать проекту использовать приложение.
После этого запустите syncdb снова:
Примечание переводчика:
Для Django версии 1.7 и выше вам нужно будет запустить сначала команду makemigrations — для создания миграций на основе изменений в моделях, а после этого выполнить команду migrate — для того чтобы применить созданные миграции.
Примечание переводчика:
Вывод для Django 1.7 и выше:
Заметьте, что Django создает таблицу с именем contacts_contact : по умолчанию Dj ango дает таблицам имена используя комбинацию имени приложения и имени модели. Вы можете изменить это с помощью опций модели Meta.
2.3. Взаимодействие с моделью
Теперь, когда модель синхронизирована с базой данных мы можем взаимодействовать с нею используя интерактивную оболочку:
Здесь использовалось несколько новых штук. Во-первых, команда manage.py shell запускает для нас интерактивную оболочку Python’а с правильно установленными путями для Django. Если вы попробуете запустить интерпретатор Python и просто импортировать ваше приложения, будет выброшено исключение, потому что Django не знает, какие настройки использовать, и не может отобразить экземпляры модели на базу данных.
2.4. Написание тестов
Вы можете запустить тесты для вашего приложения используя команду manage.py test :
Если вы запустите это, то увидите что выполнилось около 420 тестов. Это удивляет, так как мы написали только один. Произошло это потому, что по умолчанию Django запускает тесты для всех установленных приложений. Когда вы добавляли приложение contacts в наш проект, то могли увидеть, что там по умолчанию были добавлены несколько встроенных приложений Django. Дополнительные 419 тестов были взяты оттуда.
Примечание переводчика:
В нашем случае (при использовании версии Django 1.6.7) предыдущий абзац несколько устарел: запустится только один тест — тот который мы создали. Вывод команды будет такой как указано ниже.
Если же вы захотите запустить тесты для определенного приложения — укажите имя приложения в команде:
2.5. Резюме
Примечание переводчика:
Для того чтобы протестировать наше, пока еще пустое, приложение нужно выполнить следующую команду:
Это запустит встроенный сервер, функционал которого любезно предоставляет нам Django. В параметрах после runserver указывается ip-адрес и порт, который будет слушаться работающим сервер. В нашем случае сервер будет принимать запросы от всех ip-адресов при обращении на 8080 порт.