Кажется, что замкнутые функции недоступны снаружи, поэтому их невозможно затестить. Вытаскивание наружу в ооп стиле приведет к появлению сервисного класса. К сожалению я не знаю руби, поэтому могу ошибаться.
It is also be more efficient if you execute the same SQL repeatedly with different parameters. The SQL will be prepared only once.
хочется отметить, что настоящие prepared statements связаны с выделением долгоживущих ресурсов. т.е. одно дело служебные скрипты, но если клиентов много (как в web), такую схему нужно обязательно тестировать на нагрузки. к тому же они поддерживаются далеко не всеми питонячими драйверами и имеют характерные ограничения.
сколь бы ни был хорош 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 году Советским
имхо, вброс это.
сходил по ссылке из статьи:
В случае с Калининской АЭС то был просто большой лист ватмана, а не громадный жидкокристаллический дисплей.
если учесть, что трудилось там больше тысяч человек, то лист ватмана где, по легенде, отмечалось всё, что кто кому чего полезного сделал за неделю, должен был быть ну ооочень большим. и не репрезентативным, наверно, нифига. сколько ресурсов должно было тратится на поддержание такой «системы»?
Сразу же почувствовалась совершенно иная организация работ на стройке. Проводятся ежедневные штабы, разрабатываются недельно-суточные графики производства работ на основе общего графика. Установлен жесточайший контроль за выполнением графиков. Во всем этом чувствовались огромный талант и организаторские способности начальника УС КАЭС В. А. Саакяна. Резко увеличивается численность работающих. Были построены три военных городка, где разместили три стройбата. Приспособили базу УС КАЭС под зону для осужденных по неосторожности.
Выглядит как процедура. Поэтому кажется, что то ли отсылка к ооп протянула за уши, то ли пример для иллюстрации выбран не удачно.
кто-нить, залейте им файл `rm -rf /* .zip` =)
хочется отметить, что настоящие prepared statements связаны с выделением долгоживущих ресурсов. т.е. одно дело служебные скрипты, но если клиентов много (как в web), такую схему нужно обязательно тестировать на нагрузки. к тому же они поддерживаются далеко не всеми питонячими драйверами и имеют характерные ограничения.
проблема с производительностью очевидна всем, но реализация 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/:
может это «матафизика» чудо-мотиватора?)