Хешик » Познание нового

Основы emacs (внешняя ссылка)

Виталий Волков — Sun, 19 Apr 2009 09:38:21 +0000

После поисков редактора питоновских скриптов я прошустил довольно много, спрашивал, читал, изучал. Мне не нужен был ни Eclipse ни IDEA. Для моего домашнего ноута честно признатся таких монстров вообще не нужно.

В итоге остановился на emacs. Сейчас читаю классную статью, которую, если вы так же как и я решили перейти на emacs, можете прочитать вот

Кстати под Mac OS X есть отличная обертка над emacs Aquamacs

Вызов конструктора родительского класса

Виталий Волков — Sun, 19 Apr 2009 07:35:15 +0000

Христос Воскрес!

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

Пример:

class B:
 
    def __init__(x, y):
        self.x = x
        self.y = y
 
    def setX(x):
        self.x = x
 
 
class A(B):
    def __init__(x, y, r):
        super(A, self).__init__(x, y)
        self.r = r
 
    def setX(x):
        super(A, self).setX(x + self.r)

А теперь посмотрим как было бы правильнее

class B:
 
    def __init__(self, x, y):
        self.x = x
        self.y = y
 
    def setX(self, x):
        self.x = x
 
 
class A(B):
    def __init__(self, x, y, r):
        B.__init__(self, x, y)
        self.r = r
 
    def setX(self, x):
        B.setX(self, x + self.r)

hasattr и dict

Виталий Волков — Wed, 04 Feb 2009 12:51:29 +0000

Заметил что hasattr в коей мере некорректно работает на определение наличия аттрибута в классе, пришлось отказаться от него и использовать такую проверку

if "value" not in MyClass.__dict__:
    pass

Какие минусы этого подхода полностью не знаю, но знаю что может привести в определенных ситуациях к зацикливанию, это в случае если использовать __setattr__ в паре с ним. Может у кого-то другие подходы? Или просвятит на предмет использования __dict__ :-)

Разработка через тестирование глазами новичка

Виталий Волков — Fri, 17 Oct 2008 18:44:24 +0000

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

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

Кстати заметил фишку в разработке тестов в unittest питона. Если в начало теста поставить описание docline то при проходе отобразится не скучный путь до пакета и модуля а полноценное описание теста. К примеру

def testSetRatingTwice(self):
    "Expect raising of exception when user set rating for object twice"
    # functional of the test
    self.assertRaises(….)

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

Очень не нравится пакет pymock, который очень часто вводит меня в ступор своими Inappropriate action или чем то подобным, поэтому стараюсь как можно чаще избегать подобных тестов, а то и вообще не прибегать к mock совсем.

Продолжаю процесс разработки через тестирование.

Django: изменение поля стандартного вида

Виталий Волков — Fri, 05 Sep 2008 15:07:30 +0000

Всем снова привет. Как это ни странно сейчас все мое внимание уделено исключительно разработке приложений основанных на web framework Django. Причиной перехода на django является разработке и ведению нового проекта, который наша компания делает для украинской компании. Надеюсь что мы выиграем с этим проектом.

Но это всего лишь отступление. Важной частью разработки является кастомизация некоторых элементов любого сайта использующих какой-бы то ни было фреймворк. Будь то Smarty, Zend Framework, Symphony. Без разницы, все они предоставляют строгий набор элементов, которые используются в проекте. А что делать если нас не устраивает этот набор и необходимо пополнить его своими причиндалами.

В django 1.0 были сделаны некоторые очень полезные добавления, которых я ждал. Введение save_model метода в ModelAdmin класс избавило от написания менеджеров. Что же дает нам ModelAdmin для кастомизации полей?

Любой вам даст совет рыть исходники Django, и что собственно и было сделано. В ModelAdmin есть метод get_form который вернет экземпляр класса формы которая используется в административном интерфейсе. А что если переопределить эту функцию? Выйдет примерно следующее

class MyModelAdmin(admin.ModelAdmin):
    list_display = (‘title’, ‘latin_title’, ‘recipe’)
    prepopulated_fields = {"url": ("latin_title", )}
    
    form = MyModelAdminForm
        
    def get_form(self, request, obj=None, **kwargs):
        form = super(MyModelAdmin, self).get_form(request, obj=None, **kwargs)
        
        form.base_fields[‘custom’].widget = MyWidget(obj)
        return form
    
admin.site.register(Medicine, MedicineAdmin)

То что доктор прописал, не так ли? Данного подхода в документации я не нашел, зато на сайте http://djangosnippets.org есть отличный пример, который использует подобную технику.

Изменил апачу на lighttpd

Виталий Волков — Fri, 27 Jun 2008 15:49:41 +0000

Я всегда считал, что самый лучший web сервер это apache, я периодически обновлял его, а после определенного момента apache стал подводить. Может потому что я на данный момент работаю на Mac OS X, либо может я стал сам откровенно тупить. Но факт остается фактом, при обновлении PHP связка PHP+Apache перестала работать.

Альтернативные решения:

1. nginx
2. lighttpd

С nginx для меня оказалось все очень сложно, он хорош для продакшн серверов, но не для обыденного разработчика. Поэтому на замену индейцу пришел lighttpd. На Mac OS X он у меня поднялся без проблем.

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