g0v & Git Cafe

Topic #1 g0v零時政府 & open data

講者：江明宗

---

一、簡介g0v與open data

• g0v -> 為了補足gov的不足而成立


• g0v 社群 motto ：「不要問為什麼沒有人做這個？先承認你就是『沒有人』，因為『沒有人』是萬能的！」


• open data 的五個等級

• 1.open licence : 開放文件的存取
• 2.RE : 提供的文件可再使用/修改
• 3.CSV : 純文字開放格式
• 4.Url : 有固定的網址存放資料
• 5.Ld : 除了自己的資料，還能跟別人的資料連結在一起

二、g0v專案

• Case 1：開放政治獻金
• 起因：監察院的資料必須到場查閱
• 2013開始
• 進監察院取得紙本資料，再將其掃描成電子檔
• 因為圖片幫助不大，考慮用openCV按照掃描完成的表格切割
• 工程師設計出一個網站，用來比照文字與圖片
• 2014/04/19 專案正式公開
• 24小時內，完成7個專戶，共309,666個文字比對
• 截至目前，取得了28個專戶資料，但仍只是冰山一角(監察院有約6000個專戶)
• 未來展望：將公司之間的投資關係畫做關聯圖，以釐清政治人物與企業之間的關係
• Case 2：
• 政府的選舉公報在2天前才會發出
• ->要在 2 天內看完十餘名的候選人的資料
• 減少盲目投票，讓民主社會的台灣更進步
• 所以我們成立了一個網站，匯入村里等行政區以及選舉資料庫的資料，羅列出所有候選人的政見，並透過tag分隔出政黨、選區等等
• 在Hackpad上線上編輯
• 發佈想要整理的格式，轉發至ptt、FB
• 運用newsdiff資料取得候選人相關新聞，並且將其比對
• 2014/7月時，GitHub開始有人傳送PR
• 2014/9月，匯入中選會登記概況

---

Topic #2 Git Cafe

講者：林旅強 Legist Qiang

---

一、Git Cafe與Git

• 代碼託管 + Open Source 協作平台
• 版本控制：
• 對修改留下log，可以輕易知道改了什麼以及回復先前的文本
• Git就是一個多人版本控制系統
• 分散式，每個人的本機端都有一種套的版本

二、Open Source

to understand the concept you should think of free as in free speech not as in free beer -Richard Stallman

