算法:莊錫榮,林鑫燦
UI:許煌標,蔡峯,林曉鋒,陳珊珊,侯雅倩,吳珂雨
博客:陳珊珊,王鍾賢html
python3前端
搜索福州商圈各方面的排行,點擊不一樣按鈕能夠展現相應結果
有一個頁面,上面有5個按紐分別對應5個評測目標
按鈕1:福州最受歡迎的商圈,根據人氣排行,顯示排行第一的商圈
按鈕2:福州最佳美食餐廳,根據人均消費分類,分別列舉出人均消費50如下,50-100,100-200,200以上的性價比前5的餐廳
按鈕3:福州最佳美食彙集地,根據評價,顯示好評最多的商圈
按鈕4:福州服飾類綜合評分最高的商圈,根據服飾類綜合評分,顯示綜合評分最高的商圈python
能夠有一個踩雷排行榜,告訴顧客哪些店性價比不是那麼的高,需慎重考慮。
就目前的形勢來看,網紅店的人氣仍是很高,所以能夠有一個功能搜索出不值得去的網紅店。
能夠有一個「有趣的分析」功能,讓顧客更好地瞭解某些地方的狀況。
能夠有個搜索出值得去參觀的地方的功能,讓用戶更好地瞭解福州。
能夠有一個對某一個地方有不一樣路線的距離排行功能,讓用戶能夠選擇適合本身的路徑。mysql
遇到的困難:
遇到挺多困難的,第一點就是對組員工做的很差分配,由於安排的問題不少人沒有發揮出特長:第二點就是關於爬蟲的知識瞭解的很少,因爲早上多人同時用校園網使得大衆點評爬蟲對本ip失效,使工做停滯了很長一段時間。
解決方法:
解決方法就是多聽聽組員想法,多討論發表意見;因爲爬蟲沒有使用代理池,最後轉向反爬措施沒那麼強的美團爬取另外一部分數據。git
遇到的困難:
對爬蟲不夠熟悉,準備工做作的不充分,api學的太慢,花了大把時間在熟悉學習各類爬蟲工具上,在實際編程過程當中遇到了問題,最致命的就是有個關鍵模塊一直接不上api,因而本身就在那裏尬住了
解決辦法:
通過一番(無用的)嘗試,無可奈何轉了其餘api,效果雖然不如預期,但還算看得過去,勉強解決了當務之急。github
遇到的困難:
小組:
①隊內分工的協調問題有點大,沒有成功地發揮每一個人的能力特色,不僅是發揮不出來,甚至忙的人特別忙,閒的人特別閒。
②整體戰略部署存在失誤,實戰前一天晚上的調api過程沒能重現,存在着沒有預想到的麻煩
③因爲隊伍內核心代碼成員的比賽,缺席了此次的編程實戰,給咱們帶來了不少困擾
④整個團隊呈現出工做效率低的狀態,最具體就是表如今性價比的計算都存在着誤差,致使不少導出的餐廳並非性價比高的餐廳。
我的:
①和分隊隊友沒有溝通好,我的的技術優點沒有獲得很好的發揮。
②發現問題後提出解決問題的時間過遲,沒有很好地串聯起團隊。
解決辦法:
綜上的全部困難,實際上都是咱們團隊和我自己過後總結出來的,問題實際上在當時並無很好解決。團隊的話,我認爲應該在實戰題目出來以前作好準備,設想出可能會遇到地困難,在出題以後的十分鐘以內有效地討論出分工再去付出實際工做。我的的話,問題仍是比較大的,作好溝通工做和能力提升。
有趣的分析:
由於我是比較喜歡外出的人,在今天的編程實戰中,我發現大衆點評的一些數據不太符合個人認知。首先是在最受歡迎商圈這裏我看到了茶亭世貿的人氣值是高於寶龍萬象的,實際上根據我一週幾乎五六次外出的經驗來看,寶龍萬象的人氣值在觀測中是要高於茶亭世貿的,多是由於茶亭世貿的消費水平比較符合大衆的平均水平,而且在店鋪數上是領先於其餘商圈的,因此人氣值在評測中會更高一些。
雷區頻出。其次我在低端消費排行榜中看到了「賽百味」和「骨之味」,這裏的出現讓我很吃驚,由於這是快餐級別的餐飲,因此必定要作得棒纔可以贏得好的口碑,我認爲這兩個餐廳是雷區,不建議你們根據這個排行榜去拔草。再舉一個高端餐廳的例子,「埖絳日式花園餐廳」地理位置比較偏,是由於長期推出霸王餐的活動提升分數,再加上其獨特的環境優點才贏得了榜單前列,但在我看來並不算是一個性價比高的餐廳。
實際上在榜單裏看到許多優質餐廳,也看到許多人爲「優質餐廳」,舉個例子,寶龍的「肉祭」和「鳥匠」的確是優質餐廳,已經連續兩年入選大衆點評的必吃榜。然而像「韓一品」這樣點評數少的五星餐廳很明顯就是人爲刷的,再加上美團的推薦費用是一年一萬二,因此這樣的店鋪在繳納費用後很容易就可以上分了,可是實際上只可以短時間高分,由於時間仍是可以證實它的優劣。
最後想說的是,實際上每一個城市幾乎都有必吃榜,這個榜單的風評仍是十分不錯的,至少在福州這兩三年的必吃榜中的餐廳都具備很大的影響力。可是這個必吃榜也包括很大一部分的網紅餐廳,由於其獨特的風格贏得了必吃榜的排名。因此在一些地方必吃榜中的餐廳並非當地人會常去的地方,若是你想吃到地道的當地風味,仍是要根據本身的需求找當地人推薦,大衆點評或許能給你很好的輔助參考價值,可是並非你選擇的絕對依據。算法
遇到的困難:
抓包過程一直出錯
解決辦法:
原來是沒下載mysql,一直傻傻的覺得有microsoftsql就行了,手動打數據瞭解一下...sql
遇到的困難:
因爲早上暫無成果而博客不少須要已經作好的頁面截圖,於是沒事嘛可寫的。
解決辦法:
寫能先寫的,並學習新技術。數據庫
遇到的困難:
主要仍是時間問題,咱們團隊兩個大佬去比賽了,自己少了核心點以後力不從心,在效率上也出現了問題
解決辦法:
最後仍是選擇了多作點時間,交個好歹能看的上去,不在意遲交扣不扣分了。編程
遇到的困難:
對爬蟲這項技術不是很瞭解,都不會用它
解決辦法:
在網站上查找一些資料,而後嘗試着運行,試圖弄懂...
遇到的困難:
沒有困難,甚至在一段時間內無所事事,完成份內的事情之後看了看前端那邊有沒有須要幫忙的,可是能作的不多,幫忙作了幾個按鈕之後又不知道本身能作些什麼了,他們也處於迷茫狀態。
解決辦法:
實際上問題並無獲得解決,反而是到最後爲了完成任務無視了質量。
遇到的困難:
此次現場編程只是負責搜一些資料,寫一些數據,沒有遇到太多的困難。
解決辦法:
找不到合適的資料時會你們一塊兒討論,選出最符合題目要求的數據。
莊錫榮:(小組任務完成的不太好,組長要要首先反省。從後往前看,咱們或許有更好的解決方案。能夠採用更多人掌握的、更簡易的html開發前端而不是使用pyqt而後把前端多個頁面的任務堆到一兩我的身上,致使工做量嚴重不均衡,不少人無事可作,最後由一兩我的完成出來的效果也並非很好。)若是再給我一次重開的機會,我會把「重擔」提早多天明確地壓到每個人身上,而不是到最後由兩三我的承擔大部分的coding壓力。
林鑫燦:若是本身可以自覺一點,早點接觸api,那麼我就沒必要在凌晨四點還在苦苦思索api的正確打開方式,如今就是後悔,十分後悔。
侯雅倩:若是能早點了解一下抓包過程,那麼就不會現場學還學不會了。
許煌標:若是咱們大哥和傑哥都在,那麼咱們會讓大家知道什麼是恐怖!
王鍾賢:若是我能學習好python,那麼我就能作更有價值的工做了!
陳珊珊:若是我能好好地利用時間早點去學習爬蟲,那麼我就幫上更多的忙了!
吳珂雨:(其實此次做業沒有將你們的做用都發揮得很好,有的工做有些冗餘,有的工做又缺人)若是可以更加合理的分工,進行足夠的溝通,那麼團隊效率會增長許多。
蔡峯:若是今天早上大哥金傑都在的話,那麼此次做業不過是一盤供他們開胃的餐前菜!
林曉鋒:若是能學會更多的知識,有更好的技術水平,那麼能夠幫助隊友更快地實現。
PSP2.1 | Personal Software Process Stages |
預估耗時 (分鐘) |
實際耗時 (分鐘) |
---|---|---|---|
Planning | 計劃 | 20 | 20 |
· Estimate | · 估計這個任務 須要多少時間 |
20 | 20 |
Development | 開發 | 100 | 120 |
· Analysis | · 需求分析 (包括學習新技術) |
50 | 50 |
· Design Spec | · 生成設計文檔 | 20 | 20 |
· Design Review | · 設計複審 | 10 | 10 |
· Coding Standard | · 代碼規範 (爲目前的開發 制定合適的規範) |
10 | 10 |
· Design | · 具體設計 | 5 | 5 |
· Coding | · 具體編碼 | 5 | 15 |
· Code Review | · 代碼複審 | 0 | 0 |
· Test | · 測試(自我測試, 修改代碼,提交修改) |
0 | 0 |
Reporting | 報告 | 10 | 10 |
· Test Repor | · 測試報告 | 5 | 5 |
· Size Measurement | · 計算工做量 | 0 | 0 |
· Postmortem & Process Improvement Plan |
· 過後總結, 並提出過程改進計劃 |
5 | 5 |
· 合計 | 130 | 140 |
第N小時 | 新增代碼(行) | 累計代碼(行) | 本週學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
---|---|---|---|---|---|
1 | 50 | 50 | 1 | 1 | 瞭解基本需求,開始寫界面 |
2 | 100 | 150 | 2 | 2 | api出現問題,從新構思思路 |
3 | 50 | 200 | 3 | 3 | 衝! 沒有回頭路衝 |
… | … | … | … | … | … |