Fanboi Channel

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

Last posted

Total of 185 posts

167 Nameless Fanboi Posted ID:uq2L9xGw2Y

ไปอ่านบล็อกนึงใน Reddit ที่ Github บอกว่าเขาไม่ใช้ Foreign key constraint เพราะอะไร

มีคนอ่านบอกว่า ปัญหานี้มันเฉพาะตัวของ Github ไม่ใช่ปัญหาที่คนทั่วไปเจอ

ผมตอบว่า No one tasked to solve generic problem, ever. แล้วผมก็แชร์บล็อกนี้เลยใน Tech Articles Group

================

ผมอยากชวนคิดว่า เราอยากจะหา Generic solution หรือมักจะเรียกอีกชื่อหนึ่งว่า "Best practice" ที่ใช้ได้ในกรณีทั่วไปเพื่ออะไร

ถ้าระบบหรือที่ไหนเจอ Generic problem เขาก็ไปอ่าน Generic solution แล้วก็ทำตามนั้นก็จบ จะจ้างเรามาทำงานทำไม คนเขียนวิธีอย่างละเอียดในการแก้ไข Generic problem มีเยอะแยะไปหมด

ทุกคนทุกระบบ เจอ Specific problem ที่จำเป็นต้องใช้ Specific solution ในการแก้ไขทั้งนั้น ดังนั้น ในแง่นี้ การที่เรารู้จัก Generic solution หรือ AKA. Best practices ไม่ได้การันตีเลยว่ามันจะแก้ไขปัญหาของเราได้ ต้องบอกว่าส่วนมากจะไม่ได้ด้วยซ้ำไป

อ้าว แล้วถ้างั้นเราควรจะทิ้ง Best practice ไปมั้ย ไม่สนใจเลยเหรอ? เราจะเรียน Best practices ไปทำไม

เพราะเวลาพัฒนาระบบเนี่ย มันไม่มีใครรู้ว่า Solution คืออะไรไงล่ะ ถ้ามีคนรู้จริงๆ แล้วเนี่ย งานมันไม่มาถึงเราหรอก

ทีนี้พอมันไม่รู้ว่าวิธีแก้ปัญหาที่ถูกต้องเป๊ะๆ คืออะไร มันก็ต้องลองอะไรซักอย่างใช่มั้ย ไม่ใช่ปล่อยให้ปัญหาคงอยู่ ต่อให้สิ่งที่ลองแก้ปัญหาไม่ได้เป๊ะๆ บรรเทาได้ก็ยังดี

ทีนี้ประโยชน์ของ Best practices มันก็คือตรงนี้ คือคุณลอง Apply best practices ไปในตอนที่ยังหา Solution ที่เป๊ะๆ ไม่เจอ โอกาสที่มันจะใกล้เคียงกับ Solution มีเยอะกว่า Apply อะไรก็ไม่รู้มั่วซั่วเยอะ ดังนั้น เวลาไม่รู้อะไร ผมก็แนะนำ Best practices ก่อนเสมอ เป็น Bet ที่ดีกว่าลองมั่วซั่วแน่ๆ คุณควรจะรู้แล้วใช้มันเป็นฐานตั้งต้นเสมอ

แต่คุณจะไปสรุปว่ามันเป็นคำตอบถาวรของระบบไม่ได้ คุณยังต้องสังเกตและ Iterate ต่อจากตรงนั้นไปด้วย แล้วถ้าจะปรับเปลี่ยน ก็ต้องเปรียบเทียบว่าทางออกที่ไม่ได้ตรงกับ Best practice นั้นในบริบทของเรามันดีกว่าหรือแย่กว่า ก็ต้องค้นหากันต่อไปเรื่อยๆ ตราบที่ระบบยัง Evolve อยู่ยังต้องดูแลกันอยู่

================

จุดที่ยากที่สุดคืออะไร คือเราต้องเผชิญหน้ากับความจริงว่า ไม่มีใครรู้คำตอบของระบบเราทั้งนั้น ถ้ามีคนรู้ ทุกวันนี้มันจะมีปัญหาเหรอ?

จะไปคาดหวังว่าคนเขียนหนังสือ Best practices เขาจะมีคำตอบที่ถูกต้องเป๊ะๆ ใช้ได้เลย คนเขียนก็คงหนักใจ ผมเองสารภาพว่าตัวเองบางครั้งเขียนหรือพูดเรื่องพวกนี้จะออกตัวมากๆ ว่าอย่าเชื่อไปเลยแล้วโยนความรับผิดชอบมาให้

ทุกวันนี้ ทุกคนอยากให้มีคนรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนในการ "ค้นหาคำตอบ" ตัว Business อยากให้มีคนรู้คำตอบ Investor คาดหวังว่าจะมีคนรู้คำตอบ Junior คาดหวังว่าจะมีคนรู้คำตอบ Senior คาดหวังว่าคนอื่นจะรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนการค้นหาคำตอบ

พอมีคนมาบอกทุกคนว่า "ผมรู้คำตอบ ตาม Best practice ที่ผมเขียนหรือให้คำปรึกษาสิ จบเลย" แค่นี้ทุกคนก็พร้อมจะจ่ายเงินให้แล้วไม่คิดอะไรต่อแล้วอ่ะ ดี ไม่ต้องผ่านขั้นตอนค้นหา เป็นโมเดลธุรกิจที่ดีมากเลย

แต่มันเป็นคำตอบจริงมั้ยนะ ก็ขอให้โชคดีกับขั้นตอนการ "ค้นหาคำตอบ" ที่ปลอมตัวใส่เสื้อผ้าว่านี่คือการ "มีคำตอบให้ แค่ทำตาม" ละกัน

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

168 Nameless Fanboi Posted ID:uq2L9xGw2Y

>>166 ฟ้องกรมแรงงานก่อนได้เปรียบ

