Публикации о языке Python   страница 295

Быстрое обновление всех клонированных репозиториев

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

Итак, работая с любым Django проектом я использую целую тучу разнообразнейших reusable apps. Установка и добавления любого reusable app'а в свой Django-проект проста и не тривиальна: клонирование репозитория, обновление sys.path, добавление appname в INSTALLED_APPS.

Намного интересней становится, когда приходит время пробежаться по всем склонированным локально репозиториям и проверить наличие обновление в них (сейчас и далее актуально только для тех, кто на передовой). Согласитесь, имея в наличии под 100 svn репозиториев c googlecode, да 20-30 git репозиториев с github'а, а также по паре тройке разнообразных bzr с hg репозиториев, их обновление посредством ручного набора поочередно:

$ svn up /path/to/django
$ cd /path/to/werkezeug && hg fetch
$ cd /path/to/django-debug-toolbar && 



Сохранение времени в базе данных

Очень часто бывает, что практически все знают, как надо делать правильно, но при этом всё равно постоянно делают неправильно. Один из таких случаев — сохрание времени в базе данных. Понятно, что на персональном блоге вполне можно обойтись наивных подходом, не учитывающим перевод времени. Но для круглосуточно работающих приложений строгой системы отчётности вроде биллинга это неприемлемо.
Я не буду здесь рассматривать все возможные варианты корректной работы со временем. Покажу лишь насколько просто можно реализовать самый распространённый вариант — хранение в базе в UTC — на примере SQLAlchemy. Для этого достаточно определить новый тип колонки:
from sqlalchemy import types
from dateutil.tz import tzutc
from datetime import datetime

class UTCDateTime(types.TypeDecorator):

    impl = types.DateTime

    def process_bind_param(self, value, engine):
        if value is not None:
            return value.astimezone(tzutc())

    def process_res



Логгинг в базу или борьба с рекурсией

Как-то понадобилось мне сделать логгинг в базу для модуля logging. Сразу видна очевидная проблема: внутри такого обработчика идёт сохранения в базу некоторыми принятыми в проекте средствами, которые сами используют logging. В результате обработчик рекусивно будет вызывать себя и зацикливаться. Понятно, что можно отбросить привычные средства и сделать либо логгинг своими средствами без использования стандартного пакета logging, либо в базу писать низкоуровневым кодом, который logging не использует. Но это всё не интересно и ведёт за собой неудобства в использовании.
Первая мысль была выставлять флаг в обработчике перед записью в базу и снимать его после. Но это без ухищрений не будет работать в многопоточном приложении, а ведь есть ещё и обработчики сигналов. А нельзя ли определить, что обработчик был вызван из самого себя? Оказывается, можно — с помощью средств работы со стеком интерпретатора в модуле i



cx_Oracle. Работа с полями типа LOB (large object).

Прямая вставка.
При прямой вставке достаточно определить тип переменной:

Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning option
JServer Release 9.2.0.8.0 - Production

SQL> create table test( id number, msgtxt clob);

Таблица создана.

test_clob.py:

import cx_Oracle,sys

tns = 'test/test1@test_bd'
conn=cx_Oracle.connect(tns)
curs = conn.cursor();
curs.setinputsizes(p_msg=cx_Oracle.CLOB)

msgtxt= '*' * 10000

try:
curs.execute('''insert into test values (:p_id,:p_msg)''',p_id=1,p_msg=msgtxt)
conn.commit()
except cx_Oracle.DatabaseError,info:
print "SQL Error:", info
sys.exit(1)



FreeSWITCH+Django

FreeSWITCH предоставляет замечательный механизм - xml_curl. Этот модуль может забирать номерной план, пользователей и даже конфигурацию через http запросы.
Работает весьма просто, например так:


# cat /opt/freeswitch/conf/autoload_configs/xml_curl.conf.xml
<configuration name="xml_curl.conf" description="cURL XML Gateway">
<bindings>
<binding name="fs2web_user_fetcher">
<param name="gateway-url" value="http://localhost:8000/get/user/" bindings="directory">
</binding>
</bindings>
</configuration>


# cat /opt/freeswitch/conf/autoload_configs/modules.conf.xml
...
<load module="mod_xml_curl"/>
...



Теперь FS будет слать тонну информации метод




FreeSWITCH+Django

FreeSWITCH предоставляет замечательный механизм - xml_curl. Этот модуль может забирать номерной план, пользователей и даже конфигурацию через http запросы.
Работает весьма просто, например так:


# cat /opt/freeswitch/conf/autoload_configs/xml_curl.conf.xml
<configuration name="xml_curl.conf" description="cURL XML Gateway">
<bindings>
<binding name="fs2web_user_fetcher">
<param name="gateway-url" value="http://localhost:8000/get/user/" bindings="directory">
</binding>
</bindings>
</configuration>


# cat /opt/freeswitch/conf/autoload_configs/modules.conf.xml
...
<load module="mod_xml_curl"/>
...



Теперь FS будет слать тонну информации метод




вечная проблем GIL

Мало кто знает почему-то, но есть вполне живая и неплохо работающая ветка Python, в которой GIL не существует [>>>]. GIL это общий лок интерпретатора, благодаря которому, или точнее говоря вопреки которому Python вмеру быстр в малтитредных приложениях.




Работа и вакансии для программистов

В связи с участившимися вопросами о поиске программистов и интересных вакансий, решил организовать у себя в блоге отдельный раздел.

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

Чаще всего ищутся разработчики со знанием Python, Ruby и JavaScript. Если вы пишите на PHP, CSS/HTML, хороший управленец, пиарщик или занимаетесь веб-дизайном, также добавьте ваше резюме.

Мои партнер




Django signals по-новому

На пути к 1.0 релизу Django претерпевал немало радикальных изменений. Одно из них рефакторинг системы сигналов.

Если вы первый раз читаете и не в курсе «что это такое и с чем его едят», то скажу в двух словах. Это система реагирования на события приложения. Любой JavaScript или прикладной UI программист хорошо знаком с системой событий (event) — клик мышкой, нажатие горячей клавиши и т.п. Для программистов серверной части веба все выглядит немного по другому. Есть HTTP-запрос и есть его обработчик, анализируется как правило URL на предмет «кому отправлять запрос». Но на самом деле это та же система сигналов-событий, только узкопрофилированная под обработку HTTP-запросов.

Оказывается серверная часть веб-приложения тоже может, и я уверен, просто должна генерировать намного больший спектр сигналов, чем просто обработку URL и данных запроса. С чем успешно и справляется Django. Теперь немного прозы




Django 1.0 was released