Посты с тегом разработка (29)

Про не свой монастырь, но свой устав

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

Нет. я не отрицаю этап моделирования или проектирования. Они безусловно нужны. И теоретики agile подхода на этом делают акцент. Но не надо возводить их в ранг первостепенных и основных этапов разработки.

Имея настолько гибкие инструменты как динамические языки программирования (питон), и фреймворки (джанго), можно и моделировать, и проектировать используя их. Тот DSL который предоставляет джанго для описания моделей, на мой взгляд, настолько нагляден и даже визуален, что заменять его диаграммами, и уж тем более ставить их во главу угла нельзя. Написанная модель это не только некая мета информация, но уже готовый функционал, который можно подергать через shell и прикинуть варианты использования. Всё это сразу. Без сугубо теоретических рисований диаграмм и их перетаскивания их одного угла в другой.

Диаграммы конечно же нужны. Но потом. Либо в момент написания некой вспомогательной документации, либо просто для вникания в проект. Благо есть почти автоматически решения, которые по моделям джанго строят вполне приятного вида картинки с прямоугольниками и связями:)

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

Наследство с особенностями - 2

Я всё продолжаю по рабочим и не только нуждам ковырять наследование моделей, поэтому как и обещал - то ли ещё есть!

  • Очередной сюрприз ждал меня, когда я обновляя свой блог-движок под текущий транк. Я обнаружил сломанным блок "Архив" из-за того, что метод dates() перестал возвращать уникальные значения на месяца, а выдавал мне всё подряд. Я сильно удивился. Но пофиксил всё при помощи, в последнее время моего любимого, set. Да, костыль, но ковырять дальше пока желания нет.

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

    class Base( models.Model ):
       field1 = models.IntegerField( default = 10 )
       # + неявное поле id
    
    class Derived( Base ):
       field2 = models.IntegerField( default = 1 )
       # + неявное поле base_ptr
    
    1. Сериализатор дампит модель наследника целиком, т.е. со всеми полями в том числе и родителей.

    2. При загрузке модели родителей не могут подцепить свой первичный ключ, а просто делают новый INSERT, получая тем самым новый id. Потом этот id идет вверх по иерархии и затирает имеющиеся уже(загруженные из фиксчюры) значения. Похоже, что из-за этого ломается и CRUD.

    Так же это эффект проявляется когда вы просто хотите присоединить к уже имеющемуся базовому объекту какое-то дополнение в виде объекта ...

qs-refactor уже в транке!

Наконец-то! Уверен, что я не один воскликнул это слово, когда узнал что долгожданная queryset-refactor ветка влилась в транк и теперь ORM в джанго стал ещё лучше и удобней! Этого момента ждали долга, поскольку это один из самых больших шагов по направлению к 1.0 версии джанги. Итак, что же мы получили.

Начну с основных изменения уже имеющегося функционала:

  • Указание сортировки по при-join-ненным моделям теперь стало более логичным и совпадает с фильтрами lookup'ов. Просто пример:

    Order.objects.all().order_by( "product__price" )
    
  • Обновлена реализация __iter__ метода queryset'a. И не грузит все строки результат в память сразу.

  • Особенно меня радует: сделана нормальная обработка None значения в lookup'ах. Т.е. если раньше приходилось писать писать воркэраунды для случая когда селект осуществлялся по NULL значениям, например так:

    if value is None:
        queryset = queryset.filter( field__isnull = True )
    else:
        queryset = queryset.filter( field = value )
    

    То теперь эта проверка лишняя не нужна. Ура!)

  • Есть ещё некоторое количество изменений, но они на низко уровне и на прямую не влияют на использование. Хотя именно они окончательно убивают некоторые баги, которые были в джанговском ORM до сего момента.

Помимо изменений, есть ещё и целый ряд дополнений к возможностям ORM. Вот основные из них:

  • Добавлена возможность производить обновление(UPDATE) нескольких ...

svn:externals и django - дружба на век

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

Я всегда использую транк джанги, поскольку релизится она не часто, а для примера можете сравнить насколько отличается текущая её версия от последнего релиза. Ага, как-будто вообще разные фреймворки в некоторых местах:)

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

Обычно я устанавливаю джангу в общедоступный PYTHONPATH, например /usr/lib/python/site-packages/ и все проекты используют именно этот, один инстанс. И тут ключевое слово все. Когда на одном хосте расположены несколько проектов, то сценарий описанный мною ранее, перестает радовать и практически не возможен.

В чем же дело? Да ...

Все без ума от GAE

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

Всю неделю сообщество бурлило новостями и первыми откликами на Google App Engine. Такой информационный волны я уже давно не припомню. Но волна уже схлынула и тут у меня появилось время тоже чуть-чуть высказать свои мысли на этот счет.

Google App Engine

Я почему-то не удивлен, что на первых порах выбор гугл пал на python, а не на другой язык. Гвидо уже давно проводит просветительскую деятельность по внедрению в умы гугловцев питонистических идей. Это можно сказать их апогей. Там уже давно применяется разработка Гвидо - Mondrian. Приложение написанное на django для внутреннего core-review. Но это уже следующий шаг. Роман Гугла с джанго уже давнишний и продолжается, хотя сейчас он только набирает обороты.

То, что в коробке с GAE идет джанга - это супер. Это бальзам на сердце тем, кто продвигает её идеи в массы. Такой мощный соратник как google поможет внушать скептически настроенным гражданам её идеологию и область применения.

Да! YAML! Я долго ждал, чтобы кто-нибудь из крупных игроков питон-сообщества обратил внимание и стал применять YAML как декларативное средство описания данных. Это же мега удобно по сравнению с xml ...