169 Nameless Fanboi Posted ID:3jb8hqnwz8

ผมเห็นด้วยที่ว่า Agile ไม่ได้แปลว่า เร็ว (ใน Absolute Term/Sense) ... ทุกอย่างมันขึ้นกับ Frame of Reference ว่าเราเอาอะไรไปเทียบกับมัน และมันเหมาะสมหรือไม่ มัน Overkill เกินไปหรือเปล่า ในทุกเรื่อง

ผมเห็นว่าทุกกระบวนการ มันมี Scale ที่เหมาะกับมันเอง สิ่งที่จะทำให้มันยากลำบากและช้าลง ไม่ใช่ที่ตัวกระบวนการ แต่เป็นการไม่เหมาะสมกันระหว่าง Process และ Scale ต่างหาก

นี่ยังไม่รวมถึงลักษณะงาน และเป้าหมายนะ ... เช่น ถ้าเป็นงานแบบ "ใช้แล้วทิ้ง" ใน Scale ที่เล็กพอที่จะ Cowboy-Developer ได้ตรงๆ แบบดุ่มๆ ไปเลย เดี๋ยวก็เสร็จ และการันตีได้ว่าไม่ต้องดูแลต่อ (ไม่ว่าจะโดยใครก็ตาม) การทำ Agile ก็ Overkill ไม่ต่างอะไรกับการใช้ Process อื่น ...

แต่กับอีกหลายงานมันก็ไม่ใช่แบบนั้น

จริงๆ ก็ไม่ต่างจากเรื่องบริหารบริษัทหรอก บริหาร Enterprise แบบ SME ก็ตาย บริหาร SME แบบ Enterprise ก็ตาย ... บริหาร SME แบบงานส่วนตัว ข้ามาคนเดียว ก็ตาย บริหารงานที่ทำคนเดียวแบบ SME ก็ตาย ... ทั้งนั้นแหละ

ประเด็นมันไม่ใช่ Agile เร็วหรือไม่เร็ว เพราะตัวมันเองไม่ใช่ความเร็ว เพียงแต่ว่าเมื่อนำมันไปใช้กับ "งานบาง Scale" แล้วมัน "เร็วกว่า Waterfall-based ในระยะสั้นและระยะกลาง" และ "เร็วกว่า Cowboy-Develop ในระยะกลางและระยะยาว"

ซึ่งพอเรา "เคยชิน​" กับ Frame of Reference บางอย่าง (พูดอีกอย่าง คือเรามี Implicit Frame of Reference) เราอาจจะรู้สึกว่ามัน "เร็วขึ้น"​ เสมอ แต่ถ้าเราเคยชินกับอีก Frame หนึ่ง เราอาจจะรู้สึกว่ามัน "ช้าลง" เสมอ เช่นกัน

การนำ Process ไปใช้ ถ้าเรารู้สึกว่ามันเร็วขึ้น แปลว่า Scale ของงานที่เราทำ และ Process มันมี matching ที่ดีกว่า แต่ในขณะเดียวกันถ้ามันช้าลง แปลว่า matching มันไม่ดี

ประเด็นสำคัญคือ ... ทีมงานหลายทีม ใช้ Process ผิด Scale .... ส่วนหนึ่งก็เพราะว่าตอนเรียน เรียน Process for Enterprise มา .. แต่ตอนทำโปรเจ็คจบ หรืองาน Freelance แรกๆ ดันทำแบบ Cowboy ....

ต้องยอมรับกันนะ ว่างานบ้านเราที่ต้องใช้ Scale ระดับ Enterprise มันไม่ได้มีเยอะขนาดนั้น แต่งานส่วนมากมันเกิด Scale ของ Cowboy Coding ไปเยอะอยู่

Agile จึงเป็นทางออกที่ดี และผมเห็นว่ามันเป็น Bootstrapping Platform ที่ดี สำหรับการ Rescale Enterprise ให้เป็น Smaller Units ในการทำงานต่างๆ

แต่ที่แน่ๆ คือ เราต้องแยกแยะให้ออกระหว่างตัวปรัชญา (Philosophy) ของแต่ละอย่าง กับ "Implementation" ของมันทั้งหลาย ไม่ว่าจะเป็นการ Implement แบบไหนก็ตาม

หลายอย่าง Philosophy ดีมาก เช่นพวก CMMi แต่ตัวปรัชญามันเอาไปทำอะไรไม่ได้ มันก็ต้องมี Implementation ... ซึ่งแน่นอนว่า Implementation ทุกตัวมันจะเหมาะกับบางรูปแบบ (เช่น บางตัวเน้นการใช้เอกสาร) ... แต่ถ้าเราถอดเปลือกของ Implementation กลับไปมองที่ประเด็นของปรัชญาของมัน เราอาจจะสร้าง Process ใหม่ๆ ได้โดยไม่อิงกับ Implementation บางแบบที่ไม่เหมาะสม ได้ทั้งนั้น

ก็เช่นเดียวกันกับ Agile .... ณ วันที่ผมลงชื่อใน Manifesto เมื่อประมาณ 15 ปีก่อน ....​ ณ วันนั้นมันยังไม่มี Agile Methodology หรือ Agile Process มากมายดังเช่นทุกวันนี้ ยังไม่มี Scrum ไม่มี Kanban ไม่มีอะไรทั้งนั้น ... พวกนี้เกิดจากการเอาปรัชญาไปใช้สร้าง Process ของตัวเอง จนมันเวิร์กขึ้นมา และทำจนเชี่ยวชาญ จนมันเร็ว

บางที กลับไปหาปรัชญามันซะบ้าง แล้วก็คิดบ้าง ว่ามันไม่มี one size fit all ... และทุกอย่างมันไม่มี absolute term

ผมจะลบโพสท์นี้ในอีก 1 ชั่วโมง

