顯示具有 web 標籤的文章。 顯示所有文章
顯示具有 web 標籤的文章。 顯示所有文章

星期四, 12月 11, 2008

[tips] 針對特定model改變django ORM預設delete()行為的方法

Django ORM裡的預設delete行為是去模擬ON DELETE CASCADE, 主要是為了保證資料的一致性, 但是雖然在自帶的admin介面裡會提示是否要刪除其他相關聯的資料, 不過仍然可能會對某些需求帶來一些困擾, 而且到目前為止並沒有一個標準的方法來更改這個機制, 這邊我提供一個簡單的方法將model的ON DELETE CASCADE行為改為RESTRICT, 就是在需要不同機制的model裡去override orm原本的delete行為 :

 
def delete(self):
s = CollectedObjects()
self._collect_sub_objects(s)
if len(s.items()) == 1:
super(self.__class__, self).delete()
else:
pass



這可確保當沒有任何關聯物件時才會刪除, 否則只會安靜的pass,
this hack probably need django 1.0+.

星期一, 10月 29, 2007

[tips] using flup as trac's default fastcgi backend. (with lighttpd)

I've found trac's fastcgi backend simply out-dated. I thinks it's direct copied from an old flup source, and since then flup really updates a lot, I've already use thread pool techniques everywhere in our web applications/frameworks for a while, so current trac's fastcgi backend implement just so out-dated and looks wierd when I installed it, really.

But thanks there's WSGI to save us ! I could just replace the fastcgi backend to flup-0.5 (latest, and author claims it maybe final version of flup) and SAVE MEMORY !

and it's simple too,
just install the flup package, and edit your old trac.fcgi / lighttpd's settings.

trac.fcgi:


try:
import pkg_resources

from trac import __version__ as VERSION
from trac.web.main import dispatch_request

from flup.server.fcgi import WSGIServer
WSGIServer(dispatch_request,maxSpare=100,minSpare=100,maxThreads=100).run()

except SystemExit:
raise
except Exception, e:
print 'Content-Type: text/plain\r\n\r\n',
print 'Oops...'
print
print 'Trac detected an internal error:'
print
print e
print
import traceback
import StringIO
tb = StringIO.StringIO()
traceback.print_exc(file=tb)
print tb.getvalue()


