Одно из слабых мест джанго-админки — главная страница. Идея авто-группировки моделей по приложениям и вывод столбиком в одну колонку работает только на начальных этапах, дальше это становится просто неудобно — куча лишней информации и довольно сложные пути для того, чтобы добавить полезную. Ну, например, чтобы названия приложений писались русскими буквами — полностью перекрывать шаблон.

И тут на помощь приходит django-admin-tools. С этим приложением минут за 20 можно получить «приборную панель» с произвольной группировкой приложений/моделей, вкладками, любым числом колонок, различными блоками, которые каждый пользователь сможет расставить, как ему удобнее, скрывать и сворачивать по желанию, закладками, настраиваемым меню и удобным способом добавления во все это хозяйство всего, чего только можно придумать.

Вот так, например, сейчас выглядит админка к сайту НадоВместе:


(это только часть, вот скриншот целиком)

Разберемся поподробнее.

Буквально вчера вышла в свет новая версия набора свободных библиотек для работы с множеством различных медиаформатов — FFmpeg за скромной версией 0 точка 6.

Разработчики немного затянули с выпуском(больше года, предыдущая версия датируется мартом 2009-го), но этот факт меркнет перед списком улучшений этой версии — они просто коллосальны.

Если в кратце, то цель главная цель — улучшение поддержки HTML5 видео, на что указывает ненавязчивое название релиза — «Works with HTML5».

Это заключительная часть перевода статьи. Декораторы, switch для функций, некоторая информация о классах.

Всем привет,

Собираюсь поделиться с вами технической стороной того, как я за 16 недель сделал новый вебовый rss ридер, и чуть не сошел с ума.
Отходя от долгой предыстории, будем считать, что все началось в феврале этого года, когда мы с Дэвидом (dmiloshev, UI-дизайнер) решили сделать прототип нашего детища вдвоем.
«В одиночестве» — потому, что не было никаких скрамов, совещаний, «коллективного разума», а всю техническую часть, довелось делать самому.

Если бы меня попросили описать всю статью в одном предложении, то получилось бы:
No-SQL, mongodb, node.js, фак мой мозг, Evented I/O, очереди, выводы, git, nginx, memcached, Google Reader, Atom, TTL, PHP, ZF, jQuery, выводы.

Почему после распараллеливания выполнение вашей программы может замедлиться вдвое?
Почему после создания потока перестает работать Ctrl-C?
Представляю вашему вниманию перевод статьи David Beazley «Inside the Python GIL». В ней рассматриваются некоторые тонкости работы потоков и обработки сигналов в Python.

В мире все примерно распределяется в соответствии с принципом Паретто. Меньшая часть — богатые, большая часть — бедные (читающий, ты входишь в золотой миллиард). Тоже касается и материалов о программировании. Порой очень сложно найти хоть что-нибудь не начального уровня.

После прочтения Dive into Python или подобной ей и ознакомления с документацией возникает вопрос, а что читать дальше? Можно обратиться к списку книг на python.org. Там есть раздел Advanced Books, но в нем всего лишь 6 книг (седьмая не выходила), и только одну я бы назвал по-настоящему стоящей.

К счастью, у Питона есть очень подробная и качественная документация. Но даже в ней многие темы либо только поверхностно затронуты, либо их очень сложно найти (потому что документация большая, и если не знаешь, куда смотреть, не найдешь).

Ниже собраны сложные материлы про Питон, его устройство и возможности. Все на английском (грех, не знать технический английский). Про Dive into Python я слукавил. Большинство приведенных материалов требуют хорошее знание Питона и наличие опыта программирования на нем.

Как то я уже писал топик про каптчу 3D

А вчера решил слегка переделать, добавить рюшечек и еще одно измерение.
Долго сказка пишется, да быстро дело делается, рушил сделал и вот наваял гиперкуб Капчу 4D.

Работая долгое время области банковского ПО, а в частности по всяким электронным платежам, вместе с коллегами я составил мини-ЧАВО на тему банковских пластиковых карт. Многие вопросы очевидны, а некоторые могут быть весьма туманными. В России бизнес пластиковых карт набирает обороты, что приятно, и лучше быть подкованным по «матчасти».

Итак, 10 распространенных заблуждений.

Не давно писал как можно рекомендовать товар в Интернет-магазинах или других местах, используя информацию о пользователе. Сейчас хочу показать алгоритм, который позволяет рекомендовать друзей, например в социальных сетях.

