The login-feature is almost done～
We are able to start setting-up the service to communicate with python-server.

Based on the information that I obtained:

1. Will use gPRC to communicate between each other.
2. Use jwt to send the user-info to python-server.
3. python-server is responsible for recording the jwt-info (user-info) in its own db.

我的最愛檔案 .fav 的測試檔已經上傳了，該使用者應該有 test 以及 ALLPOST 兩個最愛。

檔案位置位於
https://github.com/PichuChen/go-bbs/tree/master/testcase/fav

相關的Header 位置位於
https://github.com/ptt/pttbbs/blob/af507e0029c4e6b3a564ec98328ffe7cd7fd16be/mbbsd/fav.c
https://github.com/ptt/pttbbs/blob/af507e0029c4e6b3a564ec98328ffe7cd7fd16be/include/fav.h

目前在Access Token 的設計上應該會採用 JWT Token

已知裡面會有 User ID 作為簽發主體

現在看還需不需要多塞什麼東西以利Client端利用，以及有效時間大約多久？三十分鐘？五分鐘？

brc3 檔案的用途是暫存目前使用者在各個看板已讀哪些文章的記錄檔

原本作法的問題 / Solved Problem

• 目前 #53 正在進行符合 Golint 檢查的修改，將自動檢查添加到 CI 流程中可避免未來發生違反規則的修改。

實作細節 / Details of Implement

目前有二方案，一是簡單添加 golint 工具直接執行。另一是使用 Go 生態圈常用的 Go linters aggregator golangci-lint 來執行 golint，額外的好處是，隨著專案持續發展，我們可以逐步啟用各種靜態分析工具。

相關文件 / Documents

• https://github.com/golang/lint
• https://github.com/golangci/golangci-lint

預計要做 board header parser 以及 unit test 的部分
會修改的程式碼包含
board.go
board_test.go

只會做最初步的parser，基本上就是按照 pttstruct.h 裡面的boardheader_t結構去實作

原本作法的問題 / Existed Problem

Golang 1.16 推出了，應該可以開一個 Branch 測試目前 1.16 跑起來會不會有問題

實作細節 / Details of Implement

建立一個 feature/golang_1_16 然後修改 CI 檔案讓他使用 golang 1.16 做測試，沒問題的話就 merge 回來

期程 / Schedule

• 討論時間：一日
• 實作時間：一日
• 確認時間：一日

相關文件 / Documents

https://golang.org/doc/go1.16

實作細節 / Details of Implement

• 請參考 pttbbs admin.c 當中的 add_board_record 的行為。
• 不做權限檢查，權限檢查交由 Ptt-backend 套件進行，但是需要進行資料結構完整性上的檢查，例如是否超過最大看板數量。
• 是否支援 Cache (SHM) 需要討論，有可能同時支援沒有 Cache 的版本。

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 三日，到 2/13
• 實作時間： 一日，到 2/14
• 確認時間： 三日，到 2/17

相關文件 / Documents
pttbbs admin.c

The Problem

Run go run pttbbs/cmd/main.go ，always return "unsupport connectionString"。

L278 always return error

實作細節 / Details of Implement

• 實作讀取草稿的功能
• 原始碼參考edit.c 的 read_tmpbuf
• 參考 #89 的Pull Request
• 在 bbs.go 和 draft.go 裡加入 ReadUserDraft method (具體參數和實作細節請參考註解和原始碼)
• 可以的話加入test case

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 一週, 到 6/11
• 實作時間： 一週, 到 6/18
• 確認時間： 一週, 到 6/25

相關文件 / Documents
參考method 註解

實作細節 / Details of Implement
目前準備製作一份貢獻者名單加到專案裡面。
包括但不限於 coding，撰寫文件等

歡迎大家提名自己到名單內

期程 / Schedule
無，但會定時 merge 到 development

相關文件 / Documents
CONTRIBUTORS.md

1. 名字 （網路名稱）：必填
2. GitHub 帳號：非必填
3. 社交帳號：非必填，請給連結
4. 貢獻內容：必填

雖然套件名稱是 Cache 但實際上是用來讀取 SHM 的套件

初步想法是這樣，目前在測試環境的 SHM 已經被打包下來了，約 44MB, 因此在 Parsing 的時候透過 mmap 的 System call 就能夠讀入記憶體了。