you can change the line which specify
maxSpare,minSpare,maxThreads,I use 100,
you should use less than 381 if you're using
python 2.4 (you'll hit stack limit at least on i386-linux) however if you're using python 2.5 you can change stack size via thread.stack_size,
though I don't think anyone would need that high concurrency (who knows?!).

below's also a sample setting in lighttpd.conf,

what really matters here is to remember add a
"max-procs" => 1
line in it, since we've already using thread pools technique, forking another process seems redundant (and WASTE memory).


fastcgi.server += ("/sandbox" =>
("sandbox" =>
("socket" => "/tmp/trac-sandbox.sock", #need to change for each
"bin-path" => "/var/trac/cgi-bin/trac.fcgi",
"max-procs" => 1, #default 4
"check-local" => "disable",
"bin-environment" =>
("TRAC_ENV" => "/var/trac/sandbox")
)
)
)


oh, btw I'm using trac-0.11dev, but I think any version below 0.11 which implement WSGI should also works.

星期日, 6月 24, 2007

Thread dying problem may fixed in django/flup.

一直都耳聞django的apache+mod_fastcgi+thread mode在高負載狀況下有問題,
甚至也有人將之歸結於python的thread實作有問題,
所以我一直以來都是使用prefork的方式來啟動fastcgi/wsgi,
上禮拜在替django作負載調試的時候,
也發現thread mode在超高壓力測試的情況下,的確會停止運作造成service unavailable
(concurrency > 1000)
因此才花時間找出真正的原因(至少在我這邊的原因),
應該是django所採用(其實不止django, pylons跟turbogears也有採用)
的FastCGI to WSGI adapter -- flup,
在threadpool的實作上有些許的小問題, 沒有對運作異常的thread拋出例外的情形加以處理,
才導致了發生問題的thread沒有再次進入threadpool,所以運作一陣子後會讓所有thread悄悄死去.

在修正了這個問題之後, 即使在concurrency > 1000的情況下仍然保持順暢運作,
也擺脫了使用modpython或prefork mode的fastcgi大量耗用伺服器記憶體的情形,
thread mode + FastCGI/WSGI 果然才是王道!

已提交patch, 期待新版的flup收納之後, 讓python的web framework在thread mode下運作更順利.

星期日, 6月 10, 2007

[link] 有愛連結: 以 New Gameday 數據解析王建民的投球特性

剛剛讀到這篇 Whither所寫的 漫步在綠海豚街上: 以 New Gameday 數據解析王建民的投球特性, 看到這篇文章用心的透過Gameday的XML數據分析王建民的投球. 着實又讓大家見識到所謂的"有愛"是怎麼回事 :D

MLB於2006年裝設了新版的gameday,除了將線上轉播帶進了一個新的時代,在棒球場上更裝設了30fps的高速攝影機以便能及時的分析到投打對決的實況, 然而目前只有九隊安裝高速攝影裝備, 很可惜洋基目前尚未裝設, 所以大大的減少了分析王建民投球數據的資料, 而該文便是在分析王建民於2007/05/16芝加哥白襪隊客場先發時所留下的XML數據. 內文有詳實的內容跟美觀的圖表, 透過科學化的角度分析投球內容 ,非常值得所有洋基/王建民的球迷一讀.

星期四, 5月 31, 2007

Google gears !

今天進 google reader的時候發現右上角多了幾個字: offline

好奇的按下去之後發現 google reader已經引進了
google的離線儲存新技術: google gears.

也就是說安裝之後,
google reader瞬間變成離線也能閱讀的RSS瀏覽器了 !
看來離線的gmail也不遠了...

以技術面來說google gears
以new bsd license放出,是完完全全的自由軟體.
支援Windows/Mac/Linux ,
並且支援IE/Firefox/Safari(未來將會支援,目前在mac上支援firefox)
等於所有主流系統全部支援.

google gears除了離線存取現有的web application之外,
還提供了一個WorkerPool的API幫助programmer將資源吃重的一部份程式以非同步方式存取,
並且還內建輕量級資料庫sqlite 支援使用javascript撰寫sql
(沒錯... 就是像下面這樣
var rs = db.execute('SELECT dish FROM recipe WHERE recipe MATCH ?', ['tomatoes']);
)
之前雖然也有如dojo storage之類的解決方案.但總不如早已習慣的rdbms來的方便. google幹的好啊!

google gears目前雖然仍是beta中,
但解決了web application離線存取這個麻煩的問題,
由於是完完全全的自由軟體(允許商業使用)
在未來有機會成為業界的新標準.

更多詳細的資訊請參考:

http://code.google.com/apis/gears/index.html
http://gears.google.com/

星期六, 5月 05, 2007

[link] 誰說只有wiki可以這樣搞.....orz

pure html+js ... 越來越有趣了 :P

Terminal

Home

Blog

星期二, 5月 01, 2007

[link] Microsoft發表Dynamic Language Runtime (DLR).

我說, 這名字對了!!! ;D

有了Jim Hugunin的加持之後,
Microsoft這次沒有笨到取一個Sxxxxt Language Runtime這種蠢名字,
看來Microsoft這次真的知道他們在作什麼. ;D

來自Jython/Ironpython作者Jim Hugunin的消息, 看來Microsoft吸收了以往對於網路不夠重視的教訓, 這次對於業界的Dynamic Language潮投注了不少心力.

消息節錄重點如下:

"""
We're initially building four languages on top of the DLR - Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today.
"""

所以說DLR 目前已經支持 Python, Javascript,Visual Basic跟Ruby...

!? Python跟Ruby...!?
喔妳沒看錯... Microsoft居然開始注意Python跟Ruby的支援...
這一天終於要來了嗎?...

並且今天釋出的Silverlight 1.1alpha1版已支援python跟Javascript. (Silverlight看起來將會是下一代Microsoft主推的web平台??)

"""
In addition to the Silverlight release, we've also made the full source code for both IronPython and all of the new DLR platform code available on codeplex under the BSD-style Microsoft Permissive License.
"""

BSD-style Microsoft Permissive License !???

BSD style?!沒聽錯吧... 會不會..太opensource了一點? :DD

看來我這文章標題應該改成==> 神奇的Jim Hugunin
,Microsoft的自由軟體跟Python/Dynamic Language推手... XD

雖然我常常沒事虧一下MS,
不過這次還是得替Jim Hugunin跟Microsoft鼓鼓掌...
在MS裡搞自由軟體... 讚啊...

星期二, 4月 24, 2007

[link] Add OpenID consumer support to any Django application

Simon Willison just release first version of django_openidconsumer.

As Simon says:
"""
I plan to keep the package under active development, with the aim of using it to demonstrate best practises in implementing OpenID (hence the support for multiple OpenIDs and simple registration out of the box). Next on the list is integration with Django's built in authentication system, including the ability to associate one or more OpenIDs with an existing user account.
"""

This is so cool if you need any openid support in django. :)

