十月 17

近年來,搜尋引擎優化(SEO)的概念甚囂塵上,網站經營者莫不樂於借力使力,調整自己的網站架構和資訊脈絡讓網站能在搜尋引擎上發光發熱。理想情況下,搜尋引擎的使用者如果夠多,對於資料的應用夠聰明,而網友的使用習慣也夠集中,那麼和搜尋引擎互利共生倒不失為一個有利的決定。但是,真實的情況的確如此嗎?

從網站流量記錄中,發現經常爬站的搜尋引擎大致上有: 

  • Baiduspider+(+http://www.baidu.com/search/spider.htm)
  • Gaisbot/3.0+(robot06@gais.cs.ccu.edu.tw;+http://gais.cs.ccu.edu.tw/robot.php)
  • Googlebot-Image/1.0
  • Mediapartners-Google
  • Mediapartners-Google/2.1
  • Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  • Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
  • Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)
  • msnbot/1.1 (+http://search.msn.com/msnbot.htm)
  • Sogou web spider/4.0(+http://www.sogou.com/docs/help/webmasters.htm#07)
  • Sosospider+(+http://help.soso.com/webspider.htm)
  • Yanga WorldSearch Bot v1.1/beta (http://www.yanga.co.uk/)

 這代表什麼意思?大家可以試算一下:

 (閱讀全文)

八月 06

因為 php 上面提供的 mailparse 模組實在是爛到一個不行,看不下去只有自己寫,這就是網路。有興趣的人請自行取用~~註明出處即可。

/* 作者:丁昶文
    電郵:charlie@ics.com.tw
*/

class        mail_parser    {
    function    mail_parser()    {
        $this->tree        =    array() ;
        $this->header    =    array() ;
        $this->body        =    array() ;
        $this->counter    =    0 ;
    }
    function    explode($message,$pid=0) {
        if    ($pid == 0)    {
            $segment        =    preg_split("/\r*\n\r*\n/",$message,2) ;
            $this->header[0]=    iconv_mime_decode_headers(trim($segment[0]),2,SCRIPT_CHARSET) ;
            $this->body[0]    =    trim($segment[1]) ;
        }
        if    (preg_match("/boundary=\"([^\"]+)\"/i",$message,$m))    {
            $boundary    =    $m[1] ;
            $tail_off    =    array_shift(explode("--{$boundary}--",$message)) ;
            $parts        =    explode("--{$boundary}",$tail_off) ;
            array_shift($parts) ;
            if    (!isset($this->tree[$pid]))    $this->tree[$pid]    =    array() ;

            foreach    ($parts as $this_one => $part)    {
                $segment                            =    preg_split("/\r*\n\r*\n/",$part,2) ;
                $this->counter                        +=    1 ;
                $oid                                =    count($this->tree[$pid]) + 1 ;
                $this->tree[$pid][$oid]                =    $this->counter ;
                $this->tree["<-{$this->counter}"]    =    $pid ;
                $this->header[$this->counter]        =    iconv_mime_decode_headers(trim($segment[0]),2,SYSTEM_CHARSET) ;
                $this->body[$this->counter]            =    trim($segment[1]) ;

                $this->explode($part,$this->counter) ;
            }
        }
    }
}
 

用法就是:
$mp = new mail_parser() ;
$mp->explode(MAIL_CONTENT_FROM_EML_FILE) ;
然後它就會幫你把整封信炸開,之後,你可以用二種方式去捉資料。

  1. for ($i = 0 ; $i <= $mp->counter ; $i++) {
        $header = $mp->header[$i] ;
        $body = $mp->body[$i] ;
    }
  2. 也可以用樹狀的方式去捉出信包中各區塊的關係,重點就是從 $mp->tree[0] 開始,然後逐層去撈。找到 index 後,一樣從 $mp->header 和 $mp->body 去捉檔頭和內容。

這個類別基本上只作信包拆解的部份,而且是不管什麼死人骨頭全部拆光光。純粹是為了處理 mailparse 在 body 解析上的無厘頭表現而已。至於打包部份,目前我沒需求,就也沒作囉。不過就是反其道而行就對了。
email 的關鍵就是 boundary 和 mime type 處理好,然後拆拆裝裝而已。

附註:

  1. 類別中用了 SCRIPT_CHARSET 和 SYSTEM_CHARSET 這個定義,是用來將標頭內容轉成指定的字集,別忘了 define (SCRIPT_CHARSET,'***') ; 和 define (SYSTEM_CHARSET,'***') ; 先。
  2. 樹狀結構的存取就自行處理囉。
  3. php 指令 iconv_mime_decode_headers 也有點不盡理想。主要在 header 長度過長被切斷成數行的情況時,重組的結果會有不可預期的空白出現。另外則是部份 mail agent 的設計失當,在 header 中使用特定字集而未加以編碼,造成還原上的錯誤。這部份,可以考慮自行改寫 header 的反解功能來取代它。

 

七月 18

必備

01.谷歌閱讀器(Google Reader)網頁版RSS閱讀器,方便訂閱,組織和分享新聞。有手機版。

02.個性化主頁(iGoogle)顯示Gmail,日曆,天氣,新聞等等,多模板。

03.谷歌相冊服務(Google Picasa)提供照片的下載和編輯軟體,用這個軟體Email,上傳,張貼照片到博客,也可以直接使用網路相冊。

04.谷歌文件(Google Docs)您不再需要桌面版的Office了,這個是谷歌的線上Office,你可以創建,發佈,共用和協作線上文檔和幻燈。

05.谷歌記事本(Google Notebook)剪貼文本,圖片和鏈結頁面,可以保存,檢索或共用。

06.谷歌桌面(Google Desktop)桌面搜索,可以搜索你電腦裏的電子郵件,電腦文件,音樂,照片,聊天和Web歷史記錄,和iGoogle類似,也安裝小工具。

 (閱讀全文)

七月 12
一般來說這和資料庫的正規化(normalization)有極大的關聯性,但除了把工作丟給 DBA(DataBase Administrator) 之外,還可以從幾個面向來思考 ───
  1. 網站的功能需求
    這往往取決於網站提供資訊的方式,例如社群網站有各種討論版的總覽、討論版內有話題列表、然後是討論串的內容等等,當然也總是有最新討論的話題摘錄。
    這可以濃縮成二個重點:在導覽內容上循序漸進在氛圍營造上突顯特色
    表現在功能需求上會變成──
    • 資訊的陳列
      例如新聞列表、產品列表、討論版總覽、....。它的特色是多樣化,設計方式隨網站、內容甚至使用者愛好不同而異。
    • 資訊的展示
      例如部落格文章、產品介紹、討論串內容、....。它的特色是差異極大,如部落格文章的多樣、產品介紹的複雜、討論內容的龐大。

  2. 資料的更新頻率
    從上述的內容中來看更新頻率,可以發現陳列方式的更新頻率大於展示內容。
    舉部落格的例子來說,一篇文章寫好後,除非作者去修改內容,否則內容是永遠不變的。然而這篇文章在部落格中陳列時,卻會因為時間、新文章推擠、....各種可能的因素,而改變他出現的地方。
    從實體店面來看則是,銷售的商品(內容)不變,但可能排放的位置(陳列)會經常性的調整。所以,陳列資訊的更新頻率是遠高於展示內容的。
  3. 資源的有效運用
    網站的資源不外乎主機運算能力、記憶體等等(頻寬不在討論之列)。
    要如何有效運用資源?簡單來說,就是只作絕對必要的運算。
    回到資料庫的範疇來看,如果一個網站的文章內容和統計資訊放在一起,那麼資料庫就會變得龐大。而當統計資料在更新時,就必須連同不變的文章內容一起寫回主機,增加了硬碟IO的時間。甚至,如果文章內容更新頻率極低,那麼將內容轉為靜態檔案,就可以減少資料庫佔用的記憶體數量。(當然這必須在記憶體資源和硬碟IO速度上評估最佳作法)
所以,網站效能除了靠資料庫正規化之外,還必須仔細分析資料的應用、更新和資源分配。有幾點必須注意的: (閱讀全文)
六月 30

在台灣的許多網站上可以發現,設計師往往習慣於直覺式的設計方式來建構平台,因而造成許多的問題。雖然這不全然是設計者的問題,更大的因素可能來自顧主對需求的不明確、任意調整、修改,而使得設計者難以謹嚴地遵守程式設計上的必要規範。這或許是為什麼歐美各國,對於資訊人才的重視程度遠超乎華人世界的原因之一。但不論如何,身為設計者必須更明確地認知自己的專業,並積極地向上宣導,才能讓設計這一行變成是高度專業、高額獲利、高度成就的三高行業。

為了達到這個目標,熟悉網路服務的功能規劃策略就是一項不容忽視的課題了。 

因為網站人人能架,但功能規劃各有巧妙不同;部落格人人可以申請,但寫的文章是否有人氣可就不一定了。所以,仔細的評估、規劃,絕對是決定輸贏勝敗的關鍵因素之一。那麼,該怎麼作呢? (閱讀全文)

五月 30

看了 n 遍都還是英文的,不如捉下來邊看邊翻譯,有興趣的人請參考並歡迎接力翻一下想看的部份囉。 (閱讀全文)

五月 28

這一篇是在網路上爬文後的心得,先介紹一篇值得參考的文章,有興趣的人可以先去閱讀一下:

閱讀完並實作之後,果然解決了原本苦惱中的 Firefox 和 IE6 對於 padding 的計算差異,這個問題造成網頁版面的編排無法只在最外層的 box 設定尺寸,而其內所有容器(如 div, table, ....)則採用相對尺寸來維持彈性和簡潔。

 (閱讀全文)

五月 25

每個完整的網站都有它應該具備的元素,而這些元素是否能彈性應用、快速複製、整合,則是每個從事網站設計、企劃和營運者的挑戰。面對網路市場、趨勢的快速變化,這將是業者所面臨的重要課題。

組成要素有什麼呢? (閱讀全文)

五月 18
這十條金科玉律般的職工座右銘,我建議作為職工必讀的經典之作。 要把它張貼在自己工作生活的牆上,經常閱讀反省,對我們大有好處。 比爾‧蓋茨之成為最受尊敬的人,成為近十年"世界首富",恐怕一個重要道理正在于此。 (閱讀全文)
五月 08

網站設計由傳統的靜態網頁(static pages)轉為採用資料庫的動態網頁設計已經早被大家所接受。但是,隨著資料量的增加、網站功能的複雜化、互動頻率的增加,一昧地採用資料庫+程式去即時產生網頁,也一再出現效能下降的警訊。

有鑑於此,許多因應的技術就被發展出來了,包括: (閱讀全文)