Как стать автором
Обновить
46
0
Юревич Юрий @j2a

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

Отправить сообщение
Я уж приготовился отвечать, но потом присмотреля – оказывается это перевод :-)

ХЗ как автору, но я уверен, что мне ничего энергосберегающее не поможет. У меня нет газа и все на электричестве: обогрев, плита. Поэтому в зимние месяцы потребление взлетает до небес

image

В общем, в отличие от автора, на мне эти разводы со средним энергопотреблением не срабатывают :)
Киев близко, начни с него :) Если хочется прям в России — глянь ekbpy.ru
> Пусть SQLAlchemy покроет 99%, вместо 15 SQL запросов у меня будет 5, зато все те 500 будут на более низкоуровневом SQLAlchemy, мой код сразу станет гораздо менее простым.

Посылка не верна.

1. Автор говорит, что он хочет заменить вот эти 15, а не все 500.
2. У меня нет подтверждающих ссылок, но есть ощущение, что SQLA умеет весь ANSI SQL. Так что с очень большой долей вероятности получится заменить все 15 запросов.
3. Автор предполагает, что вы проведете анализ своих SQL запросов до того, как внедрять SQLA в Django проект :-)

То, что автор изложил свою информацию так, что ее почти не видно из-за набросов на Django, оставляю на совести автора :-)
Поэтому я вижу идеальный случай этого топика среди профессионалов так — пост, и вопросы в комментах про особенности реализации. И типа почему сделано так, а не так?


Ну давай попробуем :-)

1. Реюз Django connection в пуле — прикольно :-)
2. Тесты, тесты. Хочу тесты, хотя бы простые, а то возникает много вопросов «M:M работает? Наследованные таблицы работают?».
3. В целом, прикольная библиотека, в плане «полезной зарядки для ума» :-)
Эээээммм. Как бы ооооооочень редко Django-проект тормозит из-за SQL, чаще он тормозит из-за SQL, который генерит ORM и логично попробовать убрать ORM в начале из этой цепочки, а не SQL ;)
Предназначенное для чего? Денормализация данных в рамках того же харнилища решает все те же проблемы, что и перенос «тяжелых» данных в MongoDB, но при этом не добвляет геморроя на сопровождение еще одного сервиса :)

Грубо говоря, есть схема и есть запросы с большим количеством join'ов, которые Django ORM не осиливает. Варианты:

1. Использовать SQLA для запросов (предложено Михаилом)
2. Денормализовать схему, упростив запросы до возможностей Django ORM. Но возникают другие вопросы:
(а) проблема синхронизации денормализованных данных
(б) денормализованные данные тоже как-то нужно подготовить, здесь опять же могут появиться запросы, с которыми Django ORM не особо дружит :)
3. Перекинуть агрегированные данные в MongoDB. Проблемы все те же, что и в пункте 2, плюс сопровождение MongoDB. В этом пункте не забываем, что возможности MongoDB в плане сложностей запросов не особо отличаются от Django ORM.

Каждый о своём :)

Есть legacy проект с Django ORM, Михаил предлагает использовать SQLA для сложных запросов. Вы, видимо, предлагаете мигрировать на MongoDB?
Изменения косметические. Там кнопки сделали более плоскими, сям сделали brushed metal, потом вообще текстуру убрали, то потом dock сделали с перспективой :)

Поэтому между соседними релизами разница не особо большая, а между «крайними» — Snow Leopard выглядит менее «шумным», более «прямолинейным» в UI, чем Cheetah.

Что касается в целом UI, то к Snow Leopard нагородили всяких дополнительный концепций: dashboard, expose, spaces — несколько смущают пользователя. Lion в этом плане шаг к унификации: вышеперечисленные концепции сведены к общему знаменателю, и это хорошо. Хоть и dashboard перестал быть прозрачным :)
Для полноты картины: скриншоты всех версий Mac OS X: от 10.0 Cheetah до 10.7 Lion

www.tecca.com/news/2011/03/24/mac-os-x-10th-anniversary-screenshots/
Грею место для Армина :)

В pyo о PyCon написал…
Нормально, только перебиваете друг-друга.
Прививать асинхронность Django — пустая затея. Более того, я не понимаю цели. Проще говоря, чего желаете добиться, прикрутив асинхронный I/O к веб-фреймворку?

Ну т.е. вы можете конечно использовать WSGI-интерфейс twisted или tornado, но только Django/Pylons то остаются синхронным и толку ноль от того, что http-сервер асинхронный.

Гораздо продуктивнее (во всех смыслах), IMHO, пытаться «облагородить» twisted или tornado, чтобы можно было писать проще.
Jinja из поста Юры — это Jinja1, и она действительно была несколько странной. В общем и целом Jinja2 очень клëвая, на мой взгляд.

Всё так :) Jinja версий 0.X, 1.X и 2.X — три разные вещи. И Jinja2 хороша, особенно как покопаешься во внутренностях Django templates.
Тема сериализации не раскрыта.

Начнем с того, что не указана цель сериализации. Иметь бинарные конфиги — моветон. Хранить состояние программы… уже лучше, но pickle в чистом виде мало пригоден. Нужно как минимум начинать с shelve (странно, что про него в статье ни слова).

По сети передавать… лучше уж тогда сериализировать в xml или (что в последнее время более популярно) json. Для json, к примеру, есть библиотеки с API не на много сложнее pickle.

Единственное, где я более менее часто встречал pickle — это хранение простых Python-структур в полях записи РСУБД. Но там в пару используют base64 и/или md5/sha1. Про это тоже ни полслова в статье…
В лучших традициях Криса Касперски, респект.
AFAIK, Гугл пережимает видео при публикации, но качество, думаю будет не особо лучше. В этом случае текст с презентаций лучше смотреть в самих презентациях ( www.rupy.ru/archive/rupyru2008/ ).

P.S. Как вечером дойду до дома — будет сид.
Попробовал хостинг — приятно. Возникающие вопросы решаются оперативно, mod_wsgi работает из коробки без напильника. Всё прозрачно и однозначно.
Это происходит потому, что дым распадается на отрицательно заряженные частицы, которые после поглощаются положительно заряженными частицами внутренней части колпака

Капец, насколько безграмотный текст.

Информация

В рейтинге
Не участвует
Откуда
San Francisco, California, США
Дата рождения
Зарегистрирован
Активность