170 Nameless Fanboi Posted ID:e+6VmtQKo9

>>169 ในนี้มันลบไม่ได้ไอสัส

171 Nameless Fanboi Posted ID:STBXBlb+JA

>>166 หางานใหม่เหอะ เป็นกุเดือนเดียวก็ไม่อยู่แล้ว ดูทรง เจ้าของลอยแพ แน่นอน อยากได้ไปฟ้องเอา

172 Nameless Fanboi Posted ID:hBLAW2aEjn

Gartner ทำนายเอาไว้ในปี 2017 ว่าภายในปี 2019 จะมีแบรนด์ราว 20% ถอดใจกับ mobile app ของตัวเอง

ไม่รู้ว่าตอนนี้ตัวเลขมันไปถึงไหนแล้ว แต่ส่วนตัวคิดว่าการทำ mobile app มันจะถูกลดความนิยมในอีกไม่นาน และถูกแทนที่ด้วย web technology มาตรฐานใหม่ ๆ ที่สามารถทำงานได้ในทุก ๆ อุปกรณ์มากกว่า

มีงานวิจัยจาก Forrester ที่ให้บทสรุปออกมาแม้ว่าคนส่วนใหญ่จะใช้เวลาในแต่ละวันเกือบ 85% หมดไปกับมือถือ แต่ก็มีแค่ราว ๆ 5 apps เท่านั้นแหละที่ถูกเรียกใช้งานถี่ที่สุด

ผมมานั่งนับดูของตัวเอง.. เออ จริง ๆ ก็ใช้หลัก ๆ แค่นี้แหละ facebook, line, gmail, youtube และที่ขาดไม่ได้คือ chrome

คุณมีกี่ app ในมือถือของคุณ?
คุณใช้วันละกี่ app?
app ละกี่ครั้งต่อวัน?

นอกจากเรื่องการใช้งานแล้ว ผมว่าอีกปัจจัยที่ทำให้ mobile app มันจะถูกลดความนิยมไปก็เพราะมันพัฒนายากกว่าเว็บ และราคาสูง ทั้งค่าพัฒนาและค่าบำรุงรักษา แล้วถ้า app ที่ทำขึ้นมา ยิ่งมี ROI ต่ำด้วยแล้ว.. มันยิ่งเป็นหายนะไปใหญ่.. พอ app ไม่ทำกำไร สิ่งที่ตามมาคืองบในการพัฒนาและบำรุงรักษาก็จะค่อย ๆ ถูกตัดไปใช้ในส่วนอื่นที่ทำกำไรมากกว่า แล้วสุดท้ายคนก็จะเลิกสนใจเพราะมันขาดการอัพเดตอย่างต่อเนื่อง เป็นวัฏจักรไป

แต่ผมก็ไม่ได้หมายความไม่ควรมีใครทำ app เลย.. ไม่ใช่นะ.. app ยังมีความจำเป็นในบางสินค้า/บริการ ทั้งนี้ทั้งนั้นต้องดูว่าแต่ละองค์กรมีแผนการใช้งาน mobile app อย่างไรมากกว่า

เช่น app ของโรงพยาบาล.. อันนี้ร้อยวันพันปีลูกค้าจะได้ใช้สักที คงไม่มีใครยากเจ็บไข้ได้ป่วยบ่อย ๆ หรอกมั้ง จะโหลดมาเก็บไว้ในเครื่องทำไมให้เปลืองเมม ตอนที่สภาพร่างกายปกติดี ใครจะเปิด app โรงพยาบาลมาใช้ แล้วไหนทางโรงพยาบาลยังจะต้องคอยนั่งแก้โค้ดให้รองรับการ update ใหม่ ๆ ของ OS มือถือแต่ละค่าย.. ผมมองไม่เห็นความคุ้มค่าในการมีอยู่ของแอพนี้เลยจริง ๆ

ถ้าธุรกิจของคุณกำลังสนใจอยากจะทำ mobile app ไว้ใช้สักอัน.. ลองพิจารณาดูให้ถี่ถ้วนก่อนนะครับว่า.. ไหวหรอ? 😅

ปล. ให้คำปรึกษาด้านเว็บสำหรับเจ้าของเว็บฟรี แต่ไม่รับทำนะครับ..ไม่มีเวลาทำจริง ๆ.. ทิ้งคำถามไว้หน้าไมค์หลังไมค์ตามสะดวกเลยครับ

REF:
- https://www.gartner.com/en/marketing/insights/articles/gartner-predicts-2017-marketers-expect-the-unexpected

- https://techcrunch.com/2015/06/22/consumers-spend-85-of-time-on-smartphones-in-apps-but-only-5-apps-see-heavy-use/

173 Nameless Fanboi Posted ID:WYMdlczbsy

คอมติดไวรัส .zobm ทำไงถึงกู้ไฟล์ได้คับ

174 Nameless Fanboi Posted ID:wZhk2CE1aB

หนึ่งใน "หนังสือที่ผมอยากให้โปรแกรมเมอร์ทุกคนอ่าน" ....

The Elements of Programming Style โดย Brian Kernighan และ P.J. Plauger

หนังสือตั้งแต่ปี 1974 (2nd edition ปี 1978) ที่ยังคงคลาสสิคและ "core content", "messages", "philosophy", "wisdom" มันยังคง relevant ในปัจจุบัน

จะเห็นว่าโลกมันไม่ได้หมุนไปไหนมากมายเลย ทุกวันนี้เราก็ยังคงต้องพูดอะไรกันแบบนี้อยู่ .... แค่คำที่ใช้มันเปลี่ยนไปเฉยๆ ...