Первый шаг, представим информацию о пользователя в интервальной шкале и рекомендуем пользователю друзей используя коэффициент корреляции Пирсона, который будет измеряет степень линейной зависимости между двумя интервальными переменными. Например, у нас есть 4 пользователя: Дима, Анна, Петя и Саша. Мы знаем о них информацию, которую представляем в виде чисел в массиве (интересы, блоги, возраст и т.д.)

Погода за окном просто требует чего-то горяченького, поэтому воспользовавшись возможностью что-то по исследовать в свободное время, я решил подумать — а можно ли не останавливая скрипт, подменить функцию, которая выполняется? С таким требованием я встретился чуть ранее, при разработке нашего стартапа. У нас был один из внутренних серверов, который заведовал всеми действиями между пользователями в реальном времени. Это обычный РНР-демон-роутер, который обрабатывал запросы от клиентских запросов (внутри сервера), но была одна сложность — в случае, когда я что-либо изменял в коде сервера или обработчиков отдельных команд, демон приходилось перезагружать, что означало отключение текущих клиентов и потеря информации о состоянии сервера (этот вопрос решаемый, конечно). То же самое было в случае ошибки в коде — все подключенные пользователи сразу это чувствовали на себе (хорошо, что все они такие же разработчики, а не реальные клиенты). Можно ли этого избежать?

Конечно можно, например, отказавшись от скриптов-демонов, как мы и сделали. Однако это проблему не сняло, просто переместило ее в другую плоскость. Ведь остались другие сервисы-демоны, которые также должны работать непрерывно, хоть их значимость меньше, однако перезагружать каждый раз не очень то хочется. Поэтому решил я поискать возможность на лету подключать новый код и сразу его исполнять. Минимальным кодом будет функция, но вполне возможно подключать и методы классов.

В связи с некоторыми вычислениями на питоне (например, подсчётом коэффициента симметрии карты реликтового излучения) мне захотелось сделать процесс более наглядным. Ну хотя бы добавить прогресс-бар. Скучно, знаете ли, сидеть перед пустой консолью и втыкать на запущенную команду. То ли работает, то ли висит… с ходу не понять. А делать какой-нибудь лог исполнения не хочется, так как потом в полученом хаосе глаз теряется.

Какое-то время назад Хабре проскакивала заметка про клиент-парсер сайтиков на Питоне. Автор на этом примере разбирал проблемы многопоточных сетевых приложений.

Но мне показалось, что ту же задачу (вернее, ее главную часть — параллельные соединения c http-cервером) вполне можно эффективно решить и без потоков.

Существует много разных способов css разметки. Некоторые базируются на абсолютном позиционировании, другие используют float'ы. Первый метод плохо поддерживает «резиновость» макета, тогда как второй это неплохой способ разметки.

Но, как и многие мощные инструменты, float'ы имеют свои изъяны. Для начала, верстка на основе float'ов не такая простая к пониманию, а также float'ы есть источником многих багов (в основном в ИЕ), что делает их не идеальным вариантом в погоне за кроссбраузерностью.

Итак, речь далее пойдет о

Асинхронная концепция программирования заключается в том, что результат выполнения функции доступен не сразу же, а через некоторое время в виде некоторого асинхронного (нарушающего обычный порядок выполнения) вызова. Зачем такое может быть полезно? Рассмотрим несколько примеров.

Первый пример — сетевой сервер, веб-приложение. Чаще всего как таковых вычислений на процессоре такие приложения не выполняют. Большая часть времени (реального, не процессорного) тратится на ввод-вывод: чтение запроса от клиента, обращение к диску за данными, сетевые обращение к другим подсистемам (БД, кэширующие сервера, RPC и т.п.), запись ответа клиенту. Во время этих операций ввода-вывода процессор простаивает, его можно загрузить обработкой запросов других клиентов. Возможны различные способы решить эту задачу: отдельный процесс на каждое соединение (Apache mpm_prefork, PostgreSQL, PHP FastCGI), отдельный поток (нить) на каждое соединение или комбинированный вариант процесс/нить (Apache mpm_worker, MySQL). Подход с использованием процессов или нитей перекладывает мультиплексирование процессора между обрабатываемыми соединениями на ОС, при этом расходуется относительно много ресурсов (память, переключения контекста и т.п.), такой вариант не подходит для обработки большого количества одновременных соединений, но идеален для ситуации, когда объем вычислений достаточно высок (например, в СУБД). К плюсам модели нитей и процессов можно добавить потенциальное использование всех доступных процессоров в многопроцессорной архитектуре.

Нужно было прикрутить регистрацию на сайт. Вспомнил про django-registration (классический django reusable app). Первое, что удивило — в исходниках не было шаблонов. Пришлось немного покопаться в интернете, поискать ответы на вопросы и поделиться результатом.