一些 OpenID 的連結:

How to use OpenID

Six cool things you can build with OpenID

The Future of OpenID

Web developer Simon Willison talks to Vitamin about OpenID


What is OpenID good for?

星期六, 4月 14, 2007

[link] django template utilities

James Bennett發佈了django-template-utils

django的template tags的使用跟抉擇一直是個藝術,
有些人嫌他功能過於強大(ex: guido),也有不少朋友覺得他功能過少,
James Bennett開發了一些template tags並整理了不錯的使用文件.有興趣的人可以參考看看.

星期二, 4月 03, 2007

真是個好節日啊~~

http://pythononplanes.com/

"Planes is the most well thought-out snake oil framework I’ve ever sniffed."

這個我一看就知道很明顯的不僅可以減少程式碼,
還可以快速增加生產力10000倍!!! XD

"it lets you write beautiful code by favoring snake oil over gems."

Snake Oil 萬歲! XD

星期日, 4月 01, 2007

Tim Oreilly -- blogger的行為七準則草稿

Tim O'reilly, O'Reilly Media 的Founder,
就在不久之前發表了Call for a Blogger's Code of Conduct
也拋出了這樣的一個早已存在但終於不得不正視的新議題.

事件的導火線在於Kathy Sierra,著名的Head First系列的女作者,
(Head First Java,Head First Design Patterns,Head First Servlets and JSP,Head First EJB)
不久前因在其blog上受到了死亡威脅,
而中止參加一場O'Reilly在San Diego的ETech conference.

有圖有真相: http://headrush.typepad.com/photos/uncategorized/2007/03/26/unclebobpicture.jpg
http://headrush.typepad.com/photos/uncategorized/2007/03/26/unclebobcomments1.png

於是有鑑於此, Tim O'reilly拋出了的新的Blogger行為準則草稿, 略譯之後加上個人的感想如下:
(如果以Web 2.0行銷術語來說, 也就是"Web 2.0時代的新部落客行為準則" XD)

1)Take responsibility not just for your own words, but for the comments you allow on your blog.
不只對在blog上的發表的文章負責, 也要包括blog上的評論.


提姆註: Tim O'reilly對於Chris Locke的'YOYOW -- You Own Your Own Words'的論點提出的對應觀點, 在目前, 有非常多的blogger認同Chris Locke的觀點, 也就是評論者應對自己的評論負起責任, 而網站所有者不應對此負責. Tim O'reilly認為, 這樣的YOYOW的觀點不應無限上綱, 而應該有個最低限度, 就像我們常說的所謂"自由"的前提是在不妨礙他人的情況下.

Tim O'reilly: """Yes, you own your own words. But you also own the tone that you allow on any blog or forum you control."""

2) Label your tolerance level for abusive comments.
在blog上標示對含攻擊性的評論之容忍限度.

提姆註: Tim O'reilly 提到 BlogHer所提出的"不可接受的內容"應該是一個不錯的起點.

3) Consider eliminating anonymous comments.
可考慮停用匿名評論

提姆註: Tim O'reilly認為雖然匿名性仍然在某些地方有必要,
不過在大部分的情況下,Identity會改變人們的行為.

4) Ignore the trolls.
忽略小白

提姆註: 避戰而不畏戰是也, 有不得不戰的理由時再踩小白幾腳,
大部分時間請直接忽略小白. 因為小白是殺不死的 :D