ไม่ว่าจะเป็นเรื่องพวก test-driven, unit-testing, readable code, clean & clear code, SOLID, etc ..... โดยเ​ฉพาะอย่างยิ่งเรื่องอย่าบ้ากับเรื่อง performance มากนักในกรณีทั่วไป ..... (ถ้าต้องบ้าขนาดนั้น ส่วนมากต้องมาดู algorithm ของตัวเองใหม่แล้วล่ะ -- ซึ่งในเล่มนี้เขียนว่า "Don't diddle code to make it faster. Find better algorithm") .... หรือต้อง measure/profile ก่อน optimize ... อย่าเชื่อความคิดตัวเองเรื่อง performance มากกว่าตัวเลขจริง​ (และ algorithm complexity) ฯลฯ

ถึงคำที่ใช้จะแตกต่างกัน .... แต่เนื้อหาและสาระเหมือนเดิม (ผมชอบคำในเล่มนี้มากกว่า "ชื่อท่าต่างๆ" ในสมัยใหม่ด้วยล่ะ มันเรียบง่าย และหนักแน่น)

ผมยังคงต้องบอกโปรแกรมเมอร์สมัยใหม่เรื่องแบบนี้อยู่ (และหลายคนก็ยังคงดื้ออยู่ คิดว่าที่ตัวเองทำมันดีแล้ว -- พวกนี้ก็ต้องปล่อยไป)

พูดง่ายๆ คือมันเป็น Timeless Wisdom

ผมแปะ snapshot จากหนังสือเล่มนี้ให้อ่านครับ เป็นตัวอย่าง ว่าทำไมมันน่าอ่าน

175 Nameless Fanboi Posted ID:Vop6Qp206C

>>172 แอพ พวกที่รอดต้องแบบที่รวดเร็ว ไม่เหมาะกับใช้บนบราวเซอร์ ใช้บนเว็บยิ่งไม่สะดวก แป๊บๆคือเข้าใช้งานได้เลย หรือไม่ก็ต้องออกแนวที่เชื่อมต่อกับอุปกรณ์บนมือถือ , IoT ต่างๆ

176 Nameless Fanboi Posted ID:S1YqZW4nc+

หนังสืออีกเล่ม ที่อยากให้โปรแกรมทุกคนอ่าน ..... ด้วยเหตุผลเดียวกับเล่มเมื่อวาน คือ Timeless Wisdom .....

"The Art of UNIX Programming" ..... โดย Eric S. Raymond (ESR)

ชื่อหนังสืออาจจะทำให้คนคิดว่าเป็นการสอนเขียนโปรแกรมบน UNIX หรือหัดใช้ UNIX API (System Calls) อะไรพวกนี้ .... แต่จริงๆ มันคนละเรื่องเลย .... Very far from that ด้วยซ้ำ

มันคือปรัชญาและ Wisdom เบื้องหลังการสร้าง UNIX (และโปรแกรมใน UNIX Ecosystem) ที่ผมถือว่าเป็น very-well-designed และ stood the test of time มากๆ .... จนกระทั่งปัจจุบัน

ทุกอย่างในนี้ยังคง relevant ..... ทุกวันนี้เราก็ยังคงต้องสอนเรื่องแบบนี้กันอยู่

ลองอ่านตัวอย่างบางหน้าดูได้ครับ

ป.ล. ... ผมอยากจะจัดคลาส based on เล่มนี้ และ The Elements of Programming Style มากๆ เลยนะ :D

177 Nameless Fanboi Posted ID:UDieycegAL

ผมคิดว่าเวลาเราจะใช้อะไรควรดูให้รอบด้านครับ ความเร็วเป็นแค่มิติหนึ่งที่ใช้ประกอบการตัดสินใจ ร่วมกับว่า

1. ใช้ง่ายไหม
2. เครื่องมือที่ใช้ถนัดไหม
3. Library ที่ต้องใช้มีครบไหม
4. เขียนไปแล้วเพื่อนอ่านออกไหม (4.1 เขียนไปแล้วตัวเองกลับมาอ่านออกไหม)
5. เทสง่ายไหม -- ถ้าสนใจจะเทส
6. ดีพลอยง่ายไหม

ยกตัวอย่าง คือ ผมไม่ชอบ syntax ภาษา go เอาซะมากๆ เลย แต่ถ้าต้องเขียน command line tool ผมก็เลือกใช้ go เพราะมันเป็น binary ไฟล์เดียว คอมไพล์เสร็จโยนไปใช้ได้เลย ไม่ว่าภาษาไหนจะมีรันไทม์ลงง่ายแค่ไหนก็สู้ go 1 binary ไม่ได้ กรณีนี้ไม่ได้ขึ้นกับว่าภาษานี้เร็วแค่ไหนเลย เพราะไม่สำคัญ

ทั้งนี้ พึงระลึกถึงคำสอนปราชญ์โบราณ ท่านกล่าวไว้ว่า Only a sith deals in absolute ครับ

178 Nameless Fanboi Posted ID:gnQrcYIBbR

ลองใช้กลยุทธ์ ทรัมป์ ก็จะได้เห็น Dark Side ของคนมากขึ้น
ได้ข้อมูลมาเยอะแยะ ดีเลย จะได้เห็นว่าจริงๆแล้วเค้าคิดยังงัยกับเรา

คนที่เห็นประโยชน์เราตอนเราดีก็มีเต็มไปหมด
ตอนเราร้ายก็ด่าเราลับหลัง
ความโกหกตอแหลมันโผล่ออกมาชัดเจน

สิ่งที่อยากได้จาก Community คือความจริงใจเป็นอันดับแรก
มันเป็นวิธีการกรองคนที่ได้ผลดีอย่างที่ตั้งใจไว้

