сколь бы ни был хорош django orm, как прикладное api, в реализации это куча тормозного говнокода. факт.
проблема с производительностью очевидна всем, но реализация django.db такова, что разобраться с этим чудовищным мутантом очень сложно. поэтому мало находится отважных, кто рискует туда полезть дальше исследований.
не так давно, некто Anssi Kääriäinen, в dev-рассылке предлагал заняться поэтапным рефакторингом, и взять для начала — QuerySet. тут естественно возникла дилемма: свежая кровь и здравый смысл vs совместимость с легаси-кодом (ааа. кабыче у кого не сломалось). подробности по ссылке, есть-ли прогресс — не знаю.
альтернативная мысль: давайте использовать SQLAlchemy, как все нормальные люди, — это комета Галлея. прилетает, сверкает, делает много шума, а затем опять погода — тишина. :)
в общем, спасибо за статью, но если действительно есть желание разобраться с проблемой, и хватает скиллов, — айда в django-dev@ :)
инкапсуляция — это скрытие реализации за интерфейсом (что называть интерфейсом, в каждом конкретном случае, определяет сам разработчик). интерфейсы в ООП суть стереотипы поведения.
в случае крутых изменений в подклассах нужно привлекать LSP.
уровни абстракции это компромисс между нужностью и удобством. и чем их меньше приходится создавать, тем лучше. как пишут в букваре, сообщение http представляет собой последовательность октетов. поэтому «массив байт» это тоже — абстракция. так вот, нужна-ли она, такая? ведь очевидно же, что в p3k удобства, в этом плане, стало меньше, а хорошо задокументированных заморочек — больше.
это не мне необходимо, а www.python.org/dev/peps/pep-3333/#unicode-issues :)
хочу сказать, что если в python2 «суть строк» была вполне утино-однотипна, то разработчики p3k, соорудили для нас самостоятельную заморочку. что, например, в стеке wsgi приводит к нескончаемой череде этих самых decode() / encode().
кстати, исходники git-flow это изумительный пример кодинга на #!/bin/sh. для меня было открытием, что синтаксис sh позволяет писать достаточно сложные вещи весьма абстрактно и чисто — без многоуровневых вложенностей и обилия «закорючек», что свойственно многим системным скриптам.
Хочу вынести на суд широкой общественности идею системы премирования (мотивации) сотрудников.
Метафизика идеи заключается в привнесении рыночных отношений в производственные процессы.
По легенде, эта идея впервые была предложена в 1982 году Советским
имхо, вброс это.
сходил по ссылке из статьи:
В случае с Калининской АЭС то был просто большой лист ватмана, а не громадный жидкокристаллический дисплей.
если учесть, что трудилось там больше тысяч человек, то лист ватмана где, по легенде, отмечалось всё, что кто кому чего полезного сделал за неделю, должен был быть ну ооочень большим. и не репрезентативным, наверно, нифига. сколько ресурсов должно было тратится на поддержание такой «системы»?
Сразу же почувствовалась совершенно иная организация работ на стройке. Проводятся ежедневные штабы, разрабатываются недельно-суточные графики производства работ на основе общего графика. Установлен жесточайший контроль за выполнением графиков. Во всем этом чувствовались огромный талант и организаторские способности начальника УС КАЭС В. А. Саакяна. Резко увеличивается численность работающих. Были построены три военных городка, где разместили три стройбата. Приспособили базу УС КАЭС под зону для осужденных по неосторожности.
По изоляции мне нравятся больше интеграционные тесты, по тестируемому объекту — функциональные. У таких тестов очень большое покрытие кода, это и плюс и минус одновременно… они достаточно быстро проходят (3-4 минуты ~250 тестов)
как будто про нас. :) тоже с этого начинали. и щастье при первом рефакторинге. и разочарование, когда более-менее освоили метод, а количество тестов перевалило за сотню — запуск занимает какое-то неразумное время, при этом видно невооруженным глазом, что получаемая польза не оправдывает вложения.
чем крупнее кусок системы, охватываемый тестом, тем больше у него параметров состояния и тем меньше шансов проверить, пускай даже лишь существенные, их комбинации, ничего не упустив. при этом, чем больше глубина куска (по задействованным уровням системы), тем менее очевидны связи между этими параметрами, с точки зрения внешнего наблюдателя, коим является тест.
мне кажется, что «большое покрытие кода» интеграционными тестами — иллюзия. как раз о коде они дают лишь крайне поверхностное, оценочное представление. по сто раз дергают одни и те же куски, пропуская значимые граничные аспекты. отсюда эффективность. данный вид тестов хоть и хорош в начале, но в качестве основного средства tdd-разработки не особо практичен. вроде как хождение на четвереньках.
в то время (2007) рендер freetype оставлял желать лучшего. но эти проблемы как раз относились к низким, монтиорным, dpi. на высоких dpi пляски с antialiasing и cleartype не нужны. а на печати всё было достойно. не в последнюю очередь потому, что система рендера X всю свою сознательную жизнь ориентировалась на dpi (истоки которой можете поискать в 80x по словам «PostScript» и «Apple»), и только сейчас впала в маразм.
По мне, так уже сама абстракция над if-else кажется избыточной:
def wrapper(request, *args, **kwargs):
if not condition_func(request, *args, **kwargs):
return false_func(request, *args, **kwargs)
return view(request, *args, **kwargs)
Если много потрудится, то в пределе всю логику можно выразить в виде функций и их применения, только зачем? Ведь процедурный подход в python прекрасен.
Кстати, в django присутствует схожий по смыслу механизм — стек middleware. Поэтому, в качестве альтернативы пляскам вокруг декораторов, было бы любопытно посмотреть в сторону адаптации его механизмов, под нужны отдельных view.
проблема с производительностью очевидна всем, но реализация django.db такова, что разобраться с этим чудовищным мутантом очень сложно. поэтому мало находится отважных, кто рискует туда полезть дальше исследований.
не так давно, некто Anssi Kääriäinen, в dev-рассылке предлагал заняться поэтапным рефакторингом, и взять для начала — QuerySet. тут естественно возникла дилемма: свежая кровь и здравый смысл vs совместимость с легаси-кодом (ааа. кабыче у кого не сломалось). подробности по ссылке, есть-ли прогресс — не знаю.
альтернативная мысль: давайте использовать SQLAlchemy, как все нормальные люди, — это комета Галлея. прилетает, сверкает, делает много шума, а затем опять погода — тишина. :)
в общем, спасибо за статью, но если действительно есть желание разобраться с проблемой, и хватает скиллов, — айда в django-dev@ :)
в случае крутых изменений в подклассах нужно привлекать LSP.
хочу сказать, что если в python2 «суть строк» была вполне утино-однотипна, то разработчики p3k, соорудили для нас самостоятельную заморочку. что, например, в стеке wsgi приводит к нескончаемой череде этих самых decode() / encode().
(если что, это не работает)
а теперь прикиньте во что превращается аккуратное:
в p3k.
зы: не троллинга ради — это Армин так писал lucumr.pocoo.org/2010/5/25/wsgi-on-python-3/ :)
сходил по ссылке из статьи: если учесть, что трудилось там больше тысяч человек, то лист ватмана где, по легенде, отмечалось всё, что кто кому чего полезного сделал за неделю, должен был быть ну ооочень большим. и не репрезентативным, наверно, нифига. сколько ресурсов должно было тратится на поддержание такой «системы»?
офф: вот из другого источника helion-ltd.ru/part-10-kalininskaya-npp/:
может это «матафизика» чудо-мотиватора?)
чем крупнее кусок системы, охватываемый тестом, тем больше у него параметров состояния и тем меньше шансов проверить, пускай даже лишь существенные, их комбинации, ничего не упустив. при этом, чем больше глубина куска (по задействованным уровням системы), тем менее очевидны связи между этими параметрами, с точки зрения внешнего наблюдателя, коим является тест.
мне кажется, что «большое покрытие кода» интеграционными тестами — иллюзия. как раз о коде они дают лишь крайне поверхностное, оценочное представление. по сто раз дергают одни и те же куски, пропуская значимые граничные аспекты. отсюда эффективность. данный вид тестов хоть и хорош в начале, но в качестве основного средства tdd-разработки не особо практичен. вроде как хождение на четвереньках.
Если много потрудится, то в пределе всю логику можно выразить в виде функций и их применения, только зачем? Ведь процедурный подход в python прекрасен.
Кстати, в django присутствует схожий по смыслу механизм — стек middleware. Поэтому, в качестве альтернативы пляскам вокруг декораторов, было бы любопытно посмотреть в сторону адаптации его механизмов, под нужны отдельных view.