星期日, 7月 25, 2010

[Python] Patterns in Python


Design Pattern那本四人幫的經典是1995年出版的 居然已經歷經15年了 實在是太可怕了..... 雖然Design Pattern並非銀彈 也極容易被濫用 但是還是一個很重要的思維的參考與轉變.....

在不同的語言下 會有不同的Pattern的實作 甚至根本不需要 因為語言本身就直接解決..... 像是Observer Pattern....在C#直接可以用delegate/event解決....

雖然都了解Pattern大概的concept 但是每當換一個語言 要implement的時候還是傻眼...... 不知從何開始... 最近在寫Python.. 在網路上找到這一篇倒是挺有趣的...... Patterns in Python

大概讀完了文章 就來作個紀錄 還有英翻中 + 複習Patterns吧...

# Factory Pattern
主要的精神 把Create objects獨立出來單一窗口 回傳一個符合基本interface的object.... 單一窗口內要怎麼create不同的objects 可以一直改變....

這在任何語言實作都很簡單... 但是在Python中 文章提及很有趣的觀點是 「Python」可以把Factory Pattern的精神 做在Module level.... 以下面為example

import random  def listOfRandom(n):         return [random.random() for i in range(n)]
random這個module可以隨時被抽換....
呵~ 我倒還沒真的想過這樣使用


# Singleton
這是最易懂卻難實作的Pattern了
在Python的話 直接貼上文上的範例 就不多作解釋了

class Singleton(object):         _instance = None         def __new__(cls, *args, **kwargs):             if not cls._instance:                 cls._instance = super(Singleton, cls).__new__(                                    cls, *args, **kwargs)             return cls._instance

# Flyweight
Flyweight主要的精神在於reused很多數量 或是 heavy的物件 所以用一個很多小的proxy 指向共用的物件,而這些物件存在pool裡......

實作如下 值得一提的是它用的是Weak Reference....
其實不用也沒關係 就是always Pool那份不會被清掉 用Weak Reference的用意我想在於long term來說 比較節省記憶體 因為Pool Dictionary那份 如果沒有被用到 可以確保long term應該會被garbage collection掉..... 因為是用weak reference的關係

class Instrument(object):     _InstrumentPool = weakref.
WeakValueDictionary() def __new__(cls, name): '''Instrument(name) Create a new instrument object, or return an existing one''' obj = Instrument._InstrumentPool.get(name, None) if not obj: print "new",name obj = object.__new__(cls) Instrument._InstrumentPool[name] = obj return obj def __init__(self, name): '''Complete object construction''' self.name = name print "New instrument @%04x, %s" % (id(self), name) # ... connect instrument to datasource ...

# Observer

這個實作有點長 我就不貼了 直接refer 文章
主要是實作Delegate跟Event....
我之前也有找了很多Delegate/Event的實作體
剛剛稍稍研究了一下 好像這篇考慮的比較全面一點....


# Iterator & Generators

Iterator的概念很好懂..... 實作也很單純 因為Python已經有內建這個概念 直接實作就好了.....

Generator其實我是第一次看到 也沒有特別看的太懂....不過可以refer另一篇文章(中文)..... 看完就看似比較懂一點....

英文文章是說....如果使用iterator 實作上被迫得放棄recursive way的直覺方法..... 像example他就是用stack/pop/push的方法實作 但是用generators 有一個"yield"的特別方法 可以在實作上變的直覺又容易....


# Command Dispatch Pattern

四人幫的Patterns沒有這個Patterns....不過文中說很多python libraries都用了這個十分elegant的方法..... 唔...... 是還蠻方便的,只是我沒有特別感受到妙用 (通常會這麼講 以我的經驗就是沒有全懂 或是 這部分經驗還不夠.....:p)
class Dispatcher:      def do_get(self): ...      def do_put(self): ...      def error(self): ...      def dispatch(self, command):         mname = 'do_' + command         if hasattr(self, mname):             method = getattr(self, mname)             method()         else:             self.error()

好啦~~ 複習結束..........
本來只是要作個筆記 結果說了一堆.......歲月真是不饒人,很多東西真的很容易忘掉,像是簡單的Weak Reference...我剛剛還特別想了一下,這倒底是什麼東西,明明一年前大量使用,卻還是忘掉....... Orz

