分別於今年 2 月及 4 月於松山文創美國創意中心演講的課程投影片，簡介 Azure Machine Learning 以及微軟提供的各項創業所需要的資源，如 BizSpark 等:
![[AIC課程] 初探「機器學習」與創業資源](https://i0.wp.com/accupassv3storage.blob.core.windows.net/userupload/4bebec5fae99414790d3a6ae3a857181.jpg)
相關閱讀:
1. 本部落格 Machine Learning 系列文章 (中文): http://blogs.msdn.com/b/mengtsai/archive/tags/machine+learning/
2. Microsoft Azure 機器學習官方學習網站 (含教學影片及文件): http://azure.microsoft.com/zh-tw/documentation/services/machine-learning/
3. 美國創意中心 (American Innovation Center) FB: https://www.facebook.com/twaic?fref=ts
微軟在今年三月揭示了未來的 Universal Apps，將能在各種不同裝置上執行的願景。這些裝置包含了 PC, Mobile, IoT 裝置, Xbox, Surface Hub, 甚至 HoloLens。
那麼，要如何讓同一隻 Universal App 在這些不同的裝置上執行呢? Extension SDK 即是解答之一。
以往的作法是什麼?
我們先檢視一下在 Windows 8/8.1 上，欲同時開發 Windows Store App 及 Windows Phone App 的方法。我們可以將共享的程式碼 (如 Business Logic, Data Model, etc.) 實作於 Shared Projects 中，開發者只需額外處理如螢幕大小等 User Experience 上的不同。
但是，編譯之後將會產出兩份針對不同裝置的 Binary or Package，必需分別上傳至不同的 Store 作審核、也必需在不同的 Dev Center 之中作管理:
另一個開發者會面對到的問題是，當有些 API 只適用於某些裝置時，要如何處理呢? 例如 ：Windows Phone 手機上的實體 Back 鍵、Xbox One 的遙控器、HoloLens 的互動控制等，都不會出現在 Windows 平板上:
常見的處理方式即是 Compilation directives，透過 #if 語法，讓開發工具在編譯 (compile) 期間即決定某功能是否會被引入:
小結以上：
簡介 Extension SDK：
Windows 10 的 Extension SDK 即是要達成同一個應用程式 (Binary) 能執行在不同裝置上的解決方案：
如下圖。不同的裝置上都跑著 Windows Core，提供諸如 File I/O, Drivers 等基礎服務；UAP 則提供了一些通用型的控制項，也就是一群 API 的集合，作為通用型應用程式開發的基礎:
而在特定裝置上才提供的 APIs，則以 Extension SDK 的方式來實作，表現在圖中的話，即是以延伸的方式由 UAP 的通用型 APIs 再向外擴展:
實作 Extension SDK：
1. 透過 Project > Add Reference > Universal App Platform > Extensions ，即可新增您所需要的 Extension 至專案之中。各位可注意到其後有版本別，亦即可各自分別更新並被引入:
2. 接下來，即可於程式中使用 Windows.Foundation.Metadata.ApiInformation 這個 Class，在執行 (runtime) 期間判斷某 API 是否存在:
若您只想實作一小部份的 APIs，可以考慮直接使用 ApiInformation.IsTypePresent:
// Note: Cache the value instead of querying it more than once.
bool isHardwareButtonsAPIPresent =
Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons");
if (isHardwareButtonsAPIPresent)
{
Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
HardwareButtons_CameraPressed;
}
以上程式中，我們只需驗證此裝置是否支援 HardwareButtons 這個 class，若支援，則必定亦包含 CameraPressed 這個事件，我們即可放心的使用它。
當然，除了 IsTypePresent，我們也可使用 IsEventPresent, IsMethodPresent, IsPropertyPresent 測試個別的事件、方法、參數等是否存在:
bool isHardwareButtons_CameraPressedAPIPresent =
Windows.Foundation.Metadata.ApiInformation.IsEventPresent
("Windows.Phone.UI.Input.HardwareButtons", "CameraPressed");
小結：
另請注意，Extension SDK 的目的並非取代 #if 的功能，Compilation directives 的方式仍然是可行的!
註：
若要嘗試這些新功能:
同時：
1. 若您在測試過程中遇到問題:
2. 若您對 API 有任何新功能的需求，則可透過 Windows platform developer UserVoice site 來建議，這網站會在 BUILD 2015 前持續更新，反應最新的 API 功能。
延伸閱讀：
Windows 10 推出之後將支援許多種的輸入 (input) 方式，包括 Windows Hello 透過臉部特徵或虹膜取代密碼輸入、HoloLens 利用全息虛擬實境技術與人作 3D 互動等等。
本文則將介紹 Windows 10 加強後的筆跡 (Pen & Ink) 技術。 對開發者而言，多了 InkCanvas 控制項與基礎 DirectInk 類別，可以使用您已熟悉的程式語言如: C++、C# 或 Visual Basic 等，在 Windows 10 Apps 中實現更強大的筆跡功能。
比如：
叫出地圖後，用筆(或手指)畫上路線圖：
在連線遊戲中，即時紀錄如「狙擊手在右邊建築物屋頂」的筆跡訊息:
用原始筆跡回信：
或是先轉成文字…
Windows 10 在 Pen & Ink 的擴充性
要作到以上應用， Windows 10 提供的 InkCanvas 控制項定義了一個用於繪圖以及轉譯筆跡筆觸的重疊區域。此控制項的功能 (輸入、處理和轉譯) 則來自 InkPresenter、InkStroke、InkRecognizer 與 InkSynchronizer 等類別。
(目前使用 JavaScript 的 Windows 應用程式不支援這些類別)
也就是說，無論使用者是以「觸控筆」或是「手指」作輸入所得到的 “Ink” 物件，都能以原始筆跡、加上述解或描述 (metadata)、亦或轉譯成文字或圖檔等方式，作進一步創意的實踐。
開始實作吧!
假設我想在一個影像 (image) 上面疊一個筆跡畫布，在 XAML 描述中只要多加一個 InkCanvas 即可，非常直覺簡單:
<ScrollViewer>
<Grid>
<Image Source="Assets/signature.jpg" />
<InkCanvas x:Name="myInkCanvas" />
</Grid>
</ScrollViewer>
執行畫面如以下，各位可注意其中細微的筆觸差異，這些都會被紀錄在 Ink 物件中；同時寫字速度等資訊也會被紀錄下來，可作為進一步 (如筆跡辨認) 的應用。
想更進一步了解 Windows 10 在筆跡功能上的應用，請參考以下 10 分鐘的影片: (Developer’s Guide to Windows 10 Preview: (07) Pen & Ink)
https://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/07/player
註：
若要嘗試這些新功能:
同時：
1. 若您在測試過程中遇到問題:
2. 若您對 API 有任何新功能的需求，則可透過 Windows platform developer UserVoice site 來建議，這網站會在 BUILD 2015 前持續更新，反應最新的 API 功能。
本文將介紹 2 種全新的 XAML 作法， 來達到 Windows 10 的 UAP 中 “Adaptive User Interface” 的要求。讓我們的 App 在任何螢幕大小的環境之下，都能適切的調整元件的相對位置、或是動態改變元件的呈現方式。
1. RelativePanel：可決定控制項之間的相對位置
<RelativePanel>
<TextBox x:Name="textBox" Text="我是一段文字我是一段文字我是一段文字" />
<Button x:Name="yellowBtn" Background="Yellow" Content="黃色按鈕" RelativePanel.RightOf="textBox" />
<Button x:Name="blueBtn" Background="Blue" Content="藍色按鈕" RelativePanel.RightOf="textBox" RelativePanel.Below="yellowBtn" />
</RelativePanel>
「”yellowBtn” 將位於 “textBox” 的右邊；而 “blueBtn” 不但位於 “textBox” 的右邊，也會位於 “yellowBtn” 的下方。」
2. VisualStateManager：可根據螢幕的大小動態改變控制項的呈現方式
<TextBlock x:Name="text" Foreground="Azure" HorizontalAlignment="Center" VerticalAlignment="Center"/>
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="SizeStateGroup">
<VisualState x:Name="Min">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="0" />
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="text.Text" Value="喔喔好窄!!!!!" />
</VisualState.Setters>
</VisualState>
<VisualState x:Name="Middle">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="651" />
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="text.Text" Value="寬多了啊!!!!!" />
</VisualState.Setters>
</VisualState>
<VisualState x:Name="Wide">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1000" />
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="text.Text" Value="可…以…躺…下…了!!!!!" />
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
觀察以上的 XAML，我們只要注意兩點：
以白話文說明以上 XAML 描述:
「若 App 寬度至少為 0 pixel 的話，改變文字為 “喔喔好窄!!!!!”；若寬度至少為 651 的話，改為 “寬多了啊!!!!!”，若寬度至少為 1000 的話，改為”可…以…躺…下…了!!!!!”。」
以下是結果，請觀察寬度及文字的關係：
將以上的 RelativePanel 及 VisualStateManager 綜合使用，就可以作到微軟資深技術主管 Kevin Gallo 在 Mobile World Congress 2015 上的 Demo 效果 (約第 30:00 開始約 3 分鐘):
註：
若要嘗試這些新功能:
同時：
1. 若您在測試過程中遇到問題:
2. 若您對 API 有任何新功能的需求，則可透過 Windows platform developer UserVoice site 來建議，這網站會在 BUILD 2015 前持續更新，反應最新的 API 功能。
延伸閱讀：
Guide to Windows universal apps: https://msdn.microsoft.com/library/windows/apps/xaml/dn894631.aspx
如果您有開發過 Windows Store 或 Windows Phone App 的經驗，以下幫您整理了 Windows 10 Developer Preview (開發者預覽版本) 之新增功能。
當然，若要親自嘗試這些新功能:
同時：
1. 若您在測試過程中遇到問題:
2. 若您對 API 有任何新功能的需求，則可透過 Windows platform developer UserVoice site 來建議，這網站會在 BUILD 2015 前持續更新，反應最新的 API 功能。
以下即重貼來自 Windows 10 開發者預覽的新功能：
應用程式模型
|
檔案總管 |
新的 Windows.System.Launcher.LaunchFolderAsync 方法可讓您啟動 [檔案總管] 並顯示您指定的資料夾內容。 |
|
共用存放裝置 |
新的 Windows.ApplicationModel.DataTransfer.SharedStorageAccessManager 類別與其方法，可讓您在使用 URI 啟用啟動其他應用程式時，透過傳遞共用權杖來與另一個應用程式共用檔案。目標應用程式會兌換權杖，以取得來源應用程式共用的檔案。 |
|
設定 |
搭配 LaunchUriAsync 方法使用 ms-settings 通訊協定，顯示內建設定頁面。例如，下列程式碼會顯示 Wi-Fi 設定的頁面。 bool result = await Launcher.LaunchUriAsync(new Uri("ms-settings://network/wifi")); 如需您可以顯示之設定頁面的清單，請參閱如何使用 ms-settings 通訊協定顯示內建設定頁面。 |
控制項
|
WebView 更新 |
數個完整支援 HTML WebView 控制項的新 API 與事件，包含： · MSWebViewUnviewableContentIdentified 事件的 MediaType 屬性 · MSWebViewUnsupportedUriSchemeIdentified 事件 · MSWebViewNewWindowRequested 事件 · MSWebViewPermissionRequested 事件，適用於嘗試取得使用者同意以存取地理位置服務的WebView 內容。 |
|
使用者輸入的用戶端資料驗證 |
新的 XAML 控制項屬性可讓您收集和顯示資料驗證錯誤。您可以新增、移除或清除控制項上的ValidationErrors 集合。當 ValidationErrors 計數變成非零，唯讀 ValidationState 屬性就會變更，且控制項會顯示驗證錯誤指示器。 使用預設的指示器樣式，或透過以自訂樣式覆寫 ValidationIndicatorStyle 屬性的方式自訂資料驗證指示器。或者，您可以設定 IsValidationIndicatorEnabled 屬性來啟用或停用指示器。 |
|
Windows 核心文字 API |
新的 Windows.UI.Text.Core 命名空間提供一個可將鍵盤輸入處理程序集中至單一伺服器的主從式系統。 您可以使用它來管理您自訂文字輸入控制項的編輯緩衝區。文字輸入伺服器可透過應用程式和伺服器之間的非同步通訊通道，確保您的文字輸入控制項內容與其編輯緩衝區的內容一律保持同步。 |
|
輸入更新 |
有了 InkCanvas 控制項與基礎 DirectInk 類別之後，現在可以更容易地使用採用 C++、C# 或 Visual Basic 的 Windows 執行階段應用程式中強大的筆跡功能。 InkCanvas 控制項定義了一個用於繪圖及轉譯筆跡筆觸的重疊區域。這個控制項的功能 (輸入、處理和轉譯) 來自 InkPresenter、InkStroke、InkRecognizer 與 InkSynchronizer 類別。 重要 使用 JavaScript 的 Windows 應用程式不支援這些類別。 |
|
地圖 |
已經更新地圖控制項類別，以支援 Windows 10 Technical Preview 通用應用程式。這些 API 現在已屬於通用裝置系列。 |
裝置
|
位置 |
Windows 10 Technical Preview 導入了新方法 RequestAccessAsync，可以詢問使用者是否可存取其位置。 使用者可以利用 [設定] 應用程式中的 [位置隱私權設定]，來設定其位置資料的隱私權。您的應用程式只有在下列情況下，才可以存取使用者的位置或位置歷程記錄： · 定位已開啟 (不適用於 Windows 10 Technical Preview 手機版) · [讓 Windows 與您選擇的應用程式使用您的位置與位置歷程記錄] 設定已 [開啟] · 在 [選擇可以使用您的位置的應用程式] 底下，您的應用程式已設定為 [開啟] 請務必先呼叫 RequestAccessAsync，才能存取使用者的位置。此時，您的應用程式必須在前景且RequestAccessAsync 必須從 UI 執行緒呼叫。在使用者授與您的應用程式存取其位置的權限之前，您的應用程式無法存取位置資料。 |
|
AllJoyn |
Windows.Devices.AllJoyn Windows 執行階段命名空間引進了 Microsoft 的 AllJoyn 開放原始碼軟體架構和服務的實作。這些 API 讓您的通用 Windows 裝置應用程式參與 AllJoyn 驅動、物聯網 (IoT) 案例中的其他裝置得以實現。如需關於 AllJoyn C API 的詳細資料，請下載位於 AllSeen 聯盟的文件。 使用此版本中包含的 AllJoynCodeGen 工具，以產生可用來啟用您裝置應用程式中 AllJoyn 案例的 Windows 元件。 |
|
電池 |
Windows.Devices.Power 命名空間中的電池 API，可以讓應用程式深入了解執行您應用程式之裝置所連接的任何電池。 · 建立電池物件以代表個別的電池控制器，或是所有電池控制器的彙總 (當由 FromIdAsync 或AggregateBattery 個別建立時)。 · 使用 GetReport 方法傳回指示相對應電池的充電、容量及狀態的 BatteryReport 物件。 |
|
MIDI 裝置 |
新的 Windows.Devices.Midi 命名空間可讓您建立： · 可以與外部 MIDI 裝置通訊的應用程式。 · 與 Microsoft GS MIDI 軟體合成器直接通訊的應用程式和外部裝置。 · 多個用戶端同時存取單一 MIDI 連接埠的案例。 |
|
自訂的感應器支援 |
Windows.Devices.Sensors.Custom 命名空間可讓硬體開發人員定義新的自訂感應器類型，例如 CO2 感應器。 |
圖形和遊戲
|
DirectX |
Windows 10 Technical Preview 中的 DirectX 12 引進了下一版的 Microsoft Direct3D，也就是 DirectX 核心的 3D 圖形 API。Direct3D 12 圖形提高了低階、主控台式 API 的效率和效能。Direct3D 12 比以往更快更有效率。支援更豐富的場景、更多的物件、更複雜的效果，且能夠更有效地使用現代化圖形硬體。 |
媒體
|
HTTP 即時串流處理 |
您可以使用新的 AdaptiveMediaSource 類別，將彈性視訊串流功能新增到您的應用程式。物件已透過將它指向串流處理的資訊清單檔案來初始化。支援的資訊清單格式包含 Http 即時資料流 (HLS)、Dynamic Adaptive Streaming over HTTP (DASH) 與 Smooth Streaming。一旦物件繫結至 XAML 媒體元素，就會開始彈性播放。您可以查詢，並在適當時設定資料流屬性，例如可用、最小與最大位元速率。 |
|
適用於 Media Foundation Transforms (MFTs) 的 Media Foundation Transcode Video Processor (XVP) 支援 |
使用 Media Foundation Transforms (MFTs) 的 Windows 應用程式現在可以使用 Media Foundation Transcode Video Processor (XVP) 轉換、縮放及轉變原始影片資料： · 新的 MF_XVP_CALLER_ALLOCATES_OUTPUT 屬性支援對呼叫端配置紋理的輸出 (即使在 Microsoft DirectX 視訊加速 (DXVA) 模式中)。 · 新的 IMFVideoProcessorControl2 介面可讓您的應用程式啟用硬體效果、查詢支援的硬體效果，以及覆寫視訊處理器所執行的旋轉作業。 |
|
轉碼 |
新的 MediaProcessingTrigger API 可讓您的應用程式在背景工作中執行媒體轉碼，因此即使終止前景應用程式，轉碼作業仍然可以繼續執行。 |
|
MediaElement |
在 Windows 10 上，MediaElement 可播放包含多個串流的內容，即使其中一個串流發生解碼錯誤，只要媒體內容包含至少一個有效串流，便可繼續播放。例如，如果內容中的視訊串流包含音訊，而視訊串流失敗，則 MediaElement 仍然會播放音訊串流。PartialMediaFailureDetected 會通知您無法解碼串流中的一個串流。它也會讓您知道失敗串流的類型，以便在 UI 中反映該資訊。如果媒體串流中的所有串流皆失敗，就會引發 MediaFailed 事件。 |
|
傳統型應用程式的媒體傳輸控制項 |
ISystemMediaTransportControls 介面和相關的 API 可讓傳統型應用程式與內建系統媒體傳輸控制項互動。這包括使用傳輸控制項按鈕回應使用者互動，以及更新傳輸控制項顯示，以顯示目前播放媒體內容的中繼資料。 |
|
隨機存取 JPEG 編碼和解碼 |
新的 WIC 方法 IWICJpegFrameEncode 和 IWICJpegFrameDecode 可編碼和解碼 JPEG 影像。您現在也可以為影像資料編製索引，以提高大型影像隨機存取的效率，但是會耗用較多記憶體。 |
|
媒體組合的重疊 |
新的 MediaOverlay 和 MediaOverlayLayer API 可以讓您輕鬆地將多層靜態或動態媒體內容新增到媒體組合。每層可各自調整不透明度、位置和時間，您甚至可以為輸入層自行實作自訂的組合器。 |
|
新的效果架構 |
Windows.Media.Effects 命名空間提供簡單且直覺的架構，可為音訊和視訊串流新增效果。此架構包含基本的介面，可實作以建立自訂的音訊和視訊效果，並將之插入媒體管線。 |
網路功能
|
通訊端 |
通訊端更新包括： · 通訊端代理程式。通訊端代理程式可以代表處於應用程式週期中任何狀態的應用程式來建立及關閉通訊端連線。這可以讓應用程式和應用程式提供的服務更容易被找到。例如，透過通訊端代理程式，Win32 服務甚至在未執行時仍可接受連入通訊端連線。 · 改進輸送量。通訊端輸送量已針對使用 Windows.Networking.Sockets 命名空間的應用程式最佳化。 |
|
背景傳輸後續處理工作 |
Windows.Networking.BackgroundTransfer 命名空間中新的 API 可讓您註冊後續處理工作的群組。因此，即使您的應用程式不在前景，也可在背景傳輸成功或失敗時立即採取動作，而不是等到下次使用者繼續執行應用程式時才採取動作。 |
|
廣告的藍牙支援 |
有了 Windows.Devices.Bluetooth.Advertisement 命名空間，您的應用程式可以透過藍牙 LE 連線傳送、接收與篩選廣告。 |
|
Wi-Fi Direct API 更新 |
裝置代理程式已更新，可在不離開應用程式的情況下啟用裝置配對功能。Windows.Devices.WiFiDirect 命名空間的新增項目可讓裝置成為可供其他裝置搜尋的裝置，並讓裝置接聽連入連線通知。 注意 此版本中，Wi-Fi Direct 增強功能並未內建到 UX 中，且它們只支援一鍵配對。此外，此版本只支援一個使用中的連線。 |
|
JSON 支援改良功能 |
Windows.Data.Json 命名空間現在在偵錯工作階段期間轉換 JSON 物件時，對於現有的標準定義和開發人員體驗提供較好的支援。 |
安全性
|
ECC 加密 |
Windows.Security.Cryptography 命名空間中新的 API 支援了橢圓曲線加密法 (ECC)，這是以有限體上橢圓曲線為基礎的公開金鑰密碼編譯實作。ECC 演算方式比 RSA 更複雜，提供較小的金鑰大小、減少記憶體耗用量，並改善效能。它提供了 Microsoft 服務與客戶一種 RSA 金鑰和 NIST 核准曲線參數的替代方法。 |
系統服務
|
電源 |
現在在執行或停止執行省電模式時，會通知您的 Windows 傳統型應用程式。藉由回應電源條件變更，您的應用程式有機會可以協助延長電池使用時間。 · GUID_POWER_SAVING_STATUS： 使用這個新的 GUID 與 PowerSettingRegisterNotification 函式，即可在執行或停止執行省電模式時收到通知。 · SYSTEM_POWER_STATUS： 這個結構已經更新，以支援省電模式。第四個成員 SystemStatusFlag(先前稱為 Reserved1) 現在可指示省電模式是否已經執行。使用 GetSystemPowerStatus 函式來抓取這個結構的指標。 |
|
版本 |
您可以使用 Version Helper 函式判斷作業系統版本。針對 Windows 10，這些 Helper 函式包含新的函式IsWindows10OrGreater。當您想要判斷系統版本時，您應該使用 Helper 函式，而不是已過時的GetVersionEx 與 GetVersion 函式。如需如何取得系統版本的相關詳細資訊，請參閱取得系統版本。 如果您是使用已過時的 GetVersionEx 或 GetVersion 函式來取得 OSVERSIONINFOEX 或 OSVERSIONINFO結構中的版本資訊，請注意這些結構包含的版本號碼會從 6.3 (適用於 Windows 8.1 與 Windows Server 2012 R2) 增加到 10.0 (適用於 Windows 10 Technical Preview)。如需作業系統版本號碼的相關詳細資訊，請參閱作業系統版本。 在您的應用程式中，您也需要特別以 Windows 8.1 或 Windows 10 為目標，以取得這些利用 GetVersionEx或 GetVersion 函式取得之版本的正確版本資訊。如需如何將您的應用程式以這些 Windows 版本為目標的相關資訊，請參閱將您的應用程式以 Windows 為目標。 |
儲存空間
|
可供 Windows Phone 使用的檔案搜尋 API |
身為應用程式發行者，您可以新增延伸項目至應用程式資訊清單，以便註冊應用程式將儲存資料夾與您發行的其他應用程式共用。然後呼叫 Windows.Storage.ApplicationData.GetPublisherCacheFolder 方法取得共用的儲存位置。 Windows 執行階段應用程式的增強式安全性模型通常會防止應用程式彼此之間分享資料。但是，對於來自相同發行者的應用程式，在以每個使用者為基礎的方式下共用檔案和設定而言很有用。 |
工具與效能
|
屬性變更通知 |
Windows.UI.Xaml 命名空間現在定義了數個支援變更通知的 API，以控制識別為 DependencyObject 的屬性。 通知的運作方式類似於事件，但實際上會公開為回呼。回呼會像事件處理常式一樣接受傳送者引數，但不接受事件引數。相反地，只會傳遞屬性識別碼來指示屬性。您的應用程式可以利用此項資訊，為多個屬性通知定義單一處理常式。如需詳細資訊，請參閱 RegisterPropertyChangedCallback。 |
|
追蹤記錄 |
追蹤記錄是適用於使用者模式應用程式與核心模式驅動程式的新事件追蹤 API；它是建置在 Windows 事件追蹤 (ETW) 上。這個 API 提供簡化的方式來檢測程式碼，並包括含有事件的結構化資料，而不需要個別的檢測資訊清單 XML 檔案。 WinRT、.NET 與 C/C++ TraceLogging API 可用來為不同的開發人員對象提供服務。 |
使用者經驗
|
清單捲動虛擬化 |
XAML ListView 和 GridView 控制項具有新的 ListViewBase.ChooseItemContainer 事件，可在資料集合中發生變更時，改善控制項的效能。 相對於執行清單的完整重設 (這會重播進入動畫)，系統現在會保持目前檢視中的項目，以及焦點和選取的狀態；檢視區中新的項目和移除的項目會以動畫流暢地顯示進出。在資料集合中 (其中的容器未受到破壞) 進行變更後，應用程式可以快速地將任何「舊」項目與先前的容器比對，並跳過容器週期覆寫方法的進一步處理。只有「新」項目會被處理，並與回收的或新的容器產生關聯。 |
|
不同的應用程式平台之間的拖放功能 |
新的 Windows.ApplicationModel.DataTransfer.DragDrop 命名空間將拖放功能帶入 Windows 執行階段應用程式。目前來說，一般的傳統型程式拖放案例 (例如將資料夾中的文件拖曳到 Outlook 電子郵件訊息中以附加檔案) 在 Windows 執行階段應用程式是不可能的。使用這些新的 API，您的應用程式可讓使用者輕易地在不同的 Windows 執行階段應用程式和桌面之間移動資料。這絕對是比以往更好且更直覺化的應用程式經驗。 |
|
按鍵輸入瀏覽鍵盤快速鍵的支援 |
新的 Windows.UI.Xaml.KeyAccelerator 類別可讓您為您的 XAML 標記頁面宣告鍵盤快速鍵。鍵盤快速鍵會在按下特定按鍵 (以及選用的輔助按鍵) 時叫用指定的事件處理常式。您也可以使用 x:Uid 屬性與您的KeyAccelerator 來進行當地語系化。 |
網頁
|
Internet Explorer |
Internet Explorer 引進了「邊緣」模式：一種新的動態文件模式，針對搭配其他現代化瀏覽器和網頁內容最大互通性所設計。這個實驗模式已透過漸進方式提供給一組隨機選取的 Windows 開發人員預覽使用者。您可以透過新的 IE about:flags 機制手動啟用或停用邊緣模式。如需詳細資訊，請參閱： |
延伸閱讀：
微軟雲端副總裁 Scott Guthrie 日前宣佈了 “Azure for Students” 的方案，開放給所有學生，不用信用卡即能開始使用! 直接至 Microsoft Azure for DreamSpark 認證您的學生身份，即可免費使用 3 種公有雲服務:
Azure App Service (Web Apps): 建立具備 AutoScale 及 Load Balancing 功能的網站，可以選用 .NET, Java, PHP, Node.js, Python 等語言、支援 Git, TFS, GitHub 等版控工具之外，同時內建 WordPress, Umbraco, Joomla, Drupal 等樣版，可以套用後快速建立你自己的網站。
Visual Studio Online: 是專業的專案版控工具，不用安裝或設定伺服器，不到幾分鐘時間就可以在雲端基礎結構上順利運作。 Visual Studio Online 可連接至 Visual Studio、Eclipse、Xcode 和其他 Git 用戶端，支援各種平台和語言的開發。
Application Insights: 針對你的 Web 應用程式作效能、可用性等偵測，支援 ASP.NET 應用程式和 HTML 網站，提供使用頁面、事件和使用率等資料，也可以透過電子郵件即時收到警示，建立您的應用程式遙測機制。
“Azure for Students” 開通程序：
文中主要提示了即將發佈的 .NET 2015 在各種角度上的改變，包括對各平台的支援、走向開放等等。
在進入本文之前，她的結論提到身為多年的微軟人，親身經歷 .NET 走向開源的過程及感想，說出了許多人，尤其是長期關注微軟技術者的心聲，在此轉述如下:
“對微軟來說，開放原始碼並不是新的舉動，但對 .NET Runtime 函式庫卻是。這對一個超過 15 年的老專案是個非常重大的決定，對許多內部的員工來說，這開放的不是單單只有程式碼而已，而是將整個工程都開放出去。改變是需要時間的。所以這是為甚麼 .NET 小組剛開始只能釋出一小部分的物件函式庫。我們在未來需要有更長更遠的路要走。從決定開放也至於現今的成果，可以讓我們這個團隊學到這些舉動激起的漣漪、以及產生的貢獻，這些都讓我們自嘆不如。”
.NET 2015 – 主要架構
其中，針對 .NET Core 有以下三個主要的投資及改變:
1. .NET Innovation－微軟已將許多語言的編譯器重新設計、改良，以符合新一代開發者的需求，包括底層物件函式庫 (BCL: Base Class Libraries)、應用程式模型(App Models)、執行階段 (Runtimes) 及相關工具。
2. Open Source (開放原始碼)－微軟已將開發流程透過開源社群公開，也透過開源社群得到進一步的支援及協助，經由這樣與全世界開發者間的互動，一起培育 .NET 的生態系統。
3. Cross Platform (跨平台)－使用者的執行平台及環境越來越多樣，有鑑於此，讓 .NET 跨平台相容至 Linux, Mac 等平台上當然也是必需的。
.NET Framework 持續提供一個受控管的執行環境，於其上提供各種服務讓應用程式使用。.NET Framework 主要由兩個元件組成：其一是通用語言執行庫 (CLR)，CLR掌管並且提供應用程式的執行引擎；另一個元件是 .NET Framework 物件函式庫，是一組穩定且可重複使用使用的現成程式庫，讓他們能夠在自己的應用程式中呼叫使用。
.NET Framework 4.6 建立於 4.5.2 版之上，加入了許多新的 API，並且強化了事件追蹤 (Event tracing) 並修復了許多的Bug，這將會是下一個完整的.NET Framework! .NET Framework 4.6 也將會包含於 Windows 10 之中。先前的作業系統也可以透過 Windows Update 來取得最新的.NET Framework! (Vista 含以上的版本)
更多有關於.NET Framework 4.6的詳細資訊參考 .NET Framework 2015 Preview
.NET Core 5 是一個提供多種功能、模組化的設計框架 (framework)，能在橫跨多種平台的環境中使用，且為開放原始碼，將會支援Windows、Linux、Mac OSX。.NET Core 5 的內部架構包含底層物件函式庫 (corefx) 以及 Rutime (coreclr)，包括 JIT 編譯器 (RyuJIT)，.NET 回收機制 (GC)，原生語言互通性 (Native Interop)，以及其他.NET Rumtime 元件。
.NET Core 5 目前可運行在 Windows 上面，微軟也即將加入 Linux 以及 Mac 支援，讓 .NET 的主要元件能運行在這兩個平台上。
更多有關於 .NET Core 的詳細資訊請參考 Introducing .NET Core 以及 CoreCLR is now Open Source.
如果以上兩個詳細資訊您只想選一個來看，那我會推薦看 Introducing .NET Core，這會讓您瞭解為何我們需要 .NET Core，以及適合在那裡使用。
.NET 編譯器平台 (“Roslyn”) 提供開放原始碼 C# 以及 Visual Basic 的編譯器，並提供豐富的程式碼分析以及 API、並提供了程式碼分析工具。
為 .NET 2015 量身打造的 Roslyn，其平台與核心、框架皆使用獨立的中繼語言(IL) 所完成。在 .NET 2015 釋出之時，整個 .NET Framework 將都會是由 Roslyn 所編譯完成的。除此之中，在 C#、VB 甚至 F# 語言本身都將有重大的革新。
Roslyn 的專案已開放原始碼放置在 Roslyn on GitHub。
“RyuJIT” 是 .NET 在 64 位元平台上的全新預設 JUST-IN-TIME(JIT) 編譯器。於執行期間，JIT編譯器將使用中繼語言 (IL)，即時編譯於目標機器中執行。
在桌上型電腦以及伺服器的執行情境裡，RyuJIT 更新了先前 64 位元的 JIT 編譯器，顯著減少了啟動所花費的時間。RyuJIT 也支援 SIMD (單指令流多資料流, Single Instruction, Multiple Data)，這代表能夠同時平行執行大量的數學運算。將讓使用到向量運算的應用程式得到顯著的效能提升!
更多關於下一代 JIT 編譯器的訊息，請參考 The next-generation JIT compiler for .NET
.NET Native 將 C# 直接編譯為為原生機器碼，如同 C++ 一樣。亦即，開發者能夠在享受 .NET Framework 高生產力的同時，還能得到優異的執行效能。一般情形下，.NET 所編譯的應用程式會先被轉換成中繼語言 (IL)，在執行時期再透過JUST-IN-TIME(JIT) 編譯器將中繼語言 (IL) 轉換成原生機器碼。
而 .NET Native 則是一種提前編譯器 (ahead-of-time compiler)，會先把應用程式直接編譯成原生程式碼，並且包含最小的通用語言執行庫 Runtime (CLR Runtime) 以降低套件大小。如此一來，能讓使用 .NET Native 編譯的 Windows Store Apps 再啟動的速度加快 60%，並且減少 15~20% 的記憶體。Universal Windows apps 都將會運行在 .NET Native 上(包括 ARM, X86, X64 的 CPU 架構)
有關於 App 使用 .NET Native 編譯的詳細資訊參考Compiling Apps with .NET Native.
在 .NET Framework 4.6 以及 .NET Core 5 中，延伸了先前的通用函式庫以及應用程式模型，例如 Windows Forms、WPF、ASP.NET Web Forms、MVC 5 等等。您所熟悉的應用程式模型在 .NET Framework 中將會加入許多新功能，能夠與全新的程式語言和 Roslyn 編譯器、RyuJIT 作完美的整合。在 .NET 4.6 中新增了許多有趣的東西! 請參考 ASP.NET Overview – What about Web Forms?、The Roadmap for WPF、.NET Framework 2015 Preview.
附帶一提，新的應用程式模型也為 .NET Core 5 做了設計的優化。
ASP.NET 5 使用現代的 .NET 應用程式模型來設計 Web 應用程式。透過已優化的開發框架打造雲端或者本地端的網頁應用程式。透過 ASP.NET 5 模組化的元件以最小的資源耗費打造出有彈性的專案，ASP.NET 5 可以運行於 .NET Framework 4.6 或者 .NET Core 5 之上。現在 ASP.NET 5 已可以透過 Mono runtime 執行在 Linux 以及 Mac 上面。
從 .NET Core 開始支援 Linux 以及 Mac 後，ASP.NET 5 將會計畫透過 .NET Core在這些平台運行。
關於ASP.NET5 的詳細內容可以參考ASP.NET 5 Overview以及Introducing ASP.NET 5。
Universal Windows App (通用型應用程式) 是一個能夠讓您在 Windows Phone 及 Windows apps 上互相共用程式碼，並能部署到 Windows Store 的一個應用程式模型。通用型應用程式將會以 .NET Native 運行，將中繼語言編譯成原生機器碼，並包含執行所需要最小的通用函式庫`。
更多關於 Universal Windows App 以及如何使用 .NET Native 開發可以參考Building universal Windows apps for all Windows devices 以及 Getting Started with .NET Native
讓我們再複習一下.NET Core
.NET Core 5 是一個泛用途、模組化，且因為重構並使用底層物件函式庫(corefx)以及Rutime(coreclr)，因此具備跨平台特性的 Framework。
.NET Core 在不同的應用程式模型使用相同的底層物件函式庫(BCL)，或許這些 API 看起來不太一樣，但其實它們分享同一種實作方式。大部分的 API 都擁有高度模組化且易於重構、並獨立於作業系統的平台之外的特性。
下圖是當您在使用 .NET Core 開發應用程式時的簡化圖。從撰寫程式碼/建置/除錯的循環，及至於部署並執行的過程。請注意在部署執行階段，會根據最後的執行平台，以不同的應用程式模組去編譯您的程式。
在您撰寫程式碼中，會參照許多位於底層物件函式庫 (BCL) 內的參考。Roslyn 編譯器會將您的程式碼轉換成獨立於平台的中繼語言 (IL)。除此之外，編譯器擁有豐富的 API，讓您能夠做各式各樣的程式碼分析工作。如果您正在使用Visual Studio，將會有許多的新功能應用這些 API，讓您在撰寫程式的過程中更有效率。
如果您正在打造通用型 Windows 應用程式，可以利用 .NET Native tool chain將 您的程式建置為原生碼，且包含執行最小需求的通用函式庫。
而如果您在開發 ASP.NET 5 ，將可參照使用您部署伺服器端的 CoreCLR，同時利用 JIT 彙整程式碼後，由 RyuJIT 建置。
另外一提，ASP.NET 5 允許您在執行階段更改並儲存程式碼，之後只要重整您的瀏覽器而不需要在執行重新建置。Visual Studio 使用 Roslyn 的動態編譯，讓您擁有強大的開發框架，更能提供您更流暢更像直譯式語言的開發。
附記：如果您要使用 .NET Framework 4.6 為建置的目標，您仍然能夠使用這些全新的功能以及 Roslyn 編譯器。應用程式部署將不會因為目標改變而有變化，這必須要依賴於您編譯該應用程序系統的 Framework 版本。但在執行階段則會使用JIT彙整並且編譯利用 RyuJIT 執行。
在 .NET 2015 底下，有許多部份是開放原始碼且由 .NET Foundation 管理。我們正在將這些專案一一的開放給開源社群們使用。
您可以在 .NET Foundation 的 GitHub 上面看到所有可供使用的開源專案：http://dotnet.github.io/
以下有幾個不錯的代碼庫，能夠透過以下連結來得到不同專案的原始碼及專案檔：
值得一提的是，完整的 .NET Framework 是 ”source open”，這代表我們不是全然的將程式碼開放並且也不是全然的遵守 OSI 授權 (譯註：OSI 為 Open Source License)，但您仍然可以瀏覽所有的原始碼: http://referencesource.microsoft.com/
敞開心胸
對微軟來說，開放原始碼並不是新的舉動，但對 .NET Runtime & 函式庫卻是。這對一個超過 15 年的老專案是個非常重大的決定，對許多內部的員工來說，這開放的不是單單只有程式碼而已，而是將整個工程都開放出去。改變是需要時間的。所以這是為甚麼 .NET 小組剛開始只能釋出一小部分的物件函式庫。我們在未來需要有更長更遠的路要走。從決定開放也至於現今的成果，可以讓我們這個團隊學到這些舉動激起的漣漪、以及產生的貢獻，這些都讓我們自嘆不如。
您或許會問自己，「我沒有足夠的時間打造我自己的應用程式，但至少我還能寫一點 code 來貢獻 CLR!」。您的想法沒錯，我們將會與您一起努力，您可以自由選擇您要用甚麼方式來參與我們，您也可以不成為寫程式碼的貢獻者，可以選整理問題、提供一些您的意見、或者回答問題，或者只是到處看看社群努力的成果
您又或許會想「我不想要失去簡單好用以及有一定品質的 .NET Framework…」，別擔心！我們的等級跟品質還有服務會跟以前一樣好，我們所做的只是單純開放我們的工程成果。純粹將先前我們所在內部做開放，同時也會保持我們軟體上面的品質。
我對 .NET 以及 .NET 小組迎接的新文化感到興奮！
在「Windows 10 對於開發者的意義在哪?」文中提到，4/29~5/2 的 BUILD 大會中，才會有進一步針對 Windows 10, Cortana, Xbox, Surface Hub, 以及 HoloLens 上開發應用程式的完整訊息。那麼在這之前，開發者可以怎麼準備呢?
首先，即是先開始熟悉 Universal Windows Apps 了!
同時，在三月初於巴賽隆納舉辦的 Mobiel World Congress 上，微軟又進一步公佈了未來 Windows 10 的通用應用程式平台 (Universal App Platform):
這張圖的上方提示了 Universal Apps 將橫跨多種不同裝置；下面的部份則可細項來看其說明:
As we built the universal app platform, we set out to ensure that all Windows developers would equally benefit from this one core. The platform enables a new class of Windows universal apps – apps that are truly written once, with one set of business logic and one UI. Apps that are delivered to one Store within one package. Apps that are able to reach every Windows 10 device the developer wants to reach. Apps that feel consistent and familiar to the customer on all devices, while also contextually appropriate to each device’s input model and screen size. The new universal app platform completes our developer platform convergence by providing you with the ability to finally create one app that can run on mobile, desktop, console, holographic, and even IoT devices.
Adaptive UX: enables your app’s user interface to fluidly adapt at runtime based on how the customer is interacting with your app and the available device capabilities – rendering an experience that is contextually appropriate.
Natural user inputs: Windows 10 helps you build an app experience that is more personal and more human, by making it easy to incorporate natural user inputs into your app, such as natural speech, inking, gestures, and user gaze. Because Windows handles all of these inputs, we free you from needing to worry about how to parse the input for meaning – you only need to worry about which inputs are appropriate for your app and we’ll determine if they are present and parse the intent for you.
Cloud-based Services: Windows provides a number of services for use in your apps, such as Windows Notification Services (WNS), Windows roaming data and the Windows Credential Locker. With Windows 10, we are making more Windows services available to developers, including an expanded Cortana AI, OneDrive, and Application Insights. Beyond Windows, we continue to make it easier to take advantage of Microsoft Azure using services like Azure Mobile Services and the Azure Notification Hub.
最後，則是再次提醒大家:
1. 歡迎參加 Windows Insider Program，提早取得並體驗 Windows 10，同時還能率先得到開發工具預覽的通知。
有個網站可以讓你作測試。只要依次選擇艙等、性別、年齡、有幾個同行親屬、購買的票價、由哪個港口出發 (不知道的話就隨便選):
然後 Submit，就能得到你的生還機率了:
是的! 11.11% 就是我照實填寫之後得到的生還機率，還幫我加註解說我的生存機會渺茫…><~
反正這預測是免費的，所以您可以多方嘗試，看看哪一種乘客是最有可能存活的。首先，我把性別由 Male 改成 Female:
是的!! 只要變性為女生我就 100% 可以存活了~ XD
(以下開始包含技術內容)
所以這網站是怎麼作預測的?
簡單來說，即是利用了「機器學習」這方式。先將所有鐵達尼號乘客的資料 (data) 拿來作輸入，經過 ML (Machine Learning) 的學習之後，即得到新的預測技能 (skill):
(想先了解一下何謂「機器學習」? 請見 「機器學習」FAQ)
一、取得乘客資料
首先，Kaggle 這網站可以取得當年所有 891 個鐵達尼號的乘客資料 (“train.csv” 檔)。免費下載，以 Excel 打開後如以下:
檢視一下可以發現…
二、使用「機器學習」的線上工具 (Azure ML Studio)
各位可直接以瀏覽器打開看看鐵達尼號生存機率的 ML 學習機制，以下我即會簡單介紹一下這張圖。
(想學習如何使用這工具? 請見 Azure 「機器學習」初體驗)
三、資料整理
所謂 Garbage in, garbage out! 原始資料之中有些對預測沒有幫助、或是不完整的地方，我們都可以用簡單拖拉、設定的方式作資料整理。
如：無視 PassengerId, Name 等欄位: (Exclude column names)
又如：將不完整的資料 (missing values) 以中位數 (median) 來代替:
四、建立學習模型
資料整理完後就可開始學習了! 工具內建了不少微軟研究院開發出來的機器學習演算法，使用者只要拖拉合適的演算法進來即可。
如以下鐵達尼號的例子中，用了 2 種演算法來比較哪一個的正確率比較高:
(想了解更多演算法? 請見: 我該用哪種演算法 (algorithms)?)
五、檢視學習成果
就像我們上學要考試一樣，我們也要來檢查這個預測模型的學習績效。
如以下我們可以檢查所有的預測 (Scored Labels) 相對於實際是否生還 (Survived) 的對照圖:
也可利用如 ROC 等方法，以曲線表示相較於亂猜 (45度對角線) 的準確程度:
六、發佈為 Web Service
最後我們當然想作成網站或是 App，讓其他使用者使用。透過發佈為 Web Service 的方式即可讓其他開發者使用你的預測。
同時還會提供 C#, Python 及 R 語言的 sample code:
註：Azure ML Studio 是微軟所開放出來的「機器學習」工具，主要是設計讓非資料科學家也能輕鬆學習使用。任何一種瀏覽器上都可執行，無需信用卡，登入 Microsoft Account 之後即可。
延伸閱讀:
1. Tutorial: Building a classification model in Azure ML
2. BUILDING AND DEPLOYING A CLASSIFICATION MODEL IN AZURE ML: A Step-By-Step Tutorial
3. 本部落格 Machine Learning 系列文章 (中文): http://blogs.msdn.com/b/mengtsai/archive/tags/machine+learning/
4. Microsoft Azure 機器學習官方學習網站 (含教學影片及文件): http://azure.microsoft.com/zh-tw/documentation/services/machine-learning/
“R 語言，一種自由軟體程式語言，主要用於統計分析、繪圖及資料探勘。”
本文將帶您檢視 410 個預裝的 R packages、展示如何直接使用既有的 R script，或直接在 Azure ML 中撰寫、透過 R 作資料清理進而建立預測模型、以及如何極大化 R 語言在「機器學習」上的應用。
使用 Azure ML Studio
微軟所開放出來的「機器學習」工具 Azure ML Studio，可以在任何一種瀏覽器上執行，無需信用卡，登入 Microsoft Account 之後即可免費開始使用: https://studio.azureml.net/。
Azure ML Studio 包含 “Execute R Script” 及 “Create R Model” 模組可供使用:
檢視預裝的 R packages
目前支援 410 個 CRAM R packages, 包括 plyr and dplyr, car, datasets, HMisc, MASS, Intel Math Kernal Library，及 rpart, nnet, survival, boot 等資料探勘工具。
要檢查哪些預建的 R packages 可供使用，請先開啟一個 Experiment，拉入 “Execute R Script” 模組，並貼入以下命令:
data.set<-data.frame(installed.packages())
maml.mapOutputPort("data.set");
按下執行 (Run) 後，點選左下角圈圈並選擇 Visualize，即可看到所有預先安裝的 410 個 R packages:
使用 ggplot2 繪圖
開啟一個全新的 Experiment，並拉進 “Adult Census Income Binary Classification dataset”、以及 “Execute R Script” 模組如以下:
[小技巧] 善用左上角的 Search 功能，可直接找到這些模組!
其中 “Adult Census Income Binary Classification dataset” 這份普查資料即是我們的資料來源，這份資料收集了 3 萬多人的 age, race, sex 、並標示年薪是否大於 5 萬美金 (50K):
點選 “Execute R Script”，鍵入以下命令以匯入 ggplot2 及 data.table:
library(ggplot2)
library(data.table)
接下來我們要用 ggplot2 畫兩張圖：一張是 sex 相對於 income 的長條圖；另一張是 age 相對於 income 的 density graph:
foo = qplot(x=sex, data=dataset1, geom='histogram', fill=income, position='dodge'); print(foo)
foo = qplot(x=age, data=dataset1, geom='density', alpha=0.5, fill=income); print(foo)
最後的 R 程式如下:
執行 (Run) 之後，點選其右下角小圈選擇 Visuallize，即可見到我們畫的二張圖 (看來是男生賺的多、老的賺的多):
利用 R 作資料整理
原始資料的各個欄位中，含有許多的 ‘-‘ (dash) 符號，我們可以加入以下命令，將所有的 ‘-‘ 換成 ‘.’ (dot):
names(dataset1) <-
sub(pattern='-', replacement='.', x=names(dataset1))
再將處理後的資料指定回 “dataset1:
maml.mapOutputPort("dataset1");
最後的 R 程式:
執行 (Run) 之後，點選其左下角圈圈選擇 Visualize，即可注意到原本的 ‘-‘ 皆已被替換成 ‘.’:
建立預測模型
假設我們想要以 age, sex, race 等資料，來預測其年收入 (income) 是否大於 5 萬美金 (50K)。
預測模型的建立有類似的模式，我們使用 “Two-Class Boosted Decision Tree” 演算法, 再拉入 Split, Train Model, Score Model, Evaluate Model 並連結如下:
並記得在 “Train Model” 中選擇我們想預測的欄位: “Income”
執行 (Run) 之後，查看 Score Model，即可看到這個模型預測 income 大於 5 萬美金 (50K) 的機率:
當然我們也可查看 Evaluate Model，觀察如 ROC 等模型評估數值:
發佈為 Web Service
若我們滿意這個預測模型，按下 “CREATE SCORING EXPERIMENT” ，就可自動產出 Web Service ，還會出現一段動畫，將你的模型變成以下:
同時提供 C#, Python 及 R 語言的 sample code:
極大化 R 程式在 Azure ML 的價值
“Excute R Script” 模組不但可接受二組不同的 dataset 作為資料來源，同時也提供 ZIP 的方式作輸入，例如，若有套件並未包含在預裝的 410 CRM packages 當中，即可透過 ZIP 的方式引入。
輸出的方式則如本文範例所示，不但能將結果透過 R Devices (如 ggplot2) 顯示，也能輸出為 dataset 作後續使用。
在 Azure ML 也提供 “Create R Model”，讓您直接應用 R 語言於預測模型建制，包含 Training Model 及 Scoring Model，再進而發佈為 Web Service 供其他人員使用:
延伸閱讀:
2. 本部落格 Machine Learning 系列文章:http://blogs.msdn.com/b/mengtsai/archive/tags/machine+learning/
3. Microsoft Azure 機器學習官方學習網站 (含教學影片及文件): http://azure.microsoft.com/zh-tw/documentation/services/machine-learning/
Raymond's Tech Notes 