คนที่เขาทำงานด้านมืดนี่ รู้จักจริงๆหลายคน ธรรมมะธรรมโมมาก ดูแลผู้หญิงดีมาก ไม่งั้นผู้หญิงก็ไม่มาทำงานด้วยหรอก
เพราะสังคมบีบคั้นทำงานแล้วโดนกดขี่ เก็บเงินไม่ได้ โดนขูดรีดจากผู้มีอิทธิพล แต่ละคนก็มีทางเลือกต่างกัน ไม่ต้องรีบตัดสินก็ได้ถ้ายังไม่รู้จักกันดีพอ

คนที่ทำด้านสว่างก็ทำเรื่อง Dark ๆ เยอะ ก็เห็นมาเยอะแต่ทำไรไม่ได้ พอยกเรื่อง dark ที่ตัวเองเคยทำขึ้นให้เห็น ก็แสดงตัวเป็นคนดีขึ้นมารับไม่ได้ก็แปลกดี ตัวตนจริงๆตัวเองยังยอมรับไม่ได้เลย

ริเริ่มทำไรใหม่ๆก็ไม่มีคนเข้าใจอยู่ละ ไม่จำเป็นต้องอธิบายมาก เพราะไม่ได้อยากอธิบาย อยากทำให้สำเร็จมากกว่า ยังงัยก็ทำอยู่ละ

ก็ไม่อยากจะโอ้อวดว่าตัวเองทำมาไม่น้อยกว่าใคร เห็นปัญหามากมายที่มันไปต่อไม่ได้ด้วยวิธีการเดิม ก็พิสูจน์กันละกัน เอาตัวเองให้รอดก่อน

ถ้าคิดว่าสิ่งที่ทำมาในอดีตมันคือความดี มันก็เป็นอดีต ที่ไม่ได้มีใครสนใจ ป่วยมายังไม่มีใครเหลียวแหล ทุกอย่างมันก็เป็นแค่อดีต

ผมเจ็บแทนคนใน Community มาเยอะกว่าที่หลายคนรู้ ไม่แฉก็ดีแล้วครับ แต่ละคนแสบๆทั้งนั้น

ก็อยากจะ Filter ให้เหลือน้อยๆ เหลือแต่คนที่ลำบากไปด้วยกันลุยไปด้วย

Set to Zero ถ้าไม่ทิ้งบางอย่าง เราก็ยากจะก้าวผ่าน ใครจะดราม่าก็ดราม่าไปนะครับ มีไรทำเยอะ

เอาเวลาไปทำงานสร้าง Value ให้ Community ที่คุณคิดว่าดี ดีกว่าครับ

ทำไมฝั่ง business เขาชอบมาคุยกับผมมากกว่าคุยกับ Dev และ Community ก็ลองคิดเองว่ามันยังมีปัญหาอะไรอยู่ ทำไมอีกหลายๆที่เขาไม่อยากสนับสนุน

อย่ามาเสียเวลากะผม อีกไม่กี่ปีเราก็ตายจากกันละ แมนๆก็มาคุยกันได้ ไม่ต้องโพสต์หรือนินทาลับหลัง ขี้เกียจตามไปอ่าน

179 Nameless Fanboi Posted ID:gnQrcYIBbR

ขอบคุณเพื่อนพี่ๆน้องๆที่ทักเข้ามาถามไถ่ ด้วยความเป็นห่วง กลัวสิ่งที่ทำจะเสียชื่อเสียง กังวลแทนผมซะเยอะกว่าเจ้าตัวอีก ถ้าไม่มีหนี้ผมก็ทิ้งได้หมดแหละ ตอนโดนมีดโดนปืนจ่อหัวยังน่ากลัวกว่าเยอะ เรื่องความเห็นไม่ตรงกันมันสิวมากสำหรับผม เรื่องที่ทำมันไม่ได้คิดเองเออเอง มันผ่านการคิดจากผู้หลักผู้ใหญ่ที่สนับสนุน พร้อมรับผล มันคืองานของผมกับทีม ไม่ตัองโยงไปกับ กลุ่มใด vision ใด ไม่ได้เกี่ยวกันเลย ผู้หลักผู้ใหญ่บอกมาว่าถ้าร่วมกันทำงานสำเร็จ รอบหน้าจะพาไปเขียนโค้ดบนเรือยอร์ช #DEAN

180 Nameless Fanboi Posted ID:3KN+X4F3sH

เห็นพี่ที่เคารพท่านหนึ่งพูดเรื่องเข้าใจ พื้นฐาน OOP ผิดกันเยอะ

ทั้งหมดโพสต์นี้เป็นความเห็นส่วนตัวของผมนะ แต่ก็เป็นวิธีที่ผมใช้มอง OOP แล้วยังคง Sanity ไว้ได้

- OOP ตัวตั้งต้นของ Alan Kay พูดถึงเรื่อง State encapsulation ซึ่งผมเข้าใจว่าเขาต้องการแบ่งปัญหาออกเป็นปัญหาย่อยๆ และจัดระเบียบและแบ่งสันปันส่วนว่าระบบตรงไหนเข้าถึง State ตรงไหนได้บ้าง ซึ่งเขาไม่ได้สนใจเรื่อง Code reuse เลย ไม่มี Polymorphism ด้วย ไม่ต้องพูดถึง Inheritance เลย

- ยุคหนึ่ง การทำ Dynamic link เพื่ออัพเดทโค้ดผ่านการวาง DLL หนึ่งไฟล์ หรือ Class 1 ไฟล์เป็นอะไรที่โอ้โหเจ๋งมาก ผมคิดว่ามันเกิดในยุคที่คนยังส่งมอบซอฟต์แวร์ผ่าน Floppy disk จำนวนมากอยู่ แล้วคอนยเซปต์ Dynamic link ที่สามารถสับเปลี่ยน Class ได้ตลอด ไม่ต้องส่ง Floppy disk 40 แผ่นผ่าน EMS เพื่ออัพเดทซอฟต์แวร์หนึ่งชิ้นแล้ว โคตรเจ๋งเลย!!! ในยุคนั้นสิ่งนี้เป็นเรื่องสำคัญ ส่วนสมัยนี้เหรอ ทำ Patch ทั้ง App ผ่าน Internet ง่ายกว่าเยอะ ซึ่งบนข้อจำกัดนี้ ไม่แปลกใจที่ Inheritance เป็นคอนเซปต์ที่มีพลังมาก ผมจำได้ว่าผมอ่าน Polymorph ครั้งแรกช่วงที่ยังใช้ Floppy disk กันอยู่ เดาว่าคอนเซปต์มันเกิดช่วงนี้