說好聽是見山不是山.......說難聽是歲月不饒人....



星期五, 6月 25, 2010

[Django] Django Web Framework Introduction


88頁 十分言簡意該的投影片.....

不過對於完全沒學過的人而言 可能不是那麼好懂

有點知道的話 可以pick-up 十分快

有幾個slides 我也才學會一些基本的語法

還蠻值得參考 可以掃過一遍複習一下....

The Django Web Application Framework

星期四, 6月 24, 2010

[Python] Debugging Python by PDB


最近寫Python寫到快瘋了..... 被Visual Studio寵壞的我

其實十分不習慣Eclipse....用vi也是不是很順

Debugging更痛苦........ 所以下定決定好好研究一下python debugging 的技巧.........

以下這一篇大概是比較step by step很好簡易的介紹...

the Python debugger � Python Conquers The Universe

[Summary]

1.

在code任何地方 可以下中斷點 by inserting the line below
pdb.set_trace # 但記得要import pdb

2. 然後就可以直接執行程式了 python your_program.py

3. 就會進入 (Pdb) 這時候就可以開始用console來debugging了

重點的指令如下

n : next statement

[ENTER] : repeat last debugging command

q: quit the debugging

p : print..... (example: p a,b,c)

c : continue

l : list the current line of program

s : step into subroutines

r : return the current subroutines

![command python scripts] : execute some python scripts (example: !b = 'BBB')









星期四, 6月 17, 2010

[Python] Python Profilers in Default

26.4. The Python Profilers — Python v2.6.5 documentation

python Default附三套
1. cProfile

2. Profile

3. Hotspot

簡而言之, 選cProfile就對了.... 又快又新又完整.....

based on cProfile 開始Survey Django相關的Profiler by using cProfile

可以找到的是

Django Middleware using cProfile --> Django snippets: Profiling middleware using cProfile

Profiling each request at Apache/MOD_WSGI level: ProfilingDjango: profiler-cprofile.py - Django - Trac


不過稍微google一下才發現....cProfile的資源比較少,hotspot的比較多一點

所以可能要refer 到這篇Profiling Django (based on Hotspot).

這篇可以做function level的profining (用decorator的方式),middleware level或是整個server level的 (MOD_PYTHON)


另外django-profiling 還有django-logging似乎都已經不再maintain了 所以指向的library與是 django debug toolbar

看起來django debug toolbar support features set是蠻吸引人的 等我試用完 再跟大家報告心得吧... 不過這裡有一篇看起來很棒的簡介.....

  • Detailed SQL queries
  • Request timer
  • Common HTTP headers
  • Cache statistics
  • HTTP variables
  • Settings variables
  • Profile module
  • Templates rendered
  • Logging message output


[Django] Middle Concept and Introduction

Django | Middleware | Django documentation

這篇在講解Django的Middleware的細節..... 終於有空開始看這些東西了 讀完之後 Summary如下.....

[Summary]

主要是Middleware會overwrite 幾個重要的funcitons...


1. process_request(self, request)

每一個http request都會進來, 還沒分派到view之前......... 是top-down的order來呼叫 (即第一個到最後一個)

可以選擇return None or return HttpResponse

如果是return None --> 繼續call 下一個middleware

如果return Reponse --> 停止call下一個......

2. process_view(self, request, view_func, view_args, view_kwargs)

分派好view之後,馬上call這個function........也是top-down order

可以選擇return None or return HttpResponse (同上 process_request, i.e. 不會續call if return Response)

3. process_response(self, request, response)

已經有HTTP Response......注意,這裡是bottom-up order

must return HttpResponse (alter or create new one)

Always會call下一個middleware....可以所以預期所有的middleware都會被call到這個function

4. process_exception(self, request, exception)

Process requets的時候在view throw exception......注意,這裡是bottom-up order

可以選擇return None or return HttpResponse (同上 process_request, i.e. 不會續call if return Response)


基於以上的論點 參考下圖可以馬上了解整個流程


Middleware application order.


--> __init__ of middleware

__init__不可以有參數,而且只會被call 一次 after web server starts up.

--> Runtime switch Django Middleware

