Dev 2Share

對於寫網頁的朋友而言, 或許和我一樣, 最害怕的問題就是, 在冗長的開發過程中解決了很多疑難雜症, 一路打通關之後, 卻在終於要發行到目標網站時, 才發生問題。這就像千辛萬苦爬上了 101 的頂樓, 才發現門竟然打不開...

最近遇到一個小需求。原本我為了讓使用者方便, 在不使用 TimePicker 的情況下, 讓他們可以手動方式輸入日期時間 (若使用 DateTimePicker 之類的工具, 效率會減少十倍)。然後我又幫他們自動加入當天的日期 (因為在大多數情況下, 他們需要輸入的日期都是當天, 但是都不是現在時間), 例如 "2014/9/30 "。接著, 我又下了 autofocus 屬性, 當網頁載入後, 讓這個文字框自動成為焦點, 因為這是第一個必須輸入的欄位。如此, 他們只要輸入時間的部份就行了。問題是, 他們每次要輸入時間時, 都必須再按一下滑鼠游標或者 End 鍵, 才能讓文字游標指到日期的後面, 這樣才能開始輸入時間。雖然這只是一個小工夫, 但是總讓人覺得討厭! 難道不能讓游標自動跑到最後面嗎?

在各式網站中用了一些 Log 套件之後, 我覺得其實有時候我們不一定需要那麼多複雜的功能, 或許我們只需要偶爾攔截並記錄一些例外錯誤而已。這時候, 我會推薦大家使用最簡單的方法, 也就是把網站中出現的所有例外情況都記在 Server 的 Event Log 裡面...

從 Visual Studio 2013 / .Net Framework 4.5.1 開始, 關於使用者驗證這件事, 可以說做了革命性的改變。大家在過去 12 年來再熟悉不過的表單驗證方式, 在這個版本中再也沒辦法使用 (或者更正確地說, 是沒辦法延用過去的做法)。相反地, 我發現它對 AD 認證的支援變得異常地簡單; 如果你在建立專案時選擇 Windows 驗證, 那麼你的網站自動可以抓取使用者的網域登入帳號, 不必再寫任何程式。如果你要寫的是企業內部網站的話, 就變得相當容易了。至於新的表單驗證方式, 我們會面臨的最大的困難在於不熟悉, 以及資訊太少(未來會慢慢變多, 這是確定的)。其實我是直到最近一個專案中需要用到表單驗證, 才突然驚覺它被改掉了。但是兩個多禮拜下來, 我覺得它其實基本上和原來的表單驗證方式並沒有太多的差異。你只要了解它的運作原理, 就會逐漸習慣...

Linq2Excel 是一個非常方便好用的小工具, 它是一個 Excel 專用的 LINQ Provider, 可以讓我們很快速地讀取 Excel (包括 Excel 2013) 的試算表。我們可以直接在 Visual Studio 中透過 NuGet 取得, 目前的版本是 1.7.1。如果你對這個套件有興趣, 你可以參考「LINQ - 實作 LinqToExcel」這篇文章, 足以讓你快速入門...

App_Code 是一個 ASP.NET 網站專案的特殊子目錄。如果你的專案不是 Web Site 專案而是 Web Application 專案, 你並不需要、也不應該特別建立一個 App_Code 子目錄來存放你的程式碼 -- 除非是為了某種特殊的目的。例如, 如果你希望幫網站加入動態產生版本的功能的話, 那麼你可以建立 App_Code 子目錄 (在這裡都使用 Web Application 專案), 並且在這個子目錄下隨便建立一個如下的類別檔...

我想, 凡是已經寫 ASP.NET 很久的程式設計師, 一定都知道如何透過 RegisterStartupScript(key, script) 和 RegisterClientScriptBlock(key, script) 這兩種指令在頁面中插入動態的 JavaScript 程式。但是只有這種方法嗎? 以下, 我要示範一個「超級小」的技巧, 以更簡單的方式達到相同或類似的功能。只不過, 這種方式比較適合「罐頭」式的 JavaScript 指令, 也就是比較偏向靜態、很少改變的 JavaScript 程式。我將使用 ASP.NET 的網頁的 PostBack 機制, 讓已經寫好的 JavaScript 程式在網頁 PostBack 之後自動執行...

在 C# 中 Enum 是一個純粹靜態的結構, 當你宣告了一個 enum, 那麼它的值就固定在那裡了, 你非得去更改它的定義, 才能看到內容項目的變更。那麼, 如果我們能把它的內容項目 (包括它的值) 變成動態的呢? 在接下去之前, 我必須先把它適用的情境清楚的描述一遍, 否則大家可能無法理解為什麼要這麼做...

當你下載並安裝 Visual Studio 2013 Preview 之後, 要如何建立一個使用 Entity Framework 的專案呢? 在以下文章裡, 我要示範一個使用 Code First 方式建立的專案。我所將描述的內容可以在以下影片中看到... 此外, 你也可以在「Code First 至新的資料庫」這篇文章裡找到相當完整的 Step by step 操作步驟 (中文)...

