:::
顯示具有 GitHub 標籤的文章。 顯示所有文章

Zentyal 3.0動手做模組入門 / Zentyal 3.0 Module Development

Zentyal 3.0動手做模組入門 / Zentyal 3.0 Module Development

image

Zentyal是一個強大的路由器套裝軟體,他也提供了客製化製作模組的功能。我參考Zentyal的說明建立了一個修改SSH連接埠的功能,並記錄一下製作模組時的一些步驟。

Zentyal is a powerful Router and could install custom module. Base on Zentyal module development tutorial, I created a SSH module for modifying SSH port. Following is my create steps.


安裝Zentyal / Install Zentyal & Configuration

image

我安裝的是zentyal-3.0-2-amd64.iso,Zentyal 3.0 64位元版本。安裝在VirtualBox上,並配置兩張網卡:eth0為Host-only,設定為內網;eth1為NAT,作為外網。

我將預設帳號設為Linux的root群組,以省去每次都要sudo的困擾。所以下指令我都不用sudo,因為已經假設是root權限了。

然後我也關閉了Zentyal的桌面功能,作法參考這篇,語法是:

sudo mv /etc/init/lxdm.conf /etc/init/lxdm.conf.nostart

最後我安裝了pound作為後續研究的需要,語法是:

apt-get install pound

Zentyal雖然不難裝,但是也有些稜稜角角的小細節需要額外下指令去克服。詳細安裝細節此處就省略。

Zentyal模組開發教學 / Zentyal module development tutorial

Zentyal已經提供了模組開發教學的網頁文件。我大致上是照著這個步驟來操作,不過有遇到一些問題,此篇一一記錄細節。

安裝開發環境 / Development Environment

要開發Zentyal的模組需要安裝很多東西,以下列出我安裝的東西:

apt-get install build-essential gcc zbuildtools fakeroot

然後在家目錄中下載Zentyal的鷹架工具skel,並調整鷹架工具的權限:

wget https://raw.github.com/Zentyal/zentyal/master/extra/scripts/zentyal-module-skel
chmod +x zentyal-module-skel

這樣就準備好可以開發了。

建立SSH模組鷹架 / SSH Module Scaffolding

我們可以用鷹架工具skel來建立SSH模組鷹架。現在位置是在家目錄(cd ~)底下,指令為:

./zentyal-module-skel SSH ssh

然後就冒出一個空的模組啦。這到這邊為止的進度是教學中的Scaffolding

修改SSH模組 / Revise SSH Module

鷹架模組無法正常運作,所以我們要進行修改。修改的方式教學中寫得很清楚,請看這個網頁。修改之後的結果請看我上傳到GitHub的程式碼

主要修改的程式為:

跟教學文件相比,修改的差異在於設定檔是SSH的/etc/ssh/sshd_config,而參數的樣板service.conf.mas也差異很大。

必須特別要說明的是在參數樣板中要加入#開頭的註解文件時,必須要用以下語法來加入:

% print "# the setting of \"PermitRootLogin without-password\".\n";

注意雙引號""中間要記得脫逸,還有最後要加上\n表示換行。

編譯並安裝SSH模組 / Compile & Install SSH Module

編譯的方法是先移動到模組目錄,然後輸入zentyal-package指令:

cd ~/ssh
zentyal-package

編譯成功的話,模組目錄底下會冒出debs_ppa,裡面是可以安裝的檔案。再來就是安裝編譯好的檔案:

dpkg -i ~/ssh/debs-ppa/zentyal-ssh_3.0_all.deb

如果安裝時沒有特別的錯誤,那就是安裝完成了。我猜這個安裝檔應該可以轉給其他Zentyal系統,讓他們也能安裝你自己製作的模組。

啟用SSH模組 / Enable SSH Module

image

安裝好SSH模組之後,導覽列Core底下會出現SSH。但是它目前還沒啟動,要先到Module Status中,在SSH的Status裡打勾,然後再右上角Sava changes。