可以在Middlewared的__init__ method raise django.core.exceptions.MiddlewareNotUsed exception
不過要restart web server.

這點我可以用到可以runtime configure setting, such as 開啟一個ProfilerMiddler, ...etc
在Web 界面可以更改到/etc/django.settings 然後再restart apache or web server
然後就可以configure 成另一個mode without code modification.

(雖然也可以直接改 django_project.settings.... 不過的確比較麻煩一點點....呵)


--> Django Default Support 的Middleware List

像是Cache middleware, GZIP middleware, Conditional GET middleware, Locale middleware, Message middleware, Session middleware, Authentication middleware, CSRF protection middleware, Transaction middlware.



星期二, 6月 15, 2010

[Django] Django Deployment with Fabric

Django Deployment with Fabric

在Clouding的Deployment我覺得是一個蠻複雜的事情

於是我也玩過一下Fabric 也希望最終於的deployement能全靠Fabric解決....

這一篇Slide 有點相見恨晚 因為很多東西我已經走過一遭 不過看完之後 也能印證很多想法大家看法一致 .....

這也是很好的一個Fabric的Introduction..... :D

[update 6/18]

在網路上有找到一篇 跟我類似想法的人 也做了跟fabric有關的deployement 可參考


[Django] Very Good Introduction to Django

Python & Django: Fast and easy web application development

這一篇雖然十分短 但是把Django最重要的架構跟精神在幾個slide揭露無遺...

MTV的架構用圖表畫出 十分清楚.....

Model --> Model
Template --> View
View --> Controller

對應到我們熟悉的MVC架構...

[Django] Django Con High Performance Django

Django Con High Performance Django

針對Django High Performance提供了許多有用的建議

1. Template Engine可以換更快的 像是換成Jinja

2. 作Caching....object cache and browser cache, using such as Squid, Vamish or Nginx

3. Profiling your code and database queries
Slide裡也有Example的Screenshot可以參考....


[Django] Debugging Django Slide


這個slide (Debugging Django) 大概簡介了怎麼Debuggin Django的一些方法與細節

十分有參考價值...

Summary 如下

基本的就直接用Python的logging 可以logging to console, file, ..etc

db-error-log: 這個module可以幫忙把exception記錄在database裡

ProfilerMiddleware: 可以作Profiling 直接在Browser上打Url 可以看到Profiling與hotspot的結果

DebuggerFooter: add a SQL footer into every HTML files




重新開始.....

歷經兩年 決定再開始寫blog.....作一些技術上的記錄...

之後Survey的方向會有很大的出入.....

再之前都是集中在WPF/Silverlight 微軟的.net framework

接下來就是Clouding/Web Services方面的技術了....

星期日, 9月 21, 2008

[WPF] .net 3.5 SP1 feature - Splash Screen Support


WPF的Startup一直為人所垢病

在3.5 SP1的版本中 有做了一個很特別的Feature 可以十分容易在WPF Project隨便放一張圖變成Splash Screen

有效降低Users對Long Cold Startup Time的痛苦.... 至少... 他們知道程式還在run...

細節可以看這一篇

WPF Performance : What’s new in WPF 3.5 SP1: Splash Screen to improve perceived startup perf

[WPF] Cross Threading Binding Support of ObservableCollection



這幾天又重新在思考ObservableCollection的設計與用法

雖然Notifiy的機制已經十分方便 但是還是有效率上的考量

尤其是大量的CollectionChanged 會讓UI不是十分順....

所以在思考怎麼改善.... 其實最簡單的想法 就是開一個Thread來做

但其實是沒辦法的 因為Binding到的UI Object通常都有Thread Affinity (簡言之 就是只認自己的Thread可以用)

找到一篇解決了這個問題...........

WPF Data Binding ObservableCollection (cross thread binding support) « C# Live

星期五, 6月 13, 2008

[C#] Using Extension Methods in .net framework 2.0



在.net framework 2.0 or 3.0 沒辦法Compile Extension Method怎麼辦?

很簡單 在幾行code就可以了

namespace System.Runtime.CompilerServices
{
public class ExtensionAttribute : Attribute { }
}

方法是從下面的blog來的


The Moth: Using Extension methods in Fx 2.0 projects