RogueLike in Linux C++-寫在前頭

我想再利用閒暇時間瞭解下 Linux 的程式開發,以俾得以對 Linux 系統底層有更進一步的應用與控制。因為未來開放式硬體的架構 (ex. Raspberry Pi, BeagleBoard, Cubieboard ...etc),必然是以 Linux 為開源系統,並以此為基準點,建立各類硬體裝置控制的應用。

我偏好採用 C++ 作為 Linux 開發的程式語言,畢竟 Linux 系統底層/服務 大都以 C/C++ (其實還是要當為兩種不同的語言,只是 C++ 可以很容易引用 C 的函式庫。)來開發的。再則:

  • 高移植性:重點在於函式庫的跨平台 (Windows/Linux ...)、跨硬體架構 (Intel/ARM-based CPU)!且太多開源各類的函式庫可資引用,方便太多。
  • High-Performance。
  • 物件化的始祖:畢竟我還是習慣採物件化的思維來設計與開發,具 OOP 的機制還是會比較直覺。

我希望初期先透過一個主題來持續學習與實踐 C++ 的開發 (先不需牽扯到系統底層處)。因為畢竟與工作無關,且是當成休閒嗜好的輕鬆態度學習的;所以我想乾脆就把 RogueLike 遊戲 的程式開發作為學習的標的。

因為我現在也正在玩 DCSS (Dungeon Crawl Stone Soup),而 RogueLike Game 不需著重在畫面音效等,僅需利用 ASCII 字符的格狀畫面來呈現即可,所以就不用考量到畫面效果的處理技術。另外一點很重要的是,大部分的 RogueLike 遊戲係以 Open-Source 連原始程式碼都免費釋出,還有許多教學資源可供充分的研究與學習。

我就打算以這一系列-Complete roguelike tutorial using C++ and libtcod,作為我學習以 Linux C++ 開發 RogueLike 遊戲的教案,然後逐步的把心得筆記下來。

總之,我是打算抱著很輕鬆的態度來學習 Linux C++ 的,應該是會視之為 long-term 的學習歷程。

閱讀全文 »

Linux C++-開發環境與Hello程式

實作目標:在 Ubuntu 與 Raspbian 建立 C++ 開發環境。
副目標:撰寫並執行 Hello 程式,以測試開發與編譯環境。

實作:

  • 關於 Code::Blocks IDE
    Linux C++ 老手普遍僅以 vim 為程式碼開發平台,並以 g++ 與 Makefile 工具達成自動化編譯的目的;不過對新手尤其習慣 Windows-based 具有整合開發環境的開發人員來說,只用上述命令列模式指令來編輯與撰寫 scripts 難度高了些。

    Code::Blocks 是一個開源、跨平台的 IDE 開發工具,可以撰寫 C/C++, Fortran 等程式語言;除了提供視覺化的開發環境外,也可以透過其 plugin framework 擴展功能,例如得以增強在程式編譯與除錯方面的功能。

  • 安裝 Code::Block & gcc/g++
    Code:Block 安裝非常容易。Ubuntu 可以透過 XWindows 下的「軟體中心」搜尋「Code Block」找到安裝即可;Raspbian 則在 Pi Store 以同樣關鍵字搜尋安裝。

    至於 gcc/g++,先釐清這是兩種不同的 compiler。gcc = gnu compiler collection,可以編譯多種語言;g++ 則只可以編譯 C++ 程式。關於兩者的區別,可參考-gcc和g++的區別

    Ubuntu 14.04 只需另行安裝 g++ 編譯器即可 (同上安裝方式);而 Raspbian 則已預行安裝。只要在 terminal 下打:

    # gcc (or g++) - v

    即可查知是否已安裝及其版本訊息。

  • 閱讀全文 »

ASP.NET MVC 框架學習心得註記

這幾天利用撰寫一個 Web.NET 小專案的機會,打算使用 ASP.NET MVC 5,藉此順便學習下 Web MVC 的框架技術。

