по факту — ни в чем. в деталях, если загнянуть в модуль warnings и в его документацию, то можно найти фильтры варнингов, какие будут вызываться, а какие «глушиться», куда сообщения будут направляться (можно отправлять через logging.warning), а так же форматирование сообщений и прочие плюшки, недоступные обычным исключениям.
модуль warning генерирует исключения типа Warning*, тогда как logging.warn просто отправляет сообщение c уровнем события logging.WARN или 30 — аналогично можно записать logging.log(logging.WARN, 'warner brothers').
сначала argparse, теперь logging — какой стандартный модуль в скромном переводе без сравнений с аналогами, жизненными примерами, подводными камнями и прочими интересными вещами, будет следующим? перевели бы всю документацию на русский язык тогда уж.
P.S. касательно logging — чем лучше/хуже logbook? как обстоят дела с многопоточностью, в том числе и многопроцессорной среде(via multiprocessing)? есть ли параллели с log4j? как можно шарить конфиги между разными логгерами? как писать свои хендлы и форматтеры?
PHP: история одной аварии Как-то раз мы решили использовать php в продакшене и вроде все было хорошо. Но однажды на пике посещаемости сайт стал работать очень медленно и почти всегда выдавал 504 ошибку. Мы долго думали, в чем же дело, но нашли в логах заметку о timeout operation. Много гуглили — ничего не нашли. Полезли в конфиг — а там оказывается можно выставлять время выполнения скрипта! Увеличив значение поумолчанию до 600 мы решили проблему и теперь сайт работает. Не повторяйте наши ошибки.
А если серьезно, то не серьезно — раз уж использовали в продакшене, то хотя бы раз в конфиг стоило бы заглянуть и узнать, что там вообще настраивается.
Вопрос не столько в однострочниках, сколько в неправильном использовании языковых средств.
Не зачем обращаться к символам строки по индексу, чтобы сравнить два символа, когда можно итерировать строку посимвольно и сравнивать символы. Не зачем итерировать ключи словаря, чтобы проверить, что искомое значение есть в их списке — hash-lookup будет быстрее и правильней и т.д.
То, что после устранения этих проблем все функции прекрасно описались через list comprehensions — случайность =)
Простите, но если мы все же пишем на питоне, то давайте писать на питоне:
from itertools import cycle
def form_dict():
return dict([(i, chr(i)) for i in range(128)])
def comparator(value, key):
return dict([(idx, [ch[0], ch[1]])
for idx, ch in enumerate(zip(value, cycle(key)))])
def encode_val(word):
d = form_dict()
return [k for c in word for k,v in d.items() if v == c]
def full_encode(value, key):
d = comparator(value, key)
l = len(form_dict())
return [(v[0] + v[1]) % l for v in d.values()]
def decode_val(list_in):
l = len(list_in)
d = form_dict()
return [d[i] for i in list_in if i in d]
def full_decode(value, key):
d = comparator(value, key)
l = len(form_dict())
return [(v[0] - v[1]) % l for v in d.values()]
Возможно ревизий? Эти ревизии не предназначены для версионирования данных — нужно хранить либо инлайново, если нужна историческая индексация (и нам не важен размер документа), либо вложением. Сжимать базу не обязательно для потерь старых ревизий — первая же репликация убивает их в новой копии.
А при больших количествах обновлений обычно настраивают автообновление всех view функций, чтобы не было застоя и не тормозило.
It depends. За 2 года CouchDB очень сильно изменился, но как минимум две задачи он решал и решает прекрасно: обработка больших массивов статистических данных во времени, при условии, что все map/reduce функции были заранее продуманы, и самодостаточные couchapp web-приложения.
Ждем окончательный выход на мобильные платформы — из андроид.маркета они как то быстро выпилились.
В новых версиях есть compaction daemon, который при накоплении определенного буфера через заданный интервал времени в фоне сжимает базу, тем самым минимизируя нагрузку и сохраняя место. Все настраивается в конфиге.
CouchDB — не лучшее решение для очень динамических данных. Оно идеально для статистических обработок, где данные в прошлом не меняются, база не сжимается по 10 раз в неделю, но и тут обычно выносят оперативные данные в отдельную базу, а по уменьшению их актуальности реплицируют в общий котел, если не было сделано с самого начала, и удаляют её за ненадобностью. Партицирование и в RDBMS актуально, так и тут.
Тогда коуч работать будет быстро и действительно relax.
используете CouchDB, чтобы хранить документы с низкой продолжительностью жизни (сессии, лок-файлы, очереди)
Очень странное использование для этих целей в продакшене решения, которое никогда не претендовало на быструю запись. Redis не просто так ведь придумали, например.
1. Выгрузка != оперативная работа с данными. Так же вы рискуете изобрести велосипед в виде обработки этих данных, если нужно так же как в 1С. Не говорим о том, что такая схема не годится для онлайн режима взаимодействия с.
2. Автоматизировать работу через браузер — надеюсь имеются ввиду веб-сервисы — иначе это уже тянет на большее извращение нежели com-соединение =)
3. Прямым доступом в базу вы убиваете весь предпроцессинг данных не говоря уже о рисках создать конфликтные состояния данных. Не нужно прыгать через бизнес-логику, нужно с ней взаимодействовать.
Вариант автора ничем не уникален и вполне нормальное решение, а работать с com-объектами можно хоть из vbscript: синтаксис другой, результат тот же =)
Прекрасно! Следующим этапом развития будет создания нормального, единого интерфейса для внешних приложений на стороне 1С и сведение всей работы com-объектов и/или web-сервисов только к нему. Чинить 100500 мест после очередного обновления структуры данных в 1С или синхронизировать реализации бизнес-логики очень быстро надоест =)
ну тогда XML, получается, вообще забросили — видимо никому не нужен =)
А на счет IE6(привет, VW Group) не хочется разводить очередной холивор, но вот вопрос: зачем гоняться за новыми технологиями/фреймворками, но при этом продолжать использовать устаревшее, потенциально не безопасное ПО? И раз копроративный стандарт, то зачем нам лишняя поддержка других браузеров?
Мы все таки либо развиваемся, либо топчемся на месте, вечно бегать за двумя зайцами не получится.
Не понравилось:
— Название. Уверен, многие видя и слыша слово YAML думаю о формате данных, а не о CSS. А если в одном проекте будут использоваться оба инструмента, то путаница просто гарантированна.
— Лицензия: обязательное упоминание фреймворка на странице.
Примеры как-то подозрительно напоминают bootstrap, а раз не видно разницы, то зачем платить больше?
От CouchDB, судя по его отсутствию в статистике/доках, но наличию в конструкторе на главной, вы собираетесь отказываться или он просто статистически никому не нужен?
P.S. касательно logging — чем лучше/хуже logbook? как обстоят дела с многопоточностью, в том числе и многопроцессорной среде(via multiprocessing)? есть ли параллели с log4j? как можно шарить конфиги между разными логгерами? как писать свои хендлы и форматтеры?
Как-то раз мы решили использовать php в продакшене и вроде все было хорошо. Но однажды на пике посещаемости сайт стал работать очень медленно и почти всегда выдавал 504 ошибку. Мы долго думали, в чем же дело, но нашли в логах заметку о timeout operation. Много гуглили — ничего не нашли. Полезли в конфиг — а там оказывается можно выставлять время выполнения скрипта! Увеличив значение поумолчанию до 600 мы решили проблему и теперь сайт работает. Не повторяйте наши ошибки.
А если серьезно, то не серьезно — раз уж использовали в продакшене, то хотя бы раз в конфиг стоило бы заглянуть и узнать, что там вообще настраивается.
Не зачем обращаться к символам строки по индексу, чтобы сравнить два символа, когда можно итерировать строку посимвольно и сравнивать символы. Не зачем итерировать ключи словаря, чтобы проверить, что искомое значение есть в их списке — hash-lookup будет быстрее и правильней и т.д.
То, что после устранения этих проблем все функции прекрасно описались через list comprehensions — случайность =)
… а не изображать basic-style.
А при больших количествах обновлений обычно настраивают автообновление всех view функций, чтобы не было застоя и не тормозило.
Ждем окончательный выход на мобильные платформы — из андроид.маркета они как то быстро выпилились.
Тогда коуч работать будет быстро и действительно relax.
Очень странное использование для этих целей в продакшене решения, которое никогда не претендовало на быструю запись. Redis не просто так ведь придумали, например.
2. Автоматизировать работу через браузер — надеюсь имеются ввиду веб-сервисы — иначе это уже тянет на большее извращение нежели com-соединение =)
3. Прямым доступом в базу вы убиваете весь предпроцессинг данных не говоря уже о рисках создать конфликтные состояния данных. Не нужно прыгать через бизнес-логику, нужно с ней взаимодействовать.
Вариант автора ничем не уникален и вполне нормальное решение, а работать с com-объектами можно хоть из vbscript: синтаксис другой, результат тот же =)
А на счет IE6(привет, VW Group) не хочется разводить очередной холивор, но вот вопрос: зачем гоняться за новыми технологиями/фреймворками, но при этом продолжать использовать устаревшее, потенциально не безопасное ПО? И раз копроративный стандарт, то зачем нам лишняя поддержка других браузеров?
Мы все таки либо развиваемся, либо топчемся на месте, вечно бегать за двумя зайцами не получится.
— Название. Уверен, многие видя и слыша слово YAML думаю о формате данных, а не о CSS. А если в одном проекте будут использоваться оба инструмента, то путаница просто гарантированна.
— Лицензия: обязательное упоминание фреймворка на странице.
Примеры как-то подозрительно напоминают bootstrap, а раз не видно разницы, то зачем платить больше?