這樣就之後就可以正常使用SSH模組了。


結語:只是開始 / Conclusion: Just Begin…

摸了一整天總算搞懂怎麼修改Zentyal。意外地發現它的工具寫得很好用,也不難理解。只是一些細節它沒有說明,讓我試誤了好一陣子。這些細節解決之後,我想要開發新功能應該是得心應手吧。

我目前想要做一個整合pound反向代理伺服器的功能。然後再做一個DNS + NAT Port Forwarding + Reverse Proxy綜合控制的介面,讓管理者可以一口氣在一個介面設定這些東西。

不過目前進度到這邊得暫停來做一下開會的準備了orz

(more...)

「布丁布丁吃什麼?」在GitHub上開放原始碼囉! / My Blog is now open source on GitHub!

布丁布丁吃布丁

「布丁布丁吃什麼?」在GitHub上開放原始碼囉! / My Blog is now open source on GitHub!

image

布丁布丁吃什麼?」這個Blog最大的特徵就在於網站上有著許多奇奇怪怪的小功能。從側邊欄上的「最近留言」、「最新文章」「留言板」,到文章本身的「自動摘要法」「圖片延遲載入」等各種小工具,都是Blogger沒有提供、我參考別人的寫法或自己撰寫而成的功能。

現在這些程式碼統一保存在GitHub上進行版本控制。對於改造Blogger有興趣的朋友、JavaScriptCSS有興趣的朋友,歡迎參考我的程式碼,彼此多多切磋交流吧。

Welcome to Pulipuli.blogspot.tw. My blog has many features which are not provided by Blogger, for examples, like “recent response list”, “recent post list”, “post auto digest”, etc.. Today, I released the code of these features on GitHub. You can use them freely. Enjoy it!

存放空間的遷移歷程 / History of Code Hosting

說真的,「布丁布丁吃什麼?」很早之前就是Open Source了。除了Blogger內建功能之外,大部分功能都是以JavaScript與CSS的程式碼來實作。這些程式碼本身都是必須讓你下載之後才能執行,換句話說,這些功能本身就是「開放」的程式碼了。

那麼這些程式碼是存在哪裡呢?這邊我就在簡單的回顧中記錄一下「布丁布丁吃什麼?」的這段歷史吧。

Google Page Creator

我印象中「布丁布丁吃?」時期一開始的時候,我是將程式碼擺放在Google Page Creator中。Page Creator是Google早期供人架站的空間。雖然它只有提供100MB的大小,在流量上也有諸多限制,但是擺放我這種小流量Blog使用的JavaScript與CSS程式碼已經很夠用了。

不過老實說它不太好用,沒有目錄功能(因為Page Creator是用來建立網頁、而不是網站),上傳介面也很難操作。幾年之後,Page Creator被關閉,成為歷史名詞。而原本在Page Creator上的程式碼則是被轉換到Google協作平台上繼續運作。

Google Sites協作平台

image

由於Google Page Creator被關閉,我的程式碼就順勢移到了Google協作平台上,叫做「布丁布丁吃?」wiki。協作平台搭上了當時流行的wiki風格,讓人容易在網頁上建立資料,也允許更複雜的網站架構。

協作平台是個穩定的架站空間,我一樣把它用來存放JavaScript與CSS程式碼。受惠於協作平台的功能,我可以將程式碼分門別類,每次上傳檔案也會記錄不同的版本。在「布丁布丁吃什麼?」介紹的功能中,有些是獨立出來讓讀者安裝使用的程式碼,這些程式碼就會放在協作平台中,跟「布丁布丁吃什麼?」專用程式碼分開保存。

可惜的是,協作平台的上傳功能依然很難用。點開網頁、選擇檔案、上傳的這幾個步驟雖然看起來很簡單,但是時常修改程式碼的話,這些步驟依然是相當地煩人啊!

Dropbox

