Fanboi Channel

มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

Last posted

Total of 356 posts

1 Nameless Fanboi Posted ID:ZcCGcY0t+a

แตกมาจากกระทู้ มิตรสหายท่านหนึ่งในห้อง lounges
แต่อันนี้สำหรับ Software Developer

เริ่มจากอันนี้

ชอบอันนี้

มีประเด็นอยากพูดถึง คือ Pinterest เขาใช้ Kafka ซึ่งก็ถือว่าเป็นระบบที่ส่วนตัวผมคิดว่าเสถียรมากๆ แล้ว แต่สุดท้ายก็ไปเจอปัญหาว่า เวลาส่งข้อมูลจาก App ไป Kafka อาจเกิดเหตุการณ์ที่ว่า App ติดต่กับ Broker ไม่ได้ (อาจจะตายจริงหรือ Network connection หรืออะไรก็ตามแต่) ซึ่งทำให้เกิด Data loss ขึ้น

ขั้นแรกเขาก็ทำ Buffer ไว้ ถ้าสมมติติดต่อกับ Broker ไม่ได้ ก็เอาของที่เคยคิดว่าจะส่งให้ Kafka เก็บไว้ใน Memory ของ App ก่อนนะ พอมันติดต่อกับ Broker ได้เมื่อไหร่ค่อยส่งไปทีเดียว

ปัญหาที่ตามมาก็คือ Buffer เต็มเพราะ Memory มีจำกัด สุดท้ายเขาก็แก้โดยการ Write ลง Disk ซะเลย

ประเด็นที่น่าคิด

- Tools ไม่ได้แก้ปัญหาได้ทุกอย่างในโลก ใช้ Kafka ไม่ได้แปลว่าคุณได้ Relliablility & Scalability โดยอัตโนมัติแต่อย่างใด นี่ก็ต้องไปสร้าง Layer บน Kafka อีกทีเพื่อกันเรื่อง Data loss สิ่งที่น่าสนใจคือ การอ่านเขียนลงไฟล์สดกับ Kafka มัน Performant เท่ากันมั้ย อะไรจะกลายเป็น Bottleneck ในกรณีไหน (ผมใบ้ให้ว่าไม่เท่ากัน แต่มีจุดคุ้มทุนทาง Performance ต้องเข้าใจด้วยว่า Kafka มันเล่นไปจนถึงระดับระบบไฟล์ที่ทำไงให้ Seek disk ได้เร็วเลย เขียนอ่านไฟล์ธรรมดา "อาจจะ" สู้ไม่ได้ในกรณี 1-1 วัดกัน)

- เขาเลือกที่จะ Write buffer ลง Disk ซึ่งช้ากว่า Memory การอ่านกลับมาจากดิสก์ซึ่งช้ากว่า Memory ทำให้เกิด Lag time ระหว่าง Application กับ Message Queue มากขึ้น ทำให้ข้อมูลกระจายไปแต่ละส่วนในระบบช้าลง ถ้าในบริบทของ Pinterest ก็เป็นไปได้ว่าเรา Pin สิ่งนึงแต่ของคนอื่นกว่าจะขึ้นเห็นของที่เรา Pin ก็กินเวลาไปบ้าง ไม่ต้องนับเรื่องการเก็บ Stats ซึ่งช้าและไม่ Real-time เท่าเดิม นี่คือ Trade-off ที่เกิดแน่ๆ กับการเลือกทางนี้ ทำไมเขาถึงเลือก Trade-off แบบนี้ผมก็ไม่ทราบ แต่ก็เป็นเรื่องฝากให้คิดว่าทุกอย่างบนโลกมี Trade-off

- ทำไมระบบแบบนี้เกิด Data loss ไม่ได้จนต้องลงทุนขนาดนี้? นี่คือลงทุนให้ Data propagate ช้าลงซึ่งอาจจะกระทบ User experience ได้ด้วยซ้ำ เขาทำที่ Layer ไหนของระบบที่ Data เสียไม่ได้แล้ว