花了快兩天的時間研讀一些文章,總算對 ASP.NET MVC 框架有了全貌的認識;先註記下基本的心得:

  • ASP.NET 源自於 Java Struts MVC,本質完全沒變。
  • ASP.NET MVC 僅是位於系統 3層(3-tier)架構的 Presentation 層,完全沒有涵蓋系統的控制 (Control)與邏輯 (Logic, or Model)層。
    {P.S. 關於這個觀念,個人已在課堂上論述許久;後續再撰寫該篇專文討論。}
  • ASP.NET 的 MVC 中的 Model,係指 Data Model,也就是屬於資料傳遞類型的物件 (DTO, Data Transfer Object),並未涉及到邏輯運算。
  • 微軟的企圖心,利用 EF (Entity Framework) O-R (Object-Relation) Mapping 技術,實現 Model (Data Model)與資料庫的無縫式對應,讓開發人員對於撈取資料庫的程序更是簡化不少。
  • ASP.NET Model 透過 EF 直接對應資料庫,本質上就是 Client/Server 架構;好像重回到 10 年來前 Windows Form 的 4GL,雖然實作變得更簡單 (不需自行控制 Web 表單的狀態與資料庫連結問題),但會導致系統本質上的混亂-沒有確實隔離問題領域 (problem domain) 的功能控制 (functional control)與業務邏輯 (business logic)層。
  • ASP.NET MVC 的頁面 (Page)係以所謂的 Razor 語法 (把它想成 PHP 就好了),以 "@" 為語法的頭尾標記,來實現 UI 邏輯控制的部位。
  • 至於 Web Page 的呈現,則係利用最為普遍的開源專案-Bootstrap,綜合了 HTML/CSS/Javascript 框架技術,來呈現 Web Page 的動態呈現與彈性 Layout 控制 (有些意外,微軟竟然也採用了開源專案)。

聊聊 C# 實作 Excel 選擇權報價交易系統

前兩個月有位委託人希能協助在 Excel 實現台指期選擇權契約報價暨自動交易決策系統。他說原來已有透過一位獨立開發者利用 Excel VBA 撰寫,但無論如何都無法符合他的需求,甚至連正常執行顯示報價都有問題。

直覺聽來,我是不可能考慮使用 Excel VBA 來實作選擇權報價的,它需要動態處理即時資訊的更新太多也太過頻繁,且實現邏輯可能比想像得還複雜,要能動態處理運算並處理選擇權契約月份與履約價格,這非得使用 OOP 語言來實現會容易許多相對也比較有擴展的彈性。

原來是不打算接受這個委託的,因為要克服相關技術的難點預期應該不少。不過後來想想,反正早有計畫要利用 C#.NET 實現包括報價資料源的連接、當沖策略的設計、自動下單等功能,並直接以 Excel 當使用者介面 (GUI),可以直接利用其簡便的圖形報表呈現所需的結果。

由於幾乎是從無到有,且個人對即時性 (real-time)系統的設計實現並不熟悉,包括從研讀大量相關文件到寫碼實作,整整花了約有一個月 part-time 時間,總算能實現在 Excel 畫面上呈現選擇權履約價的報價表。

Excel 實現選擇權報價

初步實現的功能包括有:

  • 自動判斷每個月星期三的結算日,由此可決定起始的契約月份。
  • 可動態選擇選擇權契約月份。
  • 可任意排序選擇權項目。
  • 可自動判斷與更新台指期近月份報價暨昨日收盤價。
  • 閱讀全文 »

初識 Git∣GitHub-關於版本控制

關於版本控管

版本控制 (version control),係針對電子化的檔案,包括文件 (document)、程式碼 (source code)、與其它需被整理保存的資訊等,對其變動情形作有效的追蹤管理。

對於軟體開發過程,軟體開發者利用版本控制來追蹤、維護程式碼、設計文件、設定檔等變動情形;尤其是當面臨多人協同開發時,相關設計的文檔必然會複製多份版本分散置於每一位開發人員的電腦內,只要其中一份版本因功能或除錯 (features or bugs)問題經變更後,則位於其他電腦內的版本也必須保持其一致性。