image

「布丁布丁吃什麼?」的程式碼中,給讀者使用的程式碼是放在協作平台,而現在你所看到「布丁布丁吃什麼?」專用的JavaScript與CSS程式碼其實是架設在Dropbox的公開資料夾Public底下。

知名雲端硬碟Dropbox早在很久之前就提供了架站空間的功能,你可以把網頁程式碼放在公開資料夾上供他人瀏覽,也可以用DropPages之類的第三方應用輕易地架起專業網站。

雖然我的網頁內容寫在Blogger上,不過JavaScript與CSS卻也可以放在Dropbox中。我這次搭配Directory Junction整合了Aptana Studio 2 IDE與本機端XAMPP伺服器的運作環境。我不僅能在本機端開發與測試「布丁布丁吃什麼?」,也能夠用簡單地幾個步驟就能夠將JavaScript與CSS進行壓縮、上傳到Dropbox公開資料夾。

如果你對Dropbox有興趣的話,歡迎使用我的推薦連結來註冊Dropbox,順便幫我增加一點空間吧!

布丁邀請註冊Dropbox連結

GitHub

6a00d8341c767353ef016762f7c808970b-800wi

Dropbox提供了我的程式碼穩定的運作環境,而GitHub則是提供了查看我的程式碼的社交平台。

之前我開始研究起GitHub,這是因為最近看到幾篇新聞都在討論GitHub。GitHub是許多開放原始碼專案存放的保存庫,近年來也逐漸成為公司招聘程式設計師的管道。因為公司能在GitHub上看到每個人實際上寫的程式碼,而不是像LinkedIn只能看到幾行經歷。

雖然說光看程式碼也不見得夠看到實際上運作的平台,就像是「布丁布丁吃什麼?」的GitHub也是要搭配Blogger才能運作,不過光是為這個社群貢獻程式碼的精神,我覺得就具有令人值得去做的意義。

我想藉由「布丁布丁吃什麼?」的程式撰寫來練習GitHub與Git的用法,這也是「布丁布丁吃什麼?」作為讓我實驗程式碼的用途之一啊。

近期「布丁布丁吃什麼?」的調整 / Recent Changes in Pulipuli.blogspot.tw

image

除了用GitHub與Dropbox改進「布丁布丁吃什麼?」的功能調整流程之外,最近也做了幾個小地方的修改。

英文標題與摘要 / Writing Title and Abstract in English

image

作為博士生,英文寫作是必須要去面對的課題。我希望能夠在日常生活中就常常使用英文來寫作,所以現在就從寫Blog開始。我寫的英文應該會有很多錯誤,歡迎大家用留言回覆來幫我糾正一下喔!

至於為什麼只有標題跟摘要是英文,這是因為光是寫標題跟摘要就花了好多時間,等更能上手之後再來考慮全英文的Blog吧。不過我寫這Blog一部分就是為了給華人地區的讀者看,所以仍然會以中文版本為主喔!

QR Code

image

有人發現到了嗎?這是今天才剛出來的新功能喔!「布丁布丁吃什麼?」每篇全文文章最後都加上了QR Code的名片,讓讀者方便知道這篇文章的來源。

對我來說,因為我很常查閱「布丁布丁吃什麼?」的文章,有時候在電腦上看一看想要轉移到手機上的時候,在手機輸入網址總是太過麻煩。現在我只要在手機上用QR Code Scanner之類的App掃描一下QR Code,就能在手機上直接開啟文章內容喔!

image

在列印的時候,也會出現這個名片的樣子。就算將「布丁布丁吃什麼?」印成紙本,也能夠透過QR Code方便地回到網頁上喔。

這個功能是以jquery.qrcode.js為基礎,我自己建立了它的分支並進行改造,在加上適用於Blogger環境的包裝器(wrapper)來實作。如果有人也想要安裝QR Code到你的Blogger的話,請回覆在下面,我有時間會再另外寫一篇QR Code的安裝教學。