- ส่วน Code reuse ผมว่ามันมาเกิดในช่วงอีกช่วงหนึ่ง แต่ยังไม่แน่ใจว่าตอนไหน ผมจำได้ว่ามีช่วงหนึ่งมันป็อปมากเรื่อง Code reuse via OOP เนี่ย จนบอกว่าทำ OOP เพื่อจะได้ทำ Code reuse ได้ ซึ่งก็ตลกดีตรงที่เท่าที่ผมอ่านเจอ เจ้าตัวคนคิดคนแรก ไม่ได้สนใจอะไรตรงนี้ขนาดนั้นนะ

- เวลาเราเข้าใจ OOP ถ้าเราเข้าใจว่าเรื่อง Separation of concern, State encapsulation มันเกิดคนละยุคกับช่วงที่เขาโปรโมตเรื่อง Code reuse, Inheritance, Polymorph เราจะเก็ตว่าทำไมพอพยายามใช้งานจริง บางทีคอนเซปต์มันขัดกันเองแปลกๆ บางทีพอพยายามจะ Encapsulate แล้ว Reuse ยากจังวุ้ย แล้วตรงข้าม พอพยายามจะ Reuse ให้ได้เยอะๆ ทำไมโดเมนบางทีมันผสมกันไปหมดเลยวุ้ย พอเรารู้แบบนี้ เราไม่ต้องไปหาทาง Justify ครับ แค่เข้าใจว่ามันเกิดคนละยุค Practice ที่เกิดมันเลยอาจจะไม่เป็นเนื้อเดียวกันหมด (แต่เราเรียนบนหัวข้อเดียวกันคือ Object-oriented programming ทำให้หลายคนเข้าใจว่าทุกอย่างเป็นเนื้อเดียว Well-thought มาทั้งหมดแล้วถูกออกแบบมาดีแล้วแค่ทำตามพอ ซึ่งผมว่าไม่ใช่) ตรงนี้มันเป็นช่องว่างที่เราต้องใส่ไอเดียของตัวเองเข้าไป

ที่ผมแซวเรื่อง Original OOP เยอะเพราะอยากให้เห็นว่า Object-oriented มันมีหลายมุมที่เกิดในหลายยุคนะ

พอเรารู้ว่ามันมีหลายยุคแล้วได้ประโยชน์ยังไง? ตัวผมเองใช้แบบนี้

- ผมมองว่าจังหวะที่เราเริ่มสเกลทีมแล้วแบ่ง Cross-functional การมองไปมองที่ Original OOP ที่เน้นเรื่อง Domain encapsulation เป็นอะไรเหมาะสมกับโจทย์กว่า

- Code reuse strategy อาจจะประยุกต์เอาคอนเซปต์ของ Functional programming เข้ามาใช้ได้ครับ ซึ่งผมสนใจการผสมผสานตรงนี้ เพราะผมไม่ชอบ Inheritance by default เวลาคิดอะไรไม่ออก ส่วน Reuse by composition ผมว่า Function composition มัน Concise และมี Expressive power มากกว่า Object composition ครับ

181 Nameless Fanboi Posted ID:KUE.FNg5rK

วันนี้เพิ่งไปทำความรู้จักกับ Redis มาเลยจะมาแนะนำให้ฟัง https://redis.io/ (บทเรียนแบบสนุกลองไปหน้านี้ http://try.redis.io/ ครึ่ง ชม. ก็จบแล้วครับ)

มันคือ service ที่รันบนคอมแล้วเหมือนเรามีตัวแปร Dictionary, HashSet, ... มหัศจรรย์ให้ใช้ที่สามารถรุมใช้จากหลายๆ client ผ่านเน็ตได้อย่างสวยงาม ซึ่งถึงตัวแปรที่ว่าจะอยู่บน memory ไม่ได้เซฟแต่ก็มีฟังก์ชั่น replay คำสั่งให้ถึงเครื่องพังพอเปิดมาใหม่ก็มีตัวแปรสภาพเดิมได้แบบนั้นก็มีครับ เลยเอามาใช้เป็น database กันก็ดูไม่เลวไม่แคร์ความ RAM กันเลย

ความ in memory ไม่ต้องเซฟทำให้ความเร็วสูงพอที่จะใช้ algorithm ที่ไม่ค่อย scalable ใน DB ปกติได้ เช่นการ count หรือ sort (ไม่ใช่ indexing) อัตโนมัติทุกครั้งที่เพิ่มข้อมูลใหม่เข้าไป ใครเคยใช้ Firebase Cloud Firestore / RDB จะรู้สึกว่ามันน่าจะทำ scoreboard ลำบากไม่ก็เปลืองเงินมาก ส่วนมากปัญหาจะอยู่แถวๆที่ว่าอยากรู้ว่าเรา rank เท่าไหร่หลังจากเพิ่งอัพเดทคะแนนไป ซึ่ง count ก็เปลือง ถ้าจะเซฟเลขเก็บไว้เดี๋ยวมีคนแซงก็เลขเลื่อนกันหมดอีก ถ้า Firestore อัพเดทเสียเงินเป็นหน่วย document แล้วน่าจะเจ็บหนักครับ ต้องดีไซน์แผนดีๆเพื่อให้เสียเงินน้อยลงแล้วทีนี้ structure ก็จะดูไม่สวยงามอีก (เช่นต้องมี document เดียวที่มี bake คะแนน top 100 กองอยู่ด้วยกัน แล้วปัญหาอื่นอาจจะตามมา เช่นต้องคอย sync ข้อมูลหน้า avatar ที่ฝังอยู่ในนั้น ฯลฯ)

