По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:

Единственный совершенный код – это код, который так и не написали. Будучи разработчиком, вы стопроцентно будете совершать ошибки, и, кроме того, вам придется их исправлять.
Если вы программируете на Python, то вы всегда можете понять, что происходит, просто взглянув на сообщения об ошибках. Но что, если вы допустите ошибку и даже не будете знать, где конкретно вы ее допустили?
Возможно, что-то пошло не так на фоне, но вы не можете понять, что конкретно. Конечно, вы всегда можете перезапустить код, но будет еще лучше, если у вас будет возможность проверить журналы.
Что такое ведение журналов?
Если вдруг в вашем приложении возникнет ошибка, или оно начнет вести себя странным образом, файлы журналов вам очень сильно пригодятся. Вы можете просмотреть их и узнать, где именно в приложении возникает проблема и как эту проблему можно воспроизвести.
Воспроизведя проблему, вы можете копнуть глубже и найти какое-то рациональное решение. В противном случае на поиск решения может уйти несколько часов, а поиск файлов журнала займет всего несколько минут.
Как ведение журналов работает в Django
Благо, Django поддерживает функцию ведения журналов, и его разработчики уже проделали большую часть тяжелой работы. У Django есть встроенный модуль Python под названием
logging
, который используется для ведения записей в системном журнале.
Этот модуль состоит из четырех основных частей:
Регистраторы
Обработчики
Фильтры
Средства форматирования
Каждый из этих компонентов до мелочей описан в официальной документации Django. Я не хочу, чтобы вы ошибочно полагали, что это очень сложно, поэтому я кратко поясню каждый компонент:
1. Регистраторы
Регистраторы – это, попросту говоря, точка входа в систему протоколирования. Это то, с чем вы, как разработчики, собственно говоря, будете работать.
Когда регистратор получает сообщение, уровень ведения журнала сравнивается с уровнем ведения журнала регистратора. Если эти уровни совпадают, или если уровень ведения журнала превышает уровень ведения журнала регистратора, то
сообщение отправляется обработчику для дальнейшей работы с ним
. Вот так выглядят уровни ведения журнала:
DEBUG
: низкоуровневая информация о системе
INFO
: общая информация о системе
WARNING
: информация о несерьезных проблемах
ERROR
: информация о серьезных проблемах
CRITICAL
: информация об опасных проблемах
2. Обработчики
Обработчики, строго говоря, определяют, что будет происходить с каждым сообщением в регистраторе. Как и у регистраторов, у обработчиков также есть уровни ведения журнала. При этом мы, в принципе, может определить, как будет обрабатываться каждый уровень.
Например, сообщения уровня
ERROR
могут отправляться разработчику в режиме реального времени, а сообщения уровня
INFO
могут просто отправляться на хранение в системный файл.
По сути, обработчик указывает системе, что нужно сделать с сообщением, например, вывести его на экран, добавить в файл или отправить через сетевой сокет.
3. Фильтры
Фильтр можно разместить между
регистратором
и
обработчиком
. Его используют для того, чтобы фильтровать записи журнала.
Например, вы можете установить фильтр в рамках уровня
CRITICAL
, чтобы обрабатывать сообщения из определенного источника.
4. Средства форматирования
Как уже можно было понять из названия, средства форматирования отвечают за описание формата текста, который будет отображаться.
А теперь, когда мы разобрались с основами, давайте рассмотрим пример и копнем немного глубже.
Здесь вы можете найти исходный код.
Отмечу, что данная статья предполагает наличие базовых знаний Django.
Настройка проекта
Для начала вам нужно создать виртуальную среду под названием
venv
внутри папки вашего проекта
django-logging-tutorial
. Сделать это можно с помощью команды, приведенной ниже.
mkdir django-logging-tutorial
virtualenv venv
source venv/bin/activate
Создайте новый проект Django и назовите его
django-logging-tutorial
. Обратите внимание, что в имени папки используется тире, а в имени проекта – нижнее подчеркивание. Здесь, чтобы настроить наш проект, мы также запускаем ряд команд.
Как настроить файлы журналов
Давайте для начала настроим файл проекта под названием
settings.py
. Обратите внимание на комментарии в коде, которые я там оставил. Они помогут вам лучше понять, что там происходит.
Этот код также приводится в
третьем примере официальной документации
, и он отлично подойдет для большинства наших проектов. Но я немного его изменил, чтобы он стал более надежным.
LOGGING = {
'version': 1,
# The version number of our log
{ # Номер версии вашего журнала }
'disable_existing_loggers': False,
# django uses some of its own loggers for internal operations. In case you want to disable them just replace the False above with true.
{ # Django использует ряд собственных регистраторов для внутренних операций. Если вы хотите их отключить, просто замените в строке выше false на true. }
# A handler for WARNING. It is basically writing the WARNING messages into a file called WARNING.log
{ # Обработчик уровня WARNING. Попросту говоря, это запись сообщений уровня WARNING в файл под названием WARNING.log. }
'handlers': {
'file': {
'level': 'WARNING',
'class': 'logging.FileHandler',
'filename': BASE_DIR / 'warning.log',
},
},
# A logger for WARNING which has a handler called 'file'. A logger can have multiple handler
{ # Регистратор уровня WARNING, у которого есть обработчик под названием «file». У регистратора может быть несколько обработчиков. }
'loggers': {
# notice the blank '', Usually you would put built in loggers like django or root here based on your needs
{ # обратите внимание на пробел. Как правило, встроенные регистраторы, такие как Django или root, размещаются в зависимости от ваших потребностей. }
'': {
'handlers': ['file'], #notice how file variable is called in handler which has been defined above { # обратите внимание на то, как файловая переменная вызывается в обработчике, который был определен выше }
'level': 'WARNING',
'propagate': True,
},
},
}
Если вы читали мои комментарии, то могли заметить, что часть, которая относится к регистратору, пустая. По сути, это значит, что использоваться может любой регистратор.
Однако не стоит усердствовать с этим подходом, так как большую часть нашей работы можно выполнить с помощью встроенных регистраторов Django, например,
django.request
или
django.db.backends
.
Кроме того, дабы упростить задачу, я использовал только файл для хранения журналов. Но все зависит от вашего сценария использования. Вы также можете отправлять электронные письма в случае, если вы обнаружили сообщения уровня
CRITICAL
или
ERROR
.
Я бы посоветовал вам прочитать ту часть документации, где говориться об обработчиках, чтобы узнать о них больше. Сначала вам может показаться, что чтение этой документации – непосильный труд, но чем быстрее вы свыкнетесь с мыслью, что прочитать ее нужно, тем больше других интересных и лучших подходов вы сможете найти.
Если вы работаете с документацией впервые, не стоит беспокоиться. Все когда-то бывает в первый раз.
Я пояснил большую часть кода комментариями, но мы еще не упомянули, что же такое
propagate
. Так что же это?
Если значение
propagate
установлено как
True
, то дочерний элемент будет передавать все свои запросы на внесение в журнал родительскому элементу. Это значит, что мы можем определить обработчик в корне (в родительском элементе) дерева регистратора, и все запросы на внесение в журнал в поддереве (в дочернем элементе) будут отправляться обработчику, который был определен в родительском элементе.
Кроме того, очень важно отметить важность иерархии. Мы также может просто установить значение этого параметра в нашем проекте как
True
, поскольку в нашем случае это совершенно не важно, так как поддерева просто нет.
Как вызывать журналы в Python
А теперь, мы должны создать несколько журнальных сообщений, чтобы опробовать нашу конфигурацию, заданную в
settings.py
, в деле.
Давайте создадим домашнюю страницу по умолчанию, которая будет просто отображать фразу
«Hello FreeCodeCamp.org Reader :)»
, а каждый раз, когда кто-нибудь будет посещать эту страницу, мы будем записывать в наш файл warning.log сообщение уровня
WARNING
: «Homepage was accessed at 2021-08-29 22:23:33.551543 hours!».
Перейдите к вашему приложению
logging_example
и добавьте в файл
views.py
следующий код. Убедитесь в том, что вы добавили
logging_example
в
INSTALLED_APPS
, который находится внутри
setting.py
.
from django.http import HttpResponse
import datetime
# import the logging library { # импорт библиотеки logging }
import logging
# Get an instance of a logger { # получаем экземпляр регистратора }
logger = logging.getLogger(__name__)
def hello_reader(request):
logger.warning('Homepage was accessed at '+str(datetime.datetime.now())+' hours!')
return HttpResponse("
Hello FreeCodeCamp.org Reader :)
") Добавьте в проект urls.py следующий код для того, чтобы, когда мы получали доступ к домашней странице, вызывалась правильная функция. from django.contrib import admin from django.urls import path from logging_example import views urlpatterns = [ path('admin/', admin.site.urls), path('',views.hello_reader, name="hello_reader") ] Время для тестирования И наконец, наша несложная настройка завершена. Все, что нам теперь нужно сделать, это запустить наш сервер и проверить наш журнал. Запустить сервер разработки можно с помощью следующей команды: python manage.py runserver А теперь перейдите на свою домашнюю страницу 127.0.0.1:8000 , где вы увидите сообщение, появление которого мы запрограммировали. После чего проверьте файл warning.log , расположенный по созданному нами пути. Вот так будет выглядеть результат: Homepage was accessed at 2021-08-29 22:38:29.922510 hours! Homepage was accessed at 2021-08-29 22:48:35.088296 hours! Вот и все! Теперь вы знаете, как вести журнал в Django.
Если вы только начинаете работать с JavaScript, то вас может поразить, сколько существует различных инструментов и технологий. И вы едва ли сможете понять, какие инструменты вам на самом деле нужны.
Или, возможно, вы уже знакомы с какими-то инструментами, но при этом не задумывались, от каких проблем они вас избавляют, и какой была бы печальной ваша жизнь без них.
Лично я считаю, что программисты и разработчики должны знать, для чего нужны те инструменты, с которыми они работают ежедневно.
Именно поэтому в этой статье я решил рассказать о таких инструментах, как NPM, Babel, Webpack, ESLint и CircleCI. Я подробно рассмотрю проблемы, которые они решают, а также то, как их применять для решения этих проблем.
NPM
NPM – это стандартный менеджер пакетов, который предназначен для JavaScript-разработки. С его помощью вы можете найти и установить пакеты (программы), которые в дальнейшем сможете использовать в своих программах.
Для того, чтобы добавить npm в свой проект, просто введите команду «
npm init
». Когда вы запустите эту команду, в текущем каталоге будет создан файл
package.json
. В этом файле хранится список ваших зависимостей. Для npm этот файл выглядит как идентификационная карточка проекта.
Вы можете добавлять зависимости в этот файл. Для этого вам нужна команда «
npm install (имя_пакета)
».
Когда вы запустите эту команду, npm обратится к удаленному реестру и проверит, существует ли пакет с таким именем. Если он существует, то в ваш файл
package.json
будет добавлена новая запись о зависимости, а сам пакет со всеми его внутренними зависимостями загрузится из реестра.
Все загруженные пакеты и зависимости вы можете найти в папке «
node_modules
». Только учтите, что со временем эта папка может стать довольно большой, так что не забудьте добавить ее в
.gitignore
.
NPM не только позволяет с легкостью находить и загружать нужные пакеты, но и упрощает совместную работу над проектом.
Если бы у вас не было NPM, вам было бы сложно управлять внешними зависимостями. Поэтому, если бы вам было нужно присоединиться к уже существующему проекту, вам пришлось бы вручную загружать правильные версии всех зависимостей. Это могло бы стать настоящей головной болью.
А если у вас есть NPM, то вы можете просто запустить команду «
npm install
», и она установит все внешние зависимости без вашего вмешательства. А когда кто-нибудь из вашей команды добавит новую зависимость, все, что вам нужно будет сделать, это снова запустить эту команду.
Babel
Babel – это компилятор и транспайлер JavaScript, который преобразует код ECMAScript 2015+ в код, который будет понятен для более старых движков JavaScript.
Babel – это самый популярный компилятор JavaScript. Он по умолчанию используется в таких фреймворках, как Vue и React. Но концепции, о которых мы будет здесь говорить, присущи не только Babel, их можно применять к любому компилятору JavaScript.
Зачем вам компилятор?
Если вы знаете, что такое компилируемые и интерпретируемые языки, то у вас может возникнуть вопрос: «Зачем нам компилятор? Разве JavaScript не является интерпретируемым языком?»
Надо признать, мы действительно, как правило, называем «компилятором» то, что переводит код, который можем понять мы, в исполняемый двоичный файл, который может понять процессор. Но только не здесь.
Здесь более уместным будет термин «транспайлер». Это разновидность компиляторов. Транспайлер – это компилятор, который преобразует код, написанный на одном языке программирования, в код, написанный на другом языке. В нашем случае он преобразует более современный JS в более старую его версию.
JavaScript – это язык браузеров. Но в случае с браузерами есть проблема: кросс-совместимость. JavaScript, как и его инструменты, довольно быстро развиваются, и некоторые браузеры не успевают за ними. И здесь возникает проблема совместимости.
Надо полагать, вы захотите воспользоваться новыми возможностями языка и написать код с помощью самой последней версии JavaScript. Но если браузер, для которого вы пишете этот код, не реализовал эти новые функции в своем JS-движке, то код в этом браузере не сможет выполниться как положено.
Это довольно сложная проблема, поскольку все браузеры реализуют функции с разной скоростью. И даже если они реализуют их, всегда будут те, кто будет использовать старую версию браузера.
Так что же тогда делать, если вы хотите использовать новые функции, но при этом хотите, чтобы ваши пользователи могли без каких-либо проблем просматривать эти страницы?
До того, как появился Babel, разработчики использовали полифилы для того, чтобы можно было запускать определенный код в более старых версиях браузера. А теперь, когда у нас есть Babel, он использует эти же полифилы, но, так сказать, за кадром. И в таком случае от вас никаких действий не требуется.
Как работают транспайлеры/компиляторы?
Babel работает по аналогии с другими компиляторами. Он применяет синтаксический анализ кода, преобразует его и генерирует новый код.
Мы не будем так сильно углублять в то, как все это работает, поскольку компиляторы – все-таки довольно сложная вещь.
В принципе можно обойтись без знания о том, что такое плагины и пресеты Babel, но мы все же посмотрим, что это такое. Плагиты - это фрагменты кода, который Babel использует «за кадром» для того, чтобы скомпилировать ваш код в более старые версии JS. Можете представить, что все современные функции – это и есть плагины.
Список плагинов для ES5
Пресеты - это наборы плагинов. Если вы планируете использовать Babel для проекта React, то вы можете воспользоваться уже готовым пресетом
@babel/preset-react
. В нем есть все необходимые плагины.
Плагины пресета для проекта React
Вы можете добавить плагины самостоятельно. Для этого вам нужно отредактировать файл конфигурации Babel.
Нужен ли вам Babel для вашего React-приложения?
Для React вам определенно нужен компилятор, поскольку он использует код JSX, а он должен быть скомпилирован. К тому же его библиотека построена на концепции использования ES6-синтаксиса.
Благо, если вы создаете проект с помощью платформы create-react-app, то вам не потребуется менять конфигурацию, потому что Babel уже встроен в нее.
Компилятор в действии
На веб-сайте Babel есть онлайн-компилятор. Не лишним будет узнать, как он работает. Просто вставьте в него код и проанализируйте то, что он выведет.
Webpack
Webpack – это сборщик модулей. Когда вы создаете новый проект, большая часть фреймворков/библиотек JavaScript используют его уже в готовом виде.
Если фраза «сборщик модулей» приводит вас в замешательство, то читайте дальше. Я приготовил для вас несколько отличных примеров, которые помогут вам понять, что же это такое.
Зачем вам нужен сборщик?
В веб-приложениях у вас может быть много файлов. Речь идет, в первую очередь, об одностраничных приложениях (React, Vue, Angular), у каждого из которые есть свои собственные зависимости.
Когда я говорю о «зависимости», я имею в виду оператор import. Иными словами, если файл A для корректной работы импортирует файл B, то мы говорим, что A зависит от В.
Если у вас небольшой проект, то вы можете обрабатывать модульные зависимости с помощью тегов