結語 / Conclusion

藉著調整Blog的契機,這篇介紹了「布丁布丁吃什麼?」的JavaScript與CSS原始碼存放空間選擇的歷程,目前是用以下規則來擺放程式碼:

然後聊了一下最近「布丁布丁吃什麼?」的變動,也順便宣傳自己加入的QR Code功能。

最後我想閒聊一下QR Code。我認為QR Code不僅僅只是讓人在廣告上開啟網頁而已,它可以是連結實體與數位(從印出紙本開啟Blog)、數位到數位(從螢幕掃描到手機),也可以藉由加入特殊參數讓它用於開啟指定的應用程式。而這個簡單的轉換,卻能夠連結不同時空的人與物。

想像一下,公車的乘客不需要在座椅上塗鴉了。他們可以掃描這台公車專屬的QR Code,然後在這台公車專屬的線上討論版聊天;圖書館的讀者不僅僅是在書上從別人的筆記來認識與這本書內容相關的事情,他能掃描QR Code來到這本書專屬網站上來取得相關資訊,更能在討論版上認識同樣閱讀這本書的愛書者。

QR Code只是簡單的技術,重點在於要如何應用。這也是我們作為研究者應該去思考的問題。共勉之。

(more...)

GitHub入門 Part.3 GIT版本控制實作教學

布丁布丁吃布丁

GitHub入門 Part.3 GIT版本控制實作教學

image

繼前一篇配置好git運作環境之後,這篇就是開始教大家實際上的操作。這包括了之前概念介紹時用到的Pull、Push、Commit、Conflict、Branch跟Check out等等常用的動作,並且跟每天上下班的情境做個結合,讓大家能夠把git版本控制融入到日常作業中。

  1. Part.1 版本控制介紹
  2. Part.2 工具安裝與環境配置
  3. Part.3 Git版本控制實作教學

投影片

(Google DocSkyDriveBox.net)

這次也跟前一篇一樣做了投影片方便講解,但是投影片沒辦法寫很多細節,細節的部份請看下面文字敘述。

上班開始工作:Pull

image

上班囉!每天開工的第一件工作,就是先把遠端伺服器最新的程式碼下載下來,更新本機端的程式碼吧。

image

在儲存庫的資料夾底下按右鍵,開啟「Git 同步…」。

image

點下「拉取」(Pull)按鈕。如果順利的話,你的本機儲存庫就會直接跟遠端伺服器同步,把程式碼都更新為最新的狀態了。

工作中的習慣動作:Commit

image

當我們為了某些工作修改了儲存庫的原始碼之後,你會發現有些檔案的標示不太一樣。

image那些被修改的檔案前面都會有紅色驚嘆號「」的標示。這表示他的檔案狀態被標示為「已修改」。

image其他「未修改」的檔案則是維持原本的綠色打鉤「ˇ」標示。

當我們修改告一段落之後,我們就可以把目前的版本狀態做一次commit。

image

首先是在儲存庫按右鍵,執行「Git 提交 –> "gh-pages"」。後面的「gh-pages」表示現在的分支,一般來說,通常會是「Master」主幹。

image

接著會跳出Commit對話視窗。上面訊息記錄你必須輸入一些文字,記錄你這次修改的內容與目的。中間的變動列表會列出所有你這次修改的檔案。確認無誤之後,按下確定。

image

出現藍色文字表示Commit成功。

image

Commit之後,剛剛呈現「已修改」紅色驚嘆號的「.gitignore」檔案已經恢復成「未修改」的綠色鉤鉤。

你可以時常Commit你的儲存庫,Commit的間隔越短越好,但是每次Commit的版本內容最好都是確定可以運作的狀態,而不是改到一半無法運作的系統。

到目前為止,每次Commit其實都是在你本機端進行而已。這跟遠端的GitHub沒有關係,也跟你團隊中其他夥伴的電腦檔案沒有關係。