但是根據每個BBS編譯設定不同，欄位所在的記憶體位置也會不同，因此這部分需要動態算出位置，算出位置後下一步就能取得該位置的資料或是將資料寫入該位址。

如果回傳的是 []byte byte slice 的話，那利用者就能自由的讀取和修改某段記憶體位置了（還不用copy）
https://play.golang.org/p/vEUqcyc5g94

第一階段因為方便測試，所以用 mmap 打開測試資料，然後上線前改成透過 cgo 開啟 system V SHM 的版本。

大概是這樣的計畫，看有沒有人有興趣或是其他意見。

目前有個重要的任務我忘了開，就是需要解析文章

以前並沒有結構性的去描述 BBS 文章結構的結構，因此這部分得我們自行發明。

初步的話我希望可以解析成以下的格式

"is_header_modify": {{is_header_modified}},
"author_id": {{author_id}},
"author_name": {{author_name}},
"title": {{title}},
"post_time": {{post_time}},
"board_name": {{board_name}},
"text": {
    "text": {{text}},
    "color_map": {{text_color_map}}
},
"signature": {
    "text": {{signature_text}},
    "color_map": {{signature_color_map}}
},
"sender_info": {
    "site": {{sender_site}},
    "ip_address": {{sender_ip_address}},
    "ip_country": {{sender_ip_country}},
},
"edit_record": [{{edit_record}}],
"push_record": [
    {
        "type": {{push_record.type}},
        "id": {{push_record.pusher_id}},
        "ip_address": {{push_record.pusher_ip}},
        "text": {{push_record.type}},
        "time": {{push_record.time}},
    }
]

方法目前沒有特別的想法，也許建議使用regex或者是if else, 如果用 goyacc 寫出一套解析器應該也是可以，雖然我懷疑這個解析器會不會遇到2003以前的文章就失效了。 如果要用 NN 訓練出一個模型出來我覺得也不是不行，雖然這樣的話我可能會先讓傳統 if else 作法的先上線。

原本作法的問題 / Solved Problem

• 目前還沒有新增資料到資料庫的範例，因此用新增看板作為測試
• 目前在測試上只有跑 go test 好像不夠，所以多一個命令列來做測試以及未來的維運使用

實作細節 / Details of Implement

• 大致上直接寫

期程 / Schedule

• 確認時間： 一週

原本作法的問題 / Solved Problem

• 原本是連結到 PichuChen/go-bbs ，假如不修改的話接下來開發會比較不方便

實作細節 / Details of Implement

• @denkeni 說取代就行了

期程 / Schedule
N/A
相關文件 / Documents
N/A

Found that fav-info is stored in in-process mem,
and is brutal-forcely do fav-save when the ssh/telnet/ws session is done.

https://github.com/ptt/pttbbs/blob/master/mbbsd/board.c#L1647
https://github.com/ptt/pttbbs/blob/master/mbbsd/mbbsd.c#L206

Design concern:

1. At least the fav-info in-file should be with one complete version. it shouldn't be parts from one connection and the others from another connection (resulting broken file)
2. We should request the fav-info from file as least as possible.
3. fav-info is a many-reads-few-writes operation.

Currently pttbbs allows at most 3 concurrent connections. So it's ok to have possible conflicting fav-setup as long as we stick to Design 1.
(In rare situation, the user has a dead process, and the user allows the dead process continue working,
and the user modify the fav-info and logout before the dead-process is killed.)
(The user will just reset it again)

Requires frontend to take care of fav-editing and middleware to have cache of the fav-info.

When doing get-fav from frontend-UI:

1. middleware check the cache first.
2. if the cache is within n seconds (10 for now). return the cache.
3. middleware provides last-load-time with the go-bbs and try to get the fav from file.
4. go-bbs: first compare the load-time with the mtime of the file. return mtime as no-need to update. otherwise return the full fav.
5. middleware update the cache accordingly.

When doing update-fav from frontend-UI:

