Публикации с меткой «code»

Внезапно, глядя на сообщение Vadim Fint в группе django-russian про опыт использования джанго в большом проекте, написал ответ про мой опыт использования Django и мои решения.
Итак, начнём.
1) Конфигурация.
1.1) Подключение мелких компонент.
Использую симлинки. Потому что virtualenv ещё хуже, поддержка используемых несколькими проектами плагинов превращается в пытку.
1.2) Отсутствие модульной настройки приложений.
Всё планирую заточить для себя
http://github.com/jabapyth/django-appsettings , да никак руки не
доходят.
1.3) Отсутствие настройки media для приложений.
1.4) Отсутствие точек подключения в шаблонах. Есть
http://code.google.com/p/django-app-plugins/ , но они какие-то
дурацкие, потому что очевидно, что для extension_point нужно писать вьюшку, а не шаблон.

2) Денормализованные поля и ORM в целом.
Тут я не знаю хорошего проекта, да и вообще, не в курсе последних разработок. Мне нужно было год назад, а тогда ничего не было.
Что интересно, у меня действительно почти не возникает проблем с ORM, даже для больших баз данных.
Мне кажется, тут дело в том, что проблемы с ORM возникают из-за неудачных архитектурных решений при планировании структуры базы данных, а я очень тщательно планирую БД и стараюсь сводить количество будущих проблем к минимуму (сам себя не похвалишь..).
3) Инклуды.
Проблема: дублирование в шаблонах кода структурных блоков html, скажем, для формочек или кнопочек.
Поборол с помощью http://github.com/buriy/django-containers
Только всё равно дизайнерам, пишущим шаблоны, морально тяжело их писать и использовать.
4) 3rd-party плагины, которые проще переписать целиком, нежели править
в них баги:
4.1) зачастую нужно было использовать паттерн “Controller” вместо кучи вьюшек
4.2) шаблоны нельзя переиспользовать, нужно выкидывать и писать свои
4.3) reverse у 3rd-party плагинов временами конфликтует
4.4) бывает, вьюшки не расширяемые
4.5) временами авторы неправильно используют middleware и теги.
4.6) отсутствие единообразного способа подключить media
4.7) для большинства приложений или нет админки, или есть, но такая, что лучше бы её не было!
Короче, в целом, отсутствие культуры и низкий уровень 3rd-party плагинов. Тут друпал на 10 лет впереди!
5) Админка
5.1) Инкрементальное написание
Решил, написав http://github.com/buriy/django-superadmin
5.2) Уродские виджеты для FK и M2M, отсутствие виджетов для Date,
Duration, Color, картинки для ImageField.
Немножко помогают собранные мной из разбросанных по интернету кусков
http://github.com/buriy/django-extrafields
5.3) Сложность написания своей вьюшки для админки — нет удобных готовых блоков.
5.4) Наивный подход создателей: “админка нужна только для редактирования”:
не хватает встроенного права на чтение таблицы,
нет удобной конфигурации, кто может управлять объектами,
хаки чтобы выводить разные поля для разных пользователей,
хак, чтобы добавлять свои фильтры
(Тут тоже друпал на 10 лет впереди…)
5.5) Приходится тщательно продумывать базу данных, чтобы удобно было её выводить в пользовательском интерфейсе, особенно это забавно делать для таблицы из 10 записей.
6) Сложный деплоймент.
Хотелось бы команду, которая сгенерирует настройки для веб-сервера.
Увы, пока нету. И не будет, пока настройки media для плагинов не будут храниться.
7) проблемы копирования данных
Пришел к выводу: loaddata/dumpdata не готовы к реальному использованию. Единственное, для чего пригодны — для формирования fixture.
Использую команду на основе loaddata, которая выдирает из БД только запрошенные таблицы и объекты. Отлично помогает, когда основная БД занимает сотни гигабайт.
А для копирования базы целиком использую нативный дамп базы данных. Работает быстро и качественно.
8) Базы данных
Отсутствие поддержки нескольких баз данных до Django 1.2.
Для компании с десятками различных баз данных и весьма дурацкими взаимодействиями между ними, было критически важно. Приходилось писать API, фактически дублирующее ограниченный доступ к базе данных, или же писать SQL для всех баз данных, кроме основной (а sqlalchemy тянуть за собой не хотелось, да и если с ним — всё равно неудобно!).
Слава богу, хоть теперь с этим проблем нет.
В последнее время напрягает отсутствие поддержки NoSQL баз данных, хотя бы даже просто поддержка в виде Model и QuerySet, пусть и без join-ов: очень хочется иметь единый интерфейс.
9) Динамические формы.
Намного больше геморроя, чем со статическими, и нужно тратить намного больше времени чтобы тестировать правильность работы UI. Это вообще относится к любой динамике. Ну нету встроенных средств, как в rails.
10) Неудобно писать команды.
Решил очень просто: написал скрипт “django“, который может запускать питонячий файл, подставляя ему DJANGO_SETTINGS_MODULE и PYTHONPATH — извините, язык bash знаю плохо, сейчас бы переписал на питоне, но всё не до этого).
11) Всякие неприятные мелочи.
Опишу только наиболее существенные, для них я написал патчи:
Перезагрузка devserver-а работает не всегда (#8413),
зажевывание ошибок джангой ( fix),
плохая отладочная информация ( #11834 ).
отсутствие цветов для консоли windows (fix)

Но я не ропщу — я знаю, что в остальных фреймворках всё обстоит гораздо хуже!
Некоторые рамки есть, но я рад, что большинство мелочей Django действительно берёт на себя!
Сессии, работа с HTTP-запросом, кеши, autoescape, интернационализация, итп.

Большинство принятых архитектурных решений были удачными, а неудачные решения были приняты исключительно на безрыбьи (это значит, авторы джанги с радостью в течение года примут в trunk ваш качественный патч,
как бы они вас не убеждали в том, что они берут патчи только по знакомству) или же достались в наследство (и большинство из них сосредоточено в django.contrib.* — он просто не успевает за изменениями в django !).
А свои наколенные фреймворки от этих самых неудачных решений гораздо больше страдают — в них мучительно сложно писать то, что ещё не написали создатели, и для чего нет готового плагина!

Сначала ссылка - самое подробное рассмотрение проблем кодировок и юникода в питоне. Внятно, но по аглицки [>>>]
Теперь от себя - у меня есть код, который мигрирует из проекта в проект последние 2 года. Он позволяет забыть про проблемы кодировок на какое-то время. Выглядит он примерно так:

import locale, codecs; locale.setlocale(locale.LC_ALL, '')
# Теперь в encoding положим текущая кодировку локали.
encoding = locale.getlocale()[1]
# Если кодировка не определилась - это винды. Там полюбому UTF-8 :)
if not encoding:
    encoding = "utf-8"
# Установим дефолтную локаль. Финт с ушами reload() нужен потому что разработчики
# питона дюже умные и логично удаляют функцию setdefaultencoding при загрузке.
# Оно в общем то логично, но я же умный.
import sys;reload(sys);sys.setdefaultencoding(encoding)
# Установили кодеки для вывода в потоки согласно распорядку.
sys.stdout = codecs.getwriter(encoding)(sys.stdout, errors = "replace")
sys.stderr = codecs.getwriter(encoding)(sys.stderr, errors = "replace")