下班收拾工作:Push

image

我們今天的工作已經告一個段落了,準備把修改過很多次的程式碼送回遠端伺服器,也就是GitHub上。這時候我們要做的動作就是Push。

image

跟Pull一樣的,我們在儲存庫資料夾按下右鍵,開啟「Git 同步…」。

image

不同的是,我們這次要做的動作是Push(推送),請按下「推送」按鈕開始把本機端的儲存庫送到遠端伺服器GitHub上。如果順利的話,你就可以看到藍色的成功文字。

還不能那麼快下班:Conflict

image

有很多時候Push並不會這麼順利。舉例來說,上圖Computer A跟Computer B對同一份檔案做修改,然後下班時分別將該份檔案Push到伺服器,這樣就會發生衝突 Conflict,其中一方的Push會失敗。

發生衝突的原因:互相衝突的程式碼

團隊合作中很容易發生衝突,現在Computer A跟Computer B都修改了index.html。以下是Computer A對index.html的修改內容:

   1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   2: "http://www.w3.org/TR/html4/loose.dtd">
   3: <html xmlns="http://www.w3.org/1999/xhtml">
   4:     <head>
   5:         <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6:         <title>New Web Project</title>
   7:     </head>
   8:     <body>
   9:         <h1>New Web Project Page</h1>
  10:         <!-- test 2 -->
  11:     </body>
  12: </html>

然後是Computer B對index.html的修改內容:

   1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   2: "http://www.w3.org/TR/html4/loose.dtd">
   3: <html xmlns="http://www.w3.org/1999/xhtml">
   4:     <head>
   5:         <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6:         <title>New Web Project</title>
   7:     </head>
   8:     <body>
   9:         <h1>New Web Project Page</h1>
  10:         <!-- test 1 -->
  11:     </body>
  12: </html>

其中這兩個檔案的第10行內容是不一樣的,這就是發生衝突的原因。

然後他們修改之後各別Push到了伺服器上,這順序是這樣:

  1. Computer A Push了index.html,Push成功。
  2. GitHub上最新的index.html是Computer A的版本。
  3. Computer B Push了index.html,Push失敗。

image

現在Computer B嘗試Push,可是他失敗了,因為衝突發生,GitHub無法直接把Computer B的儲存庫加入伺服器中。

接下來,我就是要介紹發生衝突的時候,怎麼使用TortoiseGit來做合併、解決衝突。

1. 發生衝突的話就先Pull吧

image

既然遠端伺服器不接受你的Push,那就代表遠端伺服器有比較新的版本。我們必須先Pull取回遠端伺服器的版本來做個檢查。

2. 處理衝突清單

image

這份衝突清單會列出Git發現本機端跟伺服器端不同的檔案。請雙擊檔案名稱,我們來一一解決這些衝突。

3. 合併

image

TortoiseGit提供了一個精美的編輯器來合併程式碼:TortoiseGitMerge。從上圖中你可以看到左上角是「對方的 – REMOTE」程式碼,也就是代表位於GitHub上最新的程式碼端;右上角則是「我的 – LOCAL」,也就是本機端的程式碼;而下方「已合併 – index.html」則是合併雙方程式碼之後的結果。

請試著把遠端與本地端做個整合,然後再按照上圖所示位置「標記為已解決」。

4. Commit已解決的版本

image

解決這些已衝突的檔案之後,記得還是要做一次Commit喔。

5. 再度Push

image

接著我們再做一次Push。

image

這次的Push就會成功了。

如果又失敗,那可能是又發生衝突了。請再繼續Merge吧!

新功能開發:開啟Branch

image

接下來我們來實作分支的功能。現在我們試著在下一次commit的時候建立一個新的分支,叫做「demo-branch」。

image

要建立一個分支很容易,就是在Commit的時候,把「新建分支」打鉤,然後在「提交至」設定新分支的名稱「demo-branch」就可以了。

