關於 Udemy 線上課程平台課程大綱規劃與模板 (提供下載)

最近在整理原來實體課程的教材內容,準備移轉到線上教學平台上 (我的第一個線上課程應確定爲「活用 UML 體現軟體設計思維」),首先考量的應該是國外最大的教學平台 - Udemy

實體教學與線上教學肯定是截然不同的方式,前者重於與學員的「互動」,甚而需「因材施教」,動態改變課程內容;但後者並沒有可與之互動的觀衆,所以事前錄製的內容與呈現方式,以及每一個單元的主題與目標,就要相當明確了。

最主要的呈現方式當然就是視頻錄製,並可以使用如 Powerpoint 的簡報作課程大綱與內容說明,另外涉及到開發工具的操作等,就需要螢幕錄製操作步驟。每一個視頻單元,據我大量查看 Udemy 衆多課程講師,大都爲 5~10 分鐘左右,單元主題要能切中該視頻內容,可以是很通俗的命名。

與我實體課程規劃大綱的方式最大的不同是,Udemy 課程大綱主要只有兩層:Section 與 Lecture

Section 比較像是章、節的概念,而 Lecture 與傳統書籍大綱內的小節觀念可能不大相同,它要呈現的是一個講課、講座、講稿這樣的概念。

Section 比較容易界定,一個「章/節」的目標 (objective) 明確就沒有問題。而 Lecture 我是很不習慣,主要就在於要配合視頻 5~10 分鐘內的長度,所以以前的小節觀念,需要分割或合併,但要給予一個清晰的 Lecture 講座名稱,有時沒想像得簡單。

閱讀全文 »

關於 DDD (Domain Driven Development) 微服務的結構設計議題

** 本文同步發表於 FB社群-軟體設計鮮思維 **

最近在線上輔導了一位 技術職PM 結構設計的實現 (Realization)議題,他傳給我 DDD 的架構圖,覺得在「Domain Service」與「Domain Model」的責任界定上,觀念不是很清楚。

嗯,其實這所謂的 DDD (Domain Driven Development) 架構圖根本就是典型 3-tier (Presentation-Application Logic-Data Source) 分層結構呈現爲圓形的剝洋蔥層次而已,越是內層 (Domain Model) 越代表爲系統的核心。
關於 DDD (Domain Driven Development) 微服務的結構設計議題

工程師從這張圖往往會認爲「Domain Model」是最重要的核心觀念。是這樣沒錯,但對以「需求爲導向」的專案開發性質,它卻反而沒那麼重要!況且結構設計的基礎功夫要很紮實,封裝-介面-多型 諸多「虛」的設計觀念確實能充分了解並能整合活用,沒有花上 5-10 年以上功夫,是不容易應用在現實的系統開發上的。相對於此,「Domain Service」對現實的專案開發可是更切實際,且結構設計上的觀念也會比較容易入手。

閱讀全文 »

Manjaro 18 安裝 XAMPP – WordPress 本機開發環境

WordPress 寄放於遠端虛擬主機廠商,而希望在本機具有開發 Web 的環境,我自己是安裝了虛擬機的 Manjaro (安裝版本 18) 類 Arch Linux 系統,但我實在不想再重新一個個安裝與設定相關 LAMP (Linux, Apache, MySQL, PHP) 開發環境,所以找尋有否已整合好的開發套件。

以前我就在 Windows-based 安裝過 XAMPP,原來也有適用於 Manjaro 的系統,但需要手動安裝 (也可以透過 AUR 安裝,但建構過程出現問題),不過安裝過程倒是非常簡單。

稍微注意下,是從 MySQL 被 Oracle 併購之後,開源組織應該是擔心後續的商業利益問題,因而復刻了一個幾乎等同於 MySQL 的 MariaDB,所以安裝 XAMPP 目前版本後的資料庫是 MariaDB 而非 MySQL。原來我是有些擔心因爲主機商提供的仍是 MySQL,而在本機安裝的卻是 MariaDB,不知 WordPress 是否會有相容的問題,但爬文後普遍看來是沒啥問題,所以就先給安裝下去,留待後續再查看是否有資料庫相容性問題。

閱讀全文 »

如何從巨觀的需求流程分析,可以直覺無縫的橋接至程式寫碼?

本文同步發表於「FB 軟體設計鮮思維」社團。

這裡採用個人所發表關於需求分析的「MSS」與 程式寫碼的「SSD」三層次分析與實作方法。

需求分析階段的 MSS 三層次

關於 MSS,可以參考原來寫的這篇:「大業務流程塑模的MSS三層次原則」。

o M(multiple) Process。
o S(ingle) Process。
o S(ystem Function)。

    以「請購-採購」作業流程 (business process)為例:

  • Multipole Process:「請購」與「採購」兩個作業流程的表達,焦點擺在「請購」作業內部的一連串活動 (activity)分析。
  • Single Process:「請購」作業流程的內部活動表達,焦點擺在「進行供應商評等及比價」的系統功能對應。
  • System Function:「採購」資訊系統的系統功能界定 (利用使用案例)。焦點擺在「比價」的系統功能實現 (realization),實現的步驟主計有「列出廠商資訊」、「評等列出優先順位供應商」、「儲存比價交易紀錄」。

程式寫碼的 SSD 三層次實作

可以參考「實作 Enterprise MVC 巨觀結構的 POC-觀念篇」內關於「控制類別」的說明。

o S(ubject) 主題。
o S(TEP) 實現主題的步驟。
o D(etail) 實作每一步驟相關的細節 (欄位明細與業務邏輯)。

    承接上述例子關於「比價」使用案例的實現。

  • Subject:「比價」使用案例-對應至「比價Control」控制類別。
  • STEP:「比價Control」類別內的 Function (Method)對應為:
    「ListSuppliers()」、「ComparativePrice()」、「SaveComparativePriceTransaction()」。
  • Detail:「ListSuppliers()」列出廠商的清單與欄位資訊From資料庫;「ComparativePrice()」處理比價的邏輯與評等;「SaveComparativePriceTransaction()」儲存本次比價的交易結果至資料庫。

Visual Studio 使用 Quickfix 重構工具簡單說明與錄影操作示範

參考 使用 Visual Studio Quickfix 重構工具的幾個主要類型與範例

這裡提供程式碼練習案例 (放於 Github),可以參考上述網址的操作說明或後述的錄影操作示範。(其中有改寫幾個案例,每一個案例均可透過 Console 程式執行。)

重構範例的操作錄影教學與簡單說明則已發布於「FB 社團—軟體設計鮮思維」:

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal