第 5 次 Stand-up Meeting 記錄

[zxcvbnm7548]

Tips : 避免在會議中討論問題，但可以討論『解決問題的時間』，因為站立會議的目的是交換訊息同步彼此狀態，而不是要解決問題，且不需要做筆記或其他事情，要專心聆聽與會者。

1. 昨天做了什麼事情

• 修正履歷、CRUD練習、複習會員登入系統、為專題做準備

2. 昨天做的事情有遇到什麼問題

• 上課內容許多地方不熟悉，Rails須多練習

3. 今天預計處理哪些問題

• 複習線上課程、登入系統複習、鐵人賽事前準備、專題發想

專題發想：
-優先以旅遊規劃網站方向擬定計畫
-懶人包為主做完再擴充處理部落格
-視覺圖片為主、文字為輔

然後最近很多人感冒要多注意身體，大家加油

Date : 2022 / 8 / 5 下午
Time : ~ 20 mins

[noracami]

1. 昨天交出履歷、準備部落格文章(前三篇預計寫 上傳部落格、計算機練習with vanilla JS、昨天提到的 Memorization)

2. 遇到問題 : 履歷很難寫、部落格文章寫太慢

3. 週一前完成文章、練習的小專案推上線 (必要功能 : 會員註冊登入發文評論登出)

4. 專案想法 :
   我在前幾天逛 side project 社團看到的 關於做 SIDE PROJECTS：改善點子的7個小技巧
   其中的 Amazon Working Backwards https://rickhw.github.io/2019/04/05/About/Working-Backwards/
   當中可以想成：快轉到發表日，我們要如何介紹我們的作品，有什麼功能，可以如何使用
   如龍哥所講我們不必去找出沒人做過的事
   但這種由結果開始出發的思考方式，應該可以更容易聚焦討論
   ( 其實我沒有旅遊的習慣，不太能想像要什麼功能 XD)
   回到 懶人旅遊 的目標上的話
   我覺得主要挑戰會是
   生成推薦行程的時間 → 可以在每次使用者選擇條件後，於背景先行搜尋，並依之後選擇逐步修剪
   推薦標的資料取得 → 要預先爬梳各網站資料放在本地資料庫、或是即時以外部API取得資料、或並行
   如何推薦 → 預先由人工想出並寫好各種推薦模式 → 自動化的話可能就是機器學習的領域

而 自動生成行程 跟 使用者自行規劃行程 我認為底層是一樣的事情，即若前者開發完成了，後者也應該可以操作
有差別的會是要考慮 使用者 與 介面 之間的互動 (UI/UX)
→→總結 : 題目我沒意見都可以做 🤣