全端開發人員天梯

在上一篇文章JSX基本篇裡面我們已經針對JSX的原理和使用方法做了一些基本的說明，接下來就來談一些實際開發時的使用技巧吧！

有些系統在開發時，常常會直接用真實世界資料庫中的資料做為測試案例，這樣在開發時會更貼近實際需求的行為；而當使用SpecFlow來描述Feature時，把真實資料庫中的資料轉成相關資料的Table時有一些小技巧可以使用。

Emotion API是微軟Project Oxford專案提供的一組API，用來辨識圖片中人臉部上的情緒。之前曾經看到一篇文章：「不負責研究之程式開發者調查：java 工程師最年輕，但是臉最臭」；利用GitHub上的developers照片配合Face API來分析各種語言開發人員的臉部特徵。覺得這是個滿有趣的主題，於是想說也來玩玩看，改用Emotion API來分析看看Apple、Facebook、Microsoft等公司工程師的表情如何。

JSX與法是React中很特別的一個部分，它可以讓你用JavaScript產出HTML時用最直覺的方式去表達，也就是類似直接撰寫HTML的方式，大幅簡化產出元件的難度，今天我們就來比較深入的了解JSX！

Build 2016過後微軟投出了很多讓開發人員感到驚豔的震撼彈，像是Win10未來可以run原生的使用linux指令，Xamrian免費等等。趁著連假也惡補了幾段內容，其中「The Future of C#」談到了一些未來C# 7的新語法，讓人感到滿興奮的，因此在這邊做個簡單的紀錄。

上一篇文章「[React速成班]從TodoList範例學習React(2)-透過實作TodoItems學習props」中，我們學到如何使用props來取得元件傳遞的參數值，也實作了TodoItems及TodoItem元件，藉此了解props的應用。接下來我們將透過實作AddTodoForm部分，來學習React中state的使用。

上一篇文章「[React速成班]從TodoList範例學習React(1)-基本架構」中，我們學到了在React的世界中，一切都是由元件組成的，也在基於這樣概念中把TodoList基本上需要的元件框出來，接下來在這篇文章中我們將實作TodoItems的部分，順便學習React中元件與元件資料傳遞的方法。

除非我們做的都是純靜態的頁面，否則在前端處理資料一定會是一個重要的議題，在React中，對於資料的處理或傳遞有兩個主要的屬性：props和state。而props就是用來作為元件與元件之間傳遞資料的媒介。

接下來終於要開始透過從實做一個TodoList來學習React啦！本篇文章將會先對React的特色簡單做一些基本且必要的介紹，然後先框好我們的TodoList基本的內容，之後在後續文章一個一個去完成它。

單純以程式碼Highlight來說的話，Sublimt Text 3算是個人感覺看起來最舒服的(雖然我還是偏好使用Visual Studio Code)，所以這篇就來快速說明一下如何設定讓Sublime Text 3可以支援JSX檔的Highlight吧！

要讓Visual Studio Code開發React的語法highlight不要亂掉，只需要把.js檔改為.jsx檔即可，不過大部分React的範例還是會用.js檔來完成，這樣會造成我們在閱讀別人程式碼時的不便，所以今天就來介紹一下如何用Visual Studio Code開發React時可以在.js檔內開發JSX也不會造成highlight的問題，另外也介紹一下如何讓Visual Studio Code支援React的intellisense。

俗話說得好，好的IDE帶你上天堂，壞的IDE讓你時程delay住套房。在寫todo list練習之前，先讓我用幾篇文章來介紹一下IDE的部分。React雖然熱門，但畢竟還算是比較新的東西，所以許多常見編輯器或IDE針對React的支援度都還是有限，最常見的問題就是把JSX程式碼存成.js檔時，由於一般都會在裡面插入類似HTML的JSX語法，結果就導致了大部分編輯器語法highlight出錯。不過畢竟React可是當今世上最熱門的library啊，當然許多主流的編輯器還是多少都有支援的。今天就在不要太貪心，只要求語法highlight不要出錯、不管是否有autocomplete、intellisense等其他酷炫功能的條件下，來比較幾款常見的程式編輯器。

如果要說2015年最熱門的前端框架，那肯定非React莫屬了！之前看到一篇PTT上的文章「[心得] 前端/Front-End/F2E面試心得分享(22間)」，作者發表了他個人面試22間公司的心得，其中以可以看到多數的公司現在都開始趨向使用React，其中也有提到一些目前AngularJS的問題，對於已經使用AngularJS一段時間的我來說也頗為感同身受！雖然即將現身(?)的Anular 2會對一些常見的問題進行改善，但跟風學學現在熱門的東西也不是個壞事...所以就決定摸索看看React。
 

使用Unity進行相依注入的時候，比較常見都是一個Interface對一個實作的Class，但是需求變得複雜，經過幾次重構後，很可能會拉出一個Interface出來，再由不同的Class去實作它，這時候要進行DI時code改怎麼寫？

在之前的文章中，我們已經可以在一般呼叫API的情況下將回傳的JSON格式統一，且在Exception發生時也能夠將Exception已我們想要的格式回傳，但由於Asp.Net WebApi已經先幫我們做好了找不到正確的Controller和Action時的處理，導致當呼叫不存在的API時，還是無法依照想要的JSON格式回傳，這篇文章就來解決這個問題。

在設計ASP.NET相關程式的時候，有時候我們必須在Global.asax中加入一些自訂的程式，例如希望每次Request時只會進行一次資料庫連線的建立，則可以在Application_BeginRequest中建立資料庫連線，然後在Application_EndRequest中將連線dispose掉。而在這個階段的處理若有exception時，之前的系列文章介紹的方法將無法正確處理傳回統一的JSON格式；如果有在Global.asax中做其他的處理，也希望在這裡有exception時可以用統一的方式回傳JSON結果，那們我們必須另外在Global.asax中處理這個錯誤。

本文章將簡單介紹TestStack.White這個Windows UI自動化測試的套件，並對一個簡單的加法器Windows Form程式進行Windows UI的自動化測試。

在上一篇文章「統一回傳訊息格式比較完整的處理方法 (2) Action中Exception處理」中，我們增加了一個繼承自ExceptionFilterAttribute的類別讓在Action中的方法產生例外時可以用統一的格式回傳。

在上一篇文章「統一回傳訊息格式比較完整的處理方法 (1)回傳訊息統一」中，我們利用自訂ActionFilter的方法成功把所有WebApi回傳的結果包裝成一個統一的格式，接下來我們會面臨到出現錯誤時，也要依照我們自己定義的格式回傳JSON。

由於目前有一個實作Api Server的需求，是會開放給很多第三方使用的，因此需要不管任何情況(包含各種Exception)都將回傳的內容格式完全統一，以方便其他使用Api的人容易解讀內容'，研究了一整天，終於有點結論了。

在使用jquery.unobtrusive時，可以在html表單欄位標籤中加入特殊屬性，讓表單在送出時自動驗證欄位而不必額外撰寫javascript就可以達到client端的驗證。不過當動態增加表單驗證欄位時，送出會無法對這些欄位檢查