Недавно расквитался в первом приближении с давно висящей и давящую на голову задачкой: опубликовал исходный код всех Джанго-приложений, которые поддерживают разные части SoftwareManiacs.Org. И меня посетила мысль поделиться тем, как оно вообще у меня тут все живет.
Сайт SoftwareManiacs.Org работает на VPS-сервере (у компании TekTonic) и представляет собой сборную солянку из технологий:
- блог — вполне себе стандартный WordPress с парой плагинов и собственной темой, которую я меняю раз в год в начале мая
- форум, каталог программ, статистика и about — мои собственные программы, написанные на Django
- еще wiki (DokuWiki) и багтракинг (самописный), которые используются исключительно для личных целей
Меня периодически спрашивали, как это все интегрировано. Очень просто — на уровне конфига веб-сервера (lighttpd), который раздает задачки трем бэкендам:
- FastCGI-сервер со всем Джанго-кодом
- PHP через FastCGI для всего PHP-кода (wiki и блог)
- FastCGI-сервер для багтракинга
На самом деле, меня этот зоопарк не радует. Во-первых, лишнюю память кушает, а во-вторых, заставляет хранить одинаковые части шаблонов для блога и джанго-части в двух местах. В связи с этим, я наверное буду это все лениво упрощать: передвину багтракинг и блог под Джанго в каком-нибудь будущем. Впрочем, все это не особенно тяготит и сейчас.
Открытие исходников
Идея выложить свои приложения у меня созрела давно, и причина этому очень простая: вдруг кому что полезно будет. Тем не менее, не все они, что называется, "коммерческого" качества. К таким я с чистой совестью могу отнести только Cicero и Vooid, которые можно брать и устанавливать. Два других — Soft и SaneStat — это скорее код, в который можно просто полюбопытствовать.
Все исходники выложены просто в виде ссылок на Bazaar-бранчи, без всяких красивых интерфейсов и без всякой сопроводительной инфраструктуры типа публичного багтракинга и wiki. Сделано так намеренно. Дело в том, что равносильно желанию поделиться, у меня существует осознание, что я не смогу находить время, чтобы поддерживать все эти вещи как нормальные открытые проекты. Иначе бы просто выложил все на Google Code, где уже все это есть. А пока, я буду рад всяким советам, сообщениям о багах и патчам, но надеюсь, что их количество не сведет меня с ума :-)
Soft
Выкладывание программок собственного сочинения было первым назначением моего сайта. В те времена (2000 год где-то) у него еще не было собственного домена (хотя адрес http://www.mtu-net.ru/maniac/ до сих пор правильно редиректит!), и весь сайт, как наверное у многих, представлял собой набор статичных HTML-файлов. Довольно быстро это стало очень неудобно поддерживать по очевидным причинам. Но я мучился до 2005 года :-). И только тогда, когда я "заболел" Джангой, я сподобился сделать софтинку, которая бы позволяла выкладывать программы и обновления к ним автоматизированным способом.
Надо сказать, что вообще вся история развития этого сайта — это попытка избавить себя от лишней работ, которую я придумываю себе на голову всякими бессонными ночами :-). Это видно даже по оформлению, в котором с каждым годом становится все меньше элементов.
В итоге "soft" — это достаточно узконаправленная программа, в которой, тем не менее, есть кое-что интересное для внешнего наблюдателя.
Реализовано достаточно элегантное решение мультиязычного контента. В итоге, сейчас у меня есть программы на двух языках (highlight.js, TagsField, mysql_replicated), у которых переведено все вплоть до новостей. Все это достаточно удобно рулится из админки.
Есть зачатки кастомизации шаблонов для отдельных приложений, благодаря чему у того же хайлайтера есть кастомная страница загрузки, которая, кстати, сама по себе является отдельным Джанго-приложением, отвечающим за формирование списка языков и запаковывание zip'ов для скачивания.
Следующее, что мне очень хочется туда привернуть — это выкладывания новых версий программ. Сейчас мне приходится руками ходить на сервер, чекаутить последние версии из репозиториев, упаковывать архивы и раскладывать все в нужные места. Хочется это все делать в рамках джанговской админки, просто создавая новый объект "Релиз", который будет делать все сам через шеллный скрипт, привязанный к каждой конкретной программе.
SaneStat
Эта штука началась с простого питоньего скрипта, который парсил апачевский лог в поисках рефереров, которые на меня ссылаются. Этот же скрипт простыми print'ами выводил и HTML, когда вызывался по CGI. Это, опять-таки, было медленно и неудобно, поэтому было переведено под Джанго. Как и у любого парсера логов, у него есть две части — собственно парсер, который оформлен в виде команды для manage.py, вызывающейся из крона, и набора вьюшек, которые передают в шаблоны результаты этого парсинга.
Сборщик статистики интересен тем, что в нем собран за несколько лет большой набор регулярок, определяющий "неинтересные" рефереры, спам-рефереры, а также семейства браузеров. Все это, кстати, выложено в виде отдельного архива в формате джанговской fixture.
Но вообще, я этой софтиной вечно недоволен :-(. С самого рождения она недостаточно удобна, а тратить время на улучшение хочется меньше, чем с остальными программами. Как-то никак я с ней дзена не достигну... Иногда хочется вообще от нее отказаться и повесить какой-нибудь стандартный js-счетчик.
Все остальное
Все остальное в джанго-части сайта реализовано стандартными джанговскими приложениями: admin, flatpages, redirects. Я слышал мнение, что джановский контриб бесполезен для чего-то реального, но могу это авторитетно опровергнуть. Его вполне можно использовать, надо только знать ограничения и не хотеть слишком многого.
Админка используется у меня по прямому назначению: редактирование программ, добавление рефереров в базу статистики, редактирование about'а и т.д. Практически не кастомизирована. Самый сложный экран — это пожалуй редактирование программы с кучей inline'утых линков и переводов:
На flatpages реализуется все, что либо статично по сути, либо еще не стало повторяться настолько часто, чтобы хотелось написать под это код. Яркий пример первого случая — about. Просто flatpage с кастомным шаблоном. Пример второго случая — описание создания языков для highlight.js. Пока такой документ единственный в своем роде. Если вдруг другие программы начнут обзаводиться похожими вещами, допишу для этого немножко когда в приложение soft. Так и живем :-).
Расположение проекта
На сервере все это у меня лежит, как и положено по best practices джанго-проектов. Проект — отдельная папка с настройками, конфигами, шаблонами и локализацией. Приложения — в совершенно другой отвлеченной папке. Что как раз и позволяет выложить приложения в мир, потому что они не привязаны жестко к сайту. В итоге INSTALLED_APPS
в настройках выглядит довольно длинно:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
'django.contrib.admindocs',
'django.contrib.flatpages',
'django.contrib.redirects',
'common',
'soft',
'hljs_download',
'vooid',
'sanestat',
'cicero',
'cicero_punbb_import',
)
И все это нужно :-).
Вот такой обзорчик вышел. Сильно подробней я писать не стал, потому что непонятно, что из этого вообще интересно. Поэтому, если что-то хочется узнать подробней — спрашивайте в комментариях, с удовольствием поделюсь.
Комментарии: 11
Оговорочка:
Ссылку на hljs-post забыли =)
Все поправил, спасибо.
лениво спрошу: чем Google Code лучше Launchpad.net? Учитывая, что у вас bzr.
Что именно у меня, разницы особой не имеет. Если бы оно жило где-то на чужом хостинге, жило бы под тем, что там есть.
А чем лучше — понятия не имею :-). Google Code просто первым в голову пришел.
Не в тему, но с чего посоветуете начать изучать Python ?
Ваша инструкция по работе с bzr — это конечно для совсем незнакомых с этой системой. Однако вы сильно переупростили.
Я хочу порекомендовать хотя бы одну доработку в инструкции:
вместо просто
пусть народ пользует
Все же лучше будет, а?
Я просто не знал, что такая вещь есть. Честно говоря, мне казалось, что merge так должен вести себя по умолчанию. Поправил, спасибо.
Просто вы не указали, что после настоящего merge нужно обязательно делать commit. Я понимаю, что вы пытались упростить как можно сильнее, но... есть нюансы. :-)
merge в bzr так не делает по умолчанию, так по умолчанию работает git. В bzr рекомендуют использовать pull, когда нужно обновлять копию и merge когда нужно объединить две ветки. merge --pull появился как ответ гиту ;-)
Извините, а статистику вы писали или это есть в Джанго?
Статистика самописная (самонедописанная :-) ), исходник есть: http://softwaremaniacs.org/soft/sanestat/