Записи по категории “Познание нового”.

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

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

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

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

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

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

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

Пример:

  1. class B:
  2.  
  3.     def __init__(x, y):
  4.         self.x = x
  5.         self.y = y
  6.  
  7.     def setX(x):
  8.         self.x = x
  9.  
  10.  
  11. class A(B):
  12.     def __init__(x, y, r):
  13.         super(A, self).__init__(x, y)
  14.         self.r = r
  15.  
  16.     def setX(x):
  17.         super(A, self).setX(x + self.r)

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

  1. class B:
  2.  
  3.     def __init__(self, x, y):
  4.         self.x = x
  5.         self.y = y
  6.  
  7.     def setX(self, x):
  8.         self.x = x
  9.  
  10.  
  11. class A(B):
  12.     def __init__(self, x, y, r):
  13.         B.__init__(self, x, y)
  14.         self.r = r
  15.  
  16.     def setX(self, x):
  17.         B.setX(self, x + self.r)

hasattr и __dict__

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

  1. if "value" not in MyClass.__dict__:
  2.     pass

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. class MyModelAdmin(admin.ModelAdmin):
  2.     list_display = (‘title’, ‘latin_title’, ‘recipe’)
  3.     prepopulated_fields = {"url": ("latin_title", )}
  4.    
  5.     form = MyModelAdminForm
  6.        
  7.     def get_form(self, request, obj=None, **kwargs):
  8.         form = super(MyModelAdmin, self).get_form(request, obj=None, **kwargs)
  9.        
  10.         form.base_fields[‘custom’].widget = MyWidget(obj)
  11.         return form
  12.    
  13. admin.site.register(Medicine, MedicineAdmin)

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

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

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

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

1. nginx
2. lighttpd

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

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