這種頻繁且複雜的變動管理追蹤,幾乎是無法透過手動方式來管理的,自然而然,一個好的版本控制系統 (version control system, VCS),就要能擔負起下列的管理工作:

  • 對於所有團隊成員們的開發文檔 (尤其係指程式碼),要能保持一致性 (consistent)。
  • 因為錯誤的修改或遺失檔案,可以很輕易地回溯 (revert)至原來的狀態。
  • 任何再細小的變動,都可以知道是誰做了修改。
  • 可以輕易地部署 (deploy)不同版本的程式碼至開發或產品的伺服器內。
  • 團隊所有成員甚至可以利用 VCS 當成相互溝通的媒介。

儲庫 (Repository)

儲庫[1]是版本控制系統的核心組件 (core component)。它是一種資料倉儲的概念,主要儲存著下列的資訊:

  • 一組具階層性 (hirarchy)的檔案與資料夾結構。
  • 儲庫內的歷史性變更紀錄 (historical record of changes)。
  • 一組提交的資訊與指向該提交的指標,稱之為表頭 (head)。

簡而言之,版本控制系統的儲庫就是儲存著多個版本的文檔資訊。基於儲庫的位置所在,可以大致區分為兩種類型的版本控制架構。

集中式版本控制

集中式版本控制 (Centralized Version Control)是典型的「主從 (Client/Server)」 架構。記錄著多個版本檔案的儲庫是置於單一的伺服器內,並提供給具有存取權限的多個用戶端從伺服器提取檔案,所有的變更與提交等資訊均必須在連線到伺服端後才得以完成工作。

最普為人知且為免費開源的集中式版本控制系統,就屬 CVS、Subversion 為代表,並幾以成為業界所熟悉的版本控制標準模式了。

集中式版控系統模型

圖1-1:集中式版控系統模型

參考上圖1-1,集中式版控系統只有一個儲庫,是位於伺服器內。用戶端連線後發出 update 更新指令,就會從中央儲庫內複製一份工作複本 (working copy)至區域端電腦內;當開發者新增或變更檔案內容後,則需要提交 (commit)至伺服器的儲庫內;當儲庫與工作複本的檔案內容有不一致發生衝突 (conflicts)的現象時,則需要作合併 (merge)的動作。

閱讀全文 »

初識 Git∣GitHub-Git 簡史

Git[1]是由 Linux 之父-托瓦茲 (Linus Torvalds)為了維護 Linux 核心 (kernel)所開發出的版本控管工具。

早於 1991-2002 年間,當時 Linux 系統的核心維護,僅以補丁與備份性檔案 (patches and archived files)的方式實現。而後當 Linux 核心的維護規模日益龐大後,核心團隊決定與當時一家提供商業性版本控制系統-BitKeeper 合作,由其免費提供核心源碼的儲庫 (repository)。

這段蜜月期至 2005 年時,Linux 核心開源社群與 BitKeeper 結束長達三年的合作關係,而這也使得核心團隊必須著手開發屬於他們自己的版本控制工具。從 BitKeeper 的使用經驗中,他們制定了新的版本控制系統需要能達成下列幾個目標:

  • 速度。
  • 簡單設計。
  • 可以給予數以千計並行分支 (parallel branches)的非線性開發模式強力支援。
  • 完全分散式。
  • 能有效處理如 Linux 核心大型專案的規模 (速度與資料量的考量)。
  • Git 自 2005 年誕生以來,日益成熟且易於使用,而且還能維持原來的初衷-確實履行上述的目標設定;而最為人樂道的分散式架構,已證明更能有效應用在大型的協同式專案開發。有別於 CVS/Subversion 的中央集權控管方式,Git 可以不需要伺服器就可以在單機上運作版本控制,這也使得原始碼更容易發佈與分享。

    閱讀全文 »

軟體思維顧問

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

Personal