Isaac的電腦世界

OS X 中的Wi-Fi Analyzer 工具 要對無線網絡進行分析及診斷， 首先要在PC中安裝Wi-Fi Analyzer 應用程式。 Wi-Fi Analyzer是一種可以檢察Wi-Fi 信號強弱，找出適合架設Wi-Fi 的Channel ， 搜尋附近Wi-Fi 接點及竊聽經Wi-Fi 傳送的網絡封包(這功能要視乎你的網卡是否支援監控模式）的工具。  在網絡上有不同的Wi-Fi Analyzer 供大家下載。 而在OS X 系統中， 其實已預設安裝了Wireless Diagnostics 程式。   在本文中， 會假定讀者對Wi-Fi 的專業名詞(如noise, ssid bssid 等)有基本的認識。 因此， 只會展示Wireless Diagnostics 的操作方法 。  Wireless Diagnostics  Wireless Diagnostics  是一個預設安裝在 OS X 系統的Wi-Fi 分析工具。 用戶可透過它的GUI 介面操作。  在主畫面中，按下option 鍵並點擊在上角的Wi-fi標記會出現Open Wireless Diagnostics。 然後點選它。 點擊工具列中的Window。 並會出現以下選項 如圖 1. Info     點取Info， 會顯示你現在所使用的Wi-fi資訊。 包括它的BSSID，Mac Address，Channel, Network Interface  等等資訊。 如下圖 2. Logs 點選Logs的話， 你可以選取想要收集的網絡介面日誌資訊。 要注意這設定需要重啓電腦才能生效。 並且它是會把收集到的資訊紀錄在電腦中。 因此當你不需要使用時，請記得把它關閉， 以免造成資源浪費。 3.Scan    點選Scan 的話，系統會立即掃描附近的AccessPoint  並列出它們的資料，包括SSID，Mac Address， Noise，RSSI，Channel 等等 資訊。另外系統也會對系統的現時環境作出評估， 列出最合適架設Wi-Fi 的 Channel。 以下圖 圖中的Summary， 就是系統對現在環境的評估。 Total 是系統偵擦到的AccessPoint 數目。 而Best 2.4GHz和Be

C# 的Dynamic Object  介紹 在 .Net 4.0 版本 ， C# 引入了動態編程。 實則上它並不是C# 語言的一部分 ， 因為它是通過引入Dynamic Language Runtime(DLR library) 來實現的 。 對DLR Library 有興趣的話 可瀏覽( https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/dynamic-language-runtime-overview )  但對於編譯語言(Compiled Language) 來說 ，  引入Dynamic 特性在當時(.Net 4.0 是在2010 發佈的)是一種大躍進 。 雖然 C# 中已有支援動態特性 ， 但C# 始終是一種編譯語言 。所以我還是建議如非必要的話，還是不要使用動態編程 。 如果靜態編譯是可以做到這個效果的話就用靜態編譯實現 。 因為使用動態編程的話 ， 在編譯時是不會提示你的程式碼會不會有錯誤 ， 因此大大增加了執行時出現錯誤的風險 。 而且由於動態編程是late-binding. 所以物件的類別在執行時才會決定 。這種做法相對於靜態編譯是會有執行效率低的問題。 因此 編寫C# 程式應該以靜態編程的方式為主 。 但在以下情況 ，  用動態編程來編寫會較為合適 需要興COM Object 互動 Duck typing 需要與dynamic script language 如IronPython 或Ironruby 等互動 。 以上的情況, 有興趣的讀者可從互聯網中參考，  本文的以下部分會集中 說明C# 中 動態編程的基本語法， 介紹ExpandObject, DynamicObject 和 IDynamicMetaObject 及ExpandoObject 和DynamicObject 的用法。 Dynamic Keyword 若要在C# 中使用dynamic object, dynamic 這個keyword 你是絕對需要知道的 。 當一個變量以dynamic 作為它的型態 。 便代表它是late-binding. 編譯器在執行編譯時不會判斷它的型態 。 因此

React Native 開發的匯率計算器(SmartCurrency Converter)   在上文（ https://isaaccodeandbusiness.blogspot.com/2018/02/react-react-native-react-vr.html） 中曾提及 使用React Native並配合Expo來開發手機應用程式 ，其中之一好處是可以快速地在手機中預覧開發出來的效果， 不必像開發Native 一樣要先Build 後再經USB 放在手機上。  本文將會以我放在Expo Cloud 的匯率計算器(SmartCurrencyConverter) 為例 介紹如何在手機中預覽，把程式放上Expo 的Cloud 中和我放在Expo Cloud 中匯率計算器(SmartCurrency Converter) Expo Client  首先需要在手機中下載Expo Client 然後按照官方教學 安裝Expo Cli https://expo.io/learn 在正在開發的項目的目錄下運行  之後便會生成一個QRCode  和Link  如下圖 使用剛在App Store 下載 的Expo Client 使用 Scan QR Code 便能在手機中打開你正在開發的手機應用程式了。 至於要把程式放上Expo Cloud 的話 則只需要開發目錄下 登入Expo Account 並運行以下指令便可 運行後會顯示 你項目所在的URL。 由於exp publish 會生成iphone的ipa檔 和 android 的 apk 在expo 的cloud上， 所以上載會需要花較長的時間，請耐心等候。  把生成的URL 復制貼上瀏覧器便可前往項目的專頁了 只要把專頁中右手邊的QR Code 分享出去，其他人就可以透過Expo Client 使用你編寫的手機應用程式了。 匯率計算器（SmartCurrencyConverter） 接下來的部分為大家介紹一下我放在Expo Client 上的手機應用程式 SmartCurrencyConverter 是一個讓用戶進行單一對或多對貨幣匯率計算的小工具， 除了提供現價查詢外，還可以使

React 自2013 React面世以來，React 的使用人數不斷增加， 而且它的使用範圍也越來越廣，從Web Page，Web App， Cross Platform Mobile 到現在新推出的React VR。因此， 我相信React是現在大多數開發者必學的Library 之一。 這篇文章會談及React 的基本概念，和React Native，React 和React VR 之間的應用和分別。 在開始講解React 之前，我會先向大家展示我在互聯網找到關於React  的統計數據。 React 在Javascript framework 中的排名 以下圖片是從  https://hotframeworks.com/languages/javascript 中獲得 上圖展示出，React 在2016 開始便一直有90 的評分，證明用家對React 的評價也不錯，它只是屈居Angular JS之後，但Angular  JS 是一個早於React 面世的 JS Framework ， 它於2009 年便推出。 所以仍然有很多用者。 但從上圖可見，Angular JS的分數已有開始下降的趨勢。 主要原因可能是因為其他Framework 的出現和Angular 2 的推出令原本的用戶感到沮喪吧。 再來下圖是React 在Website 中的使用率。 資料來源於  https://www.similartech.com/technologies/react-js 和  https://trends.builtwith.com/javascript/React/Market-Share 而大部分React 的增長率是原於JQuery  的使用者。 在眾多國家中， 美國為使用React 最多的國家，日本和 中國 緊隨其後。 最後，下圖為2017 年NPM (Node package manager) 中各Javascript Framework 的下載增長率。 資料來自於  https://www.npmjs.com/npm/state-of-javascript-frameworks-2017-part-1   Laurie Voss 的The State of  Javascript Fra

Extension Method(擴充功能)  相信大家在編寫程式的時候都會把一些通用的方法定義為靜態方法並放在自定義的靜態類別中 。 因為這樣做的話 ， 就能在程式透過調用該類別方法來獲得你想要的結果 。 如以下例子所示 ， 在一個名為EnumerableUtil 的類別中定義headThree 方法來拿取首3個元素 。 在程式的另一處呼叫該方法獲Enumerable 集合的首3個元素 。 在 .net framework 3.5 之前的版本 ， 以上的編寫風格可為非常常見 。 但在C#3.5 或之後的版本 ， 提供了另一種彈性更大的風格Extension Method(擴充方法) 為甚麼說它彈性比起Util風格更大呢?? 首先先看看以下例子 ， 以下定義了一個同樣是獲取Enumerable 集合首3個元素的方法在EnumerableExtension中。 並在Program.cs 中的Main 調用。 從上例看到 ， 使用Extension Method(擴充功能) 的話 ， 只需在方法的第一個參數前加上this。  它的呼叫形式與物件呼叫實例方法一樣 。 編程風格更與OOP(物件導向編程)相似 。 在.net framework3.5 或以後的版本 ， 當物件呼叫實例方法時 ，編譯器會嘗試尋找類別是否有定義這方法， 若沒有的話 ， 則編譯器會再尋找現在執行的命名空間和導入的命名空間是否有定義這方法 。 由於ExtensionMethodExample 命名空間中的EnumerableExtension 有定義headThree這方法 。 所以沒有編譯錯誤 。 另外一點是 ， 使用 Extension Method(擴充功能) ，  能讓程式的編寫更加簡潔 。 例如 想要計算IEnumerable<int> 類型 的頭3個元素的差。 使用Util 的編程風格時, 會是以下這樣 先在EnumerableUtil 中定義 計算 差的方法 再調用該方法 若是編寫Extension Method(擴充功能)  風格的話, 也是先在EnumerableExtension中定義計算差的方法