Конституция, и далее везде

Приветствую всех, недавно я предложил вам обсудить систему голосования, разработанную Департаментом информационных технологий (ДИТ) г.Москвы.

Обсуждение вышло весьма продуктивным, и по его результатам можно выработать некоторые рекомендации по процедуре голосования. Все, кому это интересно, приглашаются под кат.

Открытые исходники

Недавно в открытый доступ были выложены исходники системы голосования, которая по всей видимости, и будет применяться на электронном голосовании по Конституции в Москве и Нижнем Новгороде.

Данным посланием хабражителям я хотел бы открыть обсуждение того, что получилось у разработчиков, и как нам теперь с этим жить.

Рано или поздно, разработчик на Django встречается с проблемой: как сделать так, чтобы пользователи не могли изменять или удалять, а то и вовсе не видели разные объекты одного и того же типа.

Допустим, ваш проект касается хранения информации о проектах. Разные пользователи входят в разные проекты и не должны видеть информацию о другом проекте. Один и тот же пользователь может входить в несколько проектов и иметь разный статус в разных проектах — где-то он может только просматривать информацию, а в других — править данные. В каком-то проекте пользователь зарегистрирован как персонал проекта, а в другом — только как потребитель его услуг. Уровень доступа соответственно, должен быть совершенно разным.

Этими вопросами занимаются несколько пакетов, мы рассмотрим один из них — Django-Access. Все, кому это интересно, приглашаются под кат.

Вышел пакет Django-REST-Access для подключения пакета Django-Access в качестве бакенда динамического управления доступом на уровне объектов (строк) и фильтрации видимых объектов в Django REST Framework.

Django REST Framework — популярный расширяемый пакет конструирования HTTP API на основе проектов Django.

Django-Access — гибкий пакет динамического управления правами на уровне объектов (строк).

Привет всем! В связи с ростом блокировок, в том числе необоснованных, сайтов со стороны государства, вашему вниманию предлагается описание идеи, а также прототип настроек сайта, защищенного от блокировок по конкретному пути и доменному имени. Идеи по защите от блокировок:

• со звездочкой
• по адресу IP

будут изложены в других постах. Кому интересна тема, заходите под кат.

Привет всем!

В проектах, основанных на Джанго, часто хочется использовать гибкое управление доступом на уровне записей (объектов), когда разные пользователи имеют, или наоборот, не имеют доступ к отдельным объектам в рамках одной и той же модели.

Я хочу рассказать, какая именно политика доступа к данным требовалась в нашем проекте, почему не нашлось подходящей готовой системы и как появилась новая система управления доступом на уровне записей.

Для наиболее дотошных, далее приведены детали устройства системы, ее внутренней логики и порядка обращения с ней.

Как я перетащил пакет Tastypie на Pony ORM и что из этого получилось.

Данная статья продолжает историю моей борьбы за производительность приложений на python и django.

Предыдущий пост посвященный производительности, описывал Pony ORM, показавший фантастические результаты по сравнению с Django ORM и SQLAlchemy.

Впечатленный столь неординарными результатами и озабоченный производительностью собственного проекта, я решил внедрить Pony ORM в свой проект. Что из этого получилось, см подкатом.

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

У кого как, а у меня зимой руки мерзнут. Поэтому я надеваю на них перчатки. При этом, почитать ленту твиттера, или даже просто ответить на звонок становится весьма затруднительно: снять перчатки, достать телефон, махнуть замерзающим пальцем по слайдеру разблокировки… и срочно надевать перчатки обратно, потому что руки-то — мерзнут.

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

В своей первой статье на Хабрахабре я писал об одной из основных проблем существующих ORM (Object-Relational-Mapping, объектно-реляционных отображений) — их производительности. Рассматривая и тестируя две из наиболее популярных и известных реализаций ORM на python, Django и SQLAlchemy, я пришел к выводу: Использование мощных универсальных ORM приводит к очень заметным потерям производительности. В случае использования быстрых движков СУБД, таких как MySQL — производительность доступа к данным снижается более чем в 3-5 раз.

Недавно со мной связался один из разработчиков нового движка ORM под названием pony и попросил поделиться своими соображениями по поводу этого движка. Я подумал, что эти соображения могут быть интересны и сообществу Хабрахабр.

Данный текст рассматривает вкратце особенности объектно-реляционного отображения (Object-Relational Mapping — ORM) и вводит новое понятие реляционного отображения коллекций (Collection-Relational Mapping — CoRM), предлагая обсудить перспективы и возможности технической реализации новой концепции долговременного хранения состояния объектов

Хорошо, когда при разработке проекта под django, разработчики проекта изначально озаботились его интернационализацией.

Минимальными усилиями, проект адаптируется под различные языки. Django имеет богатый набор инструментов, достаточный для почти автоматического добавления новых языков, исправления и добавления переводов отдельных участков текста и так далее.

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

Столкнувшись с существенными потерями производительности на использовании django orm, я стал искать выход из положения, рассматривая разные способы использования orm. Что у меня получилось — смотрите подкатом.

Анализ некоторых python ORM на непроизводительные расходы

Введение

При разработке приложения на python django, я столкнулся с его неадекватным торможением.
После нескольких попыток улучшить довольно сложные алгоритмы расчетов, я обратил внимание, что существенные улучшения этих алгоритмов приводили к весьма скромному результату — из чего я сделал вывод, что узкое место вовсе не в алгоритмах.

Последующий анализ показал, что действительно, основным непроизводительным потребителем ресурсов процессора оказался django ORM, который был использован для доступа к данным, необходимым при расчетах.