Прочитал статью «Фрагментарное кэширование в MVC веб-фреймворках». Статья описывает проблему кеширования фрагмета отображения, а именно проблему полного разделения контроллера и отображения — контроллер отрабатывает полностью до вызова отображения. Если в отображении мы кешируем фрагмент, это ничего не меняет — контроллер-то уже отработал! В статье описан способ этого избежать: сделать запрос данных «ленивым».

Начав писать, как это должно быть сделано правильно, решил написать, как устроены шаблоны Django, чтобы не-джанговодам тоже было понятно.

Как это сделано в Django?

Мой первый хабратопик, надеюсь, что не последний.

Представим ситуацию: есть корзина покупок на сайте, при добавлении в корзину мы ставим на товар т.н. lock, исключающий его из списка доступных для покупки товаров. Когда клиент удаляет товар из корзины — lock снимается. Но что делать, если пользователь просто закрыл браузер? В таком случае сессия будет удалена сборщиком мусора, а локи так и останутся.

Когда я столкнулся с такой ситуацией, первое что мне пришло в голову — хранить локи и дату доступа в БД и периодически дергать её кроном. Но костыльность этого решения очевидна. А вот ещё бред, с которым я столкнулся при решении сабжа: для сериализации и десереализации сессий используются функции и формат, отличные от функций serialize и unserialize. Приходится делать велосипеды для ансериализации сессии.

Ближе к телу: как решил проблему я…

В Питоне совсем не важно, что вы поместите в определение класса. Это могут быть строки, числа, объекты, переменные. В третьем Питоне можно даже передавать именованные аргументы.

Триггер — это хранимая процедура, которая не вызывается непосредственно, а исполняется при наступлении определенного события ( вставка, удаление, обновление строки ).
Поддержка триггеров в MySQL началась с версии 5.0.2

Что было нового в версии 3.0:

1. Поддержка питона 3.1 и выше.
2. Опции «process-group», «application-group», «callable-object» и «pass-authorization» могут быть размещены в директивах WSGIScriptAlias и WSGIScriptAliasMatch
3. Если клиент обрывает соединение в процессе обработки итератора вместо «бросания исключения» теперь записывается отладочное сообщение в лог
4. В директиву WSGIDaemonProcess добавлена опция «chroot», позволяющая запускать приложения более изолированно
5. Добавлена глобальная директива WSGIPy3kWarningFlag, при использовании python2.6 будут выдаваться предупреждения
6. Исправлена «assertion error» если питон был скомпилирован с директивой Py_DEBUG
7. Добавлена поддержка «Content-Type: chunked» в запросе (директива «WSGIChunkedRequest»). Данные склеиваются и передаются приложению на обработку.
8. Значения HTTP заголовков теперь передаются в справочнике окружения, для хуков доступа, авторизации и аутентификации
9. Флаг «flag wsgi.run_once» не выставляется в True, при работе в режиме демона, когда «maximum-requests» установлен в 1. В случае использования множества потоков, параметр «maximum-requests» проверяется только после завершения обработки запроса, поэтому нет гарантии, был ли выполнен только один запрос
10. Теперь интерпретаор инициализируется не в родительском процессе, а только после того, как будет создан дочерний
11. Сообщения из модулей-расширений на C попадают в логи виртуальных хостов, как и положено, а не в общий лог, как было ранее
12. Теперь невозможно писать сообщения в логи «чужих» виртуальных хостов
13. В режиме демона может производиться внутренняя переадресация с использоваением заголовка «Location» в ответе
14. В режиме демона может использоваться директива «WSGIErrorOverride», для того, чтобы возвращать стандартные страница ошибок Apache
15. Добавлена директива «WSGIPythonWarnings» работающая по аналогии с директивой «-W» интерпретатора
16. В директиву «WSGIDaemonProcess» добавлена опция «cpu-time-limit» определяющая количество процессорного времени, после которого процесс будет перезапущен
17. В директиву «WSGIDaemonProcess» добавлена опция «cpu-priority» говорящая за себя
18. Добавлена директива «WSGIHandlerScript» позволяющая определить скрипт, обрабатывающий определённый тип файлов

И ещё множество исправлений и улучшений, о которых можно почитать в оригинале тут: code.google.com/p/modwsgi/wiki/ChangesInVersion0301

Скачать, как обычно можно тут:
code.google.com/p/modwsgi/downloads/list

UPD:
Да, всё работает
./configure --with-python=python3.1 --disable-framework
make && sudo make install