第12組現場編程

分工及貢獻

組內有三人去考證了，只剩下6人

組員	分工	貢獻比例
王永福	先後端，爬蟲，博客主體	30%
孫承愷	建模，算法設計，統籌	18%
邱暢傑	爬蟲	15%
徐祖豪	前端數據可視化	13%
張凌昕	前端數據可視化，部分博客	11%
丁樞桐	數據可視化，聚類算法	13%

GitHub提交日誌

GitHub

程序運行截圖

爬蟲

服務器端

部分數據

程序運行環境

爬蟲

• Anaconda 3
• Python 3.7
• 涉及的包比較多，這裏不一一列出，稍後我會將Anaconda環境導出到environment.yml並上傳至GitHub，你們能夠去看

服務器端

• Python
• Flask
• Flask-CORS

前端頁面

• 建議Chrome 76或以上，其餘沒試過

前端構建

• Node.js 10
• Yarn包管理器
• Vue-cli 3
• 其餘依賴包在package.json中有，能夠yarn install直接安裝
• 另外須要可用的高德地圖的Key

GUI界面

基礎功能實現

數據爬取

根據題目要求，咱們須要爬取相關數據，根據對題目的分析，以及對美團和大衆點評、高德地圖的前期調研，咱們認爲能夠將前三個評測目標劃爲一組，數據一塊兒爬取，由於它們須要的字段比較類似（能夠見上面的數據截圖）；第四個目標咱們在美團上找不到數據，大衆點評難以爬取，所以轉向高德POI搜索爬取。

美團的數據主要從手機版網頁爬取（PC版網頁沒有經緯度且須要計算token），使用Chrome Developer Tools模擬手機訪問網頁抓取數據進行分析，發現Cookie只須要設置ci和uuid便可爬取，其餘仿照抓取到的請求設置。

爬取時須要注意美團反爬技術很是硬，須要不斷更換IP和ID，不然沒一會就會白給，早上咱們已經白給好屢次了。咱們的爬蟲理論上具有獲取全部數據的能力，但因爲瘋狂白給，最後只獲取了少許數據用於製做demo。

另外高德API雖然不反爬，可是API有調用配額限制，爬多了也會白給。建議多準備幾個Key

數據處理

獲取到數據後，須要對數據進行預處理以進行展現，對於不一樣的評測目標，採起不一樣的方法

測評出福州最受歡迎的商圈

將美團爬取到的數據按銷量降序排列，按商圈聚類，而後根據全局排名，分階梯對每個商鋪賦權，再將商圈內的商鋪權值求和，排序，獲得最受歡迎的商圈。

分別測評出福州人均消費50如下，50-100、100-200、200以上最佳（性價比最高）的前五家美食餐廳（參考評價與價格）

這個比較簡單，直接按人均消費所屬階層聚類，組內排序，第一關鍵字評分降序，第二關鍵字人均價格升序。

測評出福州最佳美食彙集地

兩條路：

