В 2015 году, когда я пришёл на своё текущее место работы, мне было непривычно от необыкновенной свободы действий. Буквально, на новом месте можно было проявить весь творческий потенциал как DevOps-евангелиста. Мне нравилось выстраивать процессы, автоматизировать рутину, делать разработку удобной. Больше всего я люблю оптимизации, а больше всего ненавижу - рутину.
Эта история одной боли и попытке не просто "принять обезболивающее", а реально излечить её. Поэтому готовьтесь переварить лонгрид.
Всем привет.
Некоторое время назад я писал про альтернативные возможности, как можно добавить в django асинхронность (есть официальный подход, изложенный в DEP-09). С тех пор у меня получилось оформить свои идеи в нечто относительно цельное, что вылилось в vinyl project. Описание проекта читайте на гитхабе, здесь же я хочу рассказать о его интересных особенностях.
Проект родился после нескольких предыдущих попыток, когда я узнал, что django, в действительности, очень неплохо расширяем. Например, он поддерживает использование нескольких баз данных одновременно (притом что модели одни и те же). Соответственно, например, ничего не мешает считать использование асинхронного драйвера как использование другой логической базы данных - чем я и воспользовался.
Для того чтобы получить полезный трафик не обязательно платить за размещение рекламных постов и баннеров на сторонних площадках и тратить на это значительную часть своего рекламного бюджета. Уже давно вошли в моду системы лояльности, которые позволяют финансово вознаграждать своих пользователей за активность в приложении. Это своего рода внутренний арбитраж трафика: мы закупаем активность своих же пользователей в обход посредников. Чтобы это реализовать потребуется несколько часов свободного времени и капелька желания.
В настоящее время практически все ИТ-продукты работают с персональной информацией пользователя: ФИО, телефон, e-mail, паспортные и другие идентифицирующие данные. Для обеспечения защиты прав и свобод, человека и гражданина при обработке его персональных данных в Российской Федерации существует Федеральный закон от 27.07.2006 N 152-ФЗ “О персональных данных”.
Согласно пункту 2 статьи 5 обработка персональных данных должна ограничиваться достижением конкретных, заранее определенных и законных целей, а в статье 6 установлено, что обработка персональных данных осуществляется с согласия субъекта персональных данных. Все это накладывает определенные ограничения на разработку программных продуктов и заставляет разработчиков думать о возможных последствиях несоблюдения норм законодательства.
Хочется заметить, что во многих случаях для непосредственной разработки личные данные пользователя не важны, необходима сама структура данных, их полнота и количество. По этой причине, а также в рамках соблюдения закона, персональные данные пользователя можно анонимизировать, чем и пришлось заниматься в рамках своей профессиональной деятельности.
Под анонимизацией в рамках статьи стоит понимать процесс изменения данных введенных пользователем и сохраненных в БД на программно сгенерированные данные, которые по виду и типу совпадают с реальными, но не имеют отношения к конкретному пользователю. О том, как была организована работа по этому вопросу и какой в итоге получился результат и будет эта статья.
Я являюсь full stack разработчиком на культурно-историческом IT портале Königsland, который успешно начал свою работу примерно месяц назад. Этот ресурс посвящается культуре и истории Восточной Пруссии и является своеобразной летописью времен, которая больше всего напоминает вирутальный музей, где можно получить довольно полную информацию об истории этого великого края, а эта информация пополняется по мере возникновения у меня свободного времени.
Страницы этой летописи приоткрывают завесу тайны и позволяют получить пользу от современных технологий тем, кто увлекается стариной.
Все мы знаем, что Django предоставляет ORM прямо из коробки, что не позволяет нам писать SQL-запросы. В этом механизме есть большой потенциал. Однако большинство из нас знакомы только с методами filter(), get(), update() и delete() из Django ORM.
В Django ORM есть много других опций, поэтому у нас все же возможность использовать функционал традиционных SQL-запросов. Сегодня в статье я вам про него расскажу.
Тесты написаны, тимлид рад, а что дальше-то делать? А дальше - автоматизация и отправка отчёта по тестам. Именно об этом мы и поговорим в данной статье, попутно затронув полезный инструмент TestExplorer и декоратор tag.
В прошлой статье мы познакомились с тестами для Django и создали личного пользователя-тестировщика. Самое время продолжить изучать тестирование сайта, написав проверку русских символов на английских страницах и разобрав тесты для JavaScript.
Сайт с багами – горе для бизнеса. Всего одна 404-я или 500-я ошибка может лишить вашу компанию солидной суммы денег и хорошей репутации. Но есть способ избежать этого: тестировать сайт. О том, как это сделать, расскажет данная статья. Прочитав её, вы узнаете, как тестировать код на Django, создать своего пользователя-тестировщика и много чего еще. Добро пожаловать под кат.
Здравствуйте!
Хочу представить вам пошаговую инструкцию по деплою django проекта.
Сразу скажу, что используя мою краткую инструкцию вы не поймете механику развертывания. По сути, это просто список команд для деплоя. Тут не будет никаких подробностей касательно работы UWSGI, NGINX и самого Django. Я просто помогу быстро добраться до цели, а цель у нас одна - задеплоить уже наконец этот **** проект!
В предыдущих статьях мы подробно разобрали работу сериалайзера на основе классов BaseSerializer и Serializer, и теперь мы можем перейти к классу-наследнику ModelSerializer.
Класс модельных сериалайзеров отличается лишь тем, что у него есть несколько инструментов, позволяющих сократить код сериалайзера:
create и update.Общие принципы работы модельного сериалайзера как на чтение, так и на запись идентичны тому, как работает базовый класс Serializer.
В современных веб-приложениях большинство запросов к базе данных пишется не на сыром SQL, а с использованием объектно-реляционного отображения (ORM). Оно автоматически генерирует SQL-запросы по привычному объектно-ориентированному коду. Однако эти запросы не всегда оптимальны, и с ростом нагрузки на веб-приложение встает вопрос их оптимизации. Как раз в ходе такой оптимизации наша команда обнаружила, что документация Django с нами не совсем честна.
Всем доброго времени суток!
В данной статье я хотел бы очень кратенько, без подробностей рассказать про интересный проект, который будучи достаточно простым, сильно увеличивает возможности Django фреймворка. Мне он показался достаточно интересным.
Сейчас хайп вокруг современных javascript SPA фронтенд фреймворков особенно горяч, и во многом эта популярность вполне заслужена, эти технологии позволяют успешно выполнять практически любую задачу. Скорость SPA приложения может быть сравнима с десктоп приложениями, это достигается за счет перенаправления большей части ответственности с сервера на клиента. К сожалению, этот новый подход порождает все более сложные технологии, а работа разработчика, которая когда то была увлекательна и продуктивна стала значительно сложнее и монотоннее. Возможны ли альтернативы современным SPA фреймворкам? Возможно ли создавать полноценные reactive user interfaces быстро, просто и только на джанго? Далее хочу обратить Ваше внимание на интересный проект который может дать ответы на эти вопросы.
Всем привет! Меня зовут Дмитрий Чернышов, я руководитель группы разработки системы «БАРС.Бюджет-Бухгалтерия». Сегодня я поделюсь своим опытом создания обучающего курса для разработчиков.
Репозиторий: https://github.com/denisxab/django-start-pack
Какая существует проблемы: Слишком много времени уходит на первоначальную настройку Django проекта. Существует много технологий которые уже стали неотъемлемыми зависимостями для Django проектов. Например:
Недавно я проходил очередное интервью, и меня спросили, пишу ли я на flask, на что я ответил, что я себя люблю, и поэтому пишу на django. Меня не взяли, потому что, кхм, у них, оказывается, много чего было на фласке, и вышло неловко. Да-да, я знаю, фласк крут, потому что он простой, всё что надо ставишь сам, а чего не надо там и так нет, но как по мне, всё равно потом получается django.
И тут, наверно, покажется, что я я свидетель Джанго, хожу по домам, стучу в двери и рассказываю, как круто на нём кодить, но вообще-то нет - Джанго тоже не без проблем... Вот об этом я и хочу поговорить.
Привет! Меня зовут Степан Лущий, я – тимлид команды тестирования компании «БАРС Груп». Мы занимаемся созданием автоматизированных тестов (автотест), инструментов для их написания, а также развитием инфраструктуры автотестирования. В этой статье я расскажу, как мы разработали инструмент, с помощью которого у нас получилось значительно сократить время реализации автотеста.
Продолжаем цикл статей, посвящённый основам Django Rest Framework. В предыдущей статье мы подробно рассмотрели, как сериалайзер валидирует входные данные.
В этой статье мы закрепим теорию на простом примере, а также затронем те вопросы, которые не успели рассмотреть раньше:
ForeignKey-поля модели;save сериалайзера.А ещё мы напишем контроллер, который будет обрабатывать запросы к API на создание записи в БД.
Проект на Django для работы с регулярными выражениями в реальном времени. Весь бекенд регулярных выражений работает на библиотеки re из Python, поэтому вам не придется переписывать шаблоны регулярных выражений специально под Python, как часто это бывает на других похожих сайтах.
Поддерживаемые регулярные функции: