Javascript 對於 !important 的處理

一直跑的很好,但是我們家的 在使用者自訂 CSS 時對 height/width 標 !important 就會爛掉...

今天花了時間去找,終於找到解法了:用 style.setProperty 蓋過去。在 這邊的程式碼裡面這樣寫:

this.style.setProperty('height', 'auto', 'important');
this.style.setProperty('width', 'auto', 'important');

改好的版本已經放到 上了:,效果可以參考 這本相本。

Google Code 更新 SSL Certificate

公告在這邊:

主要是 svn 會發現 ssl certificate 改變而跳出警告,所以特地公告出來。

另外,我發現 Repository 還是有不少問題,像是 branch 出來後修改,再 merge 回 master 後,再 git-svn dcommit 上去後可能會有問題。而 git-svn 的 manpage 裡就直接建議在開發時儘量保持 linear... XD

就是要 branch 才好用啊啊啊啊啊...

所以我有一些比較小的 project 又改回 svn client 了...

MySQL UDF (User-defined function) 與 memcached

以往 + 的作法是由 application 端「拉」資料後再塞到 memcached 上,這會產生幾個問題:

  • 資料不同步:MySQL 上的資料更新了,但 memcached 裡的 cache 因為還沒過期而尚未更新。
  • 第一次的 Race Condition:同時有很多 client 向 memcached 要一份目前還不存在的 cache,這時候這些 client 都會跑到 MySQL 要資料再放一份到 memcached 上。

這兩個問題都有在 MySQL UDF + memcached 出來之前都有解法:前者可以在更新 MySQL 時順便更新 memcached 裡的資料;後者可以靠 memcached lock 的技巧避免突然有大量 Query 造成後端 MySQL 負荷過重。這兩個方法需要 application (client) 配合,不是很完美,但在實際應用上還算堪用。(一個很簡單的場景:如果公司內同時使用 ,那麼就必須維護這兩個 library)

除了 client 自己推資料到 memcached 上,也有人研究,當 MySQL 上的資料更新時,由 MySQL server 自動到 memcached 上更新資料,也就是把資料「推」到 memcached 上的方法。資料更新時的觸發動作可以用 做到,而寫入到 memcached 的部份透過強者的 處理:

btw, 也用 libmemcache 寫過類似的東西: 這篇的下方 (「MySQL and memcached」的部份)

Google App Engine 的收費,以及功能的加強

的訪談中跟 的 Product Manager 談到收費的金額:

Update 正式的新聞稿也可以在網站上看到了:

頻寬的費用與 差不多,儲存空間的部份跟 比起來也差不多,CPU 暫時沒有想到要怎麼比較。

除了收費的事情之外,文章裡有提到會多兩組功能,一組是對圖片的處理:目前不清楚 Google 是不是自己有另外開發,不過在自己建置的環境裡常用 處理。另外一組功能是 cache,讓你可以把算好的資料存起來重複使用。

再來是大家一直都很希望 Google App Engine 可以支援 以外的語言,不過照文章裡的說法,目前暫時沒有計畫。

以後應該有 Blog software 會 porting 到 Google App Engine 的環境上,以這種用多少算多少的方式,之後可以考慮把整個站搬到上面?

Google 提供 Javascript Library Hosting

公告了他們將會 hosting 幾個常用的 javascript library 讓人使用:

最簡單的方法就是把本來的程式碼:

<script type="text/javascript" src="http://static.example.com/jquery-1.2.6.min.js"></script>

改成 Google 提供的位置:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>

剛剛先把 所使用的 都更新改用 Google 提供的 hosting。

document.evaluate()

最近在翻一些 script 的時候翻到 上可以使用 ,才發現之前用 做這種小事情很不划算...

在 Firefox 上可以透過 document.evaluate() 條件式找出符合的元素。利用這個功能取代本來用 jQuery $('.className') 還蠻容易的,等有力氣的時候來改寫 album expander... :p

Git 與 Subversion 的結合

同上篇文章,因為 連不上,所以只好寫成 Blog 胡言亂語...

昨天 講了「」,在台下聽的時候順便試 git-svn (或 git svn) 的操作,發現效能比 好許多,而我想要的功能在 上面也都有了,那麼... 也沒什麼好說了,先把手上幾個工作目錄換成 Git :p

回到家把雜事處理完後 (主要是玩 ?),打開 消化一整天沒讀的 feed,發現 也發了一篇「」跟 jserv 的主題還蠻有關係的。

雖然 使用 ,但仍然可以透過 Git 操作,操作的方式在 的文章裡寫的很清楚了。如果對於 Git 不熟的人,我建議先看「」這篇中文的 blog 文章,裡面的例子直接照做就會動。

今天上班的時候再測試看看 performance,把 1.5.2 整包塞進去會花多久 :p

Zend Framework 1.5.2

1.5.2 正式釋出了,由於 是 1.5 才納入,所以 1.5 有很多 bug 是在修正 Zend_Form。

像是「」中提到的 setRequired() 問題在「」被解掉了。

1.5.2 修正的問題,以及改善的地方,可以在「」這頁看到。

這幾天發現沒有 Zend_Form_Element_File,查了一些討論發現發展團隊似乎要等 Zend_Upload 的架構先出現才要實做 Zend_Form_Element_File,看起來這幾個月內是沒這東西了,先自己寫一個會動的版本... @_@

Zend_Form 的一些紀錄

如果是自己搞網站 (程式美術都自己來),用 設定完後,透過 render() 將 HTML code 呈現的確不錯,畢竟強迫你要用 CSS 去處理頁面呈現。不過,如果是請別人先做好美術版面,產生 HTML 後才要轉成 Zend_Form 生出來的話,就會用到很多 manual 裡不會教的「壞方法」XD

目前用到的方法是在 view 裡面 (我用 ) 直接顯示 Element,像是這樣:

<?= $this->post_form->post_title ?>

但只用上面的方法會產生一堆 dt + dd 之類的東西,這是因為 Element 預設的 Decorator 太多,所以需要重設只用 ViewHelper:

$element->setDecorators(array('ViewHelper'));

其他的在原來的 tutorial 都有寫。

另外有點很重要,因為 Zend_Form 在 1.5 版才納入,所以文件並不一定能夠涵蓋所有的方法,看 source code 瞭解用法的能力很重要...

PIXNET 徵正職 PHP 工程師

幫我們公司徵人 :p

要徵熟悉 ,以及 的正職 coder 兩名,工作地點在台北市民生東路二段這邊,有興趣的人請將履歷寄到 104@pixnet.tw,標題請寫上「應徵 PIXNET 程式設計師」。

這份工作主要的內容是寫 PHP,如果熟悉 (目前我們用這個開發) 或其他 Framework 更好。

有問題除了可以在 comment 問以外,也可以直接寫信到 gslin at pixnet.tw 問我。