- ข้อสังเกต: ทำไม Buffer ไว้ใน Memory ถึงมีปัญหา Buffer เต็มได้ นั่นสะท้อนว่า Data loss "เคย" เกิดขึ้นเยอะมากระดับนึง มีปัญหาติดต่อ Broker ไม่ได้เยอะประมาณนึง พอคิดได้แบบนี้แล้วสิ่งที่ต้องถามต่อมาคือ อัตราการ Failed ของ Broker มันเยอะขนาดไหนกันนะ มันปกติหรือผิดปกติ แล้วจริงๆ สิ่งที่ Pinterest ทำมันเมคเซนส์มั้ย นี่คือ Workaround ที่ถูก หรือควรจะไปสืบหาต้นตอว่าทำไม Broker failed บ่อยขนาดนั้น? ผมตอบไม่ได้นะ บางทีมันอาจจะเป็นปกติอยู่แล้ว แต่อันนี้ให้ดูไว้ว่าเวลาดูงานพวกนี้ด้วย Critical thinking มันไม่ควรจะเชื่อถือไปเลยเพียงเพราะเขาเป็น Pinterest หรือบริษัทใหญ่

ประเด็นที่อยากสื่อทีสุดคืออันแรกนั่นแหละ อย่าโดนขายของด้วย Tool จนขาดความสามารถในการเข้าใจ System at Scale เพราะสุดท้ายคุณอาจจะต้องทำแบบ Pinterest ก็ได้นะที่ต้องทำอะไรบางอย่างเพื่อสู้กับ Trade-off ของตัว Tool เอง

2 Nameless Fanboi Posted ID:5xftt4MgqF

คำถามยอดฮิต จะเป็น Data Scientist จะเรียน Operations Research (แบบแป้ง) หรือจะเรียน Computer Science (แบบน้องเปรียว Senior Data Scientist ของ Coraline) ดีนะ

ตอบแบบนี้นะคะ

บอกก่อนว่า ทั้งสองศาสตร์ สามารถเป็น Data Scientist ได้เหมือนกัน แต่ทำงานได้ไม่เหมือนกันค่ะ

OR จะเป็นการ Applied Math เพื่อให้เข้ากับ Process ของปัญหา และกลั่นกรองออกมาเป็นสมการ หรือ Model เพื่อนำไปวิเคราะห์ด้วยคอมพิวเตอร์ต่อไป

Com Sci เป็นศาสตร์ที่เรียนเพื่อเข้าใจกระบวนการของ Computer โดยมีโจทย์ให้ แล้วประยุกต์ใช้ Computer ในโจทย์นั้นๆ

((ความเป็นจริงแล้ว ใน OR เอง และ Com Sci เอง ก็มีแขนงแยกออกมาอีกมากมาย เอาไว้แป้งจะเล่าให้ฟังในครั้งต่อไป))

คราวนี้ กลับมาตอบว่า จะเรียน OR หรือ Com Sci ต้องถามตัวเองค่ะ

1. คุณชอบที่จะออกไปเจอปัญหา แล้วจิตนาการถึงแนวทางในการแก้ปัญหา ร่างโจทย์ในกระดาษ ไม่ได้รู้สึกเสียเวลากับการออกไปคุยหน้างาน หรืออ่านเปเปอร์ที่ไม่เกี่ยวกับคอมพิวเตอร์ ก่อนที่จะเขียนโปรแกรมขึ้นมาแก้ปัญหาหรือไม่ ถ้าใช่ คุณเหมาะกับ OR

2. คุณชอบคอมพิวเตอร์ อยากรู้กระบวนการทำงานของคอมพิวเตอร์ สนุกกับการเขียนโค้ด สามารถเข้าใจภาษาคอมพิวเตอร์ได้อย่างรวดเร็ว แต่ไม่ชอบตั้งโจทย์ มองปัญหาไม่ออก แล้วรู้สึกอึดอัดทุกครั้งที่ต้องไปคุยหน้างาน เพราะรู้สึกว่าเสียเวลาเขียนโค้ดหรือไม่ ถ้าใช่ คุณเหมาะกับ Coder

สำหรับแป้ง ใน Coraline แป้งจะบอกทีมงานเสมอว่า ทุกคน "เท่าเทียมกัน" ไม่มีใครโดดเด่นกว่าใคร ทุกคนต่าง "โดดเด่น" เหมือนๆ กัน

