Обновить
57
1.8

Пользователь

Отправить сообщение
В случае использования метода get_or_create() — написать свой метод, выполняющий принудительный COMMIT перед повторным чтением данных
тут следует учесть, что коммит приводит к глобальным изменениям. если клиентский код, использующий данный метод, помимо получения объекта, проводит с базой ещё какие-то манипуляции, то преждевременное подтверждение транзакции для него может стать чревато. в общем случае, коммитить транзакцию лучше на том же уровне, где её отрывали.
> Кажись такая же ошибка была у меня (Python v2.6),

ваша правда, что в питоне полно таких проблем. а чудо-код, который вы привели, вероятно является квинтэссенцией всего этого. :)

но баг, описанный в данной статье, касается только 2.7, в котором модуль mimetypes стал обращаться к реестру винды для пополнения собственной базы mime-типов. в предыдущих версиях этого не было, поэтому одно из решений, видимо, будет даунгрейдить python.

зы: игры с sys.setdefaultencoding() чреваты, поэтому так делать не стоит.
Как именовать ключи?
Инвалидация
как известно, в CS есть только две трудные вещи. :)

вероятно, здесь стоит упомянуть ещё одну стратегию — generational cache strategy (прочитать можно, например, тут www.regexprn.com/2011/06/web-application-caching-strategies_05.html), которая позволяет обходиться без явной инвалидации, благодаря использованию динамических ключей.
в целом, поддерживаю. только одно не понимаю, вы панк, или просто патчи не умеете делать? :) ведь оно уже использует 2to3 при установке в трёшке (см. code.google.com/p/selenium/source/browse/trunk/setup.py).

кстати, вы пробовали прогонять тесты для модифицированного кода в разных версиях интерпретатора?
мм… любопытно, ни когда раньше не задумывался об этом.

а в русской wiki про Django он обозначен как Адриан Головатый. может так правильно?

зы: вероятно к разгонам о правильном произношении слова «Django», можно добавить ещё одну — про транслитерацию фамилии разработчика. интересно, эти музыканты специально себе такие имена придумывают? :)
когда речь заходит о DSL'ях, вспоминается байка:
С востока люди пришли на землю Сеннаар (в нижнем течении Тигра и Евфрата), где решили построить город (Вавилон) и башню высотой до небес, чтобы «сделать себе имя». Строительство башни было прервано Богом, который создал новые языки для разных людей, из-за чего они перестали понимать друг друга, не могли продолжать строительство города и башни и рассеялись по всей земле. [1]
как вы считаете, грозит-ли подобная участь многоязыкому YouTrack, и если нет, то — почему? )

какие KPI можете посоветовать для управления такой разработкой — в каких случаях стоит писать DSL, и это будет оправдано, а в каких нужно сказать «стоп» и тупо кодить?
Выстраивание иерахрии это и есть часть самоорганизации систем. Таким образом решаются проблемы эффективности и выживаемости. В «плоских» системах количество потенциальных связей слишком велико, в результате чего возрастают расходы на их поддержание. Как «лапша» в коде. Модульность и иерархия, образующие структуры, появляются естественным образом, с целью минимизации связей, установки границ распространения дефектов, и оптимизации информационного обмена.
просто взял и стартовал проект.

По-моему это пример очень правильной подачи материала. Рай и впрямь можно доверить хоть ангелу, хоть чёрту — заморочка лишь в степени рисков. :) А в данной истории может нет ничего волшебного. Вероятно, весь фокус кроется в опыте лирического героя.

Похожий сценарий был весьма популярен ещё в советских книжках, когда какой-нибудь отставной генерал приходил на завод и за день чудесным образом налаживал там процессы. :) Так и тут, этот хитровывернутый мастадонт ведь не совсем чтобы вот так сразу пришел туда, с улицы, чтобы чего-нибудь там по-разрабатывать. По его же словам, у него там куча давних знакомых в верхах, с которыми он поддерживает связь на протяжении лет 20-ти. За плечами работа в крупных компаниях над R&D проектами, отработанное целеполагание, поставленное проектное мышление и т.д. и т.п. Не студент, короче. Дальше всё очевидно.

Что касается разработчиков, то самоорганизация и свобода выбора, заявленные тут как чудо, на самом деле у них врождённые. Надоел проект, ищут что по душе и уходят работать в другую компанию. Прикольно, что они нашли способ, как замкнуть эту миграцию внутри себя. Но вряд-ли это означает анархию. Скорее, система похожа на грядку, где помидоры считают, что они растут сами собой. ;)
тогда по логике в nginx должно быть аналогичное условие. что-то типа:
    location / {
         if ($request_method = GET) {
            default_type  "text/html; charset=utf-8";
            set $memcached_key "YOURSITE:1:$request_uri";
            memcached_pass unix:/tmp/memcached.sock;
            error_page 404 502 = @fallback;
            break;
        }
	try_files $uri @fallback;
    }
Если вы тоже используете less, не забудьте поставить node.js на сервер и сам компилятор
есть куча доводов против того, чтобы тащить средства разработки на продакшен.
а в целом, спасибо за статью, очень познавательно.
чтобы никто из аудитории не переключал нам слайды.

используйте HTTPS, чтобы не украли секретные ссылки снифером трафика. кажется, это просто www.piware.de/2011/01/creating-an-https-server-in-python/.
какие яйца? «длина списка» это свойство списка.
Тесты это инструмент. TDD — методология. Для того, чтобы ими эффективно пользоваться, необходимо учиться, вырабатывать навыки. Это как если вы всю жизнь ползаете на четвереньках, а затем решаете ходить на двух ногах — сначала передвигаться будет медленнее и набьете много шишек. Какие-то прежние привычки придетя забыть. Кто-то может решить, что такой вариант ему не подходит. Но шанс научится бегать есть у всех. :)
Вот, посмотри сюда. Синий график – это первый человек.
оси не подписаны — это не графики, а абстрактная живопись =) можете рефлексировать сколько влезет, рассуждая о том кто такие «красные» и «синие», но по сути статья ни о чём.
Да, всё действительно так просто! @decorator — просто синтаксический сахар для конструкций вида:
Декораторы — это просто pythonic-реализация паттерна проектирования «Декоратор».
второе утверждение не верное. пруф.

конечно, это перевод и придирка относится к оригинальному тексту.
SCM делает акценты на изменения. здесь удобнее работать не с хронологической историей коммитов, а со стеком патчей. например www.procode.org/stgit/
Только http method определяет не метод передачи данных, а указывает действие над ресурсом. поэтому, что вопросы, что ответы по данной теме в книжке — полная бессмыслица. :)
мы раньше использовали Mox, пока не наткнулись на flexmock. :)
Mox заставляет делать в тестах избыточные шаги .ReplayAll(), .VerifyAll(), что утомляет. если один из них не был вызван (например из-за того, что тестируемый код бросил непредвиденное исключение), то установленные моки могут протекать в последующие тесты, что вызывает трудно диагностируемые глюки. возможно, сейчас это всё уже не актуально. что касается функциональности, то функциональности flexmock мне хватает для повседневных нужд. не хватает, пожалуй только record'а.
У Mock синтаксис бесчеловечный. ╰_╯ Сложилось впечатление, что моки это один и тех редких случаев, где fluent интересы оказываются уместным. У нас прижился лишь flexmock.

Информация

В рейтинге
1 541-й
Зарегистрирован
Активность