1. frontend takes care of the editing, do only fav-save to the middleware. (frontend shouldn't do fav-save within 10 seconds.)
2. the middleware store in tmp-db, spawn process/thread to do fav-save after 10 second.
3. the middleware check that the fav-save is still the newest setup to do. do save on go-bbs.
4. go-bbs do fav-save only when the load-time from the middleware is newer than the mtime. return fav-from-file to middleware to ensure sync from fav-from-file.

原本作法的問題

• 因應 #67 及 #60 (comment) 的問題，在 CI 執行環境提供誇平台測試。

實作細節

• 使用 strategy.matrix.os 提供 macos、windows 及 ubuntu 測試。

這個 ISSUE 紀錄需要被解析的檔案以及解析的進度

• 使用者記錄檔 (PASSWDS)
  • 進行中 https://github.com/PichuChen/go-bbs/issues/1
  • 目前基本功能解析和轉換回二進位檔的部分已經完成，棋院相關的功能還沒做。
• 看板列表 (.BRD)
• 看板內文章列表 (.DIR)
• 看板內文摘檔案 (.Names)
• 文章內文解析
• 最近登入紀錄 (logins_recent)
• .polling
• .post
• 登入失敗紀錄 (logins.bad)
• reg.wait
• register.log
• usies
• 我的最愛列表 (.fav)
  • 於 #21 進行中
  • 二進位轉換成 golang struct 的部分好了，以及 go struct 轉換回二進位的部分也好了
• 聊天室紀錄檔
• 使用者名片檔
• 使用者簽名檔

如題，因為目前載入密碼檔案的機制是在程式執行時進行的。

也許要把它改成每次驗證時重新載入？或是幾分鐘重新載入？或是有什麼機制讓他重新載入這樣。

實作細節 / Details of Implement

• 請見 userec_t 中的 uflag 和 userlevel
• 每個選項對應的 flag id 請參見 user.c desc1 和 masks1

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 一天 4/19
• 實作時間： 一週 4/25
• 確認時間： 一週 5/2

相關文件 / Documents
userec_t

正統的 Big-5 的字集裡面應該是不支援日文假名以及「堃」字的，但是PTT有支援，主要是因為PTT並不是使用一般的 Big-5 而是使用 Unicode 補完計劃的 Big5-UAO 編碼，這個編碼看起來還沒被Golang支援的樣子，需要Patch。

實作細節 / Details of Implement

• 查詢某User的歷史文章，主要是用來與ptt-backend對接repository使用
• cache依照ptt-backend (#59) 暫定不做，暫時是存放在go-bbs這
• 權限檢查參考其他的issue，一樣由ptt-backend處理

期程 / Schedule

• 此Issue與 Ptt-official-app/Ptt-backend#59 連動，go-bbs處理完成後，ptt-backend就不需要mock

• 討論時間： 3/4-3/7(3 day)
• 實作時間： 3/8-3/11(3 day)
• 確認時間： 3/12/-3/15(3day)

相關文件 / Documents

• 其他參考文件請支援

實作細節 / Details of Implement

• board.c 檔案的 b_config 上面有看板限制和細部資訊，兩邊基本上是一起被取出的，所以可以放在同個 Method 出來。

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 一天 4/19
• 實作時間： 一週 4/26
• 確認時間： 一週 5/3

相關文件 / Documents

原本作法的問題 / Solved Problem

• UserRecord 缺少部分的方法

實作細節 / Details of Implement

• 依據 PTT-Backend 的 API 文件，發現 UserRecord 缺少以下方法:
  • NumBadPosts()
  • LastCountry()
  • MailboxDescription()
  • ChessStatus()
  • Plan()

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間：一週
• 實作時間：一週
• 確認時間：一週

@kkdai 整理分享，我想說放一份連結在這個issue，有後續資料跟討論可以在這繼續進行

https://www.evanlin.com/golangtg-ptt/?fbclid=IwAR3vojWy1K31T6eU9CT-QdgPjF95okDS8qsJmXHKTKXyzQen3_wQpoQxWbo

實作細節 / Details of Implement

• 目前看起來需要解析在 pttstruct.h 裡面的 userinfo_t，測試資料從目前 shm 測試資料的 0x40510 位置開始，長度確認中。

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 一週
• 實作時間： 一週
• 確認時間：一週

相關文件 / Documents
https://github.com/ptt/pttbbs/blob/4d56e77f264960e43e060b77e442e166e5706417/include/pttstruct.h#L349

原本作法的問題 / Solved Problem

CI go.yml 設定中的 L27 先安裝套件中宣告的依賴後，在 L28 還特別處理 Dep 宣告的依賴。考慮到專案已使用 Go Modules 且並不存在 dep 依賴設定檔，此應為無效的步驟。

實作細節 / Details of Implement

1. Go build/test 在執行時即自動安裝依賴，建議移除該 step。
2. 使用 actions/cache@v2 快取依賴，加快 CI 執行速度。
3. 允許手動執行測試。

相關文件 / Documents

• github.com/golang/dep
• Doc: Command go
• actions/cache - Go Modules

實作細節 / Details of Implement
目前有部分 code 使用 id 應該要改為 ID

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間：一天
• 實作時間： 三天
• 確認時間： 一天

相關文件 / Documents
使用 golint 確認

實作細節 / Details of Implement

• 實作移除文章草稿的功能
• 請參考 edit.c 下的 erase_tmpbuf(void)

期程 / Schedule

• 討論時間： 一週, 到 6/7
• 實作時間： 一週, 到 6/14
• 確認時間： 一週, 到 6/21

相關文件 / Documents
請參考函式註解

這個功能是為了實作以下功能

https://github.com/ptt/pttbbs/blob/master/docs/brc.txt

https://github.com/ptt/pttbbs/blob/master/mbbsd/brc.c#L444
https://github.com/ptt/pttbbs/blob/master/mbbsd/brc.c#L596

brc is per-user article-read record.
It's extensively used when displaying article-list and board-list.
As fav, this cannot be read directly in go-bbs, or the system may failed.

Requiring middleware to take-care of user-article-read mapping and determine user/article and user/board read.
middleware needs to have good mechanism to sync-back the brc.

實作細節 / Details of Implement

• 目前在 實作文章推文 以及 轉錄看板文章 都需要直接新增一行字串
• 直接編輯整個文章和在後面新增一行字串在硬碟上的效率不太一樣，新增字串會有比較高的效能
• 可能會在原有文章或是 bbs 的 connecter 新增一個 method 裡面有參數來表示某個看板的某個文章，然後和一行任意文字。

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 三天，5/2
• 實作時間： 一週，5/9
• 確認時間： 一週，5/16

相關文件 / Documents

基本上是為了實作這樣的功能

原本作法的問題 / Solved Problem

• 既有版本僅在 master 分支執行 CI 測試，無法及早發現問題。

實作細節 / Details of Implement

• Add development branch to on.push/on.pull_request

相關文件 / Documents

• #55 (comment)

目前在 https://github.com/PichuChen/go-bbs/blob/d49298349281c75edd721caece6db88744df7dba/bbs.go#L89 有定義Connector ，但目前的 Connector 只有讀取的功能，需要定義有寫入功能的 BBS Driver 要實作哪些東西。

方向上有兩種，一種是在原有的 Connector 新增 Method
第二種是定義新的Interface 可能叫做 WritableConnector 或是 BBSWriter 之類的，然後去定義這個 Interface, 使用上就是檢查如果這個 Driver 沒有實作某個 Connector Interface 的話，就是視為這個 BBS Driver 不支援某類型的功能。

logins.bad 有兩種，一個在BBSHOME，一個在User下面
https://github.com/ptt/pttbbs/blob/master/include/common.h#L56
https://github.com/ptt/pttbbs/blob/master/common/bbs/passwd.c#L255

/logins.bad: 這個檔裡有每個 user的login attempt且包含成功與失敗。第一個字元若是"-"代表失敗。

 test03      [01/01/2021 10:11:45 Fri] [email protected]
 test04      [01/01/2021 10:13:35 Fri] [email protected]
 test05      [01/01/2021 10:13:45 Fri] [email protected]
 SYSOP       [01/01/2021 10:13:53 Fri] [email protected]
 test06      [01/01/2021 10:14:38 Fri] [email protected]
 SYSOP       [01/01/2021 10:14:46 Fri] [email protected]
-test01      [01/01/2021 10:15:16 Fri] [email protected]
-test02      [01/01/2021 10:15:19 Fri] [email protected]
-test03      [01/01/2021 10:15:22 Fri] [email protected]
 test04      [01/01/2021 10:15:38 Fri] [email protected]

home///logins.bad: 這個檔裡只有該user的 失敗 login attempt

╰─➤  cat home/T/test01/logins.bad
[01/01/2021 10:15:16 Fri] 172.22.0.1

目前我的想法是用同一個struct來parse這2種logins.bad

type LoginAttempt struct {
	Success        bool
	UserId         string
	LoginStartTime time.Time
	FromHost       string
}

For /logins.bad ，這個檔裡四個field都有，所以沒問題。
但在user/logins.bad，缺少 UserId ，所以parse出來的struct就沒有 UserId，需要caller assign

實作細節 / Details of Implement

• 目前在 實作文章推文 以及 轉錄看板文章 都需要直接新增一行字串
• 直接編輯整個文章和在後面新增一行字串在硬碟上的效率不太一樣，新增字串會有比較高的效能
• 可能會在原有文章或是 bbs 的 connecter 新增一個 method 裡面有參數來表示某個看板的某個文章，然後和一行任意文字。
• 請參考 bbs.c 的 do_add_recommend

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 三天，5/2
• 實作時間： 一週，5/9
• 確認時間： 一週，5/16

相關文件 / Documents

轉錄文章在 bbs.c 的 cross_post

基本上是為了實作這樣的功能

預定修改的程式碼為

passwd.go

passwd_test.go

兩個檔案，請參考 https://github.com/ptt/pttbbs/blob/master/include/pttstruct.h 裡面的 userec 結構將 testcase 裡面的 passwd 檔案的內容解出來並做成測試檔。

實作細節 / Details of Implement

• 基本上實作是參考 #64
• 這個功能需要能夠掃瞄所有看板的所有文章，並列舉出所有屬於某個使用者的留言
• 因目前還未實作推文的功能，所以暫時的做法是透過 ReadBoardArticleFile 讀出文章內容後，判斷內容是否有包含使用者ID，有的話視為此使用者有留言。加上 TODO 之後再另起 issue 修改
• 新增 user_comment_record.go，定義 UserCommentRecord interface，至少實作以下 function
  • CommentOrder() int // 評論順序，從1開始，在 PTT 代表是幾樓的意思
  • CommentTime() time.Time // 評論時間，發出推文的時間
• 在 bbs.go 新增 UserCommentConnector interface，實作以下 function
  • GetUserCommentRecordsPath(userID string) (string, error) // 取得儲放歷史留言快取資料庫的路徑
  • ReadUserCommentRecordFile(name string) ([]UserCommentRecord, error) // 讀取快取資料，並輸出為[]UserCommentRecord
• 在 bbs.go 新增 func (db *DB) GetUserCommentRecordFile(userID string) ([]UserCommentRecord, error)
  • 參考 GetUserArticleRecordFile，先讀取快取資料庫的內容，若無資料則重新從所有看板的所有文章撈取。因目前沒有 comment_order 與 comment_time 的資料，可先回傳 empty value，再標記 TODO

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 一週, 到 5/17
• 實作時間： 一週, 到 5/24
• 確認時間： 一週, 到 5/31

相關文件 / Documents

• #64
• API文件

發生了什麼事？ / The Problem

• 在 windows 上 0.3 版跑 go build 會 fail
  如何重現 / To Reproduce
• go build
  預期的行為 / Expected behavior
  build success

螢幕截圖 / Screenshots

PS C:\Users\Tim.chen\Documents\GolangProjects\go-bbs\pttbbs> go build
# github.com/Ptt-official-app/go-bbs/cache
..\cache\mmap.go:54:12: undefined: openMmap
..\cache\mmap.go:75:9: undefined: closeMmap
..\cache\systemvshm.go:27:38: undefined: ShmidDs
..\cache\systemvshm.go:58:9: undefined: ShmidDs
..\cache\systemvshm_unix.go:9:16: undefined: unix.Syscall
..\cache\systemvshm_unix.go:9:32: undefined: unix.SYS_SHMGET
..\cache\systemvshm_unix.go:17:16: undefined: unix.Syscall
..\cache\systemvshm_unix.go:17:32: undefined: unix.SYS_SHMAT
..\cache\systemvshm_unix.go:27:16: undefined: unix.Syscall
..\cache\systemvshm_unix.go:36:38: undefined: ShmidDs
..\cache\systemvshm_unix.go:27:16: too many errors

開發環境 / Environment

• OS: windows 10
• Golang Version: 1.16
• Package Version: 0.3

目前 PTT 的支援進度比較有進度了，不過發現檔案後綴系統版本的做法會讓命名空間比較混亂，不同站台的Username或是IP長度定義可能會有不同，目前想法是參考其他人的類似專案把它變成用資料夾的形式分開

例如

/
| /pttbbs
| /dreamBBS
| /formosaBBS

https://github.com/audreyt/ournet-bbs/tree/master/lib/OurNet/BBS/Cola

這樣，那實際上根目錄的地方去設計整體的介面，感覺上應該會像是 Golang 的 database/sql 的設計模式。

原本作法的問題 / Solved Problem

• 目前在命名上有幾個golint會跳警告如下
  • ALL_CAPS命名, Ex: PTT_BRD_POSTMASK
  • JSON, Ex: favJson
  • UI, Ex: PosOfPttPasswdPagerUiType
  • Error命名, Ex: InvalidFavTypeError
  • 不一致的receiver命名

  // 前面用b
  func (b *BoardHeader) BoardID() string { return b.BrdName }
  // 後面用r
  func (r *BoardHeader) MarshalBinary() ([]byte, error)

• 一些語法可以更好
  • idx += 1 -> idx++
  • 移除unreachable code

實作細節 / Details of Implement
按照go lint建議改，這應該跟 #52 一樣問題。其中ALL_CAPS命名個人覺得有討論空間，畢竟原始的code是C

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 一週
• 實作時間： 一週
• 確認時間： 一週

相關文件 / Documents
Follow golint

另外是我已經開始著手更改了，麻煩assign給我，謝謝

實作細節 / Details of Implement

• 缺少 PopularArticleRecord 介面，應有以下 method:
  • BoardId() string

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間： 一週
• 實作時間： 一週
• 確認時間： 一週

相關文件 / Documents
PTT後端系統協定

如果不知道要做什麼的話，可以在 看板 找到 TODO
如果還是不知道的話，可以在這篇下面留言，害羞的話可以私訊 Pichu ， 在 join.g0v.tw 可以找到 pichuchen。

如標題，目前在送 PR 的時候基本上都是送往 Master Branch

初期可以這樣做，後期可能為了穩定度和開發方便可能需要分Branch

基本上有兩個方向，一個是另外開Develop Branch，另外一個則是另外開 Release Branch，相關的討論再請大家討論。

實作細節 / Details of Implement

• 目前 BBS 並沒有所謂個人看板的歷史文章，但是可以新增這個功能。
• 歷史文章資料庫應該是一個快取資料庫，他的資料庫檔案應該是隨時可以被刪除的。
• 這個功能需要能夠掃描目前所有看板的所有文章，列舉出屬於某個作者的文章
• 接著把文章列表以某種資料型態儲存在使用者的家目錄底下，檔名可能會叫做 .history_articles
• 資料檔格式目前尚未訂定，有可能是預先保留好長度的 TLV 格式、Protobuf 或者是以 sqlite 檔案實作

目前會需要儲存的欄位如下：

• 文章 ID
• 看板 ID

期程 / Schedule

• 討論時間：一週，到 3/14
• 實作時間：一週，到 3/21
• 確認時間：一週，到 3/28

相關文件 / Documents

發生了什麼事？ / The Problem

curl http://localhost:8081/v1/users/foobar/favorites
但是foobar沒有我的最愛

如何重現 / To Reproduce

1. 選一個沒有我的最愛的帳號, eg: foobar

2. 然後呼叫 curl http://localhost:8081/v1/users/foobar/favorites

3. 然後產生runtime error，但是主程式不會死掉

預期的行為 / Expected behavior

主程式可以handle exception而不會導致runtime error

螢幕截圖 / Screenshots

這個回應看起來合理
runtime error:

created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2969 +0x36c

開發環境 / Environment

Ubuntu 16.04, test with curl

實作細節 / Details of Implement

• 在 bbs.go 新增 WriteArticleConnector interface，此 interface 要實作以下二個函式
  • NewArticleRecord(args map[string]interface{}) (ArticleRecord, error)
  • AddArticleRecordFileRecord(name string, article ArticleRecord) error
• 在 pttbbs 套件新增 pttbbs_write_article_connector.go
  • NewArticleRecord(args map[string]interface{}) (ArticleRecord, error)
    • 產生並建立 fileName，對應到 setbpath 與 stampfile，命名規則可參考 stampfile 的 底層函式 ，並要確保檔名唯一性
    • 寫入文章內容，要一併寫入作者、看板、標題、時間。參考 syspost.c
    • 回傳 FileHeader struct，需設定 fileName、date、title、owner
  • AddArticleRecordFileRecord(name string, article ArticleRecord) error
    • 將 FileHeader 寫入 name 指定的路徑，注意要加上 file lock，參考append_record

待確認：setbtotal 要在哪邊呼叫

期程 / Schedule

• 討論時間： [e.g. 一週, 到 5/12]
• 實作時間： [e.g. 一週, 到 5/19]
• 確認時間： [e.g. 一週, 到 5/26]

相關文件 / Documents
pttbbs 函式註解

實作細節 / Details of Implement
BoardRecord 目前沒提供發文限制的相關資訊，所以需要提供以下 method：

• PostLimitPosts() uint8 // 發文次數
• PostLimitLogins() uint8 // 登入次數
• PostLimitBadPost() uint8 // 劣文次數

另外文件中的[發文限制] (https://docs.google.com/document/d/18DsZOyrlr5BIl2kKxZH7P2QxFLG02xL2SO0PzVHVY3k/edit#) 還有 regtime 註冊時間，如果最後需要也需一併加上
如果想要將資訊塞在新的 interface 的話也可以提出來討論~~

期程 / Schedule

• 討論時間： 一週
• 實作時間： 一週
• 確認時間：一週

目前 PTT 以及多數 BBS 將密碼進行 Hash 的演算法應該是基於 DES 的演算法。
然而這個演算法並沒辦法使用 DES 直接實作。

雖然原本的 C 程式碼裡面有 fcrypt 可以用，不過如果直接靜態編譯進來可能未來會有版權問題。
替代的方案是使用作業系統中可能原本就有的 crypt 函式，在現代電腦上效能可能差不多了。

另外的問題是無論是 fcrypt 或者是 crypt 都有回傳靜態記憶體位置的問題，網路上有看到用純 Golang 實作的版本，也有套件化，所以搞不好用該版本會更好？

原本作法的問題 / Solved Problem

• 目前在讀struct的時候會手算field位置，而原本設計的struct會有padding的動作。在不同go-bbs下有不同的PosOf表示法。例如：
  • pttbbs/passwd.go中，是前面Pos + padding + 欄位長度
  • pttbbs/board.go裡，是padding + 前面Pos + 欄位長度
• 目前在讀寫struct時命名並沒有一致，例如可能是MarshalBinary或是MarshalToByte，希望能調整成一致。

實作細節 / Details of Implement

• 看能不能將所有struct的Pos重新調整成padding + 前一個Pos + 前一個欄位長度，其中欄位長度如果原始型別是字串會希望有對應的const
• 將struct轉binary統一稱作MarshalBinary，因為在fav.go中有用到BinaryMarshaler介面；反之，將binary轉struct改作Unmarshal + struct名
• 趁這個機會重新檢視讀寫struct有沒有不一致的byte讀寫長度

改成padding + Pos + 欄位長度理由是雖然可能與現實順序不一樣，但這樣可以一眼辨別哪些是欄位長度及padding，方便閱讀及debug。

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間：兩周
• 實作時間：兩周
• 確認時間：兩周

相關文件 / Documents
pttstruct.h

實作細節 / Details of Implement

• 參考NewBoardHeaderWithByte以及pttbbs/passwd.go作法對資料做序列化。
• 對應測試

期程 / Schedule
(希望這個任務大概什麼時候做完，如果會卡到其他地方的功能也請在這邊提出。)

• 討論時間：一週
• 實作時間：一週
• 確認時間：一週

相關文件 / Documents
pttstruct.h