S

Sean's Note

Sean 的部落格, 記錄一些小教學、自己的經歷

Robust UDP Challenge - 網路程式設計概論

前情提要 這學期修習黃俊穎老師開設的網路程式設計概論(網程設),前半學期教了如何用 TCP 從簡單的 socket 應用,到實作較為複雜的 IRC 伺服器。 這次第 12 周的實驗內容讓大家用兩週的時間,寫出能抵抗惡劣網路環境的 UDP 程式,完整傳送 1,000 個平均 16 KB 的檔案。 實驗限制 這次評測端使用 tc-netem (8) 製造出不穩定的網路環境,限制如下: 封包有 40% 機率會遺失、10% 機率損毀 延遲 50 ms - 150 ms 網速上限 10 Mbps 封包大小上限 1,500 bytes 在這樣的環境下,如果不特別做處理,基本上是傳不了檔案的,也因此是考驗各組技術的地方。 使用 ping 測試的結果(封包來回需乘二) 最初的想法 在開始寫程式之前,當然是要先設計自己的通訊協定原型。原本規劃好了整套如何取得目錄、如何得知檔名及內容的協議,不過愈想愈覺得在這次的實驗中,分檔案慢慢傳反而沒效率。 因此後來決定把寫好的協議及寫到一半的程式碼全部刪掉,從頭開始設計當成單一檔案傳輸的方法。 封包結構 實驗環境 MTU 只允許每個封包傳送至多 1,500 bytes 的內容,因此會需要切成不同區塊,本次設計的封包結構前 2 bytes 是區塊編號。 在我的作法中,是先合併出一個大封包。大封包最前面的數字是總區塊數,後面接著 1,000 個數字是各檔案的尺寸,再來各檔案內容直接連接在後,以節省填充內容佔用的空間。 也因為老師保證檔案大小在 32,000 bytes 以下,最極端的例子封包數也不會超過 22,000 個,因此只需要 2 bytes 的空間(-32768 ~ 32767)即可儲存。後面再接上所有檔案,合併後一個大封包總共約 16 MB 大小。 本次定義的標頭檔 傳送邏輯 在相當穩定的環境下,我們可以只傳送不確認;在反應迅速的環境下,我們可以等收到確認封包再進行下一步;但在這次既慢又不穩的環境下,兩種做法效率都不會太好。 因此我採用的方式是發送端自行估算在恰好頂到速度上限時,每隔多久可以發送一個封包。 發送端詳細邏輯 對發送端來說,如果封包傳得太急,會踩到 10 Mbps 速率上限,導致緩衝區愈來愈長,封包需要排隊才能送出。 以我的實作來說,每個封包都是吃滿 1,500 bytes 上限,多數流量來自發送端,來自接收端的確認封包佔少數。 對於總共 16 MB 的檔案,為了符合最大傳輸上限 1,500 bytes 限制,分割後大約有 11,500 個區塊需要傳輸。 理想狀況中,每輪需要發送的區塊數量減半,所需時間也跟著減半。不過加上考慮延遲後,大約第六七輪開始,確認封包會來不及回傳。 接收端詳細邏輯 發送確認封包的方式有許多不同做法,依筆者心中的效率簡單排序,由低到高大致為: 收到每個區塊時,都單獨回傳確認(可能較差) 收到數個區塊後,用一個封包,批量進行確認 每隔一段時間,用多個封包,回傳伺服器的完整狀態 每隔一段時間,用多個封包,回傳所有收過的區塊編號 每隔一段時間,用一個封包,回傳新收到了哪些區塊 每隔一段時間,用一個封包,以 bitset 回傳伺服器狀態(可能較佳) 因此在最終的版本中,我是以 bitset 形式回傳接收端的狀態,每次只需要一個封包即可完成。 使用 bitset 儲存、傳送狀態 有思考過在最後剩下不到 500 個未完成區塊的時候,或許直接回傳近期收到的區塊編號可以再更節省流量,不過感覺實作相對麻煩就作罷了。 延遲詳細計算 已知條件為: 每個封包 1,500 bytes 速率上限 10 Mbps 約有 40% 機率遺失封包、10% 機率損毀 根據定義可以計算: (封包大小 1,500 bytes) * (單位轉換 8 bit / byte) * (成功率 60%) = 平均封包大小 7,200 bits (速度 10 Mbps) / (封包 7,200 bits) = 每秒可傳送 1,388.88 個封包 1 / (每秒 1,388.88 封包) = 每封包間隔 0.72 毫秒 雖然理論值是這樣,不過因為 tc-netem 實作的關係,似乎 0.75 毫秒才是最佳延遲,實驗及試算了好久都不知道怎麼得出正確數字。 檔案壓縮 原先在 Discord 嘴砲說想直接用外部函式庫完成這次實驗,想說既然都讓老師把檔案亂度增加了,那應該是不需要玩壓縮的技巧。 於 Discord 詢問使用壓縮函式庫 不過後來得知檔案內容只包含可視字元,轉換為 ASCII 是 0x21 到 0x7E 的區段,在每個 byte 中 256 種可能中只佔了 94 種。 在此假設檔案亂度不低,也就是外部壓縮函式庫幫助有限,因此採用類似 base64_decode() 的方式將檔案從可視字元區段映射到整個空間。 最簡單的做法當然是取消最前面固定為 0 的位元,只要透過簡單的位元運算,就讓每 8 個可視字元字映射到 7 bytes,節省 12.5% 空間。 每 8 個可視字元可映射至 14 bytes 經過計算後,發現可以透過運算,把每 17 個可視字元映射到 14 bytes,省下了 17.6% 的空間。而運算過程中,剛好勉強低於 __int128 的上限,實作起來不算複雜。 如此讓每個封包 1,470 bytes 的內容實際可塞下 1,785 個可視字元,封包總數量減少到 9,500 個。 把每 17 個可視字元映射到 14 bytes 在最極端狀況下,每個封包其實可以塞下 1,794 個可視字元: (log(256) / log(94)) * 1470 = 1794 減少多餘等待時間 在經過分析後,發現原本的程式最前面將檔案合併成大封包,再分割成 9,500 個區塊的過程中,大約會耗費 500 毫秒的時間,因此改為邊切割邊發送第一輪封包。 而接收端如果在結束前才一次寫入,會耗費大約 350 毫秒的時間,發現後改為判斷接收完一個檔案就寫入一次。 另外由於評測的機制是發送端結束後,會強制關閉接收端並開始比對檔案。因此發送端不能太快結束,但太晚結束又會影響表現。 動態調整發送間隔 為了進一步最佳化性能,在接收端回傳狀態封包時,也順便帶上當下的時間戳。 原本有實作根據延遲時間自動調整間隔的功能,不過由於延遲是隨機在 50 - 150 毫秒之間飄動,事後證實效益不大。 沒用到 UDP 的玩法 從看到實驗限制後,就有想到或許可以透過指令列參數,利用側通道傳送資料,不過覺得做起來稍嫌麻煩,因此一直沒有動工。 在正規作法進步到 13.08 秒,想不到可以怎麼繼續加速後,就決定來實作看看,完成後還真的得到比當時第一名還快 70 倍的破表分數。 當下計分板 0.18 秒成績 評測方式 評測平台會建立 /sender_dir/ 及 /receiver_dir/ 兩個資料夾,並將發送端及接收端的執行檔分別置於 /sender_dir/sender_bin 及 /receiver_dir/receiver_bin。 /sender_dir/files/ 資料夾放有 1,000 個隨機檔案,執行結束後會檢查是否成功傳輸至 /receiver_dir/files/ 資料夾。 以發送端來說,先使用 chroot("/sender_dir/") 防止執行環境存取外部檔案後,再執行 /sender_bin --read-from="/files" --send-to="localhost:4242" 指令啟動。 chroot("/receiver_dir/") 限制環境後,再執行 /receiver_bin --listen-port="4242" --store-to="/files" 指令,將透過 UDP 協定收到的封包儲存至 /receiver_dir/files/。 本題是限制網路層的傳輸速度,應該有不少做法作法可以繞過,我只挑自己較為熟悉的一種來實作。 cmdline 簡介 我是從 2021 年 4 月在調研 ldapsearch 資安漏洞時,翻閱原始碼而接觸到這件事的,不過後來發現因為有盡最大努力側面修補,攻擊雖然可行但時間點需要抓得很精確,因此後續不了了之。 熟悉 Linux 的大家應該都用過 ps aux 指令,但知道其中實作方式的人可能不多。 /proc/ 資料夾,存放核心(kernel)的相關資訊,而底下以程序編號(Process ID)命名的資料夾則存放各程序的狀態。 /proc/[PID]/fd/ 底下以數字命名的檔案,會連結(symbolic link)到程式開啟的各個檔案;而 /proc/[PID]/cmdline 檔案則寫著被執行時的參數,以 0x00 (NUL) 字元區隔。 這個 cmdline 檔案雖然無法直接修改,但程式可以透過 prctl()、pthread_setname_np() 更動,或直接修改 main() 函式收到的 char *argv[] 內容也會反映在上面。 透過 cmdline 查看指令參數 作法說明 在通常狀況下,main() 收到的 char *argv[] 長度也就幾十、至多幾百個字,如果要拿來傳資料顯然效率不足。 exec() 呼叫自己,並在 argv[1] 傳遞一個很長很長的參數,目的是擴充 cmdline 檔案大小,才塞得下整個檔案內容。 在完成後就能自由運用 argv[1] 參數了,開始每隔 0.1 毫秒更新一次 argv[1],依序將檔案內容放上。這會同步到 /proc/[PID]/cmdline,也就是 ps aux 指令會看到的結果。 而接收端則是先等候一小段時間,先確保傳送端已啟動後,持續檢查位於 /proc/[PID]/cmdline 檔案的參數內容,如果有異動就寫入 /receiver_bin/files/[ID] 目標檔案。 使用 argv / cmdline 繞過限制傳送 使用這個方法,理論上可以再 fork() 出不同程序(process)同步執行,用到本題上限的 15 個程序可以加速不少。 也可以把間隔時間依照檔案大小自動調整,或是讓接收端發出訊號,減少不必要的等待時間。 後記 寫這個實驗的過程中,心中一直被「執行效能」的想法所侷限,但仔細思考後認知到在這個場景下,最珍貴的資源是網路而不是 CPU 效能,有許多顯然花費不合理運算的事情實際上卻可以增進執行效率。 老師在隔週的課堂也說了,原先沒想到大家會把時間用在最佳化上面,因此乾脆將一堂實驗課讓出來,給同學們分享各自作法的機會。 簡報, 不過由於剛好要 參與資安檢測, 當周課堂無法出席報告,經過老師同意只好以 預錄影片 代替。 感謝 Thect、 yc油成、 Jerry Hsu、 CTFang、 Sirius Koan、 TwinkleStar03 等朋友協助審閱文章提供建議,指出盲點讓文意更通順。 Twitter、 Facebook 留言交流,或是在課堂實體捕捉我。 如果想嘗試的朋友,老師也在課後將 實驗題目規格 公開,歡迎參考練習。 .post table td { color: #666; } .post table td a { color: #6bf; } .post table td a:hover, .post table td a:active, .post table td a:focus { color: #8cf; }

2022/12/15
articleCard.readMore

交大資工所 推甄紀錄 韋詠祥

TL;DR 今年申請交大資工的丙組、丁組,由於時程因素,只做了下圖 2 頁的自傳 + 讀書計畫: 交大資工所 推甄自傳 https://img.sean.taipei/2022/11/nctu.pdf 丙丁組皆在資料審查階段就獲得直接錄取,目前已於丁組(系計中)報到。 為何只投交大 對部分資工系學生而言,研究所的順位或許是國外 > 台大 > 交清 > 其他學校,但在我的觀點中並非如此。 由於想留在台灣,現階段較不考慮出國攻讀研究所。 而且與交大相關領域的教授都相對熟識,直升對我而言是個最好的選擇。 交大資工 研究所組別簡介 交大資工共分為 4 個所,分別是: 資科工所(資訊科學與工程研究所) 網工所(網路工程研究所)/ 推甄收 30 人 多媒所(多媒體工程研究所)/ 推甄收 27 人 數據所(數據科學與工程研究所)/ 推甄收 34 人 其中資科工所又再分為 4 個組: 甲組 / 推甄收 87 人 丙組(實作導向)/ 推甄收 15 人 丁組(系統與網路管理實務,系計中)/ 推甄收 6 人 戊組(校務資訊系統技術與實務,校計中)/ 推甄收 7 人 另外資訊學院底下,還有個資安學程(資通安全碩士學位學程),前稱資電亥客。 各組別之間主要差異是: 可以找的 教授名單 不同、名額分開計算 畢業標準、必修課程不同 審查注重的面向不同 丙丁戊組通過初步書審後,需個別面試 丁組需負責開發資工系服務、戊組需協助維護交大校務系統 申請過程 通常比較認真的學生都會提前半年一年開始準備,而我雖然一直把這件事放在待辦清單,但由於出現其他更重要的事務,拖到最後一刻才處理。 上了大學之後,雖然持續有在參加各領域活動,但沒有動機整理自身經歷,連獎狀都是散落在三四個不同地方。 出國參與 ICANN 會議 回來,10/6(四)又受邀擔任座談會與談人,因此 10/7(五)才開始準備資料,共有 5 天可以處理。 第一天 10/7(五)先去行事曆、信箱、雲端硬碟到處翻,回顧大學階段做了哪些事,並將主要的經歷放上網站。 @yc97463 借用版面設計來更新。 最初的模樣(2016 年) 修改前(2022 年) 更新後(現在) 第二天 10/8(六)開始研究推甄相關規則、需求,並初步填寫系統上的資料。 第三天 10/9(日)製作自傳、讀書計畫時,由於知道教授們時間寶貴,決定這次將審查資料濃縮在 2 頁 PDF 內解決。 對於版面設計不在行的我,突然想到平常用的 Markdown 很符合資工人的日常,或許可以在維持可讀性的同時又增添一點設計感,因此用 macOS 內建的 Pages 手刻出相似樣式。 完成自傳草稿後,也寄信給四位師長,詢問是否願意協助撰寫推薦函。 詢問教授撰寫推薦函 第四天 10/10(一)國慶連假,先研究了推薦函如何填覆、有哪些欄位,整理時程資訊,再翻找信件往來紀錄、聊天記錄,列出與推薦人相關的事件供四位推薦人參考。 這次推薦人找了兩位交大資工系上的老師、一位科法所的老師、一位網路治理及安全領域德高望重的前輩。 第五天 10/11(二)17:00 報名截止,去投幣列印了歷年成績單,整理申請表將報名資料繳交至教務處。 填覆資料 交大資工所的招生申請系統中,共有 50+ 個欄位需要填寫,以下是本次主要欄位資料。 總名次及修業學分 歷年平均:81.3 分 修課狀況自評 總體而言數學及英文科目分數較差,而資訊科目應對起來較為輕鬆,尤其實務導向課程表現較為亮眼。 由於同時忙於系計中、資訊社群、資安競賽、開源貢獻、網路治理等領域,無法兼顧成績表現,僅能維持平均水準。 修習電資領域專業課程「最佳」表現 計算機系統管理:95 分 其中 NA、SA、組語為大一修習。 修習電資領域專業課程「最差」表現 線性代數:75 分 數學佔比高的科目表現較差,僅能滿足基本需求。 部分資工課程於期末時因外務繁忙而難以兼顧成績。 申請結果 這次我只申請丙組、丁組,皆由於第一階段書面審查分數較高,教授們決議跳過面試提供逕取(直接錄取)資格。 丙組成績單 丁組成績單 兩組皆得到直接錄取 (來源:交大碩班推甄榜單) 目前已完成丁組報到,並放棄丙組資格讓其他考生得以儘速遞補,畢業後碩班將繼續留在系計中服務。 後記 幾年前聽到丁組的名聲其實不太好,甚至聽過有人比喻為用勞力換學歷,某些人為了畢業不是很順利。 但從我加入系計中兩年多來,有許多事物漸漸在改變,也有愈來愈多人才加入丁組,整體氣氛相當融洽。 Leo Chen 及 David Wu 兩位系上技術頂尖的強者從大學時就在系計中服務,畢業後也以丁組作為第一志願,讓我在審慎思考過後決定留在丁組繼續與大家打拼。 同學自發於 SITCON 閃電秀分享 (圖源:SITCON Flickr) 助教休息空間鯊滿為患 (圖源:Google Maps) 本文同步分享於 Telegram、 Twitter、 Facebook, 礙於文章篇幅,如果有什麼好奇的、想暸解更多的點,都歡迎來留言區交流。 參考連結 丁組推甄心得 + QA(2021 年 9 月) 交大資工系計中 加入我們 丁戊組推甄心得 + 考古題(2021 年 9 月) 丁戊組推甄心得(2020 年 3 月) 大學個人申請 備審資料擴散紀錄(2019 年 8 月) .post h2 { margin: -6px 0 4px 0; } .post table td { color: #666; } .post table td a { color: #6bf; } .post table td a:hover, .post table td a:active, .post table td a:focus { color: #8cf; }

2022/11/27
articleCard.readMore

ICANN75 - 吉隆坡之旅

很高興這次能在 NII 舉辦的「ICANN 公共政策研習營」獲選為優良學員,受邀參與位於馬來西亞吉隆坡的 ICANN75 年度會議,並提供旅費補助。 Note: There’s also a English version of this post. 前情提要 ICANN 是統籌分配管理全球 IP 位址及網域名稱的非營利組織,內部分為多個 Stackholder Group(利害關係人團體),由下而上的討論制定政策 在台灣由 NII 每年舉辦兩場研習營,只要全程參與就能拿到數千元的獎學金,並且每年選出幾位優秀學員參與 APrIGF 及 ICANN 等國際會議。 一個是 網路治理研習營,分為網路安全、平台規範、數位人權三組,探討多個相關議題。 分享參與經驗,並獲選為優良實習學員,以中文撰寫 三篇 會議 摘要。 另一個則是 ICANN 公共政策研習營,透過扮演 GAC 政府代表、ALAC 群眾代表、GNSO 網域代表,針對頂級域名相關議題,分組討論組內的觀點,再於模擬會議上凝聚全體共識。 分為各個 Stackholder Group 討論 ICANN 公共政策研習營合照 旅程規劃 由於 NII 核銷規定,只能訂購指定日期的航班,無法自費在當地多留個幾天。 因此我選擇在週六晚上到新加坡轉機,隔天早上再飛馬來西亞。也因為這個晚上轉機的時間,讓我能參訪新加坡樟宜國際機場的多處美景。 晚上逛新加坡樟宜國際機場 順利報到,取得 ICANN75 名牌 接著週一、週二、週三,整天都在參加 ICANN75 會議,其中有 6 個場次是合約中指定的,剩下的讓我自由挑選。 回程航班訂在週四下午,也因此無緣參與最後一天的 Public Forum 等議程。 參與 ICANN75 APRALO 議程 (圖源:ICANN Flickr) 參與 ICANN75 APAC Space 議程 (圖源:ICANN Twitter) 認識新朋友 第一天抵達 KLCC(吉隆坡會議中心,Kuala Lumpur Convention Centre)時,NII 的理旋跟我說可以去參與 NextGen 議程,認識一下與我同年的小朋友們。 在 ICANN75 會場遇到的所有人都相當的友善,我只是靠近聽他們在聊些什麼,就直接叫我名字(應該是看名牌)跟我打招呼,並歡迎我加入對話。 前兩天由於時間因素,沒能跟 NextGen 計劃的夥伴們一起吃晚餐,讓我覺得非常失落。 而在週三晚上,我們約去中國城逛街,再到 Jalan Alor 美食街一起吃泰式料理。 吉隆坡中國城 共享泰式料理 我們 5 人之中,沒有人的母語是英文,但他們都非常包容我一直打結的英文。 來自馬來西亞的 Adlin 送了在地的精品巧克力、 沒想到在 ICANN 會議期間會認識到這麼多好朋友,我很後悔沒有準備任何台灣紀念品。(甚至出國前把所有新台幣都換成了馬來西亞令吉) 來自馬來西亞的 Adlin 來自柬埔寨的 Somaly 結語 我真的很榮幸能有機會去吉隆坡與來自各地的朋友交流,未來將繼續深入研究 ICANN 政策及網路治理,希望有天能成為 ICANN Fellow,再次見到令我感動的大家。 點心休息時間 APAC 團體照 (圖源:ICANN Flickr) 本文同步分享於 Twitter、 Facebook, 如果有什麼想法,都歡迎來留言區交流。 相關連結 本文 英文版 ICANN75 議程表 ICANN 官方 Flickr 相簿 ICANN 多方利害關係人模式(TWNIC 中文版介紹) .post table td { color: #666; } .post table td a { color: #6bf; } .post table td a:hover, .post table td a:active, .post table td a:focus { color: #8cf; }

2022/9/23
articleCard.readMore

ICANN75 - Trip to Kuala Lumpur

I’m glad that I got the opportunity to be selected by NII program to attend the ICANN75 Annual General Meeting in Kuala Lumpur, Malaysia. Note: There’s also a Chinese version for my Taiwanese friends. 中文版 文章。 Why I can attend ICANN75 NII hosts two study camps in Taiwan every year. It provides scholarships for all attendees who finished the course, and selects a few students to attend international conferences like APrIGF and ICANN meetings. The first one is called Internet Governance Camp, in which we discuss various issues. This year I was selected as a Intern Student, and had written three meeting summaries in Chinese. Another is ICANN Public Policy Camp, I was rated as one of the best students during a simulation meeting about closed generic TLD, which provides the financial aid to attend ICANN75 and the chance to make friends here. Discussing as Stackholder Groups ICANN Camp in Taiwan Flight Schedule I have to arrive and depart on a specific date limited by the NII contract, which means that I cannot stay longer in Malaysia at my own expense. I flew from Taiwan to Singapore on Saturday evening, stayed the night at Singapore airport, then flew to Malaysia on Sunday morning. Stay at Singapore Changi airport Got my ICANN75 badge I attended the ICANN75 session from Monday to Wednesday. This scholarship program has specified 6 mandatory sessions to attend, and the rest is up to me. My return flight to Taiwan is on Thursday afternoon, so I don’t have the chance to attend the last day of ICANN75 such as Public Forum. Attending ICANN75 APRALO session (Source: ICANN Flickr) Attending ICANN75 APAC Space session (Source: ICANN Twitter) Friends The first day I arrived at KLCC (Kuala Lumpur Convention Centre), Sophie from NII told me I can make some friends from NextGen, those who are at the same age as me. All people at ICANN75 meeting are so kind. When I approach them and listen to what they are talking about, most people will call my name (on the badge) and greet with me. But sadly, I missed their invitations for dinner for the first two nights. It’s a shame that I couldn’t spend more time with them. The Wednesday night, we went to chinatown for shopping and having Thai food at Jalan Alor Food Street together. China Town Thai food None of us speaks English as our native language, but they are all so inclusive for my unclear accent. Adlin from Malaysia gave me local refined Chocolate. I didn’t expect that I would make so many nice friends during ICANN meeting, I’m very regretful that I didn’t prepare any Taiwanese souvenirs. (I even exchanged all Taiwan dollar to Malaysia Ringgits) Adlin from Malaysia Somaly from Cambodia Ending I’m really glad to be here and have the chance to talk with different people. I’ll keep digging into ICANN Policy and Internet Governance. And hope I can be ICANN fellow one day, to meet all the nice people again. Our tea break APAC Group Photo (Source: ICANN Flickr) Links Chinese Version of this post ICANN75 Agenda ICANN Flickr Album .post table td { color: #666; } .post table td a { color: #6bf; } .post table td a:hover, .post table td a:active, .post table td a:focus { color: #8cf; }

2022/9/23
articleCard.readMore

Kubernetes 網站貢獻心得

前言 今年 4 月時,在讀文件的過程中發現了個小錯字,發 PR 後看到 Kubernetes GitHub 的完整流程覺得很酷,就開始參與社群、持續貢獻到現在了。 在研讀完幾份貢獻者說明文件、實際參與過數百個 PR 後,來寫篇中文筆記介紹整套制度流程。 本文將先快速帶過發 PR 後到 merge 經過的階段,接著解釋 標籤的意義,最後統整 社群成員身份 及晉升流程。 發起 Pull Request 後會發生哪些事 在 Kubernetes 的專案中,大多是由 @k8s-ci-robot 負責各項自動化任務的,先來講講行為流程。 在出現新的 Pull Request 時,根據改動的檔案加上不同標籤,例如: 在 k/website 專案中,自動加上 sig/docs 如果更動的行數在 30 - 99 行,標示為 size/M 依照檔案所在的資料夾,加上語言 language/zh 標籤 如果使用者有乖乖簽署貢獻者授權協議,加上必備的 cncf-cla: yes 標籤 在加上標籤後,根據修改到的檔案隨機指派兩名 Reviewer,並告訴使用者在收到 lgtm 後該找哪位 Approver 協助。 @k8s-ci-robot 為 PR 加上 label 分類(k/website#35700) 過 10 分鐘後,輪到為每個 PR 建置預覽網站的 Netlify 機器人出場了,會留言告訴我們測試站的連結、失敗的話錯誤原因是什麼。 Netlify 機器人產生好預覽網站(k/website#35700) 再來只要等搜集到 lgtm + approved 兩個標籤,並且沒有 do-not-merge/hold、needs-rebase 等負面標籤,就會被放進 Merge pool 中。 在 Merge pool 中,為了避免衝突需要等待幾秒到幾分鐘的時間,排到隊後就會自動合併進去啦! 得到 lgtm 及 approved 後自動被合併(k/website#34311) 標籤的意義 前面快速帶過了整個 Pull Request 從發起到成功合併的流程,再來介紹一下數百個標籤中比較常用的幾個。 正向標籤 lgtm,即 Looks good to me 的意思,任何 Kubernetes 組織成員都可以使用 /lgtm 指令加上此標籤。 LGTM 標籤的意義是「這份程式碼改動看起來不錯」,因此只要檔案有更動,這個標籤就會消失,需要重新用 /lgtm 指令加回來。 得到 lgtm 標籤後更動檔案(k/website#35411) approved,代表這個 PR 的大方向已被核可。 每個檔案所屬的資料夾都有對應的 OWNERS 檔案,記錄著哪些檔案由哪些人擔任 Approver。機器人會確保 PR 修改到的每個檔案都有對應的 Approver 核可,才會加上這個標籤。 跟 lgtm 不同的是,就算檔案被修改過,approved 標籤也不會消失。 使用 approve 指令(k/website#35506) cncf-cla: yes 是第三個不可或缺的標籤,在官方規則下,大家不該 review 沒有這標籤的 PR。 為了確保免於未來潛在的法律爭議,大型專案通常都會要求貢獻者簽署 CLA 授權協議(Contributor License Agreement),只要照著指示一次性的簽署完畢就行了。 CLA 貢獻者授權協議(k/website#32897) 負面標籤 只要 PR 包含任一個負面標籤,就無法被自動合併。 最常見的是,PR 作者與任何 Kubernetes 成員都可以使用的 do-not-merge/hold。 當遇到根本性的錯誤,會用 /hold 來請作者特別注意,常見狀況是 git 操作錯誤,或動到不該動的檔案。 也因為 PR 作者可以自己 /unhold 解除,有時也會被用來作為讓 PR 作者自行控制何時被 merge 的工具,像是最後再次確認有沒有小地方要修改,或是部落格文章希望在哪天發佈。 被 hold 的實際狀況(k/website#34722) 在 commit 訊息中包含禁用關鍵字的話,則會出現 do-not-merge/invalid-commit-message。 由於專案中已經有 @k8s-ci-robot 來做各種自動化事務了,為了避免意外發生,禁止在 commit 訊息中觸發原先 GitHub 提供的自動化操作。 例如不能在 commit 中寫 Fixes: #xxx、Thanks @xxx 等,這些要移到 PR 說明欄。 無效的 commit 訊息(k/website#34456) needs-rebase,偵測到 merge conflict 時會自動加上此標籤,解決後這個標籤就會自動消失了。 do-not-merge/work-in-progress,只要在標題前面加上 [WIP],或透過 GitHub 介面設定為 Draft PR,就能得到這個標籤了。 分類標籤 最直覺簡單的就屬檔案大小了,計算方式是新增的行數與刪除的行數相加。 size/XS 代表更動了 0 - 9 行,到修改超過 1000+ 行的 size/XXL。 根據不同的面向,會被標上不同的 SIG 特別興趣小組(special interest group)標籤: sig/docs、sig/release、sig/security 有些 PR 也會被標上屬於哪個領域: area/blog、area/web-development 在各語言的資料夾中,會被標上語言標籤,方便在地化翻譯者們過濾: language/zh、language/en、language/ko 對於 issue,則是分為不同的種類: kind/feature、kind/bug、kind/support、kind/cleanup 社群成員身份 全球 500 萬名 Kubernetes 開發者的數量龐大,光是 k/website 就有 4,100 位貢獻者了,因此 k8s 社群也有一套相對成熟的權限機制。 身份總覽 在開始詳細介紹之前,先讓我快速整理一下 Kubernetes 組織中各身份擁有的大略權限。 (A) 任何人 只要有 GitHub 帳號都可以發 PR、幫忙 review 給意見 (B) Member 組織成員 可以用 /lgtm 指令表示看過、沒問題 也能用 /close、/hold、/retitle 等指令管理 PR (C) Reviewer 審核者 在有人發新的 Pull Request 時,bot 會隨機指派 2 位 Reviewer (D) Approver 批准者 在 PR 被初步 review 過後,會指派 Approver 來做最終確認 在 Approver 確認過大方向無誤後,可以用 /approve 指令核可 (E) Tech Lead / Maintainer / Owner 有專案的管理權限、可以設定 /milestone 指定合併的目標時間 如何開始這場冒險 第一步當然是先熟悉社群、開 issue 發 PR,實際瞭解社群運作。 在找到問題準備修復前,最好可以找 3 - 10 個 PR,看看大家是如何互動的,幫助自己更快融入社群。 Member 組織成員 要成為 Member 的門檻非常低,只要發 5+ 個 PR,並找 2 位 Reviewer 協助背書(sponsor),就可以申請成為組織成員。 申請成為 Kubernetes 組織成員(k/org#3440) 很酷的一點是,Kubernetes 社群連 GitHub 組織成員都是用 git 管理、自動更新同步的,只要修改對應的 YAML 設定檔,@k8s-ci-robot 就會自動寄發邀請函。 接受邀請成為 Kubernetes 組織成員後,就有了 /lgtm 半通過、/close 關閉 PR、/hold 要求暫緩等大多數的權限,可以隨時參與 PR review。 Reviewer 審核者 如果想成為 Reviewer 身份,規定上的最低限制是成為 Member 至少 3 個月,並且 review 過至少 20 個 PR。 在自認對整個專案程式碼的大架構足夠熟悉後,就可以找 Approver 協助背書,送出申請。 這邊的申請流程跟成為 Member 不同的是,申請的 PR 可以自己開就好,只要約 12 - 48 小時就能成功了。 申請成為 Kubernetes 的 Reviewer(k/org#3436) 以 k/website 的中文語系為例,每當有新的 language/zh PR 時,就會在 sig-docs-zh-reviews 之中隨機指派兩個人為 PR reviewer,以確保在大家不會累死自己的前提下,每個 PR 都有人能幫忙處理。 這身份承擔的責任在某些時候還蠻重的,但似乎沒有額外授予其他權限,比較像是願意為社群付出、為下一階段鋪路。 Approver 核可者 在擔任 Reviewer 至少 3 個月後,就可以由 Subproject Owner 提名為 Approver 了。 擔任 Approver 必須在技術層面展現合理的判斷,為程式碼品質做高層次的把關,並作為新進貢獻者們的導師。 願意在社群持續貢獻半年一年的志願者們,通常都能順利取得這個身份,相應的 /approve 權限賦予 Approver 們決定 PR 能不能被合併到專案的權力。 Subproject Owner / Tech Lead / Maintainer / Admin 後續身份沒有一套通用的準則,在取得社群內大家的信任後,得到更多的權限也代表著更大的責任。 像是我很好奇那幾位主要貢獻者們到底是怎麼管理時間的,都已經有正職工作了還有辦法投入那麼大的心力在開源貢獻。 後記 我在六月成功加入 Kubernets 組織,因為很喜歡這邊的社群氛圍,期間持續發 PR、幫別人 review,這段期間算是相對積極的貢獻者。 剛成為 Member 才 2 個月的我,在上週被 k/website 最主要的維護者破例提名為 Approver 且通過了,讓我覺得非常驚喜。 因此整理相關資訊分享給身邊的社群朋友們,希望未來有更多人一起加入,期待能做出更多有意義的貢獻。 被提名為中文 Approver(k/website#35563) 本文同步分享於 Telegram、 Twitter、 Facebook, 如果有什麼想法歡迎留言讓我知道。 如果有興趣一起成為 Kubernetes 的貢獻者,歡迎加入 @SeanTalk 及 @CNTUG 群組一同交流。 參考連結 GitHub 專案連結:kubernetes/website Kubernetes 社群文件:Community membership、 Contribute to K8s docs 實戰教學文:快速成為 K8s Member COSCUP 議程投影片:How to start contributing to Kubernetes Projects .post h3 { margin: -2px 0 6px 0; } .post table td { color: #666; } .post table td a { color: #6bf; } .post table td a:hover, .post table td a:active, .post table td a:focus { color: #8cf; }

2022/8/5
articleCard.readMore

來迺陽明交大水所在 陽交校慶系列活動

前言 上週三 1/26 看到活動後,晚上臨時起意想藉這個機會參訪各大校區,趁著年假走訪完 10 個校區、共 50 個景點啦~ 經過親身走訪(踩雷)後,原本想在留言提供活動破關技巧的,但愈寫愈長就乾脆獨立一篇文章出來,若是哪裡內容不夠充足還請不吝告知。 參訪歷程 由於一開始沒有打定主意挑戰全部達成,因此時間上分為三段旅程。 第一段旅程 上週四 1/27 中午睡醒後,從山頂的研三舍出發,看著活動地圖規劃路線後,先用 40 分鐘走訪光復校區每個拍照點,再搭校車去陽明吃午餐。 吃完鮭魚親子丼後,第一次踏入陽明校園,尋找打卡點的途中有些曲折(見下段闖關攻略), 隨著愈爬愈深入,頭髮也因汗水愈來愈濕,用花了 90 分鐘爬山、尋點,終於順利找到所有打卡點。 完成光復及陽明各 15 個景點後,借了陽明圖書館旁的 YouBike 2.0,騎腳踏車前往興建中的士林校區拍照,結束後再轉乘公車到管理學院使用的北門校區。 興建中的士林校區 北門管院校區 第二段旅程 原先最不考慮的是蘭陽院區,但發上噗浪跟朋友聊了之後,一查才發現宜蘭是真的是離台北很近,開始規劃行程後就愈來愈確定要去了。 揪了朋友週六 1/29 下午出發,搭乘國道客運抵達礁溪後,沿路買了些在地美食,傍晚欣賞礁溪夜景,晚上回飯店泡溫泉。 隔天 1/30 吃完飯店早餐後,再去了重口味溫泉魚,中午搭火車到宜蘭。 區間車抵達宜蘭站後,蘭陽院區跟新民分院都在步行 10 分鐘範圍內,各別拍照留影後,就買個伴手禮搭國道客運回家。 蘭陽附設醫院 宜蘭新民分院 桃園青埔 原先在新聞報導及維基百科都只提到位於青埔,沒有確切路名或地圖,週日晚上與另一位桃園同學聊天時,意外的從籌設計畫書對照出了青埔全球校區的實際位址。 除夕 1/31 中午搭高鐵到桃園,坐一站機場捷運到 A19 桃園體育園區站後,發現月台上的角度恰好能清楚看到青埔校區建築預定地, 喬好角度拍完照後就原路折返了,回到樹林整趟旅程只用了 3 小時。 桃園青埔全球校區 建築預定地(圖中灰色三角形空地) 第三段旅程 初三 2/3 早上七點起床,跟家人去苗栗大湖親戚家採草莓,結束後下午回台北的路上,再順道載我回交大宿舍。 今天初四 2/4(五)睡飽後,上午先到博愛校區踩點,再去六家客院拍照,準備搭高鐵。 博愛校區 六家客院 台南歸仁 中午抵達高鐵台南站,最遠的歸仁校區也達成啦! 因為想說來台南至少玩個一天再回去,不過適逢年假返家人潮,六日的高鐵對號座都已完售,所以有點過分的待到初七 2/7(一)才回家。 再來的 3 天要在做好防疫準備的前提下,多品嚐台南在地美食、去高雄逛燈會,讓自己放個寒假。 台南歸仁校區 闖關攻略 雖然 8 個校區看起來很多,但其實也就新竹台北各 3 個、宜蘭台南各 1 個。如果願意捨棄蘭陽院區、台南歸仁,其實這活動只要一天時間就能達成了,而且交通成本 $50 有找。 新竹 光復校區的景點有按照建議順序編排過,只要從任意數字開始依序或逆序走訪,剛好可以用適合人類的最短路徑繞一圈完成。 新竹光復校區活動景點地圖(來源:活動頁面) 新竹拍完光復校區後,可以騎 YouBike 或搭校車去博愛校區。 以下是 總務處事務組 提供的校車時刻表,除了例假日及春節停駛,學期間班次還算多。 光復博愛線 客院高鐵線 光復陽明線 完成新竹 3 個校區的任務後,到中正堂搭光復 - 陽明接駁車,還能順便抽「呷意陽光獎」。 活動獎項(來源:活動頁面) 陽明 雖然陽明校區的編號較無規則,但 15 個景點大致沿著主要幹道分佈。參考下圖的建議路線開始往上爬,基本上就能(很喘得)輕鬆完成。 台北陽明校區活動景點地圖(來源:活動頁面) 有幾個我當初找比較久的景點供參考: (8) 憶空間:位於圖書館內,要走大馬路那側(西側)進去,不是圖上標示的位置。 (3) 三角公園:現在只有全綠一片,看到岔路就可以拍照了,信中照騙是以前的樣子。 三角公園實際樣貌 (4) 金門石:在 (1) 榕園裡面,建議用不同角度拍攝避免爭議。 (13) 陽明廣場:從上方繞過牙醫學院後,順著樓梯往下走。可以參考衛星空拍圖,紅色點即為陽明廣場,可走綠色箭頭的路線到達。 陽明廣場衛星空拍圖 (5) 神農坡:範例圖片要求要山腳下的刻字,可以爬上 (9) 異空間後再往下走。 (2) 韓園:位於人行步道上,共同教育中心與山頂網球場中間,別像我傻傻照著圖片地標跑到大馬路上找不到。 (6) 韓偉石:位於 (2) 韓園字樣後方,寫著「非以役人,乃役於人」。 韓園內紀念碑 如果還是找不到,可以參考我那天 Google Photos 記錄的路徑、拍照點,主辦單位給的編號已經用紅色字標示在上面了。 陽明闖關攻略地圖 一路逛到山頂運動場後,可以走最短路徑下來到圖書館,借台 YouBike 2.0 前往下一個校區。 台北 從陽明圖書館出發,照著導航往下坡騎,預計 20 分鐘就能到興建中的士林校區了。可以先不要還腳踏車,停在工地前面的停車場人行道,拍完照再往回騎 200 公尺去志成公園還車。 還完車後往前走幾步就是公車站了,搭 206 到捷運北門站附近後,再徒步 10 分鐘就能抵達北門校區了。 我的終點是走去西門町吃飯、回到樹林的家;如果是要搭豪泰回學校的話,也能當天來回,不過回程的交通成本就容我先忽略不計了。 後記 到家後在想參訪陽明怎麼能那麼累,查了地圖才知道,從大門口走到山頂的水平距離同樣是 700 公尺,交大只爬升 30 公尺,但陽明卻整整爬升了 130 公尺。 感謝總務處發想這個 校慶系列活動, 否則除了光復、陽明、博愛外,不會有去其他校區的契機。 從粉專大略整理,簡單記錄一下聲稱完成 8 校區共 36 景點的同學們: 名次 暱稱 完成日期 1 陳*霖 2022-02-01 2 Sean Wei 2022-02-04 3 洪*勛 2022-02-07 4 包*承 2022-02-08 5 David Chen 2022-02-08 6 Calvin 2022-02-09 7 葉*妤 2022-02-12 8 YC Shun 2022-02-12 9 Ann Cheung 2022-02-15 這次響應活動 5 個縣市跑下來,雖然光是交通住宿就肯定超過第 2 名的 $5,000 獎金, 寫成文字紀錄所額外花費的時間成本更不用說,但滿滿的收穫不是金錢能衡量的,很鼓勵大家也來享受這活動的樂趣。 國立陽明交通大學 台北陽明校區 本文同步分享於 Telegram、 Twitter、 Facebook, 如果有什麼想法,或是願意協助補充,都歡迎來留言讓我知道,祝順利達成任務!

2022/2/4
articleCard.readMore

CEH v11 證照考試心得

前言 我在一年半前的那個暑假,進入交大資工系計中擔任 Net 組及 Web 組助教,協助維護整棟資工系館的網路、機房、監控服務,以及系院網站、推甄系統、口試系統等服務。 在 2021 年 10 月底的某個早上,看到系計中的團長(行政事務窗口)通知大家,說有 CEH 公費培訓可以報名,就相揪把握機會參加了! 這次培訓是配合 資安卓越計畫 辦理,交大作為區網中心,又有酷炫的資電駭客研究所,預計成為第一批執行弱點掃描、滲透測試的教育單位,因此培育各系所網管考取 CEH 道德駭客認證。 連續 5 個週日,由恆逸講師來交大授課,每天 8 小時的課程,考證照也是在同一間電腦教室。培訓課程會用原廠的簡報(未提供給學生)上課,也有把 Kali、Win Server 包成 VM,開 RDP 給學員們在課程期間使用,教材只提供線上版本,啟用 ASPEN 平台帳號後就能開啟電子書。 受訓對象除了資工系計中外,也將課程資訊發給了交清資安相關背景的實驗室,報名資料經過教育部審核後,很高興包含我、 Karl Lin、 Freeman Hung 等人,系計中共有 5 位助教取得培訓資格。 CEH 是在考什麼 就像其他篇心得文,我也來挑一題具代表性的題目作為開場: Morris, a professional hacker, performed a vulnerability scan on a target organization by sniffing the traffic on the network to identify the active systems, network services, applications, and vulnerabilities. He also obtained the list of the users who are currently accessing the network. What is the type of vulnerability assessment that Morris performed on the target organization? (A)Internal assessment (答案在本段落最後) 全名 Certified Ethical Hacker 道德駭客認證,這張證照的重點在道德、認證,對於有接觸過 CTF 的同學們,駭侵技術反而是最簡單的部分。會考這張證照的不外乎標案需要、組織 KPI 要求、佐證自己擁有基本資安能力,為了學習資安而上課的考生可能只佔很小一部分。 教材總共有 20 個章節,含附錄共 4,000 頁,應該多數人都是在上完課後,直接從考古題下手。 涵蓋面向包含:情蒐偵查、系統駭侵、攻擊技巧、網頁安全、網路安全、手機、IoT、工控設備、無線網路、道德觀念、密碼學、雲端運算等。 對我來說考題印象最深刻的是各種 nmap 參數、沒見過的工具名稱、早期技術。有人會說與現實脫節,但其實看考題還是能學到一些觀念、專有名詞、冷知識,或許能讓討論時用較精確的語言表述。 前面這題的答案是 (C)Passive assessment,我在第一次看到時完全沒考慮過這個選項,再看一次題目才發現這題重點在 sniffing 這個行為。CEH 考題有蠻多都需要理解,多刷考古瞭解他想問什麼,才不容易被誤導。 考前準備 初期上課時,我是用 ceh.cagy.org 這套線上 CEH 考古題系統,刷 CEH v10 的題目。這套系統再進入模擬測驗後,是用 Local Storage 在本機存題目跟狀態的,於是後來拿到另一份考古題時,在自己整理過後能很方便地將題目匯入來用。 也有用 Exam Topics 來看 v11 的考古題,不過每頁只顯示 10 題,翻個兩頁就開始一直跳驗證碼了,而且少了作答正確率用起來較不習慣,對我來說主要用途是在手邊的考古題出現爭議時,可以參考此網站上的討論。 後來同學們合資買了考古題,拿到幾百題的 PDF 題庫後,花了些時間用 Sublime Text 整理成正確格式後,再寫個 Python 腳本轉換成 JSON 格式,每次隨機抽 125 題出來練習;也有同學直接轉換成 Anki 格式,用背單字的方式來背考古。在刷題時,發現有的答案甚至是錯的,幾位一起參加培訓的同學討論、查資料對照後,手動修正了十幾題。 考照過程 在簽到進入訓練教室後,用自己的帳號密碼、考試 Voucher Code 序號,搭配監考官的密碼即可開始作答。 考試題目是共 125 題的四選一單選題,限時 4 小時。之前在網路上看到都說及格門檻依難度浮動調整,會是 60% 到 85%,不過我考到的這次在開始作答前的說明文字寫及格門檻 70%、只要答對 87 題就能通過,考後搜尋起來也是如此,不確定是制度改變還是怎麼樣。 系統設計上是回答完一題後,可以選擇作答或標記(未標記的題目也還能修改),才會出現下一題題目,不能往後跳到還沒開放的題號。 我們的考試時間安排在週日下午 13:00 開始,雖然有不少題目與考古題重複,看到可以秒選答案,但因為卡到期末只刷 150 題就上場的我,還是很多要靠英文閱讀。 據同學說法,如果是以拿到證照為目標,有買考古題、認真背過一輪,不用上課也能考到高分,但這就是大家瞧不起的 Paper CEH。 沒想到才過半小時就聽到有人離場的聲音了,因為正確與否是要交卷才會知道,過程中很擔心萬一沒考過該怎麼辦;我考了快兩小時才寫完檢查交卷,教室內大概只剩一兩成的考生了。 交卷後,馬上能看到自己答對的題數、通過與否,我拿了 104 分(83.2%)。 離開考場、再次登入系統後,可以下載成績單看自己 9 大主題的正確率。 後記 在培訓開始前兩天,課前提醒的信件提到雖然補助含課程及考照,但假如沒過就要自費補考(原廠補考價 $500 USD),拿到證照後有義務要參與資安檢測作業。 目前還尚未對學生公布檢測目標、檢測範圍大小、結果報告需求等詳細資訊,有擔心過不知道概略性的空白支票會不會被凹得太誇張,但後來基於信任負責單位,加上光考照本身就要價 $1,200 USD,還是決定繼續參加。 如果要問我看法的話,雖然知道 CEH 證照本身具有一定效力,但絕對不是會想自費去考的項目,只有在業務上有需要、公司出錢的前提下才會考慮。資安社群的前輩們肯定都有遠超越 CEH 的能力,要是像 APCS 那樣親民,可能就會人手一張 CEH 了。 BTW, 我在 ASPEN 課程平台跟 Exam Center 考試平台用了不同的信箱地址,結果發證照時被自動註冊了一個新帳號,變成這樣神奇的情況。還有我在註冊考試平台時竟然把英文名字打錯了一個字母,在拿到證書後才發現不對勁,還好聯絡客服人員就能順利更正了。 不免俗的還是要放一下證照本體,可以 在 EC-Council 官網 用姓名 Yung-Hsiang Wei 與證照序號 ECC2813064597 驗證有效性。 文章推薦 沒意外的話本文內容應該不會繼續更新,如果正在閱讀的你考過後有整理相關資源,歡迎讓我知道、列在這邊供後人參考。 CEH 考試心得與讀書資料分享 by Kuro Huang(2019 年 12 月) CEH v10 考試心得 by 小曹(2020 年 1 月) CEH v11 考試心得 by 禹璿(2021 年 10 月) CEH 之越挫越勇 by 胭脂虎(2017 年 12 月) 本文同步分享於 Twitter、 Telegram、 Facebook, 如果有什麼想法,或是協助勘誤,都歡迎來留言討論; 如果你是因為準備 CEH 證照考試而查到本文的,有遇到問題都 歡迎來聊聊,祝順利考到證照!

2022/1/14
articleCard.readMore

Unicode Normalization 文字標準化

事由 在交大資工的某個系統中,需要將使用者輸入的資料產生成 PDF 文件,在某幾位老師的名字中出現缺漏字的狀況。 例如這三個關鍵字,從肉眼看來都是正常字元,但搜尋起來數量差異非常大: 年月⽇:1,000 筆 / 年月日:50,000,000 筆 李⼩⿓:100 筆 / 李小龍:3,000,000 筆 ⾦木⽔火⼟:1 筆 / 金木水火土:9,000,000 筆 由於前者是罕用/相容性字碼,可以看到只會出現少數搜尋結果;而作為對照組的後者是同個字面的常用字碼,搜尋結果數量差異高達萬倍。 推測發生原因 先前遇過相同問題的情境,是源自於 macOS 的 Pages 匯出為 PDF 時,雖然肉眼看起來完全正常,但內部儲存的文字不如直覺所想得一樣。 例如在 Pages 中寫「更加精進自己的能力」,匯出成 PDF 後看起來完全正常,不過複製文字或是 Google 索引到的文字卻變成「更更加精進⾃自⼰己的能⼒力力」,可以看到長得一樣的字重複了兩三次。 對於不暸解其中原理的多數人而言,很可能以為兩個字完全一樣就隨意刪掉其中一個;然而對電腦而言,重複的兩個字編碼卻不同,猜錯/刪錯了就會導致資料庫搜尋時無法正常匹配。 Normalization Forms 標準化格式 由於有些字元可被拆分成許多 Component(部件),同一個字面又可以用不同編碼呈現,因此 Unicode 組織研擬了一套標準化的演算法,幫每一組字串產生唯一的字碼序列。 其中依據「標準化拆解 / 相容性拆解」、「純拆解 / 拆完再標準化組裝」兩種屬性,分為 NFD、NFC、NFKD、NFKC 四種標準化格式(通稱為 NFx),適合在不同情境使用。 標準化格式 代表意義 NFD 標準化拆解 NFC 標準化拆解,再標準化組裝 NFKD 相容性拆解 NFKC 相容性拆解,再標準化組裝 以下節錄自 UAX #15 標準附錄 範例並加以說明: Singletons 以 Å (U+212B, 埃符號) 來說,如果要轉換成 NFD 形式,會透過標準化的拆解演算法,分成 A (U+0041, 拉丁字母 A) 及 ◌̇ (U+030A, 上方圈圈) 兩個部件。 U+00C5, 帶有上方圈圈 A 字母),而不是原本的 Å (U+212B, 埃符號)。 以 Ω (U+2126, 歐姆符號) 而言,經過 NFD 拆解演算法會找到相同字面的標準形式 Ω (U+03A9, 希臘字母 Omega),此範例中 NFC 等於 NFD。 上面兩個例子可被歸於 Singletons 類別,經過標準化後非標準的字碼會直接被標準字碼取代,不會被保留。 Multiple Combining Marks 多種組合標記 有些文字像 Ṩ 是 S 加上兩個標記符號,同一個字面也可以有多種排列組合方式 在經過 NFD 拆解後,除了將字母本體放在前面外,後面的 ◌̣ 跟 ◌̇ 也會用唯一的順序排列,保證同一串文字在經過 NFD 拆解後可以取得唯一的結果。 而用 NFC 形式在標準化組裝時,第一個例子因為有 ṩ 可以用(並且不在例外清單中),就直接用 U+1E69 單個字碼表示。 Compatibility Composites 相容性組合 前面講到了 NFD 及 NFC 兩種形式,都是使用「標準化拆解」,這邊 NFKD 及 NFKC 是使用「相容性拆解」。 第一個例子中,原本連字的 fi 變回了 f + i 兩個字母;第二個例子把 2⁵ 的上標屬性還原,變回純數字 25。 在第三個例子中,ẛ + ◌̣ 經過相容性拆解後,把 ſ (U+017F, 拉丁小寫長版 s 字母) 變回了 s;而 NFKC 是先做相容性拆解,再做標準化組合(而不是拿 NFC 做相容性處理),因此得到單個 ṩ 而不是 ṡ + ◌̣。 小結 NFD 是 Canonical Decomposition 標準化拆解,將音標、組字拆開,再按照一套特定方法排序。 NFC 在官方文件中的定義是 Canonical Decomposition, followed by Canonical Composition,也就是先做 NFD 拆解後再組合,而不是一步到位。 而 NFKD 及 NFKC 的 K 是 Compatibility(相容性)的縮寫,會將「𝒮𝕥r𝔞𝐧g𝘦」轉換成「Strange」,得到的文字可能會長得和原文不一樣。 「o ffi c e」經過 NFD / NFC 轉換不會變,但經過 NFKD / NFKC 會變成「o f f i c e」;而「o f f i c e」經過 NFD / NFC / NFKD / NFKC 標準化都還是一樣,不會把 f f i 變成連字的 ffi。 解決方法 在經過 @splitline 指點後,得知 PHP 有內建一個函式可以完美解決這個問題。只要在需要過濾使用者輸入的地方加上 Normalizer::normalize($text); 函式,就能用 NFC 或指定的格式來標準化,讓位於其他區段的罕用字碼回到正常的常用字碼。 在各主流語言中也有相應的解法,例如 Python 的 unicodedata.normalize()、JavaScript 的 String.prototype.normalize()。 延伸閱讀 1:Confusables 易混淆字元 在研究這個問題的前期,我循線找到了 unicode-org/icu 這份 Repo,ICU 專案全名是 International Components for Unicode,包含 C/C++ 與 Java 的版本,裡面有許多 Unicode 相關字串處理的函式。 其中 confusables.txt 讓我覺得很有趣,例如「𝟑 𝟛 𝟥 𝟯 𝟹 Ɜ Ȝ Ʒ Ꝫ Ⳍ З Ӡ 𖼻 𑣊」都會變成 3。 而某些字面相同/類似的文字,甚至會出現三四次: ⼒ (U+2F12, 康熙部首 Power) → 力 (U+529B, 中日韓統一表意文字) U+30AB, 片假名 Ka) → 力 (U+529B, 中日韓統一表意文字) U+F98A, 中日韓相容性表意文字) → 力 (U+529B, 中日韓統一表意文字) 但 confusables 不像 NFC 標準化只轉換長得一樣的字元,也不像 NFKC 轉換到意義上的標準字樣,而是以視覺上相似的常用字元為主: ſ (U+017F, 拉丁小寫長版 s 字母) → f (U+0066, 小寫拉丁字母) U+0584, 亞美尼亞 Keh 字母) → f (U+0066, 小寫拉丁字母) U+1D487, 粗斜體數學字母) → f (U+0066, 小寫拉丁字母) 延伸閱讀 2:Unicode、UTF-8 差異 這是我困惑了好幾年的問題,以前都把兩個詞混著用,前陣子仔細查過才發現之間差異,因此寫進本文附錄。 Unicode 統一碼 以往台灣用 Big5,簡體用 GB 2312,各語系有自己的一套字元集,資訊流通起來就很不方便,因此有人提出包含所有語系文字、全球都通用的 Unicode 字元集。 在 Unicode 這個字元集中,「你好」可以被表示為「U+4F60, 漢字 you, second person pronoun」跟「U+597D, 漢字 good, excellent, fine; well」兩個字碼;其中 U+XXXX 就是 Unicode 字碼的表示形式,在 Unicode 文件中也會說到這個字碼是「漢字」,代表著什麼意義;而我們平常看到「文字」,則是由字體檔告訴電腦,什麼字碼該呈現什麼圖形。 又例如表情符號「🤪」字碼為 U+1F92A,代表「眼睛一大一小的笑臉」,各家廠商(如 Apple, Google, Twitter, Samsung)再依照自家的風格指南,繪製成 我們看到的樣子。 UTF-32、UTF-16 編碼 在 Unicode 規範中,從 U+0000 到 U+10FFFF 都是有效的字碼,因此如果直接轉換每個字碼到 4 位元組的空間,對程式來說很好實作,這種做法稱作 UTF-32 編碼。 由於多數常用字元都被編排在 U+0000 - U+FFFF 區段,而規範中又保證 U+D800 - U+DFFF 不會對應到任何字元,因此有人想到可以先把所有 Unicode 都嘗試用 2 個位元組表示。遇到 U+10000 - U+10FFFF 區段時,再改用 2 個 U+D800 - U+DFFF 之間的字元(4 個位元組)來表示。 雖然 UTF-32、UTF-16 對程式來說編寫起來很直覺,但無法與 ASCII 編碼相容。即使已知某文字檔只包含 ASCII 字元,對於不相容於 Unicode 的程式來說,可能會因為每個字之間的 NULL 導致無法正常顯示;對於許多以 NULL 作為結尾的語言,甚至連單純的字串複製都無法達成。 假如在不知情的狀況下將 UTF-16 誤作為 ASCII 編碼解讀,就會把「子丑寅卯」解讀為「[PN�[�So」,在某些剛好有定義的字元下,看到時很難斷言這是 UTF-16、ASCII 或其他編碼。 UTF-8 編碼 而 UTF-8 編碼算是解決了這個問題,下圖節錄自維基百科,可以看到 ASCII 範圍的 U+0000 - U+007F 只用了 1 個位元組;而 U+0080 開始,編碼後每個位元組的第一個位元都是 1,即使當成 ASCII 編碼檢視也不會產生歧義。 另外蠻巧妙的一點是,後續每個位元組都是 10xxxxxx,第一個位元組則依照字碼長度不同,讓程式從中間讀取字串時,不管是向前或向後尋找字元邊界,都能快速準確的知道該從哪裡切割。 順帶一提,複製網址時常看到的 %E7%B6%AD%E5%9F%BA%E7%99%BE%E7%A7%91 就是中文的 UTF-8 編碼加上 URL Encoding,大多數中文字位於 U+0800 - U+FFFF 範圍內,因此佔 3 個位元組,編碼後 %E7%B6%AD、%E5%9F%BA、%E7%99%BE、%E7%A7%91 各代表一個中文字。 小結 Unicode 是字元集,其範圍從 U+0000 到 U+7FFFFFFF,對我而言算是一個抽象的定義,各個字碼定義了每個「字」的意義、基本形狀,讓字體設計師賦予其活力。 U+XXXX 轉換成 1 - 4 個位元組,讓電腦得以儲存、傳輸。 使用 Unicode 字元集時,不一定要是哪種編碼,在 Unicode、UTF-8、UTF-16、UTF-32 之間可以用數學方式轉換。 後記 最開始研究時,大家們發現那些看起來正常卻又印不出來的字,只看到 KANGXI RADICAL 康熙部首區段、CJK RADICAL 中文部首區段、CJK COMPATIBILITY IDEOGRAPH 中日韓相容性字元區段,覺得是亂碼。 mozilla/gecko-dev 開始找起,發現裡面有一份 confusables.txt。之前 fork 某專案開發時也看過 ICU 相關資料集,因此回去找了正確的上游 Repo,並稍為了解其意義。 原本打算寫成一個 PHP 套件,讓內部專案可以直接 composer install 利用的,但朋友 @splitline 從 GitHub 動態看到我開一個新的 Repo,就跟我分享 PHP 內建的標準化函式,讓我不用重造輪子 XD 在研究完前因後果、經過組內報告後,為了撰寫相關文件頁面,就生出這篇部落格文整理思緒了,希望多少能幫到幾位踩雷的有緣人。 本文撰寫期間麻煩了很多朋友協助校稿,特別感謝 xdavidwu、Thect、Marvin Liu、Cycatz、Alan Kuan 提供寶貴的意見,在討論思辨的過程中,讓這篇文章更精確的傳達科普知識。 本文同步分享於 Telegram、 Twitter、 Facebook, 如果有什麼想法,都歡迎來留言區交流。 References 參考資料 Unicode UAX #15 標準附錄:unicode.org Confusable 易混淆字元:unicode-org/icu Unicode 字碼資訊:fileformat.info 維基百科:Unicode、UTF-8、Unicode 區段、字元編碼 em { color: darkviolet; font-style: normal; }

2021/12/10
articleCard.readMore

Telegram 官方關於 TON 區塊鏈及 Gram 幣的公開聲明

關於 TON 區塊鏈及 Gram 幣的公開聲明 A Public Notice About the TON Blockchain and Grams 您可能已經聽說,自 2017 以來,Telegram 團隊一直在開發一個名為 TON Blockchain 的新區塊鏈平台和名為 Gram 的加密貨幣。我們希望這個專案能讓 Gram 成為傳統貨幣的互補品,從而改善全球日常商業交易的 速度、效率 和 安全性。我們相信,TON 區塊鏈技術將創造一個穩定的生態系統,並且在 速度、可用性 和 可擴展性 方面都將比以前的平台有重大改進。 You may have heard that since 2017 the team at Telegram has been developing a new blockchain platform called the TON Blockchain and native cryptocurrency called Grams. We hope that as a result of this project Grams will become a true complement to traditional currencies, improving the speed, efficiency and security of everyday commercial transactions globally. We believe that the TON Blockchain technology will create a stable ecosystem and represents a significant improvement upon previous platforms in terms of speed, usability and scalability. 媒體上有很多關於這個專案細節的謠言與臆測,在我們繼續構建 TON 區塊鏈平台並確定專案的確切細節以確保 TON 區塊鏈和 Gram 幣可以用 符合 法律及規範的方式運作的同時,Telegram 一直謹慎地 避免公開談論 這些謠言。 There have been a lot of rumors in the media and speculation about the details of this project. Telegram has been careful not to speak publicly about these rumors while we continue to build the TON Blockchain platform and work out the exact details of the project to ensure that the TON Blockchain and Grams can operate in a way that is compliant with all relevant laws and regulations. 鑑於最近發生的事件,我們希望花點時間公開闡明 TON 區塊鏈和 Gram 幣的某些面向,同時我們將繼續為專案的成功啟動做準備。 In light of recent events, we wanted to take the time to publicly clarify certain aspects of the TON Blockchain and Grams as we continue to prepare for a successful launch of the project. 我們在本文的段落中將以 簡單的術語 做簡短的 摘要,格式會像是這樣 👈 We’ve included short summaries in simple terms for paragraphs in this text, formatted like this 👈 目前還沒人可以買賣 Gram 幣 Nobody can buy or sell grams yet 首先,引起我們注意的是某些網站似乎向公眾提供了 Gram 幣。這些網站有時將此稱為「貨幣預售」,有些則假裝與 Telegram 相關。正如我們在 很多 地方 上警告您一樣,這些都 不是 Telegram 的官方網站,它們與 Telegram 沒有 隸屬關係,並且 Gram 幣 尚未 向任何人發行。Telegram 或其相關公司均未參與 Gram 幣的任何公開銷售或預售。相反地,乘載 Gram 幣的 TON 區塊鏈仍處於 Beta 測試 階段,您可以於 test.ton.org 造訪 Beta 測試網站,只有在 TON 區塊鏈啟動後,Gram 幣才會被創造並開放購買。 First, it has come to our attention that certain websites appear to be offering Grams to the public. These websites sometimes refer to the offers as “token presales,” and some pretend to be affiliated with Telegram. As we’ve warned you on numerous occasions, these are NOT official Telegram websites, they have NO affiliation with Telegram, and NO Grams have been issued yet to anyone. Neither Telegram nor any of its affiliates are involved in any public sales or presales of Grams. To the contrary, the TON Blockchain on which Grams will function is still in a Beta Test phase and you can access the Beta Test website at https://test.ton.org/download.html. Only once the TON Blockchain launches will Grams be created and available to purchase. 長話短說: Gram 幣還不存在,沒有人 有辦法在我們宣布推出 TON 區塊鏈前做任何買賣。 別受騙了 TLDR: Grams don’t exist yet, nobody can buy or sell them before we announce the launch of TON Blockchain. Don’t get scammed. TON 區塊鏈將是去中心化並由第三方維護 TON will be decentralized and maintained by third parties 其次,如果您正在考慮在 TON 區塊鏈平台啟動後是否該購買 Gram 幣,我們希望您了解幾件事。Telegram 及相關公司並未對 TON 區塊鏈開發任何應用程式或功能作出任何承諾。實際上,Telegram 可能永遠不會這樣做。相反地,Telegram 的目標是希望 各地的第三方開發人員社群 和其他人員將透過開發應用程式及智能合約為 TON 生態系做出貢獻。第三方 和社群將以自己選擇的方式採用 TON 區塊鏈和實施此類應用程式或智能合約,這責任只存在於第三方。Telegram 不會也不能保證任何人將在任何給定的時間表上實現,或根本不採用此類功能提供服務。 Second, if you are considering whether to purchase Grams once the TON Blockchain platform is launched, we want you to know certain things. Telegram and its affiliates have not made any promises or commitments to develop any applications or features for the TON Blockchain or otherwise contribute in any way to the TON Blockchain platform after it launches. In fact, it is possible that Telegram may never do so. Rather, it is Telegram’s goal and hope that the decentralized community of third-party developers and others will contribute to the TON ecosystem through the development of applications and smart contracts. It will be the sole responsibility of third parties and the community to adopt and implement such applications or smart contracts on the TON Blockchain in the manner they choose. Telegram does not, and cannot, guarantee that anyone will adopt or implement such features or provide such services, on any given timetable or at all. 長話短說: 我們為所有人建立了 去中心化 的平台,當他發布後 Telegram 不再有義務維護平台或為此建立任何應用程式,或說我們根本不會這麼做。 TLDR: We are creating a decentralized platform for everyone. Once it launches, Telegram won‘t be obligated to maintain the platform or create any apps for it. It’s possible we never will. Telgram 將無權控制 TON 區塊鏈 Telegram will have no control over TON TON 區塊鏈的程式碼將始終 開源 且任何人 皆可取得,一旦推出後 Telegram 將與 TON 區塊鏈的 其他任何人 站在 相同的地位,並將 無權控制、沒有任何特權、不負對 TON 區塊鏈管理的任何責任。 The code for the TON Blockchain will always be open source and publicly viewable. Once it is launched, Telegram will occupy the same position as any other party with respect to the TON Blockchain and will not have any control over, any unique rights within, or any responsibility for the management of, the TON Blockchain. 在 TON 區塊鏈推出後,Telegram 或其員工可以但不保證持有任何 Gram 幣。在一定程度上,他們將 不參與跟 TON 區塊鏈有關的表決或驗證。做出此自願性決定是為了避免任何人認為 Telegram 及其員工可以或將在 TON 區塊鏈發布後對其實施控制。 Telegram or its employees may, but do not commit to, hold any Grams following the launch of the TON Blockchain. To the extent they do, they will not take part in voting or validating in connection with the TON Blockchain. This voluntary decision was made in order to avoid any perception that Telegram or its employees can or will exercise control over the TON Blockchain following its launch. 長話短說: 在推出後 Telegram 將無法控制 TON 區塊鏈及其生態系統。就像建築師設計摩天大樓一樣,建築師無法控制建築物完工後發生的情況 - 包括周圍的建築物、內部裝潢,或頂樓加蓋。 TLDR: Telegram won‘t be able to control the blockchain and the ecosystem after it launches. Pretty much like an architect who designed a skyscraper can’t control what happens with the building after it’s finished – including what gets built around, inside or on top of it. 炒 Gram 幣並不能讓您致富 Grams won’t help you get rich 第三,您不應該基於期望獲利而購買 Gram 幣,Telegram 不做任何您能獲利的保證。Gram 幣旨在充當 TON 生態系統中用戶之間的 交換媒介,Gram 幣並 不是 投資產品,對於從 Gram 幣的買賣或持有中獲利您應該 不抱 任何期望。 Third, you should NOT expect any profits based on your purchase or holding of Grams, and Telegram makes no promises that you will make any profits. Grams are intended to act as a medium of exchange between users in the TON ecosystem. Grams are NOT investment products and there should be NO expectation of future profit or gain from the purchase, sale or holding of Grams. Gram 幣並 不 代表: Telegram 及其相關公司的任何股權或所有權利益 Telegram 或其相關公司的股息或其他分配權 Telegram 或其相關公司的任何管理權 Grams do NOT represent: Any equity or other ownership interest in Telegram or its affiliates Any rights to dividends or other distribution rights from Telegram or its affiliates Any governance rights in Telegram or its affiliates. 長話短說: 如果您在將來購買 Gram 幣,這 不代表 您持有 Telegram 的一部分,Gram 幣並不會賦予其持有者任何特殊權利,就像持有歐元不會給您歐盟的股份一樣。 TLDR: If you buy grams at some point in the future, this won’t mean you “own a piece of Telegram.” Grams don‘t give their holders any special rights, just like owning Euros doesn’t give you shares in the European Union. 在決定是否購買 Gram 幣時,您應該充分意識到 Gram 幣的價值可能會隨著時間的流逝而下降甚至失去 所有貨幣價值 的風險。購買諸如 Gram 幣之類的加密貨幣存在許多風險,包括加密貨幣市場的波動性、對交易所的監管加嚴的可能性以及其他風險。 In deciding whether to purchase Grams, you should be fully aware of the risk that Grams may decrease in value over time or even lose all monetary value. There are a number of risks related to purchasing cryptocurrencies like Grams, including volatility in cryptocurrency markets, the possibility of increasing regulation of cryptocurrency exchanges and other risks. 長話短說: 玩加密貨幣是 高風險地,由於一卡車的外在因素,實際上可能讓您變得更窮。 TLDR: Dealing with cryptocurrency is risky and can actually make you poorer than you are due to a boatload of external factors. 而假如您已經聽過 TON 區塊鏈… And if you already heard about TON… 最後,我們想提供有關 TON 區塊鏈的某些技術和治理方面的進一步說明。請注意,以下內容旨在 取代和替換 與 TON 區塊鏈和 Gram 幣有關的所有先前文章,以免發生任何衝突或潛在衝突,包括 TON 白皮書或 Telegram 及其他人在任何先前版本中規定的資訊和詳細訊息: Finally, we wanted to provide further clarity regarding some technical and governance aspects of the TON Blockchain. Please note that the below is intended to supersede and replace all prior materials or communications regarding the TON Blockchain and Grams to the extent of any conflict or potential conflict, including the information and details set forth in the TON Whitepapers or any previous communications or materials by Telegram or anyone else: (1) Telegram 沒有義務,也沒有做出任何承諾,以後不會建立 TON 基金會 或類似機構。 (1) Telegram is under no obligation, and makes no promise or commitment, to ever establish a TON Foundation or similar entity in the future. (2) 在預期推出 TON 區塊鏈時,Telegram 的 TON 錢包應用程式預計將以 獨立 的方式單獨提供,並且不會與 Telegram Messenger 服務整合。在這方面,TON 錢包有望與 第三方 提供的任何其他錢包應用程式 競爭。在適用法律和政府機構允許的前提下,Telegram Messenger 將來可能會內建整合 TON 錢包功能。 (2) At the time of the anticipated launch of the TON Blockchain, Telegram’s TON Wallet application is expected to be made available solely on a stand-alone basis and will not be integrated with the Telegram Messenger service. In this regard, the TON Wallet is expected to compete with any other wallet applications designed and offered by third parties. Telegram may integrate the TON Wallet application with the Telegram Messenger service in the future to the extent permitted under applicable laws and governmental authorities. Telegram 保留所有進一步增加、澄清或修改 TON 區塊鏈或 Gram 幣以上及任何其他方面的權利。隨著 TON 區塊鏈預定發布日期的接近,我們期待提供更多訊息。 Telegram reserves all rights to further add to, clarify or revise these or any other aspects of the TON Blockchain or Grams. We look forward to providing more information as we get closer to the anticipated launch of the TON Blockchain. January 6, 2020 本文章包含前瞻性陳述,包括計劃、目標、期望、發展狀況,以及意圖。任何數量的因素都可能導致實際結果與任何前瞻性陳述所預期的結果產生重大差異,包括但不限於此處確定的風險。 This communication contains forward-looking statements, including statements of plans, objectives, expectations, development status and intentions. Any number of factors could cause actual results to differ materially from those contemplated by any forward-looking statements, including but not limited to the risks identified herein. 譯註 以上僅是簡單翻譯,如有錯誤或任何建議還請 不吝指教 原文請見 官方部落格 如感興趣可以來 Telegram 討論區 逛逛 譯者:Sean Wei 轉載/節錄請註明來源出處 blockquote { color: black; border-left-color: #179cde; } .orig { color: grey; }

2020/1/6
articleCard.readMore

交大資工開學經歷

大學是個新的起點,很開心覺得自己過得還算充實,寫個心情紀錄給自己,只是有點流水帳 Sep 2 (Mon) 早上八點整理出門,先跟爸爸去新竹工地,媽媽再載我到交大 宿舍入住 早上十點抵達宿舍,辦完入住手續後搬了一大箱行李、床墊到房間 中午從研三騎 YouBike 滑行下去清大小吃部找 William 跟他的兩位同學 吃完飯到禮齋,在走廊上剛好遇到國中同學愷峰 選課 從三點開始,我跟 Alan、lys 三人一起選課,先是完全打不開加選頁面,後來才發現是因為網頁檔名叫 adMain.asp 所以被 uBlock origin 阻擋 一開始在系統和 NCTU+ 做模擬排課,但後來發現太過於複雜無法消化,改用紙筆規劃不衝堂的排課方式 在糾結和取捨了多次之後,到六點終於完成課程初選了,等待 9/6 公佈結果 Sep 3 (Tue) 床旁邊就是整面的窗簾,六點就被陽光叫起來了,或許這週回家補給時該買個眼罩 開學典禮 各組上台宣達新生事務,多數人在滑手機,我則是直接拿筆電架、電腦出來用 中午吃完飯後,趁禮堂人還不多,找了十多個資工系同學小聊一下,多數人對資訊是有興趣的,但許多人程式都是只會基礎,或是進來才要開始學 下午兩點休息時間,去百川的座位上找同樣會程式的何孟軒,了解當時進入主要的長才、也簡單認識周圍其他百川的同學,真的很好奇/羨慕這群同學,在一個系裡面各有不同興趣專長,約好有機會再吃個飯慢慢聊 計中工讀 清水救生隊的 Vincent 教練知道我錄取交大後,介紹了一位諮詢服務組 Sophi 給我認識,這天中午去資訊技術服務中心第一次見面,聊了一小時後順便帶我上去二樓,找校務資訊組黃世昆老師 沒想到與黃老師第一次見面,就跟我說待會下午四點有 SQLab 軟體品質實驗室的 meeting,邀請我可以讓我過去晃晃 SQLab 五點新生活動結束後,跟 Jasper 一起去 EC129 找黃老師,一進去就熱情的招待豆花、飲料 裡面大概十位碩班的學長,這次報告的大概是講 Machine Learning 利用雜訊 Retrain 增加 Accuracy,之前就有碰過一點基礎的機器學習,大概理解方法後也去找報告者討論一下,沒想到 AIS3 課程教的知識可以在這時候派上用場 跟大家聊一聊後,黃老師也表示歡迎下課時間過去那邊坐坐、有問題可以問學長們 機櫃裝系統 晚上八點跟 Jasper、William 去 ED9xx 的機櫃,有一個是放 Jasper 在上次綠界活動拿到的 Rack Server 過去時已經都放上機架了,這次幫忙裝 PVE 系統,從設定網路、設定 RAID 卡,到安裝系統 八台 server 只用先用了四台,到了十二點半結束,分開後自己去便利商店吃完晚餐再回宿舍 Sep 4 (Wed) 第二天的新生活動,除了上下午簽到外,中間休息還會「抽獎」防止偷跑 上午寫心得及回信,原本還想說有時間看個影片,但筆電用到快沒電,也只能作罷 中午回到研三舍,配 Netflix 的越獄風雲吃對面買的義大利麵 下午帶了充電器到禮堂,才發現根本找不到插座 自助洗衣 晚上洗好澡後把三天份的衣服一起拿去洗,看著單槽洗衣機跟洗衣精包裝上的指示猶豫了很久,不知道該加多少,還好最後衣服洗出來感覺還不錯 回到宿舍後叫了外送宵夜來吃,大概 15 分鐘送到了,效率還不錯,熱熱的也很好吃 放了一小時才想到要去拿,看到隔壁烘衣間每台都有人在用了,沒看清楚標示就把洗好的衣服放到滾筒式洗衣機去了,按下開始後就鎖起來了,找不到停止鈕 洗完兩次衣服、烘乾後,發現每件都還濕濕的,或許下次要改投 20 元烘一小時 還好拿回房間晾一個晚上,隔天起來就全乾了 Sep 5 (Thu) 前兩天都要八點起床,今天下午一點才有活動,終於可以睡飽一點了 但還是九點就被太陽亮醒,今早注意看才發現應該是窗簾太透光的問題 新生報到 到交大前是覺得全系 180 人要把系群從 LINE 搬到 Telegram 太困難,不打算這麼做 個別聊了一下發現竟然有人在 Telegreat 群 裡面,就重新覺得既然都資訊人,用 TG 才是常態,重新燃起推坑熱情 原本是說入學通知單作為開學後十天內的正式證件,沒想到這麼快就拿到學生證了,比起普通的新北市高中學生證,覺得這張真的很美,尤其特別喜歡雷射校徽 游泳 今天整天下雨,晚上覺得整天沒什麼動到悶悶的,就自己跑去泳池 交大的室外池有八個水道,是 50 公尺的大池,泳客大約 15 人空曠又不孤單,水質也不錯,只可惜深度就普通的 1.3 米而已 上次游泳是 SITCON 夏令營 Day -1 的早上了,整整一個月沒碰到水,果然單趟就會累了,自己複習一下各種泳姿,玩了半小時就回去宿舍休息 晚上找 William 來宿舍,外送滷味 3 人一起吃,意外開始被推 Blender 坑,看到 Blender Open Movie 真的一時難以相信,一個是這電影竟然是動畫、開源軟體製作的動畫,一方面在想電影怎麼開源、除了放出專案檔可以怎麼做 後記 再不到一週就要正式開學了,希望大學除了學到各種知識常識外,可以順利讀完,很怕選太多課反而害到自己 原本是想記錄一週或一個月再發,但看到美美的學生證就忍不住先發了,結尾再放一次海豹照片

2019/9/5
articleCard.readMore