在我目前的工作中, 環境略為有點複雜, 牽涉到開發、測試和正式環境, 而使用的資料庫伺服器也有兩到三個。如果能夠動態地切換不同環境下所使用的資料庫連線字串, 一定對工作相當有幫助。當然, 如果我都寫 ADO.NET 指令去指定連線字串, 我自然可以動態地決定應該採用哪一個連線字串。但是, 我又不想放棄簡單易用的 GridView/FormView 搭配 SqlDataSource 的作業方式。無可誨言的, 對於那些許多很小型的資料表、很少的資料、很簡單的工作, 實在沒有什麼能比上述情境更方便處理了...

最近在編寫程式時, 注意到幾個關於程式註解的注意事項, 我把它記錄起來, 同時提供朋友們參考。註解內要怎麼斷行? 例如以下用來註解 interface 的程式行, 你在註解中把它斷行是無效的...

這是一個相當古老的問題。不過, 似乎也很久沒遇到過了。當今天再度遇到時, 突然被嚇了一跳。問題是這樣的, 當我們建立單元測試專案時, 如果你看到測試不成功的原因是什麼「System.ArgumentException: 此處不允許應用程式相對虛擬路徑 '~/'」之類莫名其妙的錯誤的話, 大概就是依照以下解法就對了...

今天在設計 Master-Detail 顯示畫面時, 面對煩雜的關聯資料, 一時突發奇想, 然後隨口問了公司的 DBA 老大, 想請教他有沒有什麼想法, 結果竟然有解法, 而且異常的簡單! 所以就有了這一篇文章的出現。(順便說一下, 對一個沒有時間去鑽研資料庫的開發人員而言, 公司裡有位 DBA 是件蠻幸福的事情)...

我當過電腦講師、寫過不少文章、也在國內外各個 ASP.NET 討論區轉戰了好幾年, 接觸過無以數計想學網站設計的新手或學生。在這麼多人裡面, 我大致上可以歸納出一種或少數幾種性質蠻接近的族群, 這些人有共同的特色、遇到相同的問題、也有相同的盲點。我現在要在這裡給這些人提供幾點小小的建議。

這些人有個共同的特色, 那就是不完全清楚網站運作的基本邏輯。我時常喜歡打個比方: 以電視 (尤其是陰極射線管的電視) 為例, 我們在看電視時, 總以為電視上的圖像總是永遠是連續的, 但其實電視的畫面是從上到下、從左到右一點一點畫出來的, 每秒畫三十幀 (略估), 然後靠畫面上螢光物質的暫時殘留現象, 讓人眼 (其實人眼也有視覺殘留效應) 看不出來它其實是每秒三十次一直重畫的...

在 VS2013 Preview 中, 我們可以透過它的 Scaffolding (支架) 功能在 MVC 專案中快速建立一整套的 CRUD 網頁, 不用寫一行程式碼。甚至, 它已經內建了 Bootstrap 框架, 這使得我們甚至不需要具備美工能力, 也能設計出比以前漂亮得多的網頁...

微軟在近日 (2013/6/26) 公開了最新的 Visual Studio 2013 Preview (預覽) 版本; 我在前幾天的發文中也有提到過。不過, 到底這個最新版本有什麼不一樣之處? 微軟又為什麼在短短一年之後, 再度推出 Visual Studio 的新版本? 由於現在的資訊都不充份, 我想, 唯一, 也是最好的答案, 恐怕也只有 Scott Hanselman (現任微軟 Azure & Web Tools 的 Principal Community Architect 兼書籍作者) 能夠回答你了...

下載 Visual Studio 2013 Preview 之後, 我迫不急待地把它安裝起來, 並且建立了幾個測試用的專案。我把幾個值得注意的細節記錄起來, 同時供大家做個參考...

Bootstrap 是由 Twitter 所開發的一個免費的網頁框架, 它提供了許多從基本到進階的 CSS 和 JavaScript 功能, 讓網頁開發者可以很快速地把網頁架起來, 同時還兼顧了還算不錯的美感。通常, 網頁設計師不會、也不懂得美工設計, 所以我們如果只是很單地把網頁建立起來, 很不幸的, 這個網頁通常不會跟「美觀」這兩個字有交集。但是有了 Bootstrap, 你的網頁很容易就能讓人為之驚艷 (尤其是跟之前的做法對比的話)。
當然, 我不是說 Bootstrap 從此會讓美工人員丟掉工作。我相信美工人員也會感謝 Bootstrap 的存在, 這樣至少可以讓網頁在進行 layout 時省去一些功夫, 能夠早一點下班。
其實 Bootstrap 的應用方式並不難, 但是對於完全沒有概念的人, 仍然存在著一點門檻。在這裡, 讓我花點篇幅解釋一下...

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

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