2013-02-05_200100

於是現在儲存庫所在的分支就會變成你新建的分支。按下右鍵時Git提交後面的名稱就是現在所在的分支。

接著你就可以在這個分支修改你要的功能,而不用擔心常常跟其他人衝突囉。

完成新功能開發:合併Branch

當我們的新功能已經開發完成之後,接下來我們就要把分支demo-branch現在的狀態合併到主幹master上。在TortoiseGit裡面有一套作法,請照著以下步驟來操作看看。

1. 切換分支:Checkout

image

首先,我們要先把儲存庫目前的版本HEAD切換回主要分支master上。這個動作叫做Checkout。

image

作法是在儲存庫按右鍵,進入TortoiseGit中的「切換/取出」。

image

先切換到你最終要保留的分支。雖然上圖是寫gh-pages,但通常會是master,也就是穩定的版本。

這個Checkout功能也可以用來切換到標籤、特定版本,方便我們快速回溯到之前的狀態,以便我們偵錯。

2. 合併分支

image

當你按右鍵的時候,會看到目前儲存庫的狀態移到了分支gh-pages中。然後接著我們使用的是TortoiseGit中的「合併」功能。

image

請選擇你要拿來合併的分支,也就是你剛剛開發完新功能的分支。

image

如果你的修改只是比master多推進幾個版本,Git會用Fast-forward merge來進行合併,這不太會有問題。如果順利的話,就會看到上圖藍字的訊息,表示成功。

3. 發生衝突

image

如果在你開了新分支之後,master又有往前推進幾個commit,那麼合併時就比較容發生衝突。按下左下角的「解決」吧。

2013-02-05_204319

這時候跳出了commit對話視窗,下面有變動的檔案清單。

回到檔案總管來看,index.html被標示了黃色三角形驚嘆號image,代表這個檔案發生了衝突,需要我們解決。

4. 解決衝突

2013-02-05_204533

在發生衝突的檔案index.html上按右鍵,然後進入TortoiseGit選擇「編輯衝突」。

image

然後會跳出TortoiseGitMerge編輯器。就跟之前在處理Push的衝突一樣,請在下方把衝突處理完,然後點選「標記為已解決」。

5. Commit解決衝突的版本

2013-02-05_204805

接著我們再做一次Commit,把解決衝突的版本儲存起來。到目前為止,我們順利地把demo-branch合併到master分支,但這只是本機端作業而已。

6. Push已合併的版本

2013-02-05_205025

最後我們把已經修改好了版本Push到GitHub。因為我自己測試時做了幾次解決衝突的過程,所以中間版本列表很多。其中你可以看到最上面一層會有Merge branch的訊息,表示在這之間我們的確做了一次合併分支。

image

如果Push成功,那麼我們合併分支的工作就大功告成囉!


結語:Git還有很多功能!

我在跟實驗室的同學們介紹完上述的基本功能之後,大家對於Git還是有很多好奇的地方。像是有沒有單一檔案回溯功能啦、或是應該安排時間統一進行Merge,以免一直發生Conflict。大家的意見都很有意思,也加深了我對Git的期許。

上述的基本功能只是基本中的基本,實務上Git還有重新接樹Rebase、全新樹Stashing、里程碑Tag等功能,而GitHub常見的開發模式也並非上述介紹的單一中心式(所有人都連到KALS儲存庫做開發)、而是聯合管理員式(大家都Fork各自的KALS標註系統,然後透過Pull Request來整合到正統Blessed的KALS標註系統,可以想像成是大型Branch的感覺)等方式。想更進一步了解這些概念的人可以參考Littlebtc的「寫給大家的Git教學」投影片

而TortoiseGit還有許多功能是我們尚未探索到。可能隨著協同作業複雜化,未來我們會繼續探究更多其他的功能吧。

希望透過這些文章的介紹,大家也能一起來co-work,Coding Together吧!

(more...)