Dev 2Share

作為一個前端語言, JavaScript 天生就註定要比其它任何一種語言要處理更多的字串。如何才能更有效地處理字串, 想必也是每個程式設計師最關心的問題。最近, 我看到有人很堅持地在程式中把個別的字串以陣列元素方式宣告, 然後把它們 join 起來, 說這樣才能達到最佳的效能, 其速度遠比使用字串的加號運算來得快! 起初我也半信半疑, 直到我寫了一個程式來仔細分析為止...

根據 Macworld 在 2012/6/6 所發表的一篇文章, 一位俄羅斯駭客聲稱已駭進 LinkedIn 的資料庫並盜走帳號資料, 然後把六百五十萬 (實際數字為 6,458,020) 個密碼公布在一個俄羅斯的論壇中作為證據 (僅公布密碼資料, 並無關連的帳戶名稱及其它資料)。這些密碼事實上並不是明文, 而是已經過 SHA-1 (SHA 是 Secure Hash Algorithm 的縮寫; SHA-1 是在 1995 年發表) 方式加密的...

當我們在設計網頁時, 對於文字所使用的寬度多半使用 Pixel 或者 Em 來表示。不過我記得在更早以前是廣泛地採用所謂的 Point; 這是跟印刷息息相關的單位, 但是近來已經不太使用了, 尤其是在網頁設計上...

差不多每隔一段時間, 就會看到有人又重覆的詢問這個問題, 或者雖然沒有問到這個問題, 卻不停的懷疑為什麼在某些網站可以做的事情, 在另一個網站上面卻不行。其實這些問題通通必須回歸到一個最基本的問題, 那就是請你恢復一下記憶, 你是用什麼方式建立你的網站的...

當我們在網頁上設計了表單, 讓使用者填寫資料, 使用者通常有很大的機率會因為各式各樣的原因而意外地跳出頁面。如果表單很簡單, 或者使用者根本還沒有填寫什麼資料, 那麼使用者就算不小心離開頁面, 也不會有什麼損失。但是如果使用者已經填寫了很多資料 (例如姓名、地址、電話等等), 但是在他按下確認按鈕之前, 卻不小心按到上一頁、下一頁、關閉分頁、關閉視窗等按鈕, 那麼不管他使用何種方式回到這一頁, 他曾經填寫的資料可能都無法救回來。除非你只寫網頁給別人用, 自己從不上網, 否則我相信你一定也遇過這種切身之痛 -- 花了幾十分鐘, 甚至幾個小時打進去的文章, 卻由於一個不小心的動作, 讓自己辛苦的成果在瞬間徹底消失了! 不瞞你說, 我自己遇過太多次此種痛苦的經驗, 導致我曾有一段很長的時間, 即使只是填入自己家裡的住址而已, 我也一定要開啟 Notepad 來打字(而且還要隨時存檔), 打完之後再把文字複製貼回網頁...

這個小工具是我使用 C#, Winform 在 Visual Studio 2010 上面開發的, 其主要目的原本是寫來專供自己使用, 但是一不小心把它做得似乎完整了一點, 覺得應該也可以拿來貢獻給其他人來用用, 所以就繼續稍為給它加了一點工, 順手連多國語言也做好了 (雖然目前只有繁體中文和英文而已, 但是框架是 OK 的, 可以擴充)...

在 .Net Framework 的基礎領域中, 事件處理模型一直是令人頭痛的一環。倒不是因為它真的有什麼難度, 而是因為 .Net Framework 稍嫌麻煩的處理方式, 以及它的一些難懂的特殊用語, 有時候還真的會讓人搞得眼花潦亂, 甚至退避三舍...

在某種情況下, 我們可能需要把一段過長的文字從中截斷, 並在截斷處以省略符號 (...) 取代, 表示這段文字其實尚未結束, 只是被省略。如果你的文字是從資格庫中取得, 那麼你可以從資料庫取出時就載斷字串並加上簡略字元後傳回; 然而, 如果你不想把原始資料真的截斷...

我們知道, 從 ASP.NET 2.0 開始，我們可以使用內建而且現成的 Membership、Roles、Profile 等等功能。而且如果你使用 Visual Studio 進行開發時, 你可以利用 ASP.NET 組態工具來建立 app_data 資料夾下的 aspnetdb 資料庫，裡面就是上述功能所使用的資料庫檔案。不過在上述情況中，你必須在本機上安裝有 SQL Express 來作為資料庫引擎。然而，畢竟 SQL Express 只能使用於小網站，其功能無論如何都不能與 SQL Server 相比擬。那麼你要如何將資料庫轉移到 SQL Server 而非 SQL Express 呢...

當我們使用 VS2010 開啟一個 Web Site 專案時, 如果把它使用 Publish 功能部署到一個 IIS Server 上面時, 那麼, 即使你在專案中明明已經指定套用 .Net Framework 4.0, 這個部署的動作並不會自動幫你套用到 IIS 設定...