Вступление

Здравствуйте, уважаемые читатели! Для многих джанго-разработчиков не секрет, что с версии 1.3+ вместо используемых раннее generic views нам необходимо начинать использовать class based views. А с 1.4+ версии generic views вообще могут стать deprecated. Информация про class based views (далее CBV) в интернете довольно скупа (а в рунете и подавно). Нет, конечно есть превосходные статьи, в том числе тут на хабре. Одна из статей была опубликована буквально на днях. Но я отношусь к той категории людей, что привыкли все изучать на практике и данный топик написан для таких же людей.
В качестве практического задания мной был выбран классический вариант — создание блога. Для того, чтобы использовать возможности CBV по максимуму мы немного усложним задачу. Пусть это будет не просто блог, а блог, с возможностью публиковать приватные статьи, недоступные неавторизованным пользователям.
Дальнейшие рассуждения подразумевают, что читатель ознакомлен с фреймворком Django и имеет навыки в создании проектов.

Как-то раз возникла необходимость написать транслитерацию на Python — из кириллицы в латиницу. Из слова «ситх» получается «sith», а из «шелест» выходит «shelest».

Казалось бы, чего тут вообще писать — задача едва сложнее print "Hello world". И это отчасти так — но не совсем.

Дело в том, что некоторые буквы в русском языке при транслитерации преобразуются не в одну, а сразу несколько латинских букв: это Ж, Ц, Ч, Ш, Щ, Ю и Я. По сути, если бы правилами транслитерации предполагалось преобразовывать их в одну латинскую букву, то транслитерация русского в английский действительно была бы не намного сложнее той самой простейшей программы.

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

К примеру, фраза «ШАПКА и Юля» преобразуется в «SHAPKA и YUlya», либо в «ShAPKA и Yulya» — в зависимости от того, что задано в таблице транслитерации для «Ш» и «Ю» (иногда задаётся «SH» и «YU», а иногда «Sh» и «Yu»).

То есть регистр следующей буквы в стандартных функциях транслитерации не учитывается, и все буквы в верхнем регистре заменяются по общим правилам. Поэтому в ходе транслитерации для слов «ЧАША» и «Щи» легко получается что-то вроде «ChAShA» или «SCHi», когда реально мы скорее хотели получить «CHASHA» и «Schi».

Тем не менее, все найденные реализации транслитерации из кириллицы в латиницу на Python, как выяснилось, эту особенность не учитывали. Это и многочисленные решения, приведённые на форумах, и библиотека pytils, реализующая транслитерацию в одном из своих модулей.

Значит, напишем свою функцию транслитерации, с блэкджеком и^W^W^W^H^H. :)

В Django версии 1.3 были представлены class-based views — способ описания view в виде классов. Документация, однако, касается только generic views, не описывая общую технику написания «вьюх» в виде классов. Начав использовать generic views и затем пытаясь изменить их поведение, я постепенно дошел до того момента, когда мне пришлось смотреть исходный код, чтобы понять, как что-то сделать. Поэтому я решил написать этот текст. Цель его — объяснить, как использовать class-based view и чем это может быть полезно.

Всё чаще стал себя ловить на мысли, что нам в питонячей вселенной не хватает классического сервера приложений.

От него хочется совершенно банальных вещей:

• Менеджмента конфигураций
• Абстракции над хранением данных
• Возможности легкого добавления точек входа и компонентов
• Инфраструктуры для отложенного выполнения задач
• Каких-то батареек типа библиотеки с хелперами
• Простой интеграции с другими системами
• Предсказуемых внутренних процессов и возможности на них влиять (явная и контролируемая инициализация например)

Самое интересное, что почти всё это есть как отдельные компонеты, но нет среды которая могла бы их объединить или предложить своё комплексное решение. При этом, конечно, этот сервер должен быть достаточно легким и не давить своим весом на пугливые умы опытных разработчиков.

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

Кажется, что отсутствие такого сервера приложений не продлится вечно и через какое-то время появится новый интересный игрок в этой нише. И как всегда, приходится бить себя по рукам, чтобы не ввязаться в его написание «на следующих выходных»:-)

Цель статьи рассказать о своем поиске «идеального» редактора для python кода, о том почему выбрал emacs и кратко о том как я его (emacs) настроил для работы с python.