แต่คงจะง่ายกว่าถ้าแค่ใช้ Redis มาช่วย (หรืออยากใช้แต่ Redis ไปเลยก็อาจจะได้ แต่ด้วยกันน่าจะประหยัดเงินสุด) ใน Redis นี้มีตัวแปรประเภท sorted set ที่เหมือนเกิดมาเพื่อทำตารางคะแนนเลยครับดังนั้นเราแค่ใส่ๆข้อมูลเข้าไปรัวๆแล้วถามเวลาอยากรู้ก็รู้อันดับได้เลย

อยากศึกษาว่าทำไม leaderboard ถึงเป็นปัญหายาก https://redislabs.com/redis-enterpr…/use-cases/leaderboards/

ถ้าอยากลองเล่นสามารถลอง Tier ฟรีของ Redis Labs ที่สปอนเซอร์คนทำ Redis อยู่ได้ สามารถเปิดคอมกับ AWS/GCP/Azure ได้สามที่ เปิดมาแล้วมี RAM ให้ 30MB ซึ่งดูเหมือนน้อยแต่สมมติถ้า record นึง 32 bytes (~ GUID + float) ก็เก็บได้ตั้งประมาณ 900,000 คะแนนแน่ะ ถ้า trim ไว้ให้ rank แค่ top 10000 อะไรงี้ก็คิดว่าเหลือเฟือได้หลายบอร์ดเลยครับ

https://redislabs.com/

ของฟรีไม่มี data persistence ให้ ถ้าคอมรีสตาร์ทแล้วของใน RAM จะหายหมดไม่มี replay แล้วก็ connection ได้ถึง 30

แต่ถ้าไม่ใช้เป็น DB แล้วใช้เป็นตัวแปรจริงๆก็น่าจะพอไหวครับ เช่น ใช้ Cloud Firestore ในการเก็บคะแนนของแต่ละคนเป็นส่วนตัวอันนี้แบบกลัวหาย แล้ว export ไป Redis ที่ไม่กลัวหายเพื่อให้เป็นคอมที่เปิดไว้ ranking หรืออื่นๆที่ต้องยุ่งกับผู้เล่นอื่นแบบ active หน่อยโดยเฉพาะ

คิดๆไว้ว่าอาจจะสร้าง record ไว้ใน Redis ประมาณว่า "exported" เวลาอพยพไปแล้ว + trim เสร็จแล้ว ทีนี้ถ้าคอมพัง ฝั่ง Firebase ก็จะได้ถาม Redis เจอว่าไม่มี record นั้นแล้วดังนั้นอพยพอีกรอบ ถ้าอพยพเสร็จแล้วทีนี้ทุกครั้งที่มีคะแนนใหม่ก็แค่แถมไปใส่ฝั่ง Redis ด้วยจะได้ถาม rank กลับมาได้

เท่าที่ดูคร่าวๆนอกจาก Sorted Set แล้วมีฟีเจอร์เท่นึงที่ชอบคือสามารถสร้าง record ที่นับเวลาถอยหลังแล้วหายไปเองเมื่อถึงเวลาได้ครับ (EXPIRE) ดูน่าจะเอาไปเล่นได้หลากหลายดี (เช่น ทำ ranking ที่จัดอันดับทุก ชม. แทนเพื่อให้ไม่ต้อง connect ไป Redis ทันทีที่ใครซักคนทำคะแนนได้ ทำ timed challenge ในเกม ฯลฯ)

182 Nameless Fanboi Posted ID:m9KixmgCXW

"Don't underestimate the power of survival of the fittest. And don't ever make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence much too much credit."

Linus Torvalds

183 Nameless Fanboi Posted ID:tjmmFZ5Rv2

GildedRose Kata นี่เป็นแบบฝึกหัดที่ดีมากเลยนะ

คือ Engineer จำนวนมากพยายามแก้ไขปัญหา Technical Debt ด้วยการที่บอกว่า "อย่าสร้างสิ เขียนให้ดีสิ" แต่ในโลกความเป็นจริงแล้วเรามีโค้ดที่เละยังงี้เต็มไปหมด บางทีเราก็สร้างเองเพราะงานเร่ง มันเป็นอะไรที่หลีกเลี่ยงไม่ได้เลย

คำถามคือเราจะทำยังไง เวลาเจอโค้ดยังงี้

ถ้าใครบอกว่าจะ Refactor นี่ก็เป็นโจทย์ที่ดีที่จะได้ฝึก

หรือแม้แต่ถ้าใครบอกว่าเจอ Tech debt เยอะๆ ฉันจะไม่แตะแล้ว จะ Rewrite แม่งอย่างเดียว คุณก็ลอง Rewrite GildedRose ขึ้นมาดู ก็เป็นแบบฝึกหัดที่ดีอีก

คุณจะได้เข้าใจว่าการ Rewrite ในทางปฏิบัติ ที่ Requirement ส่วนมากจะไม่ครบ มันต่างกับในอุดมคติเยอะ เอาแค่ Rewrite ระบบเล็กๆ อย่าง GildedRose นี่แหละให้รอดก่อน ค่อยไปลองขอ Rewrite ระบบใหญ่ๆ

(ผมต้องเน้นเสมอว่างาน Rewrite != งาน Green field ระดับความยากมันต่างกันแบบคนละเลเวลกันเลย Engineer หลายคนคิดว่าเวลาที่ได้ใบอนุญาตให้ Rewrite ระบบที่เละๆ ใหม่จากศูนย์ มันจะให้อารมณ์สวยงามเหมือนทำ Greenfield Project ซึ่ง ขอบอกเลยว่าโคตรจะไม่ใช่)