ในการทำงานจริง OR จะเป็นคนระบุปัญหาที่ดี ในขณะที่ Coder จะเป็นคนพัฒนาระบบที่ดี อยู่ที่งานแต่ละประเภท แต่ละที่ ว่าต้องการความเชี่ยวชาญด้านไหนเป็นพิเศษ

แต่ ด้วยความที่ ส่วนตัวแป้งมองว่า อาชีพ Data Scientist เป็นอาชีพที่เสี่ยงตกงาน ในวันที่ AI เข้ามาครองโลก

ดังนั้น แป้งวาง Career Path ของแต่ละคนไว้ต่างกัน

OR จะเหมาะกับสาย Business ด้วย นอกจากต้องเรียนรู้การสร้าง Model ก็ควรจะเรียนรู้งานด้าน Business เพื่อสามารถตีโจทย์ให้ออก

Coder หรือ Com Sci ควรแบ่งร่างส่วนหนึ่ง เรียนรู้ส่วนงานอื่นที่เกี่ยวข้อง เช่น Com Engineer, Software Developer, UX/UI หรือ Application ต่างๆ

อย่างไรก็ตาม การที่คุณจะมี Degree ที่ 2 ได้ จงทำ Degree แรกของคุณให้เข้มแข็ง เพราะใน 1 วัน มีเพียง 24 ชั่วโมง ทั้งหมดทั้งปวง อยู่ที่การ "บริหารเวลา" ที่ดี

สุดท้ายนี้ จะเป็น OR หรือ Com Sci ก็แล้วแต่ความถนัดของแต่ละคน

ที่สำคัญที่สุด "ทุกคน.... เท่าเทียมกัน"

3 Nameless Fanboi Posted ID:R0vni+UmZe

เตือนภัย.โปรแกรมเมอร์ทีม.
แก้งค์ขโมย ฟอก source ผู้อื่น แห่งยุค
ท่ามกลางความเงียบ
ขณะที่คุณกำลัง coding ในทีมสุดเลิฟของคุณอยู่นั้น
รู้ตัวบ้างหรือป่าวถึงมหันตภัยเทียบเท่าชีวิตคุณว่า
มีบางคน บางกลุ่ม กำลังขโมย กำลังทำการฟอก
source ของคุณ ทำการศัลยกรรมใหม่
ไปเป็นของตัวเองสำเร็จ
หลังจากนั้น
เมื่อชีวิตต้องอาศัย coding เลี้ยงชีพ
ทั้งชีวิตของท่านนั้น ผลงานกว่า20ปีของท่านนั้น
จะปรากฎอยู่ที่เก้าอี้ตัวไหน?

4 Nameless Fanboi Posted ID:B507mX.k7y

ทำไมนักพัฒนาซอฟต์แวร์ต้องคุยกับคนอื่นไม่ค่อยรู้เรื่องครับ ยกตัวอย่างกระทู้นี้ เปิดกระทู้ได้สมกับเป็นนักพัฒนาซอฟต์แวร์ดี

5 Nameless Fanboi Posted ID:w8KZTt1Zzy

ลองติดตามคนนี้ดูครับ เห็นว่าเป็นเจ้าของเว็บที่มีชื่อเสียงแห่งหนึ่ง
https://mobile.twitter.com/gridth1

6 Nameless Fanboi Posted ID:q.Gd.MC0Bn

>>4 โปรแกรมเมอร์ไม่ได้คุยกับคนอื่นไม่รู้เรื่อง คนอื่นต่างหากที่คุยกับโปรแกรมเมอร์ไม่รู้เรื่อง

Be Civil — "Be curious, not judgemental"

  • FAQs — คำถามที่ถามบ่อย (การใช้บอร์ด การแบน ฯลฯ)
  • Policy — เกณฑ์การใช้งานเว็บไซต์
  • Guidelines — ข้อแนะนำในการใช้งานเว็บไซต์
  • Deletion Request — แจ้งลบและเกณฑ์การลบข้อความ
  • Law Enforcement — แจ้งขอ IP address

All contents are responsibility of its posters.