1. 對每家商鋪賦權並按經緯度聚類，生成聚類圖，因爲算法比較複雜且數據序列化困難，故Web端不採用此方法生成的數據，此方法生成的圖可用clustering中的代碼生成
2. 將原始數據提取經緯度直接在地圖上打熱力圖。此方法較爲簡單，Web前端採用此方法。理論上雖有失偏頗，可是因爲咱們爬取的原始數據按銷量和評分降序，所以爬到的都是排名靠前的，說是最佳美食彙集地應該也沒什麼問題吧(逃

測評出福州服飾類綜合評分最高的商圈

從高德地圖爬取的數據參照第一個評測目標類似的方法處理

數據可視化

主要採用了Vue框架來管理視圖路由，AntV進行可視化展現，展現效果可見截圖。地圖部分採用了高德地圖JS SDK

服務器端

理論上不須要這部分，可是沒用網絡感受很low，爲了高級一點，也爲了可擴展性，用Flask加了個服務端，動態提供數據

UI

跟數據可視化一塊兒作了，頁面上的東西基本都是有交互的，餅圖有Tooltip，點擊下面的圖例能夠取消顯示某一類，作到部分展現。地圖能夠旋轉，改變俯仰角，熱力圖是3D的

關於功能的其餘想法

高級可視化

能夠在可視化上作一些炫酷或者高級的交互，好比說:

• 像SyncFusion的Essential JS 2 的可視化組件Chart的Drilldown的多級餅圖
• 熱力圖交互，如點擊彈出推薦列表
• 根據實時數據的動態視圖，或相似延時攝影的視圖變遷

數據分析

若是能爬到大量數據

• 多平臺交叉驗證
• 評論情感分析
• 時間序列分析

腦洞

作一整個推薦平臺，同時收集用戶數據

遇到的困難及解決方法

王永福

困難

1. 數據來源反爬機制過強
2. 數據可視化不熟練，前端不熟練，Python不熟練
3. 人少

解決方法

1. 找代理池，找開源項目
2. 撿起來學
3. 一人頂倆

丁樞桐

困難

1. 對網絡爬蟲相關的類庫不熟悉，對於相關網站特別是反爬蟲的網站難以獲取有效信息
2. 對用web前端進行數據可視化的方法不熟悉，只能當場找模板現學

解決方法

1. 現場學習
2. 現場學習

張凌昕

困難

在此次現場編程中我主要負責的是前端這一塊，在寫餅圖的時候，我剛剛開始不是很懂G2，而且在挑選餅圖形式的時候，比較不知道挑選哪一個比較好

解決方法

多看一些模板，而且有的模板上會給一些註釋，讓我更瞭解G2的一些使用方法，用起來更容易。在餅狀圖格式的挑選上，先是選了一個不是太好看的，後來又選了一個比較合適的。

徐祖豪

困難

1. 有幾個組員要去考教資，現場編程只有六我的
2. 前端技術過久沒複習，不太熟悉

解決方法

1. 好在提早知道有幾個同窗會缺席，因此事先分配了任務，進展還算順利
2. 現場學習

孫承愷

困難

短期的分析和設計很使人煩躁，api接口沒開放增長工做量

解決方法

化繁爲簡

邱暢傑

困難

數據難以爬取，token算法未知

解決方法

對於美團爬取手機版頁面，採用代理池
對於大衆點評，放棄

馬後炮

• 徐祖豪：若是本身能再早幾天複習，準備充足一點，項目的進展會更順利
• 孫承愷：若是這門課不是必修，那麼我必定不會選
• 丁樞桐：若是以前我有系統地學習如何使用python進行網絡爬蟲，那麼此次就會很快地爲團隊獲取有效數據。而不會致使前面一直在爲數據苦惱
• 丁樞桐：若是以前我有系統地學習web前端的開發，那麼此次就能夠寫出更棒的UI界面
• 王永福：若是我沒這麼菜，此次能夠完成得更好(若是這門課不是必修，那麼我必定不會選)
• 邱暢傑：若是黑夜給了我黑色的眼睛,那麼我將用它來尋找光明

PSP表格

PSP	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
·Planning	計劃	5	5
·Estimate	估計這個任務須要多少時間	5	5
·Development	開發	60	65
·Analysis	需求分析 (包括學習新技術)	10	15
·Design Spec	生成設計文檔	5	10
·Design Review	設計複審	5	5
·Coding Standard	代碼規範(爲開發制定合適的規範)	5	5
·Design	具體設計	20	20
· Coding	具體編碼	40	45
·Code Review	代碼複審	5	5
· Test	測試（自我測試，修改代碼，提交修改）	3	2
·Reporting	報告	10	8
· Test Repor	測試報告	3	3
·Size Measurement	計算工做量	2	2
·Postmortem & Process Improvement Plan	過後總結, 並提出過程改進計劃	10	8
.	合計	163	195

學習進度表

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
1	138	138	30	30	學習了前端的數據可視化