• Free software foundation
• GNU project (GNU's not Unix)
• GPL協議
• 自由軟體定義
• 有使用程式的自由
• 有修改程式的自由
• 有再散播程式的自由 
• Free Software -> Open Source
• 因為free自由總是被誤解成免費
• The Cathedral and the Bazaar
• Open Source之所以好，因為它的選擇性很高，就像一個市集。
• 蓋教堂是種開發模式，而市集又是一種開發模式
• Creative Commons
• Community & Crowdsourcing
• e.g. PTT 成為納莉颱風第一手訊息流通處 

三、Open Source與個人發展\

• 把自己的code放上平台，會有自己與助教之外的人給予建議
• 參與開源專案，發掘自己真正的興趣
• 遇到問題，通常會去問有經驗的人，社群在業界與學界都有相當好的資源

四、如何參與社群

• 國際社群
• e.g. Linux Kernel,Debian,Ubuntu,Gnome...

區塊加密的工作模式

1.當message size大於或小於加密的block size時，我們通常會將其切割:

• 比如在AES的情形下，容許一次加密的明文為128bits，那我們必須先把加密文件切割成若干個128 bits 才能進行加密處理。

2.為什麼我們需要引入各種加密型式

• 將加密算法配合至各種需要（如上述第一個情形），同時也能增加密文的強度

3.ㄧ些常見的塊密碼工作模式

• ECB : Electric Codebook

• Let Plain text to P1,P2,P3,...Pn
• Let Cipher text  to C1,C2,C3,...Cn
• 把明文分成若干的block，各自加密，或將密文分成若干的block，各自解密
• 弱點：重複的block + 重複的Key → 重複的密文，面對頻率分析相當危險
• 比如加密星期二寄出的Email，Tuesday重複被加密成同樣的密文
• 重複觀察就知道，這都是禮拜二寄出的，可以借此解出金鑰

• CBC：Cipher Block Chaining

• 一樣把明文分成若干塊
• 把目前明文跟前份密文做Xor，之後再將完成Xor的明文送入加密演算法
• 第一份明文需要一個初始向量(Initial Vector)做Xor
• 限制：
• Bit Flipping Attack
• 因為傳送中有一點缺失，密文將大量改變 -> DoS
• 需要一個IV，要讓sender and receiver 知道且不可重複

---

上述模式在明文被分割成若干區塊前不可執行，需要補綴處理至區塊大小
接下來的模型將明文當作位元流，可以對即時的資料進行加密

---

• CFB：

• 將明文視為位元流
• 首先將明文切割為兩部分b-s與s
• 將明文加密，捨棄b-s的明文，將s部分的密文與前一部份的s明文Xor得密文C
• 把新明文左移s位，插入C至新明文

• 限制：
• 會有延遲，無法併行處理資料
• 跟CBC mode一樣，錯誤容易擴散
• 那麼，有偵測錯的方法嗎？
• 可以加入除錯碼，可以及時發現錯誤，但要犧牲一個bit
• PCBC mode

• OFB：

• 同樣的，把明文作為位元流
•  一開始加密一個初始向量
• 將加密後的初始向量分別傳到：
• 1.第二個block
• 2.與P1做Xor -> 得密文C1

• 再來對先前傳至第二個block的IV做加密，完成後分別傳到第3個block ......
• 優點：
• 不依賴產生出的P1或C1， 所以不產生時間延遲
• 錯誤不會擴散

• CTR (Counter):

• 加密方法：將Counter i 加密，與Pi進行Xor得到密文Ci，持續進行直到完全加密
• 解密方法：將Counter i 加密，與Ci進行Xor得到明文Pi，持續進行直到完全解密
• 每進行一次運算，便會將Counter++，所以稱為計數器模式
• Counter 不應該被重複使用，避免相同明文出現相同密文
• 類似於ECB的觀念，但放入加密器的是會變動Counter，而且Counter總是128位，所以可以視作密鑰流處理

---

• 確保資料的正確性
• message authentication
• CBC - Residue, or CMAC , NMAC
• HMAC
• 核心觀念：建立一個除錯碼以及演算出除錯碼的方式，由傳送方跟接收方約定而成，接收方在獲得密文後再進行驗證。

我的紫微星哪有這麼萌!?

Speaker：楊育誠

---

這次的分享和之前有個很大的不同，就是製作團隊從工作室至公司，所以在企劃、創作與行銷方面有著不同的格局，也論及到較多實務上及行銷上的策略，可以說是更貼近遊戲產業的現實面吧～


#1.星耀學園是什麼樣的作品

• Animen 數位科技

星耀學園是以紫微斗數為題材去進行動漫化的作品，當然啦，我們不能只餵公子吃天文圖，便置入了一堆萌妹子代表各個星靈，校長也坦承這近似西洋的黃道十二宮，但是就根本來看，把紫微斗數當背景的AVG還真的是絕無僅有，這無形中也成了行銷的噱頭。

學園設定來自於烏來鄉，至於為什麼在烏來鄉？因為那裡有山有水有溫泉，簡單來說就是滿滿的特色，而且像這樣的神奇學園，如果待在大都市裡大概天天都會被查水表，也顯得競技場這類古色古香的情境格格不入。

#2.遊戲實務製作部分

設定方面往往歸類於前期企劃，而在一個大團隊中，企劃特別要講究方法。

要將企劃內容盡可能的圖像化，不必拘泥於精細度，但是一定要呈現出概念與流程，比如說要做神奇寶貝的戰鬥，企劃要告訴團隊要如何呈現，像戰鬥方式（回合or即時）、場景配置、神奇寶貝出現的位置等等。我們可以寫一個小程式來模擬企劃內容，這樣討論時不僅降低溝通上的失誤，也能更貼近實務上面臨的難點或對現有設定該加強的部分。

而說起AVG，圖量相較於程式更重，如差分圖、臉部表情、立繪，這些都是需要精雕細琢的部分，而且良好的CG對於進軍同人市場是不可或缺的，講者有特別提到，以現今台灣市場的行情，一片沒有動畫化的AVG能賣個一千片就算不錯了，成本的回收只能鎖定在同人市場，比如角色人物的周邊，日常四格漫畫以及輕小說等等。

#3.業界的發展情形

首先要面對一個現實，所謂國產遊戲，風格到底要是什麼？

講者認為，什麼風格有市場，就嘗試什麼風格。

台灣經常有一種聲音，國產遊戲該有新風格，但是到底要如何去呈現、如何去定義，退一步而言，就算呈現出了新風格，也不保證能在市場上存活。其實原創並沒有什麼風格的問題，考慮風格當然很好，但是作品要先達到及格標準才行。


進行企劃時的思考點：

1.玩票性質與長遠發展2
2.外部及內部資源的評估

• 確保資金回收\合作對象\企劃\程式\美術

3.遊戲類型

•     大眾或小眾，以什麼去決勝負
•     低美術門檻/高遊戲性 v.s 高美術門檻/低遊戲性
•     老實說，靠現今靠遊戲性出線的非常非常少

4.發行平台

• Steam/appstore/ps平台……

5.原創or改編
6.開發規模與賣點
7.上市時間與通路

• 避免碰撞強檔，考慮發行商

8.多波次的行銷策略
9.數據回收與後期報告

• 數位文創投資報酬率高\風險也相當高

10.版權模式與跨平台的可能性

• 既然決定的是數位文創，就該注重在版權授權，這在數位文創上的獲利才是最高的

11.放長線釣大魚vs炒短線型遊戲

12.策略上的盲點

• 游擊戰與陣地戰的選擇
• 推很多不一定紅的 v.s 拼一步會紅的
• 海外市場的佈局策略與輸出
• 開闢第二戰場
• 同人/週邊/置入性行銷
• 品牌聯名效應
• 虛擬與實體的交叉模式
• 透過展覽推銷遊戲
• 時間換取空間的策略模式

自由軟體 - 台南數位文創園區

台南數位文創園區

講者 : AJ

---

• 園區提供設備
• 3D印表機
• 雷射切割機
• Tinkercad
• 線上建模網站
• 使用OpenGL，所以不支援IE
• PanScience泛科學
• 台灣第一大科普網路社群
• 用輕鬆有趣的方式，推廣科普閱讀
• Npost公益交流站
• 關注主流媒體不關注的公益問題
• 讓公益變成全民運動

 it's technology married with liberal arts, married with the humanities, that yields us the result that makes our heart sing

協會的初衷：科技應當與人結合，與人作互動。我們一開始就是使用PunCar把自己送進任何需要我們的地方，教導他人Excel、Google、Dropbox，用最簡單的方式，去替不會使用電腦的人解決問題，而在我們離開那裏後，改變仍能留下，讓科技與當地人結合，進而改變他們的生活。同時這也是增長自身經歷的過程，能從不會使用電腦的人的思考模式出發，換個不同的邏輯或許也會有不同的發現。

台南數位文創園區與政府合作，為任何想創業的人，想自己做小物品的人，想參與活動的人，提供空間與設備讓大家互相認識，同時也會邀請一些創業家來演講，讓每個人都有學習與分享的機會。

Queue - 佇列

Queue跟Stack一樣都是有順序性的，存與取之間有一定的規則。直觀來看，Queue其實就像隊列，排頭的當然先服務，後到的就得等前面完事才能往前走，當然，我們不考慮插隊的情形，每次要加入這個隊伍的，都必須排在隊伍尾端，所以成了FIFO(First in First out)的型式。

1.Queue ADT

• Queue CreatQ(maxQueueSize) ：創造一個空的quene
• Boolen IsFull(quene,maxQueuesize)：判斷quene是否滿了，
• Boolen isEmpty(queue)：判斷quene是否為空
• Quene Add(queue,item)：添入item是quene
• Element Delete(queue)：刪除quene中的一個物件，並把它傳回給item

Queue的操作都與Stack類似，主要有兩個不同：

其一是stack有一方是底，我們只需要一直把東西丟進去丟進去，不過quene則是兩端皆開放的，要分別處理排頭跟排尾，所以我們需要兩個變數(front , rear)來儲存quene的頭跟尾，而front與rear的初始值一樣可以當作-1，配合於isEmpty的判斷上。

• add : rear = rear +1
• delete : front = front +1;

第一，從上述的操作，我們可以看出quene會不斷地往右偏移，所以在判斷isFull時，我們不能僅考慮rear是否>maxQuenesize，我們要思考的是，這個隊列是不是真的滿了？如果沒滿，則要把整個隊列往左平移。

2.Circular Queue

它是一個環狀的queue，這能解決上述第二個問題，不過他也得付出一點代價，即只能放MAX_Queue_Size - 1個元素，剩下一個必須用來判斷queue為空或為滿。

3.其他quene形式

• Double ended queue：兩端都能放且兩端都能拿的queue
• Priority queue：元素在queue的位置跟它的priority值有關，跟進入queue的時間無關
• Double ended priority queue

Stack 堆疊

1.什麼是Stack?

如果把input的資料當成積木，Stack就像疊積木一樣，把新加入的磚塊放在後加入的上面，要拿出也是把新加入的拿出，屬於LIFO (Last - in -First out)模型。

2. System Stack

有些語言函式的呼叫也是個Stack，比如Function A呼叫了Function B，而Function B又呼叫了Function C，用Stack結構來表示的話：

FunctionC

FunctionB

FunctionA

FunctionC會先執行，完成後才會是B與A。
當然囉，如果函式巢狀增加，這些積木也會越疊越高，而高度也是有個極限的，當到某個地步後還要疊的話，就會發生stack overflow的情形，所以在Recursive的終止條件上要特別注意。


4.Stack 的抽象資料結構

• Stack CreateS(maxStackSize) ：創造一個空Stack，並給予這個Stack最大容許儲存量
• Boolean IsFull(stack, maxStackSize)：確認stack是否滿了，避免push時把item丟入錯誤區塊
• Boolean IsEmpty(stack)：確認stack是否為空，避免pop時丟出的錯誤資料
• Stack Push(stack,item)：配合isFull使用，當還有位置放時，把item放入stack
• Element Pop(stack)：配合isEmpty使用，當裡頭還有物件，就把物件丟給item

實作stack最簡單的方法就是用一維陣列去處理它，為此我們需要兩個東西，一個是陣列stack[MAX_SIZE]來儲存，另一個就是top，用來表示目前存了多少item。

top

...

...

Stack[2]

Stack[1]

Stack[0]

在創造一個Stack時，可以把top設為一個非合理範圍，比如 -1，這樣便可在isEmpty上做判斷。
每當push就top++，如果top合理，便加入物件，pop則把top--，丟出物件。

5.一些Stack的應用

System Stack就是堆疊的基本應用，他用於在Run-time時決定Function呼叫的順序。在進行Backtracking與Recursive上，也涉及了Stack的概念。

Excel - 第二次會議

這次開會是21:00~23:00 ，比起上次挑燈夜戰到00:30，整體狀況感覺好了很多。不過感冒還是沒有好，感謝AJ提供的楊桃汁跟金桔汁，可惜我從小喝到大，現在已經對那些有陰影了。

經歷了兩個禮拜，終於成功解決了sumproduct的問題，一開始就有發現到，是資料型態上出了錯誤，但是第一次嘗試時沒有加括號才找不到參考。現在整份表單都有值了，剩下都只是些數值上的小bug。比如對於一個紀錄時間的空儲存格判斷，在Google Sheet上會判斷為12月，而Excel上會列入1月，至今我仍理不清這種詭異的邏輯。會議中AJ提議要再對值的有無進行一次確認，但是我對人數的完整性有點顧慮而沒做答覆，人工算表一個小時表示痛苦，畢竟我們也不知道業主什麼時候才會維護表，到時候總人數突然跳到就又陷入一個除錯迴圈，所以我只另外標紀了有問題的儲存格而已。

這禮拜又收到了一份新案子，內容是關於南投的社區照顧。雖然有一部分是為了分工方便，但我仍認為這類文件應該要用資料庫保存，沒匿名化的資料放在雲端實在不怎麼安全。在9月討論AJ有提到的是別自行開發，避免會期結束後程式沒人維護，不過使用現有的軟體應該也是個辦法，當然我不否認，比起Excel填表與Google文件，如何使用一個資料庫就顯得專業些，教學上也會較難以著墨。

這禮拜新學到的函式Filter，這個東西真是太酷了，他能夠對表單中的資料做篩選，如果我們給每個專案一個ID，那透過篩選ID的動作，就能用拉選的方式分隔開每個專案，宛如一個小型的資料庫。我們目前有2個表單要處理，一個是紀錄表，一個是給志工填入的總表，志工只需要在總表輸入ID/生日/案主等等的資料，就會把資料傳入紀錄表對應的ID裡，每個ID預定可以儲存20筆資料。架構是這樣，不過編寫的過程出了一些小Bug，我猜是在拉動Execl時沒有用$固定行造成的問題，因為我們將3儲存格合成1個用，比如ABC當成A用，但是在判斷時卻把A/B/C輪著用，不過學長即時的解決了這個Bug，目前這份表單看來是沒有問題的。

為了要在會議上刷些存在感，一直是我嘗試理解那些拗口函式的最大動力，還記得剛收到第一份表時，感覺就像是踏出新手區就直接打最終Boss了，有種不知如何學起的無力感，而且裡頭的用法實在蠻進階的，google也沒什麼值得參考的範例，更別提去解決問題了。不過現在來看，其實這幾次會議讓我進步蠻多的，可能跟越級打怪有點關係，我不確定以後還會不會用Excel來做統計分析，但我知道的是，我對如何應用所學更進一步。當初填組時其實是選教學組，因為我很擔心跟不上開發的腳步，但從這幾次的成果來看，其實不是個打醬油的，幸好當時選填人數不夠，不然我應不會有這段值得回味的精歷。