Если у человека возникает желание (тем паче, регулярное) рыться в СМС'ах/почте/мордокниге партнера, то надо бежать как можно скорее. По моему опыту, это признак проблем с психикой и никакие заверения в любви и верности не помогут. Скорее всего, будут постоянные сцены ревности («сходил в спортзал? ах ты козел, наверняка трахнул кого-нибудь в женской раздевалке» и прочий подобный абсурд), чем дальше, тем хуже.
Причина обычно в черезвычайно низкой самооценке партнера (например, нарциссизм — когда снаружи она демонстративно уверена в себе, но глубоко внутри считает себя говном) или еще каких-либо мозговых тараканах.
Нормальный человек никогда не станет заниматься таким подглядыванием. А с ненормальным все равно рано или поздно придется расстаться — «перевоспитать» его не удастся.
Проблема в том, что если такая тенденция сохранится, то выбирать будет не из чего. Компьютеры будут постепенно вытеснены какими-нибудь iPad, где можно будет ставить только то, что одобрено производителем.
Давно не писал на C, но в чем сакральный смысл уродливого макроса STREQV? Вроде бы, он сравнивает первые символы строк, а потом строки целиком. Что мешает сразу использовать strcmp?
Где-то видел более запоминающийся вариант. Типа, достать из кэша — равнозначно взять булочку со стола перед собой. Взять из памяти — сходить за булочкой в соседнюю комнату. Взять с диска — спуститься на первый этаж, перейти улицу, купить в магазине, и вернуться обратно…
Мы Warcraft запускали из под Windows, потому что ему требовалось 8Мб RAM, что-ли, а на машинах стояло по 2 или по 4. Win 3.11 поддерживала своп и виртуальную память, и warcraft без проблем под ней запускался (насколько помню, даже без тормозов).
Не понимаю, зачем нужно использовать для сессий субд или фс. Сессия в большинстве случаев помещается в cookie целиком, при этом производительность значительно вырастает за счет отстутствия обращений хоть к диску, хоть куда-либо еще, и можно не беспокоиться о нескольких фронтендах.
А если для сессии мало 4 Кб, то это возможно не совсем правильные сессии. Я в ограничение на большом и посещаем проекте (социальная сеть определенного рода) еще не упирался.
Не упомянута поддержка указания контекста для переводимых строк. Мне этого очень не хватало, т.к. в коде и шаблонах часто встречаются строки, которые нельзя перевести одинаково. Самый простой пример — слово «none», которое в зависимости от контекста надо переводить то как «нет», то как «ничего», и т.д.
В предыдущих версиях Django это можно было решить только костылями (например, вручную приписывать контекст к строке в каждом таком случае и не забывать убирать его в переводах).
Перевести приложение, использующее gettext, можно при помощи Pootle, а также массой прочих редакторов для десктопа и веба. Совершенно непонятно, зачем очередной велосипед.
Опыт переизобретений велосипедов показывает, что они получаются намного менее удобными, чем gettext и утилиты для работы с ним. Был вполне конкретный опыт, когда в большой компании я предлагал gettext, но меня не послушали и написали велосипед с квадратными колесами.
Я вел бухгалтерию по полгода-году в:
— gnucash
— kmymoney
— ledger
Полгода или год веду, потом забрасываю.
Ledger — самый продвинутый инструмент, но и самый сложный в использовании. Зато позволяет составлять такие бюджеты, которые ни в одной GUI программе невозможно реализовать. Максимальная свобода.
Сейчас снова вернулся в GnuCash. Впрочем, ledger может работать с форматом gnucash насколько я помню.
Представляю сколько сломается парсеров, пытающихся выделить или валидировать URL, email. Попробуйте где-нибудь зарегистрироваться с адресом типа vasya@moscow.ibm
locals() — это PHP-стиль: «А давайте забабахаем все в template, авось что-нибудь, да пригодится»
Отсюда и дыры в безопасности и вообще гадливое впечатление от PHP. Посмотрите, сколько ненужной и потенциально опасной информации ваш locals передает в шаблон.
Ну, это вариант, конечно, но придется часть функциональности buildout писать самим. Возможно, с поддержкой IDE будет лучше, так как из IDE только PyCharm, кажется, поддерживает buildout.
Собственно говоря, buildout поддерживает сборку из нескольких репозиториев с конкретными ревизиями, у меня естественно это тоже используется. Вообще, buildout — это развесистый швейцарский нож, который может все, и многое из коробки, но отвратительно документирован и иногда глючит. Но когда я преодолел эти сложности, то вздохнул с огромным облегчением, и остальные разработчики в команде сказали спасибо.
Для деплоймента мне кажется лучше использовать buildout. Сначала придется помучиться, чтобы настроить под него проект, но деплоймент потом упрощается донельзя. И при апгрейде сервера не возникает проблем типа «ой, забыли установить пакет python-foo». И можно использовать немного отличающиеся конфигурации для production и development. В общем, я ни разу не пожалел о потраченном времени.
Достаточно иметь один клон удаленного репозитория, и уже его клонировать сколько угодно локально. Необязательно для каждого клона клонировать удаленный репозиторий.
Причина обычно в черезвычайно низкой самооценке партнера (например, нарциссизм — когда снаружи она демонстративно уверена в себе, но глубоко внутри считает себя говном) или еще каких-либо мозговых тараканах.
Нормальный человек никогда не станет заниматься таким подглядыванием. А с ненормальным все равно рано или поздно придется расстаться — «перевоспитать» его не удастся.
Не смог найти первоисточник, к сожалению.
Чтобы в cookie пользователь не запихал отсебятину, они подписываются.
А если для сессии мало 4 Кб, то это возможно не совсем правильные сессии. Я в ограничение на большом и посещаем проекте (социальная сеть определенного рода) еще не упирался.
В предыдущих версиях Django это можно было решить только костылями (например, вручную приписывать контекст к строке в каждом таком случае и не забывать убирать его в переводах).
Опыт переизобретений велосипедов показывает, что они получаются намного менее удобными, чем gettext и утилиты для работы с ним. Был вполне конкретный опыт, когда в большой компании я предлагал gettext, но меня не послушали и написали велосипед с квадратными колесами.
— gnucash
— kmymoney
— ledger
Полгода или год веду, потом забрасываю.
Ledger — самый продвинутый инструмент, но и самый сложный в использовании. Зато позволяет составлять такие бюджеты, которые ни в одной GUI программе невозможно реализовать. Максимальная свобода.
Сейчас снова вернулся в GnuCash. Впрочем, ledger может работать с форматом gnucash насколько я помню.
Отсюда и дыры в безопасности и вообще гадливое впечатление от PHP. Посмотрите, сколько ненужной и потенциально опасной информации ваш locals передает в шаблон.
Собственно говоря, buildout поддерживает сборку из нескольких репозиториев с конкретными ревизиями, у меня естественно это тоже используется. Вообще, buildout — это развесистый швейцарский нож, который может все, и многое из коробки, но отвратительно документирован и иногда глючит. Но когда я преодолел эти сложности, то вздохнул с огромным облегчением, и остальные разработчики в команде сказали спасибо.