Небольшая предистория: Разработкой на python я занимаюсь уже более двух лет и все это время пытался подобрать оптимальный редактор. Что я только не использовал за это время — mcedit, nano, gedit, netbeans, eclipse, а также некоторые другие платные варианты (демо версии). Но всегда чего то нехватало, где то автокомплита, где то подсветки, где то банально неудобно. Какой то период (около 10 месяцев) использовал Eclipse, но его прожорливость в ресурсах, зависания доводили до белого каления. Когда ошибки eclipse мне окончательно надоели, я начал поиски такого редактора который стал бы отличным помошником в работе.
Вооружившись google начал искать «идеальный» редактор.

Так уж случилось, что я оказался ассистентом у профессора в университете. Никогда не думал, что прийдётся сталкиваться с оценкой рисков и визуализацией данных, будучи, по призванию, криптографом. Курс называется «Информационные сети» и включает в себя: анализ случайных процессов, моделирование малых миров; компьютерные алгоритмы для оценки свойств сети; экспериментальные исследования крупных сетей, а также анализ рисков, которые трудно предсказать.

В виду того, что курс читается в основном для ИТ-шников, лектор сделал ставку на то, чтобы дать достаточно теории с минимумом математики и большим количеством практики. Для большинства вышеупомянутых задач подходит программа NetLogo. Она включает собственный язык программирования высокого уровня, который позволяет с лёгкостью моделировать различные случайные процессы. Для визуализации разнообразных данных была выбрана программа Gephi.

На основе опыта использования последней и была написана статья, в которой рассматривается получение входных данных для ПО с последующей их визуализацией.

Собственно постановка задачи была таковой: визуализация каких-либо реальных данных средствами Gephi.

Введение

Странно, но поискав на Хабре упоминания текстового редактора Sublime Text 2 я почти ничего не нашел. Спешу исправить положение и рассказать хабраюзерам об этом прекрасном инструменте. Вначале очень коротко расскажу о том чем же он так хорош, потом напишем простой но полезный плагин.

Сам я не очень люблю заголовки вроде «Покемоны в собственном соку для чайников\кастрюль\сковородок», но это кажется именно тот случай — говорить будем о базовых вещах, работа с которыми довольно часто приводить к купе набитых шишек и уйме потерянного времени вокруг вопроса — «Почему же оно не работает?». Если вы до сих пор боитесь и\или не понимаете Юникода — прошу под кат.

Facrtory-boy — это такая замена fixtures в django, которая позволяет более гибко и удобно генерировать данные для тестов с использование различных стратегий. Можно возвращать либо сохраненные модели, либо просто модели, пока еще не сохраненные, либо просто словарь атрибутов модели, связывать фабрики между собой. Раздолье для творчества. А написана она была Mark Sandstrom и сейчас активно развивается Raphaël Barrois. Идея была позаимствована из аналогичной библиотеки factory-girl для руби.

Некоторое время назад озадачился поиском способа развертывания проектов Django, к которому предъявлялись два требования:

1. Удобное управление запуском/остановкой/перезапуском нескольких проектов на одном хосте
2. Поддержка разных виртуальных сред для разных проектов

По второму пункту мой выбор склонился в пользу Nginx + uWSGI. По первому же, из рассмотренных мною вариантов больше всего понравились обвязки для uWSGI в Debian.

Когда мы подготавливали для Хабра свою последнюю статью о Django-батарейках, выяснилось, что про django-sphinx мы таки имеем что рассказать и наш рассказ тянет на отдельный пост. Собственно, вот он, как и обещали.

На сегодняшний день, существует несколько хороших решений для организации поиска в Django. Несколько — это два: Haystack и django-sphinx. Haystack работает с бэкендами-движками solr, whoosh и хapian и, увы, не работает со Sphinx`ом по каким-то абстрактным лицензионным причинам. django-sphinx же, как можно догадаться, работает со Sphinx`ом и только. Haystack это качественный, хорошо документированный и активно развиваемый продукт и мы, вне всяких сомнений, использовали бы именно его, если бы он хоть в какой-нибудь форме поддерживал Sphinx. Но этого, увы, пока не произошло. А Sphinx — наше всё, благодаря его скорости, гибкости и, что очень важно в наших географических широтах, способности учитывать особенности русской морфологии, чего не скажешь о его ближайших конкурентах. «Большие, но по 5… или маленькие, но по 3?» ©

