以 scrum-1 帳號為例, 若採 ssh clone 倉儲, 需要先設定對應權限.
基本概念
從 https://github.com/scrum-1/cd2019 倉儲中對應的 clone or downloads 中 Clone with SSH, 所列出的 URL 為:
git@github.com:scrum-1/cd2019.git
表示將以 git 帳號, 登入 github.com 主機, 進入 scrum-1 帳號中對應的 cd2019 倉儲, 若直接 git clone 此一倉儲, 則指令為:
git clone git@github.com:scrum-1/cd2019.git
特別注意, 其中的 github.com 為網站符號名稱, 意思是所採用的 ssh 將利用 @ 前方的 git 當作帳號, 並且將採用 ssh 協定登入 github.com 網站.
假如, 使用者所採用的可攜程式套件, 只在 home 目錄下的 .ssh 目錄登記一個 private key, 使用者就可以直接在 home/.ssh/config 中,將 github.com 當作 Host 代號, 並對應到 Hostname 為 github.com 作為連線的網站名稱.
但是, 若使用者所使用的可攜程式套件, 登錄一個以上的 private keys 時, 就必須透過一個以上不同的 Host 名稱加以區別, 以便導引 ssh 協定至不同區段, 以不同的 private key 對應 Github 上不同帳號下所登錄的 public key.
實際 .ssh/config 設定
# no proxy at home
#ProxyCommand y:/PortableGit/mingw64/bin/connect.exe -H mdeuser@140.130.17.7:3128 %h %p
# for user1
# url = git@github.com_user1:user1/cmstest.git
Host github.com_user1
User git
Port 22
Hostname github.com
IdentityFile "y:\home\.ssh\id_rsa_user1"
TCPKeepAlive yes
IdentitiesOnly yes
# for user1
# url = git@github.com_user2:user2/cd2019.git
Host github.com_user2
User git
Port 22
Hostname github.com
IdentityFile "y:\home\.ssh\id_rsa_user2"
TCPKeepAlive yes
IdentitiesOnly yes
# for scrum-1
# url = git@github.com_scrum-1:scrum-1/cd2019.git
Host github.com_scrum-1
User git
Port 22
Hostname github.com
IdentityFile "y:\home\.ssh\id_rsa_scrum-1"
TCPKeepAlive yes
IdentitiesOnly yes
根據上述設定, scrum-1 若要以 ssh 協定在近端 git clone Github 上的 https://github.com/scrum-1/cd2019 內容, 除了必須在 Github 上與 scrum-1 帳號對應的 SSH and GPG keys 中納入 public key 外, 就必須採用:
git clone git@github.com_scrum-1:scrum-1/cd2019.git
才能將遠端的倉儲內容 git clone 到近端, 之後也才能透過 y:\home\.ssh\id_rsa_scrum-1 這個 private key 進行認證後, 將近端的提交版本推送到遠端.
取得 CMSimfly 倉儲內容
git clone https://github.com/chiamingyen/cmsimfly.git
由於 https://github.com/scrum-1/cd2019 倉儲一開始只有一個 README.md 檔案, 接下來將最新的 CMSimfly 倉儲內容納入 scrum-1/cd2019 倉儲中.
有關 CMSimfly 倉儲
由於 CMSimfly 是一個以網際可程式化機械設計合成系統教學為目標的網際內容管理系統, 因此除了電子書類的動態與靜態網頁系統外, 還包括網際簡報與靜態網誌系統, 而且各系統的開發流程均採用 Leo Editor 大綱管理系統進行, 將這些原先各自獨立的網際系統混雜在一個倉儲中, 雖然容易讓初學者望之卻步, 但是若能夠花一些時間了解這些系統間彼此的關聯性, 其終極目標不外乎在試圖打造一套「網際可程式化機械設計合成系統」, CMSimfly 倉儲中包含:
1. 動態的 Python Flask 網際內容管理系統 (即動態 CMSimfly), 主要讓使用者可以編寫伺服器段的 Python3 程式, 透過瀏覽器 frontend 上的表單介面與存放在伺服器上的 CAD, CAE, 自動控制或最佳化分析程式庫進行互動, 最後再以 email 通知使用者設計分析結果, 並將 2D, 3D 與動態模擬的結果, 以 HTML5 與 Javascripts 格式傳回瀏覽器端.
2. 靜態的 CMSimfly, 主要從上述動態的 Python Flask 系統, 將各頁面轉為純 html 資料, 其目的就是要使用只提供 WWW 功能的 Github Pages, Fossil SCM doc Page, Nginx 等系統伺服這些靜態網頁.
3. 靜態的 Reveal.js 網際簡報系統, 機械設計流程牽涉一系列的表達, 因此在 CMSimfly 中採用 config 目錄中的 reveal.leo 來管理網際簡報系統的內容. 使用者透過 config/reveal.leo 所產生的網際簡報系統位於 CMSimfly 倉儲中的 reveal 目錄中, 且簡報內容所使用的靜態圖檔, 例如: .png, .jpg, .git 或 .svg, 可以取自靜態的 CMSimfly 系統中的 images 目錄, stl 格式的 3D 零組件檔案則可從 CMSimfly 的 downloads 目錄中引用, 例如, 從 http://mde.tw/cd2019/content/FreeCAD%20STL.html 頁面中引用 FreeCAD 所建立的簡單零件:
並且, Leo Editor 僅透過大綱層次管理 Reveal.js 網際簡報檔案中的各 block 頁面, 從協同產品設計實習課程的角度而言, 未來也能透過 Python 程式, 根據靜態 CMSimfly 或 Pelican 網誌, 從各倉儲版次內容中, 「自動」整理出設計階段所需的網際簡報內容.
4. 靜態的 Pelican 網誌系統, 動態或動態 CMSimfly, 目的在編寫章節清楚的電子書, Reveal.js 則旨在建立網際簡報, 而 Pelican 則可配合協同設計專案執行日期, 以日誌模式編寫協同設計紀事, 且可以在每篇網誌文章中加入 Disqus 網際留言互動系統, 以便針對協同產品設計流程中所記錄的事項進行各種互動與討論. 至於 Pelican 網誌系統中必須引用的各式 2D, 3D, 動畫或數學方程式, 與 Reveal.js 網際剪報系統相同, 可以引用自靜態 CMSimfly 中已經上傳至遠端 Github Pages 上的對應版本內容.
5. Github 倉儲中的 Issues 系統, 可用來追蹤與倉儲內容相關的各種議題, 也可以將協同產品設計專案中所牽涉的各項任務, 利用 Issues 指派給各協同人員, 並藉以回報任務處理進度或面臨問題時將採取的處理方案討論等.
6. Github 倉儲中的 Wiki 系統, 由於上述 CMSimfly, 靜態與動態系統, 或 Reveal.js, 或 Pelican 網誌, 甚至 Issues 都與協同設計流程有關, 當個別使用者針對這些內容改版時, 必須設法與先前的內容版本合併, 或必須循序針對執行任務的結果進行追蹤或討論, 而 Wiki 系統則可以在這些系統之外, 提供一個各協同人員可以隨時任意編輯的網際「快記」系統, 無論是針對尚未納入 CMSimfly 電子書之前的瑣碎資料收集, 或者在執行特定任務時, 必須提醒或引導其他組員的各種內容, 都可以直接先放在與 Github 倉儲對應的 Wiki 系統中.
手足球模擬系統專案
當參與協同產品設計實習的各組員, 在充分了解上述 Github 倉儲與 CMSimfly 所提供的各式網際內容管理系統後, 真正的協同設計任務才正要開始展開.
2019 年 Spring 的協同產品設計實習課程, 以虛擬手足球系統的搭建, 讓學員有機會利用上述網際內容管理系統, 從 Onshape 與 Solvespace 的手足球零組件設計, 到 V-rep 的機電資系統模擬, 課程專案的執行共牽涉以下任務 (各階段負責執行任務組員除了將各項執行細節內容納入倉儲網際管理外, 必須各自拍攝操作過程影片, 納入各自的 Youtube 帳號中):
1. 手足球系統的零組件尺寸分析 (可行性分析)
2. 手足球系統的零組件參數設計與繪圖 (零組件初步設計繪圖)
3. 手足球系統中各球員擊球與操控桿移動旋轉的 V-rep 動態模擬 (系統功能模擬)
4. 手足球發球與進球後自動送球機構設計與 V-rep 動態模擬 (機構與傳動系統設計與模擬)
5. 手足球模擬系統功能展示 (模擬展示與說明影片)
6. 完成手足球零組件細部設計 (可參考 https://youtu.be/PgnvZV5s13c 中各項設計), 並將設計 BOM (Bill of Materials) 納入 CMSimfly 網際內容管理系統. (系統 BOM 文件整理)
7. 各組利用倉儲中的 Reveal.js 進行結案簡報 (結案口頭簡報)
8. 各組完成 html 與 pdf 格式之手足球專案結案報告 (文字結案報告書)
協同產品設計實習課程規劃與執行討論
為何使用 Onshape
當許多在高工時代便已經熟悉 SolidWorks, Inventor, NX 或 Creo 的學員, 一接觸到以自行建構「網際可程式化機械設計合成系統」為目標的系列課程, 例如: 電腦輔助設計實習與協同產品設計實習課程時, 第一個疑問就是: 為什麼要使用 Onshape 執行零組件的參數設計繪圖, 而不採用上述這些傳統廣為業界採用的電腦輔助設計繪圖套件 (MCAD, Mechanical Computer Aided Design), 理由其實很簡單:
因為這些以單機 Windows 版本為主的 MCAD, 沒有免費提供給非營利的教育單位使用, 並且若要利用這些單機套件執行網際雲端協同產品設計專案, 通常還必須搭配高單價且綁定在 Windows Server、 MS SQL 與產品資料管理 (Product Data Management) 系統架構群中.
換言之, 之所以採用 Onshape 執行協同產品設計專案, 完全是時間與所花費心力成本的考量. 況且從網際可程式化的機械設計的角度而言, 吾人需要的重點技術是透過開源套件, 例如: Solvespace、FreeCAD、Blender、V-rep、Webots 與 Range3 等, 透過 Ubuntu 伺服器端的 Python3 加上 Cython, 讓參與協同的學員, 能夠自行快速打造各式 Python3 設計分析程式, 並透過 Cython 轉換, 以 C/C++ 的速度執行網際協同設計分析.
為何需要 Github
由於上述採用開源軟體執行專案的同時, 以程式化操控各式套件產生零組件的過程, 這些明碼的設計流程資料, 便有利用分散式版次管理系統的價值.
例如: 在 https://github.com/KmolYuan/Pyslvs-UI 的多連桿機構設計流程中, 尺寸合成後已經可以直接透過程式取得各連桿的 Solvespace 格式檔案, 但目前仍需仰賴手動進行後續避開機構干涉的組立流程, 之後若能透過伺服器端的 Python3 程式操控 FreeCAD 0.18 之後的版本 (才能支援 Python3), 整個手足球模擬系統的得分後送球機構零組件, 便可透過多連桿機構套件與 FreeCAD 的結合, 自動在尺寸合成後, 完成多連桿的組立流程, 甚至自動轉為 VRML97 格式, 轉入 Webots 進行後續的模擬分析.
而這些與機械、電子電機與資訊科技密切整合的設計過程, 所牽涉的各項參數與流程訂定, 在不同時間點會有不同的版本細節內容, 若能使用雲端分散式版次管理, 除了較無需擔心重要資料遺失之外, 也能讓每一位參與協同的成員, 對專案任務的付出內容, 完全攤在陽光下, 不僅能有效提供任課教師針對執行歷程評分外, 各學員也能養成長期參與全球協同開源專案的認知與能力.
假如沒有網路與 Github
多年來, 網路上許多原先免費提供使用的服務, 終究有中止或改變營運策略的可能, 那麼一旦 Onshape 不再免費提供非營利教育單位使用, 諸如 Github 的各種服務, 也可能不再免費或無法使用, 該如何持續進行所謂的「網際可程式化機械設計合成系統」開發或相關課程推動?
未來能夠取代 Onshape 的工具, 將會是 FreeCAD, 由於 FreeCAD 的原始碼位於 https://github.com/FreeCAD, 吾人必須有能力自行編譯各操作系統中使用的 FreeCAD 套件.
此外, 在區域網路搭建 Fossil SCM 伺服主機, 已經可以完全取代 Github 目前所提供的主要功能. 並且透過 Virtualbox 虛擬主機, 可以大幅提升網際可程式化機械設計合成系統開發的效能.