5) Take the conversation offline, and talk directly, or find an intermediary who can do so.
將對話內容離線,直接面對面交談或者找一個和事佬.

提姆註: 這點可以注意看一下Tim O'reilly的說明, Tim的意思是儘量不要就某一議題在blog上隔空對罵.很多事情見了面交談或許會好一點.比如Chris Locke覺得Kathy明明知道圖片不是他發表的,為什麼公開的指責他是網站所有者之類的. 當然, 人如果都能這麼理性的話...那就世界和平了 XD
不過Tim O'reilly的意思是, 如果可以的話, 不論如何多製造私底下交談的機會都會比對罵來的好一點.

6) If you know someone who is behaving badly, tell them so.
如果妳知道誰的舉止不佳, 告知他們.

提姆註: 可能的話, 婉轉一點 :P 我自己覺得比較糟糕的一點是, 這個時代, 大家都怕瘋子. :P 不過Tim O'reilly在這邊主要指的是自己的朋友, 不要畏懼告訴自己的朋友妳覺得他的評論或文章有過於攻擊性的問題, 應持續的溝通.

7) Don't say anything online that you wouldn't say in person.
不要在網路上說任何妳平常不會直接面對面的對人說的話.

Tim O'reilly的Blogger七準則草稿只是一個起點,
(當然, 我認為是一個好的起點)
國外也有相當多正反皆有的評論跟相關討論,
對於複雜的網路生態跟blogger習性,
未來想必有更多思考跟討論的空間.

星期二, 2月 20, 2007

[link] [screencast] 整合Django與PHP

http://showmedo.com/videos/video?name=pythonNapleonePyConTech2&fromSeriesID=54

ShowMeDo上放了有關這次PyCon2007網站架設的講題影片,
看了之後才發現原來PyCon2007的網站是由php的wiki跟django"合力"製作完成的. :)

這個影片示範了這次PyCon2007如何透過Django的Custom Template Loader
整合PHP的wiki pmwiki (恰好是Kalug的Wiki Engine :) )進入Django,

講者還示範了整合他老婆的Wordpress Blog進入Django的過程.

very cool!

星期一, 2月 19, 2007

[link] Satchmo -- 基於Django的電子商務商店架站軟體

應該不少人都有聽過osCommerce這個Opensource的PHP&GPL線上開店架站軟體.

那麼Django有沒有什麼對應方案呢?
答案似乎是有的, Chris Moffitt用BSD版權釋出了基於Django開發的電子商務開店軟體: satchmo

對於這類軟體, 大家總是有疑問, 它穩定嗎, 馬上能用嗎?
基本上這類軟體一定要經過客製化的程序,
而Satchmo還在先期開發中,雖然可用,但不見得符合你的需要.
如果你想要完全不修改就能使用那可能還是花錢買公司的Support比較妥當.
好處是satchmo以BSD版權釋出, 如果你有這類的需求, 多看看別人的程式碼也無妨.

你可以先看看Demo:
Demo站台在此

原作者在Mailing list上也有回答:
"""
1. I think Satchmo is ready with the caveat that it needs to be the
right kind of site. I do not believe any Satchmo sites are live in the
wild. I will say that the "Demo Store" is the current code and does get
a fair amount of activity (i.e. probably more then my real-life store ;)
and so far nothing has gone up in smoke. The features that Satchmo have
work and for me, they are > 90% of the features I need. My wife's store
would have < 50 items, some discounts, authorize.net integration and
possibly some other custom CMS type features. I am confident I could
put Satchmo in and it would work well for me. The only reason I haven't
is that my current site works and I haven't spent the time doing the
HTML/CSS re-design I'd like to do. In some ways, Satchmo already does
more for me than the stock OsCommerce site I'm running now. Of course,
Satchmo does not have the rich amount of modules available like OsCommerce.

I will say that OsCommerce becomes a real nightmare once you start doing
anything more than the stock store. It just feels crufty (partially
because I'm no PHP expert) and I just fear making changes to the store.
I never know how things will break.

I also think Satchmo is stable because it's based on Django. A lot of
the scary stuff around security and having different db support is
handled by the robust Django framework. There's also lots of experience
with how to scale Django that should apply directly to Satchmo.
"""

