1. 適當地使用On Error Resume Next ，避免網站程式發生錯誤時，出現重要資訊。
2. 盡量避免使用個人資料做為傳遞用參數, 個人資料包含身份證字號、ID、密碼等等。
3. 參數名稱盡量減低可讀性, 不要使用完整的英文單字, 以減低網友嘗試改變參數值以測試網站的動機。
4. 重要的參數傳遞必須編碼. 若不得已必需使用重要資料當參數，在送出參數之前，透過函式編碼；於接收頁再解碼。所謂重要參數如身份證字號、ID等。
5. 適當地網頁權限控管,有安全顧慮的網頁(如個人資料頁、與權限等級有關的資料頁)，須經權限處理，限制具權限的使用者才能讀取。可避免使用者直接輸入URL跳過正常流程來讀取不該讀取的資料。
6. 阻檔已知的資料隱碼(SQL Injection)漏洞。
作者: fanlijun 發表日期: 2006-04-28 21:36
以前我就用過破解swf格式的軟體，很長時間沒有用了，今天同事說需要破解swf格式的文件，刪除掉一些不需要的資訊，我在網站上面找了找，又看見了那個軟體，有可能你常用。
Imperator它可以將部分SWF文件還原成FLA文件，然後稍作修改就可以使用了。不過比較遺憾的是，這個軟體不太穩定，目前只能支援Flash Mx。在搜索引擎裏面輸入軟體名稱就
軟體的功能較為單一，所有的功能按鈕都可以在主界面中看到。單擊“選擇swf文件”按鈕打開要還原的SWF，然後單擊“保存lfa文件”按鈕，將swf文件以FLA格式保存，稍等後即可在保存文件夾下看到相應的FLA文件，所需要的時間是由文件的大小及內部的結構決定。最後就可以啟動Flash Mx打開課件進行重新加工修改了。
類似的Imperator FLA等都可以完成相應操作
(可能對於很多人來說,還算在加班…)引用自：http://cgi.blog.yam.com/trackback/1553803
這篇是寫給新同事以及我自己備忘用的，也歡迎大家提出指正。
在撰寫網頁程式時，有些基本的東西要非常注意，這樣寫出來的程式才不容易出現問題，也才能夠交給客戶。以下就是我自己的開發心得，供大家參考。
利用明確的指定方式來取得頁面傳來的變數
不管是 GET 或 POST 的參數，我會希望明確地指定它的型態，例如 id 應該是整數， content 是文字等。而且我也常常發現有人把接到這些變數後，沒有事先做處理就直接串到程式中，這是非常危險的一件事情！
最明顯的例子就是 SQL Injection 了，我想這應該不用多說了。總而言之，不要過份相信用戶端傳來的資訊，把它轉換成你能掌握的型態再用吧。
資料庫的連結每個頁面只作一次
資料庫連結是網站頁面常做的事情，但是儘可能不要讓一個頁面產生太多的資料庫連結。我們可以利用 Singleton 模式來取得資料庫連結物件，這樣可以確保程式裡只會用到一個資料庫連結；當然需要連結不同資料庫的話就另當別論。
所以我們要確定資料庫會在頁面初始化時連結，頁面結束時關閉。這樣有單一的入口與出口，程式也就不容易出現奇怪的問題。
相同的邏輯不要寫兩遍以上
如果發現有兩支程式會用到相同的程式邏輯時，不要猶豫，把它抽出來變成類別或函式 (最好是類別，原因在下一則) 。因為如果哪一天需要更新程式的邏輯時，你只需要更改一支程式即可。對健忘的人來說，這點尤其重要。
我就遇過有人把產生選單的邏輯重複寫在十多支程式裡，結果有次客戶要求要修正其中一個地方，可憐的維護人員 (就是我啦) 就得一支一支地去翻出來改。
利用物件來管理錯誤
我這裡指的錯誤是任何預期中的狀況，也就是你不希望使用者操作的方式，例如編號不存在或是檔案大小超過限制等。
當錯誤發生時，不要立刻結束，應該利用錯誤上升機制來讓通知上一層的程式，最後再由頁面控制程式來決定要如何處理錯誤。我常常會遇到有人在函式裡利用 exit 離開程式，但是這時候頁面的資料庫或其他物件等等都還沒釋放掉；雖然程式平台可能會幫你做，但那總是很難預期。
所以我建議不要使用函式，而改為使用物件的方法，然後利用類似 PEAR::isError() 來判斷是否執行成功；如果失敗的話就把錯誤往上丟，直到頁面能夠控制為止。
該釋放的要記得釋放
不管是物件還是資料庫，都應該在頁面結束前將它們銷毀或關閉，而不要過於依賴程式執行平台。網頁程式是很多人會同時存取的，如果沒有正確地將資源即時釋放掉的話，久而久之就會造成系統效能上的不穩定。
而釋放的動作要什麼時候做呢？記住一句話：誰開的就誰負責關。例如上面頁面控制程式開啟資料庫連結，那就在頁面控制程式的最後把資料庫連結關閉。類別建構函式產生的物件，就在類別解構程式裡銷毀。函式開的頭，當然就在函式尾收掉；不過有個例外，那就是這個函式如果本身就是要回傳產生的物件時，那就不能把它給釋放囉，而是要改為呼叫這個函式的程式來釋放。
利用樣版技術
樣版是用來分離程式邏輯與視覺頁面的，也常常有人用 MVC 這個模式來稱呼它。然而兩者分離除了不相互干擾外，其實還有一個好處：那就是程式可以在錯誤發生後，決定要顯示的結果。就像上面提到的錯誤管理，當我們在頁面控制程式取得錯誤訊息時，我們就可以而用置換樣版來避免掉頁面的錯誤，或者是導向別的處理程式。
這點我覺得 PHP 的 Smarty 就考慮得很好，因為它是後期頁面綁定 (Binding) ，而不會像傳統樣版引擎在前期就把頁面拉進程式處理，導致錯誤發生時徒然浪費處理時間 (當然要看怎麼設計的) 。
徹底瞭解開發環境的性質
網頁程式和一般應用程式 (例如視窗應用程式) 在本質上是有差異的，這些差異不僅是在操作上，就連執行的過程都非常的不一樣。雖然現在有 AJAX 或其他技術可以縮小彼此的差距，但是它還是建構在 HTTP 這個無狀態協定之上。身為網站程式開發人員，其實應該要瞭解這些基礎，而不要只熟稔某些已經被包裝過的技術就顯得自得意滿。
最簡單的就是伺服端程式與用戶端程式之間的溝通，例如 PHP 和 JavaScript 。我常常在網路上看見有人問道：要如何讓 PHP 和 JavaScript 之間的變數互通？如果瞭解 HTTP 執行的過程，那麼你就會自己發現這些問題的答案。
當我在DataGrid上按滑鼠左鍵, 將指到的那一行讀至TextBox
那在事件中不是要用DataGird.Click嗎?!
為何我讀取不到呢?
理想的作法是利用 CurrentCellChanged 事件。Click 事件用在整行被選擇時（按在最左端）。
假設是要第一欄的資料。
Dim row As Integer = Grid1.CurrentCell.RowNumber
Dim employeeId As String = DirectCast(Grid1(row, 0), String)
TextBox1.Text = employeeId
●敏捷軟體開發：原則、樣式及實務
●UML 精華第三版 : 標準物件模型語言 (UML Distilled, 3/e)
●極致軟體製程：專案應用(Extreme Programming Installed)
●規劃極致軟體製程 planning Extreme Programming
●極致軟體製程 (Extreme Programming Explained)
●Head First Design Patterns—深入淺出設計模式
●設計模式入門─物件導向設計的新觀點 (Design Patterns Explained)
●物件導向設計模式 Design Patterns
●重構─改善既有程式的設計
上面這幾本跟設計比較有關地 也不會太偏向某些語言 但是對UML要有一點概念
●使用案例寫作實務 – 寫作指南、祕訣與範本 (Writing Effective Use Cases)
這本跟分析有點關係 因為分析的書 大都結合在開發流程中
上網看的時候發現了這個小軟體
對想要練歌的人很有幫助，歌詞要找起來也方便多了…
http://ywliu.bigbig.com/
這裡可以抓到，不過具我的使用經驗…
還真是感謝這位仁兄做這麼方便的小東西出來…
1.很多檔案用手動方式找會比較快。或是把ID3裡左右兩欄都填好好像會比只有一欄找的快
2.切記，歌名、演唱者要正確～才找的到，上面有”-“、”02″數字等都會造成無法直接找到，建議是一邊聽歌一邊先修改後半部不正確的檔案ID3，或是先放一大輪～看到有空在看還沒抓到的不來修改。
3.Bug還有一些，用歌手OK～不過目前我還沒試成功用用歌名找
4.有的歌不是沒抓到，只是反應慢～應該是61歌詞庫本身的限制，好像他們資料庫並沒有做專輯預讀的功能，速度上反應不是很好…
5.MP3與歌詞檔的對應是用檔名作對應，如果跟61上面的抬頭檔名不同～常發生在有逗點的部分，或是後面有刮號註解的時候，必須用人工修改或是另存的方式。
Get Firefox!
如果你從 RC 開始用的話，可能有注意到 RC3 無法用 auto update 更新，不知道這是不是代表 RC3 就是最後的 release。
跟 1.0.x 比起來，一般使用者會注意到的明顯改進是：
* 程式開啟速度變快了
* 可以自動更新主程式
* 選項的配置改變（比較清楚）
* Windows 版 1.0.x 縮小後會將記憶體釋放，再開時會頓上一陣子，1.5 不會
* 清除隱私資料：快速清除 cookie/密碼/表單資料/瀏覽記錄…等
* 其他 2266 的請自已看 release notes
記憶體佔用的問題依然存在。
還在用 1.0.x 的使用者，建議更新至 1.5。
相關連結：
* 下載 Mozilla Firefox 1.5 英文版 / 正體中文版
* Mozilla 台灣討論區