Как организовать пул потоков? Допустим у меня есть 100 данных (пусть они находятся в каком-либо списке) и все их нужно переработать в 10 потоков. Стартуем 10 потоков, в каждый передаем по 1 данному, следим за потоками, как только один отработал, стартуем новый и так пока не кончатся данные… В общем, это не то, чтобы бред, но есть способ поудобней.

За всё время работы скрипта, стартует только 10 потоков, просто каждый из них, отработав со своим 1 данным, не дохнет, а берет из списка следующее 1 данное и делает с ним эту же работу:

# -*- coding: utf-8 -*-
import threading, Queue, time
import traceback

class Worker(threading.Thread):
    def __init__(self,queue):
        threading.Thread.__init__(self)
        self.__queue = queue

    def run(self):
        while True:

            try: item = self.__queue.get_nowait() # ждём данные
            except Queue.Empty: break # данные закончились, прекращаем работу

            try: self.work(item) # работа
            except Exception: traceback.print_exc()

            time.sleep(0.5)
            self.__queue.task_done() # задача завершена
        return
    def work(self,item):
        print item
        #pass

def main():
    # Выводим в 5 потоков цифры от 1 до 100.
    queue = Queue.Queue()
    num_threads = 5 # 5 потоков

    for x in xrange(100):
        queue.put(x) # заносим данные в очередь
    for i in xrange(num_threads):
        t = Worker(queue) # создаем поток
        t.start() # стартуем
        time.sleep(0.1) # чтобы в консоли друг на друга не накладывались

    queue.join() #блокируем выполнение программы, пока не будут израсходованы данные.

    print "Done!"
if __name__ == '__main__':
    main()

И, в общем, хотелось бы еще, чтобы можно всё это в любой момент можно было бы остановить. Но поскольку мы выполнение программы блокируем с помощью queue.join(), то скрипт наши Ctr+C банально «не услышит». Я начал искать, что делать в таком случае, нашел вот такое решение, но у меня оно работало абы как. А потом, поразмыслив, я сам придумал решение, которое оказалось ужасно простым.

# -*- coding: utf-8 -*-
import threading, Queue, time
import traceback

class Worker(threading.Thread):
    def __init__(self,queue):
        threading.Thread.__init__(self)
        self.__queue = queue

        self.kill_received = False # флаг прекращения работы
    def run(self):
        while not self.kill_received:

            try: item = self.__queue.get_nowait() # ждём данные
            except Queue.Empty: break

            try: self.work(item)
            except Exception: traceback.print_exc()

            time.sleep(0.5)
            self.__queue.task_done() # задача завершена
            self.__queue.put(item) # зациклим
        return
    def work(self,item):
        print item

def main():
    queue = Queue.Queue()
    num_threads = 5 # 5 потоков

    threads = []
    for x in xrange(100):
        queue.put(x) # заносим данные в очередь
    for i in xrange(num_threads):
        t = Worker(queue) # создаем нить
        threads.append(t)
        t.start() # стартуем
        time.sleep(0.1)

    #Пока в "живых" не останется только главный поток, ждем.
    while threading.activeCount()>1:
        try:
            time.sleep(1)
        except KeyboardInterrupt:
            print "Ctrl-c received! Sending kill to threads..."
            for t in threads:
                t.kill_received = True # даем сигнал о завершении всем потокам
    print "Done!"
if __name__ == '__main__':
    main()

Продолжаем делиться своим опытом использования полезных батареек для Django. Первая часть
Ещё рекомендуем «Сумбурные заметки про python и django» и «Django проект PR Hero: что внутри и полученный опыт».

Для Django написано огромное количество пакетов. Из них мы выбрали 10, которые использовали сами в своих последних проектах и которыми остались довольны. Все они есть на PyPI. Они продокументированы и покрыты тестами, где-то больше, где-то меньше. Исключение составляет django-sphinx, о котором отдельно.

Введение

Примерно полтора года назад я стал счастливым обладателем HP Mini 110-3155sr. Машинка всем порадовала, но была одна проблема, которая со временем надоедала все больше — отсутствие кнопок Home, End, PgUp, PgDown. О том, как я решил эту проблему при помощи небольшой программки на Python — под катом.