簡單來說只要有熟Python/Django跟Html/css的人持續修改維護就可以開店了.
大部分用Django開發的軟體,如果了解Django的基本架構就大概知道要怎麼修改而不會爛掉.
(有金主找不到的話, 就到Unofficial Python PlanetKalug灑大錢加上三顧茅廬大概就會有高手跑出來了 XD)

星期六, 2月 17, 2007

google 密技一覽表

http://www.adelaider.com/google/

Adelaider.com 作了兩張A4的google服務,搜尋方法的小抄PDF檔.
裡面列出了一堆google所提供服務的網址, 甚至連google bot的IP都有.

話說小弟我也是看了這張表, 才知道原來Google連來電五十的服務都有... XD
http://www.google.com/romance


User A: 「Finally I've found my Soulmate! Thanks, Google Romance!」


User B: "I never thought
I'd be writing an online dating testimonial.
Until I met User A…」

這台詞未免也太.....

星期二, 2月 13, 2007

[圖解][特別報導] 日本女高中生用機器語言開發AJAX網站





日本人果然很惡搞 :P

ps: 被標題騙的人請舉手 :P

星期六, 2月 10, 2007

uselessaccount.com 真是太耍寶了




http://uselessaccount.com/

Today's web is crazy. Open ID is a pipe dream. Every direction you turn you're forced to create yet another account. Most of the time it's for one of those throw-away web startups created 10 times a day, but occasionaly it's worth the effort. It might be to purchase some fancy threads, order a pizza or see how fat the Cool Kids from high school have become. When it's that important, you can't afford to drop the ball. With a useless account you can practice without fear. So when it comes to the crunch, you're ready! Sign up now!


非常具有幽默感的網站...

這真是一股清流啊~~ 哈哈~~

OpenID supports by Microsoft !?

http://slashdot.org/yro/07/02/06/2152214.shtml

http://brad.livejournal.com/2287909.html

沒想到連Microsoft也要支持OpenID了,
(雖然凡是說到Microsoft要支援什麼標準都有點可怕 :P)

slashdot雖然一向以戰文+情緒性文章著稱,
但是好的評論確實也不少:

