Amazon byteflow

Hgshelve

Few days ago there was a lot links on the Internet to gitshelve, which implements persistent versioned storage of objects in the git. I’ve read it description and realized that there are few serious design flaws:

• Can store only strings
• Uses subprocess.PIPE for interconnection with git
• Uses bunch of C+Perl+Shell code in Python library instead of using another Python library ;-)

Итак, 24 мая опять намечается тусовка питонистов! ;-) Что хорошо — у Ивана получилось, как он и обещал, устроить это всё через пару месяцев. А что отлично — что это будут мастерклассы. Три штуки.

Меня лично больше всего интересует Twisted, как наиболее далёкая для меня сейчас из всей троицы вещь. ;) А вот трюки… сделать тут интересный и полезный доклад реально сложно. Ну посмотрим, что получится.

В общем, главное — приходите! Семинар крут не только своими докладами, но и тусовкой после завершения. =)

Из исходника и обсуждения в jabber-конференции pythonua@cjr родился прикольный список соответствия языков программирования стилям музыки.

Джеймс Беннет пару дней назад опубликовал список фич, которые важны для релиза Django 1.0, по причине того, что они очень большие и важные, либо того что они простые, маленькие и порядочно улучшают/облегчают использование в обычных случаях, либо (менее важно) они заметно нарушают обратную совместимость и было бы неплохо их интегрировать заранее.

Сегодня про это пишут все, но я всё равно не могу промолчать. :-)

Ветку разработки queryset-refactoring смержили в транк Django, что означает приход порядочной толпы приятностей. ;-) Мне лично очень нравится возможность посмотреть SQL до выполнения собственно запроса (QuerySet.query.as_sql()), ну и логично работающую фильтрацию по одной и той же таблице, хорошо описанную Иваном. Ну и ещё долгожданное многими наследование моделей.

Отличные новости, в общем! :-)

Сегодня напоролись на смешной прикол. Со внешнего сайта собирается некоторое количество данных и запихивается в базу. Сначала в сырые таблички, а потом обрабатывается и пихается на положенное место вместе с инициализацией кое-какой инфраструктуры. Ну и всё бы неплохо, если бы сбор данных (и запихивание в сыром виде) не происходило за 2 секунды, против 10 секунд (в среднем) на запихивание на нужное место.

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

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

[17:20] Murkt> 
In [22]: len(connection.queries)
Out[22]: 2759

:D

Буквально только-только реализовал в Byteflow одну маленькую (совсем), но очень полезную штуку, подсказанную Катапом: в стандарте Atom’а есть два разных поля, использующихся для указания даты для элемента — published и updated, при этом updated - обязательное.

Раньше в updated просто кидалась дата создания поста или комментария, но сейчас всё по-другому. :) Теперь дата создания поста (которую можно изменить в админке для приведения в более адекватный вид, для создания “поста в будущем”) или комментария идёт в published, а в updated попадает дата, изменяющаяся при каждом изменении объекта. По идее, это должно заставить обновлённый объект появляться во всей своей красоте в рсс-ридерах. :-)

Enjoy! :)

Чисто ради интереса решил привести один маленький забавный факт о размере репозиториев. Есть у нас немаленький проект, при этом чекаут исходников джанговой части из SVN занимает 79 мегов.

При этом этот же проект, переконверченный в меркуриал — рабочая копия и полная её история вместе — занимает 80 мегабайт.

Этот пост будет кратким — благодаря стараниям Олега в Byteflow теперь присутствует сервер OpenID. Клёво. :-)

P.S.А ещё byteflow — второй по тегу django на ohloh.net, после самой джанги. :-)

[UPD от 12 ночи]

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

Но вот не так давно обсуждали его в джаббер-конференции pythonua@c.j.r (кстати, официальная конференция python.com.ua), где появилась идея слегка его проапгрейдить до возможности задавать темплейт из view (когда одна вью может выдавать различные странички). В принципе, идея усложнения декоратора мне не особенно нравится (да и потом, кому надо — может переделать себе, благо несложно), но по размышлении я увидел, что особенного усложнения нету, плюс сохраняется обратная совместимость полностью (что важно, потому как мне есть и где использовать новую фичу, но не очень хочется ломать все вьюхи, использующие старую версию ;).