ผมคิดว่าการจัดการกับ Legacy code เป็นสกิลที่สำคัญมาก คือผมมองว่ามันมีเส้นแบ่งที่ใหญ่มากระหว่างคนที่เขียนโค้ดสวย กับเปลี่ยนโค้ดไม่สวยเป็นโค้ดสวยได้ (ไม่ว่าจะด้วยวิธีใดๆ) คือถ้าสมมติแบ่งเป็น 10 Grade ผมว่าคนที่ทำได้กับไม่ได้ฝีมือต่างกันอย่างน้อย 2 Level แน่ๆ

และ GildedRose เป็นแบบฝึกหัดที่คุณจะได้ลองจัดการกับ Legacy Code ของจริง ไม่ว่าคุณจะเลือกจัดการมันยังไง ค่อยๆ แก้ หรือเขียนโครงใหม่จากศูนย์ก็ตาม

Repo นี้มีให้เกือบทุกภาษาให้เล่น ใครสนใจลองเล่นดูได้ครับ

184 Nameless Fanboi Posted ID:9HOuboPpuT

ใน Javascript, Typescript ผมชอบที่จะเขียน OOP ด้วย Higher-order function มากกว่า Class keyword
ผมพบว่าถ้าคุณรู้จักและใช้ Higher-order function (HOF) ตัวเดียว มันสามารถทำได้หมดเลยทั้ง Inheritance, Decorator, Annotation, Implements, Private, Public และอีกหลายๆ Keyword ที่ในหลายๆ ภาษา OOP คุณต้องเรียนทีละตัวว่าแต่ละตัวคืออะไร Inherit คืออะไร ทำงานยังไง Decorator คืออะไร ทำงานยังไง
ถ้าใช้ HOF คุณเรียนแค่ว่ามันคืออะไรตัวเดียวพอ แล้วแต่ละสิ่งข้างบน มันทำงาน Conceptually เหมือนกันหมด ส่วนในรายละเอียด อ่านโค้ดเองได้เลย ขอแค่เข้าใจ HOF
หรือแม้แต่สิ่งที่หลายๆ ภาษา OOP ไม่มีอย่าง Multiple Inheritance คุณก็ทำด้วย HOF ได้และสามารถบอกได้หมดว่าแต่ละ Conflict แก้ไขยังไง
เราเขียนโปรแกรมแบบ OOP Paradigm โดยไม่ต้องมีคำว่า "Class" ได้นะ เผื่อไม่รู้
แล้วส่วนตัว ผมคิดว่าโค้ด HOF สวยเพราะมี Language construct เดียวแต่ทำได้ทุกอย่างอย่าง Concise โค้ดก็ไม่ได้บวมด้วย และไม่ต้องจำอะไรเยอะแยะว่าไอ้นั่นคืออะไรไอ้นี่คืออะไรมากมาย ซึ่งอันนี้มักจะเป็นความเห็นที่ต่างกับหลายคนที่บอกว่าโค้ดที่ทำ HOF อ่านไม่รู้เรื่อง อ่านยาก พอมีคำว่า Class สวยกว่า
ปล. จริงๆ ผมเข้าใจได้นะว่าทำไมคำว่า Class สวยกว่าในแง่นึง และผมก็เลือกใช้กับหลายๆ ทีมที่เขา Familiar กับสิ่งนี้ไปแล้วเหมือนกัน มันก็ง่ายที่จะอ่านมากกว่ามาเรียนรู้ใหม่ล่ะ แต่ไม่อยากให้ปิดใจกับ HOF แล้วลองดูกัน

185 Nameless Fanboi Posted ID:J+X0H4d8PM

อยากตั้งคำถามให้วงการไอทีไทยอีกที นี่เป็นรอบที่เท่าไหร่ก็ไม่รู้แล้ว ทำไม Programmer ต้องโปรโมทไปเป็น SA แล้วไปเป็น PM/Mgr ทำไมเราไม่เห็น Growing Path ที่สนับสนุน Individual Contributors ในไทยนะ

ผมเห็น engineer อายุรุ่นราวคราวเดียวกัน (+/- 5 ปี) พอถึงอายุ 35 จะต้องเริ่มคิดว่าแล้วกูจะทำอะไรต่อดี เพราะอายุ 35 แล้วเนี่ยบริษัทไทยไม่ค่อยมี Path ให้ คุณต้องเลือกไป Management สักทาง ในขณะที่ใน ตปท เค้ามีโอกาสให้ Engineer โตจนเก๋าๆ อายุ 50 ปีเยอะแยะเลย
พอเราต้องแข่งกับระดับโลก เราก็ถามอยู่นั่นแหละ คนเก่งเราเยอะแยะ แล้วทำไมเราสู้เค้าไม่ได้ ก็เพราะคนเก่งเราเปลี่ยนจากเรื่องที่เค้าเก่งมาทำเรื่องที่เค้าเก่งน้อยกว่ากันหมด เพราะระบบและสังคมมันบังคับไง ด้วยความที่ไทยเราเป็นสังคมอำนาจนิยม ใครอายุ 3x ไม่ได้เป็น manager เราก็จะมองว่าเค้าไม่ประสบความสำเร็จแล้วล่ะ เราไม่ได้ให้คุณค่ากับ individual contributor มากพอ สุดท้ายถ้าเค้าไม่ยอมแพ้ให้กับระบบ เค้าก็จะพาตัวเองออกจากระบบไปเลย

อยากแข่งกับโลกต้องทำไง ดูจีนครับ เค้าให้ value กับ IC มาก มากพอๆกับ management แหละ #ช่วยตัวเองกันไปก่อนนะครับ

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