最近群裡有朋友提到用WMP外掛程式做網頁mp3播放機，在使用時需要檢查流覽器是否支援WMP；WMP的支援，IE下是用ActiveX，其它流覽器一般是用外掛程式。閒暇查了一下相關資料，寫了下面的檢測代碼，支持所有主流流覽器：
2011年5月30日 星期一
數位媒體串流-Windows Media Services - 使用JavaScrip操作撥放器及抓取clientData 元件(用戶端資料)資訊
<object classid="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6" type="application/x-oleobject"
id="wmp" width="0" height="0" style="width:0px;height:0px;"></object>
//基本屬性
wmp.URL:String; //指定媒體位置，本機或網路位址
wmp.uiMode:String; //播放機介面模式，可為Full, Mini, None, Invisible
wmp.playState:integer; //播放狀態，1=停止，2=暫停，3=播放，6=正在緩衝，9=正在連接，10=準備就緒
wmp.enableContextMenu:Boolean; //啟用/禁用右鍵菜單
wmp.fullScreen:boolean; //是否全屏顯示
//播放機常用控制
wmp.controls.play; //播放
wmp.controls.pause; //暫停
wmp.controls.stop; //停止
wmp.controls.currentPosition:double; //當前進度
wmp.controls.currentPositionString:string; //當前進度，字串格式。如“00:23”
wmp.controls.fastForward; //快進
wmp.controls.fastReverse; //快退
wmp.controls.next; //下一曲
wmp.controls.previous; //上一曲
//播放機常用設置
wmp.settings.volume:integer; //音量，0-100
wmp.settings.autoStart:Boolean; //是否自動播放
wmp.settings.mute:Boolean; //是否靜音
wmp.settings.playCount:integer; //播放次數
wmp.settings.balance = -100; //(左聲)
wmp.settings.balance=100; //(右聲)
wmp.settings.balance=0; //(全聲)
//常用當前媒體屬性
wmp.currentMedia.duration:double; //媒體總長度
wmp.currentMedia.durationString:string; //媒體總長度，字串格式。如“03:24”
wmp.currentMedia.getItemInfo(const string); //獲取當前媒體資訊
wmp.currentMedia.setItemInfo(const string); //通過屬性名設置媒體資訊
wmp.currentMedia.name:string; //同currentMedia.getItemInfo("Title")
wmp.network.bufferingProgress; //緩衝百分比
wmp.network.downloadProgress; //下載百分比
標籤：
JavaScrip,
Media Services
2011年5月29日 星期日
數位媒體串流-Windows Media Services - clientData 元件(用戶端資料)
您可以使用 clientData 元件將描述文字、橫幅影像及記錄資訊與播放清單元件相關聯。描述文字 (如演出者名稱與曲目標題) 顯示於 Windows Media Player 9 系列、更新的版本或使用 Windows Media Player 9 系列 ActiveX 控制項的播放程式您也可以使用 clientData 元件來顯示橫幅影像、相關的超連結及工具提示文字。
您可以將 clientData 元件插入到播放清單中任何地方。它可以是除了另一個 clientData 元件之外任何元件的子元件。當 clientData 元件正在使用時，它所包含的資訊會傳送至用戶端。
excl、seq、priorityClass 或 switch 元件可以具有一個以上的 clientData 元件，而且每一個 clientData 元件可以包含多個屬性。根據新增的 clientData 元件所在的位置，資訊會套用至個別 media 元件或 media 元件的集合。clientData 元件會被更高層級的 clientData 元件所覆寫。例如，為 media 元件群組指定的標題資訊優先於為個別 media 元件指定的標題資訊。同樣，在檔案標題中編碼的文字屬性 (如標題、作者及著作權) 也會被播放清單中相對應的 clientData 元件所覆寫。
在下列範例中，seq 元件嵌套於另一個 seq 元件中。clientData 元件會為個別 media 元件及一連串嵌套的元件指定標題。首先播放 media 元件 Open.wmv，同時顯示個別 title屬性值 Welcome。然後從 Video1.wmv開始，播放嵌套順序中的項目。因為 clientData 元件是 seq 元件的子元件，所以 title 屬性值 Segment 1 將作為順序中所有 media 元件的標題顯示。與media 元件Video1.wmv 相關的 title 屬性值會被順序中的標題覆寫。
屬性 - 屬性可修改播放清單元件的內容。您可以使用 clientData 元件的下列選擇性屬性。
album
指定專輯名稱。相關資訊，請參閱 album 屬性。
artist
指定演出者名稱。相關資訊，請參閱 artist 屬性。
author
指定作者的名稱。相關資訊，請參閱 author 屬性。
bannerAbstract
指定作為橫幅影像 (顯示在 Windows Media Player 中) 工具提示顯示的文字。相關資訊，請參閱 bannerAbstract 屬性。
bannerInfoURL
指定使用者可藉由按一下 Windows Media Player 中的橫幅影像來進行存取的 URL。相關資訊，請參閱 bannerInfoURL 屬性。
bannerURL
指定出現在 Windows Media Player 的顯示面板中的影像檔案之URL。相關資訊，請參閱 bannerURL 屬性。
copyright
指定著作權資訊。相關資訊，請參閱 copyright 屬性。
genre
指定類別。相關資訊，請參閱 genre 屬性。
logURL
指定用來公佈記錄統計資料到原始伺服器或任何網頁伺服器的 URL。相關資訊，請參閱 logURL 屬性。
title
指定標題。相關資訊，請參閱 title 屬性。
您可以將 clientData 元件插入到播放清單中任何地方。它可以是除了另一個 clientData 元件之外任何元件的子元件。當 clientData 元件正在使用時，它所包含的資訊會傳送至用戶端。
excl、seq、priorityClass 或 switch 元件可以具有一個以上的 clientData 元件，而且每一個 clientData 元件可以包含多個屬性。根據新增的 clientData 元件所在的位置，資訊會套用至個別 media 元件或 media 元件的集合。clientData 元件會被更高層級的 clientData 元件所覆寫。例如，為 media 元件群組指定的標題資訊優先於為個別 media 元件指定的標題資訊。同樣，在檔案標題中編碼的文字屬性 (如標題、作者及著作權) 也會被播放清單中相對應的 clientData 元件所覆寫。
在下列範例中，seq 元件嵌套於另一個 seq 元件中。clientData 元件會為個別 media 元件及一連串嵌套的元件指定標題。首先播放 media 元件 Open.wmv，同時顯示個別 title屬性值 Welcome。然後從 Video1.wmv開始，播放嵌套順序中的項目。因為 clientData 元件是 seq 元件的子元件，所以 title 屬性值 Segment 1 將作為順序中所有 media 元件的標題顯示。與media 元件Video1.wmv 相關的 title 屬性值會被順序中的標題覆寫。
下列範例合併了多個 clientData 屬性。
copyright="(c) Company name" genre="Rock" title="Music" />
屬性 - 屬性可修改播放清單元件的內容。您可以使用 clientData 元件的下列選擇性屬性。
album
指定專輯名稱。相關資訊，請參閱 album 屬性。
artist
指定演出者名稱。相關資訊，請參閱 artist 屬性。
author
指定作者的名稱。相關資訊，請參閱 author 屬性。
bannerAbstract
指定作為橫幅影像 (顯示在 Windows Media Player 中) 工具提示顯示的文字。相關資訊，請參閱 bannerAbstract 屬性。
bannerInfoURL
指定使用者可藉由按一下 Windows Media Player 中的橫幅影像來進行存取的 URL。相關資訊，請參閱 bannerInfoURL 屬性。
bannerURL
指定出現在 Windows Media Player 的顯示面板中的影像檔案之URL。相關資訊，請參閱 bannerURL 屬性。
copyright
指定著作權資訊。相關資訊，請參閱 copyright 屬性。
genre
指定類別。相關資訊，請參閱 genre 屬性。
logURL
指定用來公佈記錄統計資料到原始伺服器或任何網頁伺服器的 URL。相關資訊，請參閱 logURL 屬性。
title
指定標題。相關資訊，請參閱 title 屬性。
標籤：
Media Services
數位媒體串流-Windows Media Services - media 元件
播放清單中的 media 元件提供了數位媒體來源的位置，並可指定數位媒體內容播放或呈現至用戶端的方式。media 元件可以參照任何數位媒體來源，這個來源可供資料來源外掛程式存取，並可由媒體或「播放清單分析」外掛程式分析。預設會啟用適當的外掛程式。
數位媒體來源範例包括本機電腦上的檔案、來自執行 Windows Media 編碼器或 Windows Media Services 的遠端電腦之串流、其他播放清單檔案、網頁伺服器上的 Active Server Page (ASP 網頁)，或者協力廠商儲存系統上的數位媒體檔案。
下列範例顯示了一個由三種數位媒體類型組成的簡單播放清單：一個影像檔案、一個視訊檔，以及一個音訊檔：
以第一個列出的 media 元件開始，依序播放三個檔案。因為影像檔案沒有隱含期間，所以第一個 media 元件有 dur 屬性的指定值。
屬性-屬性可修改播放清單元件的內容。您可使用下列具有 media 元件的屬性。僅 src 屬性是必須的屬性。
src
指定數位媒體內容來源的名稱及位置。相關資訊，請參閱 src 屬性。
begin
指定 media 元件何時變為使用中。相關資訊，請參閱 begin 屬性。
clipBegin
指定數位媒體來源中播放開始的端點。相關資訊，請參閱 clipBegin 屬性。
clipEnd
指定數位媒體來源中播放結束的端點。相關資訊，請參閱 clipEnd 屬性。
dur
指定數位媒體來源播放的時間長度。相關資訊，請參閱 dur 屬性。
end
指定 media 元件何時變為不可用。相關資訊，請參閱 end 屬性。
syncEvent
指定用來觸發以開始，或是結束包裝函式播放清單中的元件。相關資訊，請參閱 syncEvent 屬性。
id
指定可供其他元件參照的 media 元件之名稱。相關資訊，請參閱 id 屬性。
mediaName
指定 media 元件的名稱以取代用戶端記錄及用戶端內容說明清單中的 src 屬性值。相關資訊，請參閱 mediaName 屬性。
noSkip
指定是否啟用 media 元件的向前快轉、倒帶、搜尋或略過。相關資訊，請參閱 noSkip 屬性。
repeatCount
指定 media 元件在停止之前重播的次數。如果未指定任何值，則該元件只會播放一次。相關資訊，請參閱repeatCount 屬性。
repeatDur
指定 media 元件在停止之前重播的時間長度。相關資訊，請參閱 repeatDur 屬性。
role
指定 media 元件的角色。相關資訊，請參閱 role 屬性。
下列播放清單範例顯示了具有 id、src 及 dur 屬性值的 media 元件：
數位媒體來源範例包括本機電腦上的檔案、來自執行 Windows Media 編碼器或 Windows Media Services 的遠端電腦之串流、其他播放清單檔案、網頁伺服器上的 Active Server Page (ASP 網頁)，或者協力廠商儲存系統上的數位媒體檔案。
下列範例顯示了一個由三種數位媒體類型組成的簡單播放清單：一個影像檔案、一個視訊檔，以及一個音訊檔：
以第一個列出的 media 元件開始，依序播放三個檔案。因為影像檔案沒有隱含期間，所以第一個 media 元件有 dur 屬性的指定值。
屬性-屬性可修改播放清單元件的內容。您可使用下列具有 media 元件的屬性。僅 src 屬性是必須的屬性。
src
指定數位媒體內容來源的名稱及位置。相關資訊，請參閱 src 屬性。
begin
指定 media 元件何時變為使用中。相關資訊，請參閱 begin 屬性。
clipBegin
指定數位媒體來源中播放開始的端點。相關資訊，請參閱 clipBegin 屬性。
clipEnd
指定數位媒體來源中播放結束的端點。相關資訊，請參閱 clipEnd 屬性。
dur
指定數位媒體來源播放的時間長度。相關資訊，請參閱 dur 屬性。
end
指定 media 元件何時變為不可用。相關資訊，請參閱 end 屬性。
syncEvent
指定用來觸發以開始，或是結束包裝函式播放清單中的元件。相關資訊，請參閱 syncEvent 屬性。
id
指定可供其他元件參照的 media 元件之名稱。相關資訊，請參閱 id 屬性。
mediaName
指定 media 元件的名稱以取代用戶端記錄及用戶端內容說明清單中的 src 屬性值。相關資訊，請參閱 mediaName 屬性。
noSkip
指定是否啟用 media 元件的向前快轉、倒帶、搜尋或略過。相關資訊，請參閱 noSkip 屬性。
repeatCount
指定 media 元件在停止之前重播的次數。如果未指定任何值，則該元件只會播放一次。相關資訊，請參閱repeatCount 屬性。
repeatDur
指定 media 元件在停止之前重播的時間長度。相關資訊，請參閱 repeatDur 屬性。
role
指定 media 元件的角色。相關資訊，請參閱 role 屬性。
下列播放清單範例顯示了具有 id、src 及 dur 屬性值的 media 元件：
標籤：
Media Services
2011年4月8日 星期五
在iframe中，如何讓 ASP.NET 使用 Session 資料時不要再自動消失
我們在 ASP.NET 網站使用 Session 時，常常因為 web.config 修改或更新 Bin\ 目錄下的 dll 而導致 Session 消失，Session 常常消失也挺惱人的，不是導致突然被自動登出，就是發生非預期的 Exception ... 等。 ( 有時候因為主機安裝防毒軟體也會造成 Session 資料無故消失，因為這些防毒軟體可能會誤判某檔案、某記憶體含有病毒資訊 )
這個時候我們可以將 Session 預設的模式 ( InProc ) 改成 StateServer 模式，但此時必須確認本機的 ASP.NET 狀態服務 是啟動的狀態！
請到 控制台 > 系統管理工具 > "服務"
找到 "ASP.NET 狀態服務" 或 "ASP.NET State Service"
此服務預設是屬於「停用」的狀態，請先切換到「自動」再按下「套用」再直接按「啟動」按鈕即可。
接者你可以到你的 ASP.NET 網站設定 web.config 組態檔，設定如下：
這樣就可以將 Session 的資料存到本機的 ASP.NET 狀態服務去了，也不會無故 Session 自動消失了。
這個時候我們可以將 Session 預設的模式 ( InProc ) 改成 StateServer 模式，但此時必須確認本機的 ASP.NET 狀態服務 是啟動的狀態！
請到 控制台 > 系統管理工具 > "服務"
找到 "ASP.NET 狀態服務" 或 "ASP.NET State Service"
此服務預設是屬於「停用」的狀態，請先切換到「自動」再按下「套用」再直接按「啟動」按鈕即可。
接者你可以到你的 ASP.NET 網站設定 web.config 組態檔，設定如下：
<configuration>在web.config裡的cookieless="false"改為：cookieless="true"
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=localhost:42424"
cookieless="false"
timeout="20"/>
</system.web>
</configuration>
這樣就可以將 Session 的資料存到本機的 ASP.NET 狀態服務去了，也不會無故 Session 自動消失了。
標籤：
ASP.NET C#,
HTML
2011年3月31日 星期四
SEO Check List 與原理解釋
千萬要做的事
1. 網站使用 valid html 撰寫，最好過 w3c validator
原理：這是一定要的，原因如 part3。
2. 使用正確的 html 標記描述內容與網站的元素。該用 h1,h2, strong, p 的請不要客氣
原理：這是一定要的，原因如 part3。
3. 網頁敘述要含關鍵內容。關鍵字越前面越好。（但並非 abuse）
原理：可觀察 Google 的 SERP （Search Engine Result Page）
4. 網頁 title 要含關鍵字。關鍵字越前面越好。（但並非 abuse）
原理：可觀察 Google 的 SERP （Search Engine Result Page）
5. 網址要含關鍵字。WordPress 在這方面設計的相當好，只要你把選項打開就行了。至於其他的內容網站，你可以考慮在背景使用 Google Translate 將網址標題轉成英文然後 append 在網址上。
原理：可觀察 Google 的 SERP （Search Engine Result Page）
其中權重 5 > 4 > 3 。
6. 因為 3,4,5 的關係，生產內容時必須遵守 SEO 原則，程式設計上也必須做出搭配。請看 part3。
7. 圖片內容，請加 alt 描述這張圖片。但 alt 字數也別太誇張，否則會视為 cheating。如果這是選單或 banner，請用 ul, li 和 h1,h2 寫，再用 CSS 技巧換掉。別來個 img + a 做 banner 的設計，img 權重遠低於 h1。
原理： part3。
8. 把內容放在 Search Engine highly friendly 的平台，如果是你想在 Yahoo 取得高排名，請放 Wretch，如果你想在 Google 取得高排名，請放 Blogger.com。如果你是自己 hosting，請檢視你的平台是否有做到 checklist 上的要求。
原理： 搜尋引擎偏好自家產品，結果會出現在比較前面
9. 為網站生成符合標準的 sitemap.xml。並主動將結果送至 Google、Yahoo、Bing 等等。
原理：搜尋引擎仰賴自己設計的爬蟲去抓取內容，他們的 index 路徑是遵循著網站上的內部連結以及外部連結，至於沒有被連結到網頁，自然就不會被收錄。他們沒有通靈能力，自然不知道你有產出這樣的內容。你必須主動告知他們。另外，sitemap 可以標記內容在該站的權重以及內容更新時間。有效提供 Search Engine 運算依據。這一點非常重要，根據我曾經做過的實驗，某搜尋引擎有送 sitemap 跟沒送，排名結果差非常非常多。
10. 在高 PR 的網站為自己的網站帶來 inbound link。
原理：眾所諸知，Google 的演算法是 Page Rank 演算法。PR 演算法簡單的想法是：如果一個網站，越多網站甚至是超級大站都連結這個網站，那麼它必定是重要的。但切記千萬別 abuse。
11. 提昇網站效能，開啟速度要快。
原理：網站速度，也是搜尋引擎排名的考慮因素之一。
12. 使用 Google Webmaster Tool 檢視你的網站 SEO 成效。
原理：它真的很好用….
千萬不要做的事
1. 千萬不要濫用以上原則，搜尋引擎不是笨蛋，不會不知道你想作弊。適度的標記關鍵內容就能使你的排名大幅提昇。但是濫用會造成你被下架。
原理：常識。
2. 不要把主要內容放在 image/ js / flash/ iframe 內。
原理： bot 只吃該頁的 html，image / js/flash/iframe 對他們來說只是一行外部網址。它們不會知道這是內容
3. 不要在 a 裡面加 onclick / onmouseover 類似的屬性。
原理：這多半指稱這是 js link，搜尋引擎會跳過這個 a 內的內容。如果你要上計算人氣等功能，請用 Unobtrusive Javascript 技巧實作。如果你只是想要做 css hover 效果，那就更欠人罵了，可以用 CSS 寫的東西為何要放上 a 去破壞 SEO 效果。
4. 連結不要濫用 302 redirect。
原理：http response 的 301, 302 是有意義的。301 指的是永久性重導向，302 指的是暫時性重導向，但 RD 寫 code 往往沒有深究其意義。我曾經見過人氣系統用 302 設計先轉去人氣系統再跳回來。Epic Fail。302 對搜尋引擎來說是「完全不值得收錄」的內容，因為他是「暫時性網址」。如果網站全站都掛 302 連結，那……沒有搜尋引擎想要收錄超正常。
5. 標籤不要亂包。我曾經看過一行 html 是這樣寫的 <h1><a href="xxx"> abc </a><img src="def"/></h1> 。搜尋引擎不知道重要的是 abc 還是沒有 alt 的 def。最後是連 abc 都被視為不重要內容。
原理：你讓搜尋引擎精神錯亂。
6. 每一頁的 title 與 meta description 不要重複
原理：搜尋引擎很大的權重採用 title 與 meta description。如果一個網站 50 頁 + 的 title 和 meta description 都一樣。搜尋引擎不會知道哪一頁是真正的入口點，真正重要的內容。下場就是全部都不收錄！！！
7. meta keywords 不重要
原理：Google 不採用。Yahoo 採用。但權重不大。因為 meta keywords 曾經被大家濫用 …但如果你拿 meta keywords 來做 correct 字義的功能，是不錯的。
8. 不要用 Word 生內容和做網頁
原理： part3 Word 只會生一堆垃圾 html code 出來而已。
9. 不要用 PSD 自動轉 html 做版面
原理：拜託不要惡搞啊……這種 html 根本不能用
10. 檢查你的 robots.txt ，不要上線以後上面還是放了 disallow * ，再疑惑為什麼搜尋引擎沒有收錄
原理：廢話，你就叫搜尋引擎不要抓啊。最好這樣上面還會收錄你的內容。
11. 不要故意亂塞關鍵字，再用 css 技巧做 display :none
原理：搜尋引擎不是白痴。你這樣做的話會被視為作弊，列入黑名單。
1. 網站使用 valid html 撰寫，最好過 w3c validator
原理：這是一定要的，原因如 part3。
2. 使用正確的 html 標記描述內容與網站的元素。該用 h1,h2, strong, p 的請不要客氣
原理：這是一定要的，原因如 part3。
3. 網頁敘述要含關鍵內容。關鍵字越前面越好。（但並非 abuse）
原理：可觀察 Google 的 SERP （Search Engine Result Page）
4. 網頁 title 要含關鍵字。關鍵字越前面越好。（但並非 abuse）
原理：可觀察 Google 的 SERP （Search Engine Result Page）
5. 網址要含關鍵字。WordPress 在這方面設計的相當好，只要你把選項打開就行了。至於其他的內容網站，你可以考慮在背景使用 Google Translate 將網址標題轉成英文然後 append 在網址上。
原理：可觀察 Google 的 SERP （Search Engine Result Page）
其中權重 5 > 4 > 3 。
6. 因為 3,4,5 的關係，生產內容時必須遵守 SEO 原則，程式設計上也必須做出搭配。請看 part3。
7. 圖片內容，請加 alt 描述這張圖片。但 alt 字數也別太誇張，否則會视為 cheating。如果這是選單或 banner，請用 ul, li 和 h1,h2 寫，再用 CSS 技巧換掉。別來個 img + a 做 banner 的設計，img 權重遠低於 h1。
原理： part3。
8. 把內容放在 Search Engine highly friendly 的平台，如果是你想在 Yahoo 取得高排名，請放 Wretch，如果你想在 Google 取得高排名，請放 Blogger.com。如果你是自己 hosting，請檢視你的平台是否有做到 checklist 上的要求。
原理： 搜尋引擎偏好自家產品，結果會出現在比較前面
9. 為網站生成符合標準的 sitemap.xml。並主動將結果送至 Google、Yahoo、Bing 等等。
原理：搜尋引擎仰賴自己設計的爬蟲去抓取內容，他們的 index 路徑是遵循著網站上的內部連結以及外部連結，至於沒有被連結到網頁，自然就不會被收錄。他們沒有通靈能力，自然不知道你有產出這樣的內容。你必須主動告知他們。另外，sitemap 可以標記內容在該站的權重以及內容更新時間。有效提供 Search Engine 運算依據。這一點非常重要，根據我曾經做過的實驗，某搜尋引擎有送 sitemap 跟沒送，排名結果差非常非常多。
10. 在高 PR 的網站為自己的網站帶來 inbound link。
原理：眾所諸知，Google 的演算法是 Page Rank 演算法。PR 演算法簡單的想法是：如果一個網站，越多網站甚至是超級大站都連結這個網站，那麼它必定是重要的。但切記千萬別 abuse。
11. 提昇網站效能，開啟速度要快。
原理：網站速度，也是搜尋引擎排名的考慮因素之一。
12. 使用 Google Webmaster Tool 檢視你的網站 SEO 成效。
原理：它真的很好用….
千萬不要做的事
1. 千萬不要濫用以上原則，搜尋引擎不是笨蛋，不會不知道你想作弊。適度的標記關鍵內容就能使你的排名大幅提昇。但是濫用會造成你被下架。
原理：常識。
2. 不要把主要內容放在 image/ js / flash/ iframe 內。
原理： bot 只吃該頁的 html，image / js/flash/iframe 對他們來說只是一行外部網址。它們不會知道這是內容
3. 不要在 a 裡面加 onclick / onmouseover 類似的屬性。
原理：這多半指稱這是 js link，搜尋引擎會跳過這個 a 內的內容。如果你要上計算人氣等功能，請用 Unobtrusive Javascript 技巧實作。如果你只是想要做 css hover 效果，那就更欠人罵了，可以用 CSS 寫的東西為何要放上 a 去破壞 SEO 效果。
4. 連結不要濫用 302 redirect。
原理：http response 的 301, 302 是有意義的。301 指的是永久性重導向，302 指的是暫時性重導向，但 RD 寫 code 往往沒有深究其意義。我曾經見過人氣系統用 302 設計先轉去人氣系統再跳回來。Epic Fail。302 對搜尋引擎來說是「完全不值得收錄」的內容，因為他是「暫時性網址」。如果網站全站都掛 302 連結，那……沒有搜尋引擎想要收錄超正常。
5. 標籤不要亂包。我曾經看過一行 html 是這樣寫的 <h1><a href="xxx"> abc </a><img src="def"/></h1> 。搜尋引擎不知道重要的是 abc 還是沒有 alt 的 def。最後是連 abc 都被視為不重要內容。
原理：你讓搜尋引擎精神錯亂。
6. 每一頁的 title 與 meta description 不要重複
原理：搜尋引擎很大的權重採用 title 與 meta description。如果一個網站 50 頁 + 的 title 和 meta description 都一樣。搜尋引擎不會知道哪一頁是真正的入口點，真正重要的內容。下場就是全部都不收錄！！！
7. meta keywords 不重要
原理：Google 不採用。Yahoo 採用。但權重不大。因為 meta keywords 曾經被大家濫用 …但如果你拿 meta keywords 來做 correct 字義的功能，是不錯的。
8. 不要用 Word 生內容和做網頁
原理： part3 Word 只會生一堆垃圾 html code 出來而已。
9. 不要用 PSD 自動轉 html 做版面
原理：拜託不要惡搞啊……這種 html 根本不能用
10. 檢查你的 robots.txt ，不要上線以後上面還是放了 disallow * ，再疑惑為什麼搜尋引擎沒有收錄
原理：廢話，你就叫搜尋引擎不要抓啊。最好這樣上面還會收錄你的內容。
11. 不要故意亂塞關鍵字，再用 css 技巧做 display :none
原理：搜尋引擎不是白痴。你這樣做的話會被視為作弊，列入黑名單。
標籤：
網路行銷-SEO
2011年1月4日 星期二
軟體開發工程
一般軟體開發程序分為
需求整理==>系統分析==>系統設計==>程式開發==>系統測試==>系統維護
整個流程的控管稱為專案管理，所使用的標準稱為軟體標準，因為有了標準，我們才能將軟體各階段的程序與以量化，進而評估其價值與品質。以下針對各階段作一簡要描述：
1.需求整理：通常由了解市場需求或客戶為主要人員，其目的為整理未來軟體應具備之功能說明與要求(RFP)。此為所有軟體產品或專案成立時的第一要務，如果沒有完整的需求項目與功能說明及要求，之後各階段的開發也會因需求的變動而導致大量時間與成本的浪費。
2.系統分析：通常由具備專業知識(Domain Know How)之軟體人員擔任，其主要目的在於與提出需求者溝通協調，並將提出之需求，透過流程合理性加以整理成特定規格與表示方式來呈現，並與提出需求者確認，此階段常見之方式有UML 提出之Use Case、Use Case Diagram、Activity Diagram 等等，並且需提出系統所以功能及模組測試個案相關文件。
3.系統設計：通常由資深程式開發人員擔任，其具備資料庫/程式開發之專業知識與技術，此階段主要目的在於架構系統，將使用者分析資料轉述為程式流程，供程式開發人員參考並開發符合需求之系統功能。此階段為軟體開發最重要步驟，其介於使用者導向與系統導向之溝通橋樑，此階段常見之方式有UML 提出之Activity Diagram、Sequence Diagram、Table Definition 等等。
4.程式開發：由一般程式設計師擔任，此工作內容主要以系統設計定義的規範來實作，此人員完成之產物主要為程式原始碼，並且應自行完成所撰寫程式之基本測試，主要包括所有API之輸出輸入測試及確定所有程式碼均有執行到且無錯誤。
5.系統測試：通常由一般人員偕同系統分析師根據[功能及模組測試個案相關文件]進行測試，主要為驗證模組及流程之輸出入功能是否符合客戶需求，分為阿法測試及貝塔測試兩類，前者為開發人員進行之測試驗證，後者為確認無誤後交由User之驗證程序，此階段需使用錯誤處理機制詳加紀錄，主要用於確認測試之問題所屬之類型(ex. 程式bug 或 規格異動 或 畫面調整等)。
6.系統交付與上線：通常由系統分析與專案管理人員擔任，此階段通常為軟體或專案開發最難處理的階段，其原因在於使用者對系統的認知與時間誤差，導致無法明確掌握系統結案時程，此階段最需要的是溝通與協調以及問題處理的效率，因此具備善於溝通協調的系統分析人員與問題處理的程式設計師是能夠縮短此階段的時程，但現實環境卻是最難實行的，也因此成為所有軟體開發一大阻礙。
需求整理==>系統分析==>系統設計==>程式開發==>系統測試==>系統維護
整個流程的控管稱為專案管理，所使用的標準稱為軟體標準，因為有了標準，我們才能將軟體各階段的程序與以量化，進而評估其價值與品質。以下針對各階段作一簡要描述：
1.需求整理：通常由了解市場需求或客戶為主要人員，其目的為整理未來軟體應具備之功能說明與要求(RFP)。此為所有軟體產品或專案成立時的第一要務，如果沒有完整的需求項目與功能說明及要求，之後各階段的開發也會因需求的變動而導致大量時間與成本的浪費。
2.系統分析：通常由具備專業知識(Domain Know How)之軟體人員擔任，其主要目的在於與提出需求者溝通協調，並將提出之需求，透過流程合理性加以整理成特定規格與表示方式來呈現，並與提出需求者確認，此階段常見之方式有UML 提出之Use Case、Use Case Diagram、Activity Diagram 等等，並且需提出系統所以功能及模組測試個案相關文件。
3.系統設計：通常由資深程式開發人員擔任，其具備資料庫/程式開發之專業知識與技術，此階段主要目的在於架構系統，將使用者分析資料轉述為程式流程，供程式開發人員參考並開發符合需求之系統功能。此階段為軟體開發最重要步驟，其介於使用者導向與系統導向之溝通橋樑，此階段常見之方式有UML 提出之Activity Diagram、Sequence Diagram、Table Definition 等等。
4.程式開發：由一般程式設計師擔任，此工作內容主要以系統設計定義的規範來實作，此人員完成之產物主要為程式原始碼，並且應自行完成所撰寫程式之基本測試，主要包括所有API之輸出輸入測試及確定所有程式碼均有執行到且無錯誤。
5.系統測試：通常由一般人員偕同系統分析師根據[功能及模組測試個案相關文件]進行測試，主要為驗證模組及流程之輸出入功能是否符合客戶需求，分為阿法測試及貝塔測試兩類，前者為開發人員進行之測試驗證，後者為確認無誤後交由User之驗證程序，此階段需使用錯誤處理機制詳加紀錄，主要用於確認測試之問題所屬之類型(ex. 程式bug 或 規格異動 或 畫面調整等)。
6.系統交付與上線：通常由系統分析與專案管理人員擔任，此階段通常為軟體或專案開發最難處理的階段，其原因在於使用者對系統的認知與時間誤差，導致無法明確掌握系統結案時程，此階段最需要的是溝通與協調以及問題處理的效率，因此具備善於溝通協調的系統分析人員與問題處理的程式設計師是能夠縮短此階段的時程，但現實環境卻是最難實行的，也因此成為所有軟體開發一大阻礙。
標籤：
經驗分享
專案人生─(6)專案團隊的組成類型
以下將「專案經理」的強弱和「專案成員」的強弱做為兩個維度，列出四種專案團隊的組合
(那些只出意見不做事的Sponsor或是高層主管，在此先略過不提)
A型團隊(經理弱，成員弱)
這是一般人最怕待到的專案團隊，也是老板的夢魘。如果不是搞不清楚狀況的話，通常是有特別原因才會推出這種組合去打仗。事情做不好，又做不完，大家累得要死又沒人鼓勵，專案經理報喜不報憂，這種團隊能完成專案的機率很低，大概低於50%。就算能結案，公司和專案成員大概也得遍體麟傷。
B型團隊(經理弱，成員強)
以西遊記團隊為例，相對於三位徒弟，除了佛法和緊箍咒之外，唐僧算是比較弱的一位成員；再以三國中的劉備團隊為例，論計謀用兵，劉備比不過孔明，要扁人開打，劉備又比不過關羽和張飛，但是劉備能夠讓團隊成員服從命令，共同為理想和目標而打拚，也是一種領導模式。這種團隊成功機率大於A型團隊，大概50%-75%之間。
C型團隊(經理強，成員弱)
以前面提過的江戶川柯南為例，每次解決案子，都是靠柯南一個人就搞定了，阿笠博士、小蘭、灰原哀、毛利小五郎….等人，不過是角色或輕或重的配角罷了。在這種團隊做事，好處是：專案經理無所不能，對外可搞定客戶及老板，對內可協助專案成員解決問題；壞處是：整個專案的credit很容易變成專案經理個人的credit，在他手底下要出頭天可能要等很久，因為沒有露臉的機會。這種團隊成功機率也大於A型團隊，大概50%-75%之間。
D型團隊(經理強，成員強)
這應該像是夢幻組合型的團隊了，在現實的職場生涯中，實在是可遇不可求。為什麼呢？如果真的有這麼強的團隊，一定會被老板拆成好幾個B型和C型團隊，這樣才有辦法應付較多的專案。再則，以中國人一山不容二虎的個性，要不了一兩年，成員就會有異動的心，想要自立門戶或更上一層樓(就像熱門樂團一個個單飛的主唱)。這種團隊成功機率最大，大概80%-90%之間。
說起來我很幸運，有看過D型團隊，專案經理的口頭禪是「我要成為海賊王！」，我還記得專案經理的名字，他叫「蒙其D魯夫」。
D型團隊另外一個代表是 "沉默的艦隊"
C型團隊假以時日是可以訓練成D型團隊的, 這種故事電影裡面很多的.
B型團隊如果頭兒管不住底下的成員, 就會向A型團隊靠攏.
A型團隊也有可能是實驗性質的團隊, 把一羣不知道該怎麼擺的人全部集中成一個Team, 做的好是公司賺到, 做不好的話是整個Team裁掉, 一羣人統統回家吃自己.
(那些只出意見不做事的Sponsor或是高層主管，在此先略過不提)
A型團隊(經理弱，成員弱)
這是一般人最怕待到的專案團隊，也是老板的夢魘。如果不是搞不清楚狀況的話，通常是有特別原因才會推出這種組合去打仗。事情做不好，又做不完，大家累得要死又沒人鼓勵，專案經理報喜不報憂，這種團隊能完成專案的機率很低，大概低於50%。就算能結案，公司和專案成員大概也得遍體麟傷。
B型團隊(經理弱，成員強)
以西遊記團隊為例，相對於三位徒弟，除了佛法和緊箍咒之外，唐僧算是比較弱的一位成員；再以三國中的劉備團隊為例，論計謀用兵，劉備比不過孔明，要扁人開打，劉備又比不過關羽和張飛，但是劉備能夠讓團隊成員服從命令，共同為理想和目標而打拚，也是一種領導模式。這種團隊成功機率大於A型團隊，大概50%-75%之間。
C型團隊(經理強，成員弱)
以前面提過的江戶川柯南為例，每次解決案子，都是靠柯南一個人就搞定了，阿笠博士、小蘭、灰原哀、毛利小五郎….等人，不過是角色或輕或重的配角罷了。在這種團隊做事，好處是：專案經理無所不能，對外可搞定客戶及老板，對內可協助專案成員解決問題；壞處是：整個專案的credit很容易變成專案經理個人的credit，在他手底下要出頭天可能要等很久，因為沒有露臉的機會。這種團隊成功機率也大於A型團隊，大概50%-75%之間。
D型團隊(經理強，成員強)
這應該像是夢幻組合型的團隊了，在現實的職場生涯中，實在是可遇不可求。為什麼呢？如果真的有這麼強的團隊，一定會被老板拆成好幾個B型和C型團隊，這樣才有辦法應付較多的專案。再則，以中國人一山不容二虎的個性，要不了一兩年，成員就會有異動的心，想要自立門戶或更上一層樓(就像熱門樂團一個個單飛的主唱)。這種團隊成功機率最大，大概80%-90%之間。
說起來我很幸運，有看過D型團隊，專案經理的口頭禪是「我要成為海賊王！」，我還記得專案經理的名字，他叫「蒙其D魯夫」。
D型團隊另外一個代表是 "沉默的艦隊"
C型團隊假以時日是可以訓練成D型團隊的, 這種故事電影裡面很多的.
B型團隊如果頭兒管不住底下的成員, 就會向A型團隊靠攏.
A型團隊也有可能是實驗性質的團隊, 把一羣不知道該怎麼擺的人全部集中成一個Team, 做的好是公司賺到, 做不好的話是整個Team裁掉, 一羣人統統回家吃自己.
標籤：
經驗分享
訂閱：
文章 (Atom)