# SE HW2 Meeting Minutes
會議記錄:
[link](https://1drv.ms/w/c/00fe1b05944401a4/EbLVNcL1ZF5MvWNraUYDlWQBjUeAmPG6tnqbciDM-79EcQ?e=M6oFXD)
出席:
時間:2024/3/14 23:00
地點:Discord
(截圖)

討論事項:
part 1
分組
決定組內deadline

part 2
簡介、功能發想與列舉
寫task的細節與選擇實作工具
條列task card
分工

---

## Part1
division:
李傳中&余明璠
簡弘哲&楊瑞凱
盧思樺&李福昌

### deadline 2024/04/03

---

## Part2 社群網站平台開發
~~需要有人幫忙開OpenProject畫圖~~
### 討論事項:
1. 功能、簡介
- 簡介(目標、客群、需求)
可以上傳文字、圖片、語音
青少年
分享、排解寂寞

- 功能
- 文字
- 追蹤帳號
- 自介排版
- 登入登出

2. 要完成的task
- 發文
前端：顯示發文內容
後端：對這個人的table多建一個文章的table到DB中，並且讓他可以被查找
- 追蹤帳號
前端：在刷新的時候，送一次request來看追蹤的人是否有新的貼文
後端：在收到要求後，到DB查找貼文
- 自介排版(額外)
前端(JS)：提供模板(或自訂格式)給使用者選擇
後端：從DB抓取個人資料給前端
- 登入登出(額外)
call 3rd-party API(e.g. Google API)
- 留言
前端：送出留言request到後端，等後端更改完畢貼文，顯示給使用者看
後端：對這篇貼文查找他的table，並且對這個貼文table建一個留言的table，寫入留言內容，最後送修改完成的資料到前端
- 轉發
前端：送出轉發request到後端，等後端更改完畢貼文，顯示給使用者看
後端：對這篇貼文查找他的table，並且更改貼文的table，最後送修改完成的資料到前端
- 按讚
前端：送出按讚request到後端，等後端更改完畢數值，顯示給使用者看
後端：對這篇貼文查找他的table，並且更改貼文的table，最後送修改完成的資料到前端
- 搜尋
前端(JS)：顯示搜尋結果
後端：從DB抓取個人資料、發文內容、tag敘述給前端

- 好友
前端：顯示好友列表，這個列表會將資料庫中的用戶的好友table以視覺的方式顯示出來
後端：針對這個人的table建好友的table(或查找)，直接對好友的table修改，最終將資料傳給前端

- 聊天功能
前端:頻繁向後端要資料，並且在收到新訊息後顯示對方送過來的訊息
後端:使用firebase，即時更改DB內容

- 廣告投放(額外)
前端：google API
- tag(額外)
前端：可以在發文的時候打上tag，送request給後端
後端：在建立資料庫的時候，特別為了這種tag建立一個table
- 推薦貼文(額外)
數據收集與存儲
用戶數據：收集用戶的基本信息、瀏覽歷史、互動歷史（如點讚、評論和分享）等。
內容數據：存儲貼文的詳細信息，如發布時間、內容類型、標籤等。
互動數據：記錄用戶與貼文之間的互動數據，包括瀏覽、點讚、評論和分享等。MongoDB可以存儲這些非結構化數據，並通過其靈活的文檔模型來適應不同類型的數據。
特徵提取
用戶特徵：從用戶數據中提取特徵，如興趣標籤、活躍時間段等。
內容特徵：從貼文數據中提取特徵，如內容類別、使用的關鍵詞、相關標籤等。
構建推薦模型
根據收集到的數據和提取的特徵，可以採用以下幾種推薦算法：
基於內容的推薦：分析用戶過去喜歡的內容特徵，推薦相似特徵的貼文。
協同過濾：利用用戶之間的相似性或內容之間的相似性來進行推薦。
混合推薦：結合多種推薦方法來提高推薦的準確性和多樣性。
實現推薦邏輯
在MongoDB中，可以通過聚合管道等功能來實現複雜的查詢和數據處理，以支持推薦邏輯的實現。
為每個用戶生成推薦列表：根據推薦模型，為每個用戶生成一個推薦貼文的列表。動態更新推薦：根據用戶的最新互動數據定期更新推薦列表，以保持推薦內容的新鮮度和相關性。
推薦結果展示
個性化展示：在用戶的推薦feed中展示個性化的推薦貼文。
評估反饋：通過監控用戶對推薦內容的互動反應（如瀏覽、點讚、評論等），評估推薦系統的性能，並作為未來改進推薦算法的依據。
- 列表(額外)
把想特別關注的人加到一個列表中，點進列表只會看到這些人的貼文。例如你總共追蹤[a,b,c,d,e]5人，但只想特別關注[a,b,c]的話，就可以將[a,b,c]加進列表，列表中只會出現[a,b,c]的貼文、[d,e]的貼文不會出現。

3. Scrumban board 以及 task card
總期限：六個月
第三part交給OSS tools的人操作
- Task card 至少要包含 task name、負責人以及期限。
- 發文[、負責人、期限]

- 追蹤帳號

- 自介排版(額外)

- 登入登出(額外)

- 留言

- 轉發

- 按讚

- 搜尋

- 好友

- 聊天功能

- 廣告投放(額外)

- tag(額外)

- 推薦貼文(額外)

- 列表(額外)

- Scrumban board 至少要有 Todo、Work In Progress 以及 Done 三個欄位

4. OSS tools的調查
目前我有看到[OpenProject](https://www.openproject.org/)
最終決定用Hive，選擇Hive的原因就從HW1複製過來

5. 生成式AI對SDLC的影響
感覺這個可以各自寫心得

### Part2 division
1. ~~找OSS tools的調查比較(跟上次的很像)~~
已經處理好了
3. 李福昌：用OSS tools來畫圖(處理Scrumban board 以及 task card的分配問題)
4. 盧思樺：整理會議紀錄(含排版)
5. 楊瑞凱、簡弘哲、李傳中、余明璠：寫「生成式AI對SDLC的影響」

## 參考資料
1. Scrumban example
2. SDLC是甚麼
[SDLC(軟體開發生命週期)](https://aws.amazon.com/tw/what-is/sdlc/)

## Part 2 AI心得
//自此開始撰寫
簡弘哲:
測試:
在撰寫測試資料的時候，開發人員常常需要集思廣益想出使用者可能會操作的步驟以及一些奇怪、難以想到的例外測資。又或者是不同的專案間，其測試的程式碼常常會有一些地方重複，此時就可以利用生成式AI來幫你完成任務，就不用自己維護一個測試用的模板，也省下了寫test code的時間與精力。在使用時也需注意生成出來的code是否為自己所需?抑或是它有沒有測試到想要的功能等...

開發:
當我們在開發一個專案時，常常會需要接觸新的工具、框架以及API的使用方式，在沒有GPT的時代，我們需要閱讀官方網站的教材、利用Stackoverflow去解決一些沒有見過的bug、還有閱讀冗長的API documentation後才能摸索出開始的方向。但自從GPT誕生之後，這些事情都可以只用一句話讓GPT幫你生成出來，且生成出的code幾乎可以馬上使用到專案裡，不僅方便，也省下了許多查詢資料與閱讀文件的時間，讓開發者能更專心於軟體的大架構上。

李傳中：
需求/分析階段：
生成式AI可以幫助軟體開發人員更準確地理解客戶的需求。在需求收集方面，生成式AI能夠分析客戶的需求、用戶回饋或相關資料，從中了解關鍵信息並生成清晰的需求檔案。它可以自動提取關鍵字、整理用戶意見、彙總常見問題，來幫助開發團隊更快速地獲取準確的需求信息。在需求描述方面，當建立需求檔案時，生成式AI可以協助開發團隊生成具體的需求描述。它可以根據相似案例、最佳實踐或領域知識來建議適當的需求描述，減少模糊不清或含糊的表述。

設計階段：
生成式AI可以根據開發人員提供的指導和條件，自動生成設計檔案的初始版本。這些檔案可以包括系統結構圖、流程圖、數據模型等，來幫助開發人員更快速地建立起整體設計框架。並且生成式AI可以通過分析大量的設計方案和相關資料，在成本，性能，客製化等方面提出優化建議或改進方案。