by Bogtha (906264) on Tuesday February 06, @07:50PM (#17914750)

>>> Going back to OpenID, all I need to do is supply my own authentication
>>> server, and I have corroborated my own identification.

Trust and identity are two different things. You're talking about trust. The fact that you can make up multiple identities doesn't matter unless you want somebody to trust one of them for something.

Trust is a big problem; moreso than identity. Furthermore, trust systems have identity as a requirement. And identity is useful outside of any advanced trust system. It makes sense to solve the identity problem first before moving on to complicated web of trust models.

The OpenID people are careful to distinguish between identity and trust. Trust is outside the scope of OpenID, but it's likely that any worthwhile trust system can be built on top of OpenID. You shouldn't use lack of trust as a basis to reject OpenID; in fact large-scale adoption of OpenID may well be helpful in developing a decent trust system.

PS: The one organisation that I expected to support OpenID much sooner than this is Google. Anybody have any ideas why they haven't jumped on board yet?

by CoughDropAddict (40792) on Tuesday February 06, @08:46PM (#17915308)

>>>Unfortunately, OpenID will utterly fail in it's task: it will never be a
>>>trustworthy source of identification.

You seem to be confused about the scope of OpenID. OpenID is not a system for tying user accounts to personal identities. It simply provides secure, distributed user accounts. It's not failing at it's task, it's failing at a task that you seem to want, but OpenID was never designed to solve.

===

Trust and identity are two different things.
也就是會在某一程度上將使用者"認證"(Auth)這個概念分成了"辨" 跟 "求".
這個觀念其實我覺得挺重要的, (至少原本我沒想的這麼清楚)
OpenID提供的功能只是對使用者帳號的識別(區分使用者) ,
Trust這個問題本身不僅包含了辨認, 而且要複雜的多.
對於能不能相信使用者資料所提供的資料, 則不是OpenID所能要求的,
而是透過開發者其他的認證機制.
然而對於大多數不需或無法嚴格確認身份的Web Application來說,
OpenID其實就已經很足夠了. 
而對於需要更複雜機制的Web AP, OpenID則也可以提供一個很好的起點跟架構支撐.

星期日, 2月 04, 2007

好玩的Flash遊戲 Flash Element TD



這跟django還是python都沒啥關係, 純粹就只是好玩而已 :-)

遊戲網址:
http://novelconcepts.co.uk/FlashElementTD/

網友的中文介紹

ps: 破關感想: 這遊戲實在很有財務概念...
這可比什麼現金流老鼠賽跑的遊戲有創意又好玩的多啊...

我的破關成績:

[link] 使用現有的 Yahoo! 帳號享受 openid

http://idproxy.net/

OpenID的概念很簡單, 只要妳有一個openid帳號,
妳就可以登入所有符合openid標準的網站.
這個概念基本上跟微軟的.net accounts還有google,yahoo的帳號很類似,
所不同的是openid的支援容易並且是公開標準,不為任一單一廠商所擁有.
所以可預見在未來會有更多opensource社群裡的網站支援這個標準.

然而雖然有了openid可以省下到每個網站都要建立/登錄一次帳號的麻煩,
但是不論如何建立一個openid帳號 還是得要輸入基本資料 這還是挺麻煩.
這個http://idproxy.net/就派上用場了,
如果妳有Yahoo!帳號, 那麼你就可以使用Yahoo!的帳號建立openid帳號,
花不到二十秒你的openid帳號肯定建立完成!

接下來你就可以到

http://www.lifewiki.net/openid/OpenIDConsumers
這邊列出的網址去參觀裡面的網站,
而不用特地在每個網站都建立一個帳號了, 是不是很棒呢?

延伸閱讀: 這篇Simon Willson (就是Django建立者其中之一啦)
有解釋他架設的方法.

星期六, 2月 03, 2007

[tip] Feedjack的兩個小問題

前陣子跟Shawnkalug上安裝了Feedjack, 我發現預設的Feedjack似乎有兩個小問題:

1. 使用IE瀏覽會整個亂掉. 這點我已經修復了 基本上只是調整一下CSS,
還有加了一個Check有沒有大頭照存在的filter, 因為一直都用firefox,
所以在這之前完全沒注意到有這個問題, 用了公司測試用的IE瀏覽器才發現,
Feedjack官方網站提供的Example Site除了一兩個有重新設計的之外, 也是全部都爛掉,
Feedjack居然預設完全沒考慮到IE的瀏覽, 這點實在是讓我出乎意料.

2. Tag Cloud顯示有問題:
用了一陣子之後突然發覺tag cloud的錯誤很大...
我blog上明明是django的項目最多, 但字體卻不是最大.
看了一下我的blog tag顯示計數, 再比對Feedjack上的:
In [1]: from feedjack.models import Site
In [2]: x = Site.objects.all()[0]
In [3]: from feedjack.fjcloud import cloudata
In [4]: cloudata(x)[1]
Out[4]:
[{'count': 2, 'weight': 2, 'tagname': 'ajax'},
{'count': 17, 'weight': 5, 'tagname': 'django'},
{'count': 4, 'weight': 2, 'tagname': 'humor'},
{'count': 2, 'weight': 2, 'tagname': 'link'},
{'count': 7, 'weight': 3, 'tagname': 'programming'},
{'count': 11, 'weight': 5, 'tagname': 'python'},
{'count': 3, 'weight': 2, 'tagname': 'talk'},
{'count': 8, 'weight': 4, 'tagname': 'tips'},
{'count': 1, 'weight': 1, 'tagname': 'translation'},
{'count': 5, 'weight': 3, 'tagname': 'web'}]

疑? count 跟weight都沒問題啊,
不過很明顯的Feedjack上的tag cloud跟我的blog上的tag cloud就是長的不一樣,
仔細再查了一下, 阿, style.css居然漏加了cloud_4跟cloud_5的定義:
那我就順便改了一下字體大小, 這樣就可以了.

.cloud_1 {
font-size: 80%;
}
.cloud_2 {
font-size: 90%;
}
.cloud_3 {
font-size: 100%;
font-weight: bold;
}

.cloud_4 {
font-size: 110%;
font-weight: bold;
}

.cloud_5 {
font-size: 120%;
font-weight: bold;
}


這樣就OK了.