#軟體工程師面試 #文長慎入
面試問題好像一直以來都是一個很多人關切的環節,在各大版上也一直有人會詢問。因為之前有幫公司面試一些人,還有加上從朋友那邊搜刮來的經驗,概括分享一下。
這邊感覺可以分成幾個部分:
1. 面試的題目是否都是演算法相關題目?
2. 是為什麼實際工作內容通常都和面試考的沒有相關?
3. 我現在學的東西對找工作是否有幫助?
4. 公司招募看的到底是這個人的學經歷,能力,個性,還是什麼,為什麼有些人很感覺很厲害卻一直無法拿到offer?
其實用FB排版不太容易,但因為懶得登入部落格,想說快速地打一打,所以也請各位見諒。
#面試的題目是否都是演算法相關題目
如果是投FANG之類的,Facebook Amazon, Neflix, Google (沒記錯應該是這幾間),反正就是這些有名的大廠,除了Netflix目前沒有遇到認識的聊過,其他都是考演算法沒錯。
當然也不只有會考演算法,根據你申請的職缺,可能也會加考一些其他的東西。
那其公司是怎樣呢?其實還是有很多公司會考演算法相關的,尤其是線上面試。
雖然在疫情下全都是線上,但一般來說,還是會有分兩種,一種是沒有真人的狀況下,就是給你像是HackRank這種網站,你點開可能有六十分鐘讓你做兩題。
做完以後你提交,你也不會知道你的分數跟分析結果之類的,看公司怎麼做設定,而且除了演算法相關題目,也可以設定選擇題之類的。
另一種就是真人面試,通常電腦自動面完以後,你可能會跟真人線上面試,真人也是會給你類似所謂的白板題,就是出一個題目讓你現場解題,然後中間可能有的會要你跟他討論,當然看面試官拉!
比較加分的還是,你編寫的時候可以邊闡述自己的想法,而不是低頭默默寫完,這樣也是有點尷尬。如果你編寫邊闡述的話,或者是少有點互動,也是展現你的溝通能力以及你對於題目的掌握能力,就像是你看到一個很簡單的題目 (2+3)*5 之類的,你可以很有自信的說,喔因為2+3在括弧裡面,所以要先算,然後再乘以5,展現底是真的有理解,而不是就是背題目之類的。
有些公司也可能是給你回家作業,叫你做一個小專案之類的,看你應徵的職缺,可能是叫你做一個UI 或者叫你建一個API 也可能叫你做一整個比較完整的東西出來。如果你是面試架構師的話,可能會叫你建一個架構,或設計一個架構出來。
然後也有的公司(像我們公司)就是需要pair programming 所以在線上面試的階段就是會有,真人跟你一起寫程式這樣。
#為什麼實際工作內容通常都和面試考的沒有相關
這個部分一直以來都是一個難解的謎題。像是Google Facebook這種大公司其實不難理解,畢竟他們是比較類似General 的招募,不是一開始就決定好你就是要去某個Team然後永遠讓你待在那個Team。就他們招募的是他們覺得,有潛力的人才,這樣不管需要做什麼都可以自由移動他們,給他們training就可以變得很好用。加上他們一次招募的數量也是相當龐大,考演算法相關的話,可以快速篩選,也更有機會找到他們需要的人才。
因為像是Facebook或Google這種有自己開發框架,開發技術的公司,他們的確有很多時候需要寫演算法或者系統優化的工作。
那像是普通的中小企業或新創,說真的,其實就是跟風。因為覺得人家Google Facebook都是這樣找到優秀人才,那我們也要依樣畫葫蘆,這樣鐵定也能找到厲害的人。
可是這樣找到的人進去以後,發現公司好像也是不知道在幹嘛,最後可能也會待不下去。所以這個部分,近年來也越來越多公司開始改進,開始思考什麼樣的招募流程最適合自己公司。
像是pair programming也開始成為近年來的一個流行的面試,有的公司並不是真的pair 但就是你要跟他們一起工作,了解他們公司的文化,或者跟他們的工程師進行一些深度討論。或者會問你說,假設給你設計一個系統,你要怎麼做之類的。
當然,面試問題跟流程都是每間公司各有不同,不是說你現在準備一種就萬無一失。所以說最好還是盡可能的,提升自己的基礎能力。
如果真的就是打算以FANG為目標的話,就可以從刷題開始,像是Leetcode, Hackrank, codewars之類的都不錯。之前有看到一篇文章,他刷了幾百題,而且每題刷了三次以上,真的很有毅力。刷題的重點就是在於熟練那些題目,可是也不要硬背,你練習是要練那個速度感。可是該理解的還是要理解。
因為你進公司以後,你還是需要使用那些東西來工作,不是只是為了刷題而刷題,而且面試官可能也會考你變形題之類的,或者問你一些記憶體相關的問題,或者是系統設計的問題,或者單純想知道,你是怎麼想出解法的,所以硬背題目跟答案其實也是不太行。
目前我的了解是,大部分中小型企業或者新創,很多時候你學習新東西的能力是比演算法更重要的,尤其是新創你什麼都要會,假設公司是剛起步的新創,你就要變成公司主要的技術專家,什麼東西不太會也要馬上現學現賣,也不要期望公司可能會給你什麼Training 或者有人給你依靠,可能同事還要依靠你。
中型或者普通大型企業,假設公司已經有產品的話,大部分的時候可能是既有產品維護,除非你剛好很幸運地在新產品開發的Team,這樣就有機會學到很多東西,不然維護的話,很多時候只是在了解產品本身是否有Bug,改善code品質之類,也要看公司是否有想花成本在維護上面。如果公司就是打算一個產品,改一點東西就繼續賣錢,那樣好像也不太需要一直去migrate 或者搞新東西上去。
如果你剛好很幸運在獨角獸新創,那你不但可以學到很多東西,還可以用最新科技,可能還有機會遇到大神帶你。
所以說選公司其實也是有點重要,面試的時候,可以問問他們說,那你平常的daily work是怎麼樣的,公司有沒有走敏捷開發,公司有沒有用雲端,公司一個Team的規模之類,以及公司會不會提供訓練。
#我現在學的東西對找工作是否有幫助
其實這個就要看你的未來三年五年十年規劃。
假設你就是都在寫前端,你也覺得我要寫前端寫一輩子,那好像就可以繼續一直focus在前端。如果你擔心自己會丟飯碗,是不是要學點後端,其實也是可以學,可是學了以後,你打算學得多專精?後端的東西也是會一直更新,一直進步。可能Restful API 也可能不是,DB也有好多種DB, 後端語言也很多種,所以你是想要學個大概,還是是希望,後端也問題的時候,自己可以去看code也看得懂?
前一個專案,公司有一個前端,他就是因為自己做的ticket幾乎都會碰到後端,就乾脆把整個後端也寫一寫,就變成fullstack,雖然他主要還是算前端。但也因為是.NET 所以前端跟後端可能沒有太明顯的分界,至少我相信他本來就會寫.NET了,因為幾乎有一半以上的controller都是他寫的。
如果你是寫react SPA,就是跟後端完全分開,你就只要寫到send http request 那邊的話,那好像也不太需要去了解到後端的架構,就是大概知道後端的endpoint 長什麼樣子就好,他們需要提供的文件就是需要提供。
如果說你是怕以後失業,怕公司可能覺得請全端比較划算,那的確還是多學一點好,反正多學也是投資自己。還能順便展現自己的上進心以及學習能力。
以consultancy來說好了,感覺是什麼都要學,像是公司可能就會說,啊最近我們的客人都要求要會什麼什麼,那你就趕快學一下。當然公司也不是很壞心的就叫你要馬上學會,公司最近也是有開始提供一大堆Training 之類的,還給你錢讓你去考一些證照。
目前我使用的語言主要還是Javascript 和 C#這樣,然後公司有希望我可以好好學學Java。其實也不是不會寫Java,如果有發漏我其他文章的話就知道,其實我最一開始學的時候,第一個語言就是Java。
在台大資訊系統訓練班的時候,我就上了Java和PHP的課程,為自己來英國念研究所做準備,一年的master course也都是Java 跟PHP為主,然後有用了一點Python這樣。可是工作以後就只有使用C#和Javascript 而已,所以說,學校學了也不一定會用到。
很多東西都是工作以後才學的,然後Python是平常自己刷題的時候會用,因為覺得不錯用。
其他的話,我覺得雲端相關的東西滿實用的,像是AWS或Azure 或GCP 有機會的話是可以自己摸摸。我自己是滿幸運的在工作上一直都有用到雲端產品,主要是AWS,前一個專案有用Azure 這樣。
DB的話,就是SQL和NoSQL可以個學一個,應該就滿好用的了,目前最流行的應該就是PostgreSQL和MongoDB 。如果對於Graphic Database有興趣也可以稍微看一下像是Neo4J之類的吧!
前端框架的話,就是React, Angular, Vue.js選一個吧!學會一個以後再去學其他的也不難,這三個我是剛好工作上都有用到,我自己是覺得Vue和React應該是比較好上手的,入門門檻比較低,Angular就一定要寫Typescript.
後端框架的話,看你用什麼語言,Java就學spring boot,
C#就是.NET,JS的話應該是Express,Python就Django,PHP就Laravel 。
Mobile的話我沒有寫過也不知道。
如果是平常想要補充知識的話,可以多念一些像是security 相關的東西,或者是Oauth那類的,也可以看一下架構之類的。像是Microservices, microfrontend, Domain Driven Development 這些概念性的東西。
也可以看一些像是Clean Code相關的書,怎樣重構原本的爛Code或者TDD相關的書。
反正前一篇文章就說了,這個職業就是要一直學,活到老學到老,如果打算做到老的話。
#公司招募看的到底是這個人的什麼
其實每個公司應該都不太相同。有的公司就是要招募他們覺得最聰明的人,所以就是一直問你一些很難的東西。或者就是只要找那種名校出來的人,最好有什麼數學物理奧林匹亞的。
有些公司看的是你的個性,符不符合公司文化,或者同事喜不喜歡你之類的。
有些公司就是很缺人,看你能不能馬上上工之類的。能的話就馬上錄取你之類。但通常那個可能是很雷的缺,例如公司找人找很久都找不到,終於看到一線希望。然後為什麼找不到人,可能是薪水開的偏低,或者公司名聲不好,上Glassdoor就可以查看公司的評價。也可能是職缺本身很雷,例如看起來就是個打雜缺。或者是前人都做不久就離開,所以需要一直找人。
有些公司是看你寫的code 例如看你的code乾不乾淨,可能你寫出來的code都很乾淨,設計也很好,思路也很清晰,他們就會錄取你。
有些公司看的是你有沒有某些特定的經驗,例如公司開那個缺剛好就是要找有AWS經驗的人,所以可能就是會錄取他們覺得AWS經驗比較多的人。或者是剛好想找之前有做過Serverless架構的人,或者是有碰過Kubernetes的人,這個時候真的就是靠經驗了。
也有的公司就是,他們也懶得找人,HR給他們面試的第一個人就會錄取,這個完全靠運氣。這件事情真的發生在我第一間公司的另外一個Team,主管非常不喜歡面試人,也覺得我工作都沒時間還要面試。所以就是隨便問問之類的,然後就跟HR說好。
--------------------------------------
以上就是我目前經歷過以及別人分享給我的經驗。我覺得面試的話,運氣真的也是佔滿大的比例,尤其是遇到像第一間公司那種狀況的。
當然年輕的時候可能會比較急躁,也很擔心自己找不到工作,考量到的還有金錢跟公司名聲,所以學不學得到東西也可能是其次。
選offer的時候,也可能就是可以分析一下,自己想要的到底是什麼,是金錢,是做得開心,還是想要可以做的久(這個也要看公司可以活多久),除了看Glassdoor也可以上網看一下公司財報。
最近的疫情衝擊下,有很多新創或中小企業也開始裁員跟減薪,所以公司平常的財務狀況和經營方針也是很重要的。即使公司可能一直都有收入,也可能因為現金管理問題,導致沒有足夠現金需要裁員。
「java http request」的推薦目錄:
- 關於java http request 在 小吃貨的英國生活日記 Facebook 的最佳貼文
- 關於java http request 在 โปรแกรมเมอร์ไทย Thai programmer Facebook 的最佳解答
- 關於java http request 在 Kewang 的資訊進化論 Facebook 的最讚貼文
- 關於java http request 在 How to send HTTP request in java? [duplicate] - Stack Overflow 的評價
- 關於java http request 在 Java 實作Http-Request - 麻吉卡的部落格 的評價
- 關於java http request 在 Java HttpRequest.body方法代碼示例- 純淨天空 的評價
- 關於java http request 在 SendGrid's Java HTTP Client for calling APIs - GitHub 的評價
- 關於java http request 在 Java HTTP Request Tutorial Part 15 - YouTube 的評價
java http request 在 โปรแกรมเมอร์ไทย Thai programmer Facebook 的最佳解答
+++ access token คืออะไรใน facebook ++++
😋 ปกติ facebook เปิดให้เว็บ (รวมทั้งแอพ) ที่เราเขียนขึ้น
สามารถใช้ระบบ login ของ facebook ได้
ทำให้เว็บนั้นได้สิทธิเข้าถึงข้อมูลส่วนตัวของ user นั้นๆ บน facebook
.
และในหลายเว็บไซต์ เราคงเคยเห็น
ขอแค่มีแอคเคาท์เฟสบุ๊คก็สามารถล็อกอินได้เลย
ไม่ต้องเสียเวลายุ่งยาก กรอกสมัครสมาชิกใหม่แต่อย่างใด
:
โดยในโพสต์นี้จะขออ้างอิง
การใช้ระบบล็อกอิน facebook
ซึ่งเบื้องหลังความสำเร็จนั้น facebook จะแจก access token
เพื่อให้เว็บใดๆ สามารถนำไปใช้จัดการยูสเซอร์ล็อกอินได้
:
ก่อนจะพูดถึง access token ขอย้อนไปสมัยวัยกระเตาะปี 2534
เมื่อ "ทิม เบอร์เนิร์ส-ลี" ได้ทำคลอดเว็บไซต์แรกของโลก
จนเป็นสิ่งสามัญประจำบ้านที่มนุษย์โลกใช้เป็น
:
❣ แต่จุดอ่อนของฉัน ....อยู่ที่หัวใจ
เฮยไม่ช่ายแหละ จุดอ่อนของเว็บไซต์
ก็คือมันใช้โปโตคอล HTTP
ซึ่งมันเป็นแบบ stateless ไม่จำสถานะอะไรทั้งนั้น
ความหมายก็คือ ตัว Server ความจำสั้นมาก เป็นโรคอัลไซเมอร์
พอมันรับ request จาก browser
ก็จำไม่ได้ว่ามาจากไหน???
ใครส่งมาจำไม่ได้แล้ว!!!!!
:
🤔 เพื่อแก้ปัญานี้ในทางเทคนิค
เขาจะให้ server ส่ง session id (หรือ session token)
ซึ่ง session id มันเป็นรหัสบางอย่าง ที่เราอ่านไม่ออก แถมยาวด้วย
มันจะถูกส่งไปให้ browser เก็บค่านี้ไว้ในคุ๊กกี้เสี่ยงทาย
.
..ผิดๆ ไม่ใช่คุ๊กกี้นั้น ..แต่ cookies ที่ว่าคือไฟล์ text
Server จะส่ง session id ไปให้ browser
เก็บค่าไว้ใน cookies (เก็บใส่ text อยู่ฝั่ง browser)
:
เวลาเขียนโปรแกรมในฝั่ง server
อย่าง PHP เมื่อใช้คำสั่ง session_start();
จะเป็นการบอกให้ browser เก็บค่า session id ในรูป text เช่น
PHPSESSID=tqb4s5q7k25234eabbvs11dp02
(session id เป็นรหัสที่สุ่มขึ้นมา)
:
แต่ถ้าเป็นภาษาอื่น ก็อาจเห็นเป็นคำอื่นนะครับ
เช่น JSESSIONID (Java EE), PHPSESSID (PHP), และ ASPSESSIONID (Microsoft ASP).
.
😉 ถึงตรงนี้ session id ...อาจมองว่าเป็นรหัสประจำตัวก็ได้
:
ต่อไปนี้เวลาผู้ใช้กดคลิกอะไรบนหน้าเว็บ
ทาง browser ก็จะใจดี
แอบส่ง session id ที่ว่านี้ ไปให้ server อัตโนมัติ
ทำให้ server หายจากอัลไซเมอร์
...จำได้แล้วว่า request ส่งมาจากไหน ...เย้ เย้
.
ดังนั้นถ้าเกิด request ที่ส่งเข้ามา
มันมี session id ค่าเดียวกัน
ก็ถือว่าเป็นพรรคพวกเดียวกัน
(ศัพท์ทางคอมจะบอกว่า request พวกนี้อยู่ SESSION เดียวกัน)
.
แล้วถ้าไม่ใช่ session id เดียวกัน
ก็ถือว่า request นั้น ไม่ใช่พวกพ้องเดียวกัน
:
👉 ประโยชน์ของ session id
จะถูกนำไปใช้ร่วมกับกลไก login/logout
1) เมื่อ user ชื่อ XXX ทำการ login เข้ามา ก็จะมี session id เป็นรหัสประจำตัวอันหนึ่ง
2) พออีก user ชื่อ YYY ทำการ login เข้ามา จะมี session id เป็นรหัสประจำตัวคนละตัว
3) พอทั้งสอง user ทำการ logout ก็จะทำให้ session id หมดอายุ
:
คำถาม ถ้าเราไปกดล้าง cookies ทั้งหมดใน browser จะเกิดอะไรขึ้น?
- คำตอบค่า session id จะหายไปหมด
- ดังนั้นใครแอบ login ค้างเว็บโป้ เว็บโน่นนี้นั่น อะไรไว้ ...หึหึๆๆ
- ก็ต้อง logout อัตโนมัติ เพื่อ login ใหม่ ...เศร้ามั๊ยละ
(server จำเราไม่ได้แล้ว
เพราะ browser ไม่ส่ง session id ไปให้)
:
เรื่อง session id ฟังเหมือนดี
😨 แต่การใช้ร่วมกับ user/password เพื่อ login จะมีข้อเสีย เช่น
1) ง่ายต่อ hacker มาแอบลอบขี่ session
เพื่อสวมรอยใช้ sesion id (Cross-Site Request Forgery: CSRF)
...ทางเทคนิคขอไม่พูดถึง หาอ่านตามเว็บได้
2) เป็นภาระให้ server ต้องจำ session id ว่าเป็นของ user คนใด มีสิทธิอะไรบ้าง และจำข้อมูลอื่นๆ ของ user เป็นต้น
3) แล้วถ้าจะให้ user เดียวกัน login คนละอุปกรณ์ เช่น
เว็บก็ได้ มือถือก็ดี ...จะยุ่งยากมากขึ้น (ต้องก็อปปี้ session ไปให้)
4) และข้อเสียอื่นๆ ทีไม่ได้กล่าวถึง
:
😘 แต่เขาก็มีเทคนิคเพื่อแก้ทางนะครับ
.
ก็คือใช้สิ่งที่เรียกว่า "acces token "
ซึ่งการที่จะได้ acces token
ก็ต้อง login ด้วย user/password เพื่อไปแลกเอามา
...ต้องยืนหมู ยืนแมวกันก่อน ถึงจะได้ access token
จากนั้นเราจะใช้มันแทนการ login ได้เลย
.
ทำให้เราไม่ต้องป้อน user/password บ่อยๆ
แล้วแต่ละ user ก็จะได้ access token หน้าตาไม่เหมือนกันเด็ดขาด
พอถึงเวลา user ทำการ logout ออกไป ตัว access token ก็จะหมดอายุทันที
:
😙 ถึงตรงนี้ access token อาจเปรียบได้เหมือนกุญแจ
หรืออาจมองเป็นตั๋ว หรือบัตรผ่านก็ได้ ...แล้วแต่จินตนาการเปรียบเปรย
ข้อแตกต่างจาก session id ก็คือ
1) access token จะไม่ถูกเก็บใน cookies
2) access token จะเก็บข้อมูล ที่พอเปิดเผยได้
เช่น user_id, สิทธิต่างๆ , วันหมดอายุ
(ไม่เป็นภาระให้ server จำข้อมูลพวกนี้)
:
ยิ่งถ้านำ access token ไปใช้งานร่วมกับกลไกล login ก็จะเห็นข้อดี เช่น
1) ป้องกัน hacker ไม่ให้แอบใช้ session ด้วยวิธี Cross-Site Request Forgery (CSRF)
2) สามารถ login จากมือถือ และเว็บ เพียงแค่ใช้ user เดียวกัน ก็ทำได้ง่ายดาย
ก็แค่แจก access token ให้แค่นั้น ...ก็เหมือนที่ facebook ทำไง
(ไม่เก็บไว้ใน cookies ของ browser)
3) ตัว server สามารถทิ้งหน้าที่ login/logout อันเสียยุ่งยาก ...โยนไปให้ authenticate service ข้างนอกทำแทน
4) ตัว server ไม่ต้องมีภาระดูแลข้อมูล user
:
😀 ตัดกลับมาดูกลไก login ด้วย user/password ของ facebook
ซึ่งคอนเซปต์ตามรูปที่โพสต์เลยครับ (เป็นตัวอย่าง php)
สรุปง่ายๆ
- เวลา user ทำการ login
- มันจะแอบสวิซ์ไปหา facebook ให้ทำหน้าที่ login แทน
- เมื่อนั้น facebook จะโยน access token กลับมาให้เว็บเรา
- จากนั้น user จะใช้มันเป็นบัตรผ่าน ไม่ต้อง login ซ้ำอีกแหละ
:
ซึ่ง Access token ของเฟสบุ๊คมีหลายชนิด เช่น
-User Access Token
-App Access Token
-Page Access Token
-Client Token
แต่ละชนิดมีสิทธิแตกต่างกันได้ ขอไม่ลงลึกนะ
:
👉 เรื่อง session id กับ access token ที่เล่ามาทั้งหมดนี้
ถือเป็นขอหวานอันแสนหอมที่ hacker ชอบมากๆ
ถ้าพวกเขาขโมยได้ รับรองว่าจะสวมรอย user ที่กำลัง login ได้
จากนั้น hacker จะได้สิทธิทุกอย่างเหมือน user นั้นหมด ...เสร็จโจรละที่นี้
.
ยกเว้นเราจะ logout ออก
เพื่อให้ session id หรือ access token หมดอายุ
เมื่อนั้น hacker ก็จะหมดสิทธิสวมรอย
:
ในมุม user ก็แค่ล็อกอินใช้งานอย่างเดียว
ไม่ต้องสนใจ access token เบื้องหลังเลย
แต่ถ้าเป็น #โปรแกรมเมอร์ ต้องคำนึงถึงเป็นพิเศษ
เพราะขนาดสี่ตีนยังรู้พลาด นักปราชญ์ยังรู้พลั้ง
ยักษ์ใหญ่สุด พี่เบิ้มอย่าง facebook
ยังพลาดปล่อยให้ access token หลุดออกมาได้เลย จนเป็นข่าวสะเทือนใหญ่โต
.
👌 ด้วยเหตุนี้การเขียนโปรแกรม
ก็ขอให้คำนึงถึงเรื่อง access token ห้ามหลุดรอด
ให้ปลอดภัยจาก hakcker เป็นดีที่สุด
โชคดีทุกท่านครับ
:
:
เขียนโดย โปรแกรมเมอร์ไทย thai programmer
:
+++++++++++++
อ้างอิง
1) https://developers.facebook.com/…/h…/example_facebook_login…
2) https://developers.facebook.com/…/facebook-l…/access-tokens…
java http request 在 Kewang 的資訊進化論 Facebook 的最讚貼文
前兩篇分享了 Autocomplete 的實作方式及開發細節,算是少數大家迴響比較多的文章 XDD,下面就來整理一下大家的迴響好了。
---
## 1. 減少傳輸量可以使用 msgpack
小編有聽過 msgpack 但還沒實際了解這是如何運作的。剛查了一下資料 (https://msgpack.org),說是比 JSON 更省資料大小,基本上聽過的語言都有支援。
在前公司也用過 Avro 這類的格式,主打的也是省資料大小。但現在應該還不會考慮改用這類要另外做 serialize 的格式。
主要是基於後端是以 Node.js 為主開發,JSON 已經是原生支援,再引入一種資料格式會增加前後端維護的複雜度。另外就是開發人力,新創小公司要儘量減少工作,目前可以順暢運作就好,還有其他更重要的事要做,等之後用量大了再改也不遲。
---
## 2. 減少傳輸量可以使用 HTTP server 的壓縮機制
這真的是忽略了,忘了 expressjs 只是一套 web framework,在上面對資料做壓縮其實會影響到效率。讓如 nginx 之類的 HTTP server 做壓縮應該才是更好的作法。
不過因為現在的 infra 是建在 heroku 上面,heroku 並沒有原生 nginx 的支援。等量大撐不住的時候,倒是可以優先考慮使用 heroku 的 buildpack 把 nginx 架上去試試 (https://github.com/heroku/heroku-buildpack-nginx)。
另外也有提到用 CDN 做動態壓縮,這就真的沒做過了,也是可以研究的方向之一。
---
## 3. 減少使用者打 server 的次數,加上 debounce time
這大家都主推使用 debounce 方式,前端沒玩很深的小編第一次碰到這個名詞是高職的時候。記得那時上課在教 8051,老師說按按鈕時要加上 15 - 20ms 的 debounce time,避免重複送外部中斷。小編對單晶片實在不在行,但大概記得是這個意思。
剛查了一下資料 (https://css-tricks.com/debouncing-throttling-explained-examples),前端的 debounce time 大概也是類似的意思。在輸入文字後,會 delay n 秒再送出,若是在 n 秒內又有打其他內容的時候,就把之前的 request 從 queue 裡面丟棄,只關注最後一次的 request 就好。
這個應該也是有效減少 request 量的作法了。
---
## 4. 減少使用者打 request 的次數,將已經送出的 request 取消掉
這也是一個不錯的作法,若 A request 已經送出去,但還沒回 response 時又送了 B request 的話,此時可以把 A request 取消。
但要注意就是 A request 目前正在執行的步驟是去 DB 拿資料,或是在 server 本身處理一些基本計算。之前在使用 Java (grizzly + jersey) 開發的時候,若有這種情況發生會常在 log 裡面看到 IOException。
原因是 server 已經準備好資料要回傳給 client,但發現 A request 已經取消,不知道要怎麼回傳時就會發生這個狀況。但也有可能是小編自己沒控制好收發的關係啦 XD
---
關於 Autocomplete 的三篇大概就到這篇為止啦,等上線之後做了哪些調整再來分享給大家知道一下。
#funliday #autocomplete #msgpack #debounce #nginx
java http request 在 Java 實作Http-Request - 麻吉卡的部落格 的推薦與評價
Java 實作Http-Request之前專案有實作Java-Http-Request,以下紀錄分享curl examplecurl -s -X POST \ http://localhost:4000 \ -H. ... <看更多>
java http request 在 Java HttpRequest.body方法代碼示例- 純淨天空 的推薦與評價
本文整理匯總了Java中com.github.kevinsawicki.http.HttpRequest.body方法的典型用法代碼示例。如果您正苦於以下問題:Java HttpRequest.body方法的具體用法? ... <看更多>
java http request 在 How to send HTTP request in java? [duplicate] - Stack Overflow 的推薦與評價
... <看更多>
相關內容