Fanboi Channel

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

Last posted

Total of 211 posts

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 แหละ #ช่วยตัวเองกันไปก่อนนะครับ

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

186 Nameless Fanboi Posted ID:iiWV5+IkmP

แอปเกมสนุกๆ เล่นได้ง่ายๆ ทำกำไรมากมายได้ตลอด 24 ชั่วโมงพิเศษสมัครใหม่วันนี้รับโบนัสทันที 50%
หากสนใจการทำเงินที่มีแต่ความสนุกสนานกดเลย!
https://www.ballinw.com/ดาวน์โหลด-live22/

187 Nameless Fanboi Posted ID:N8yR2iPBQ7

ขอจดอัพเดทความรู้ Technical ที่เก็บได้เด็ดๆช่วงนี้หน่อย

1. การวาง Structure Code แบบ "Functional Core, Imperative Shell"
ไปเรียน Testable Web API กับพี่คริส (Taskworld, Omise) มา สะดุดกับ Concept นี้มากๆ เพราะส่วนตัวชอบความ Resilience ของ OO ในส่วนของ IO ต่างๆ แต่พอมาเป็น Business Logic เราใช้ต่อ บางทีมันรู้สึกขัดความรู้สึก ไม่ว่าจะ Test ยากเอย เขียนเสร็จชื่อ Object ไม่ค่อย Make Sense เอย มีความขี่ช้างจับตักแตนอยู่ พอมาฟังพี่คริส Demythify เรื่องนี้ Concept มันดู Eureka จริงๆ

2. ด้วยเหตุข้อ 1 Typescript มันดูหล๊อหล่อขึ้นมาทันที ด้วยความที่มันลดความบ้านป่าเมืองเถื่อนของ Javascript ในจุดที่เราต้องการได้

3. ขึ้น Project ใหม่ ยุคนี้ หาข้ออ้างไม่ทำ CI/CD ยากละน้า นั่งลองเล่น Cloudbuild ต่อเข้า Github แล้ว Deploy ลง App/Kubenetes Engine กดๆแปปเดียวเสร็จ เข้าใจง่าย Integration Test ก็ทำไว้ใน Cloudbuild ได้หมด และ Infra as a code มันชีวิตง่ายขึ้นจริงระบุ Instance เอาขึ้น เอาลง Scale ไป Size เท่าไร ชีวิต Dev Happy

4. เช่นเดียวกันทำ Web / App ให้ Scalable ก็มาในยุคที่ Cost ถูกลงมาก (ทั้ง Cost Infra / Operation) เครื่องไม้เครื่องมือพวก Queue, Message พวกนี้ Cloud Provider มีให้ใช้ง่ายๆทุกเจ้าแล้ว

5. Concept ของพวก Distribution System อย่าง At least/Exactly Once semantic,Idempotent, Redundancy หรือกระทั่งการทำ Event Storming อันนี้น่าศึกษาไว้ Even กับ Role อย่าง Product Owner / Manager ก็ตาม

188 Nameless Fanboi Posted ID:rN.oRvueE4

ตอบในฐานะ SA นะครับ เรื่อง Set สำคัญกับการออกแบบระบบมาก เพราะปัจจุบันการเขียน Software จะให้ความสำคัญกับ Bussiness Rule มากกว่าการ Modeling ถ้าคุณอยากเขียนซอฟแวร์ในระดับลึกมันไม่ใช่การใช้ Api ชาวบ้านอีกต่อไป มันคือการสร้าง Architect ครับ
.
Set มีบทบาทยังไง การที่จะเขียนโปรแกรมให้ตอบโจทย์ Bussiness เราจะต้องมี Context กับ Operation ให้เหมาะสม ดังนั้นการเขียนโปรแกรมที่ Generic มาก ๆ ที่ชอบทำกันเนี่ย มันไม่ใช่ผลดีกับระบบ เราต้องแบ่ง Context ของระบบให้แก้ปัญหา Bussiness ให้ได้
.
แล้วอะไรจะใช้คำนวณว่าเราออกแบบ Class ได้ตรงความต้องการของระบบไหม คำตอบคือ Set ครับ
.
เช่น
A { x | ILoginService }
หมายความว่า เราสนใจ Elements ของ ILoginService
.
ทีนี้เรา Specific ได้แล้วว่าอะไรคือ Service ที่กำลังพัฒนา ต่อมาที่เราต้องเช็คคือสิ่งที่อยู่ใน Set มีความสำพันธ์กันอย่างไร
.
สมมติ A { LineLogin, FacebookLogin }
สมมติมี Service อยู่สองตัว ทีนี้เราหาความสำพันธ์ของมัน
.
ถ้ามันเป็น Isolation เคสเพราะนี้เป็น A+B ก็คือ
ต่อมาเราก็สนใจที่ตัว Elements ของ set ค่อยๆ ไล่ไปทีละตัว
.
การออกแบบ Class เราต้องนึกถึง 1. Relationship, 2. Multiplication, 3. Communication
.
ทีนี้เราสนใจลึกลงไปอีก step
เช่นผมสนใจ A { x | FacebookLogin }
.
ทีนี้ Set ของเราจะเป็น Aggregation ของ FacebookLogin
.
ดังนี้ FacebookLogin { TokenValidator, SendValidRequestEvents } ( ของจริงเยอะกว่านี้ นี่แค่ยกตัวอย่างมา 2 อัน )
.
ทีนี้ความสัมพันธ์มันเป็น AB คือ Existence Dependency ถ้าตัวไหนพังก็พังทั้ง Service
.
Event ของสองตัวนี้เป็นแบบ Sequence คือต่อกัน
คือ Validate input แล้วค่อยส่งไป Server
ทีนี้เราก็มาวิเคราะห์ว่าจะใช้ Pattern ไหนในที่นี้ใช้ Middleware Pattern เพราะ Flow input เป็นแบบ Sequence
.
เราก็ไล่ออกแบบไปเรื่อยๆ ตามนี้ ซึ่งความยากคือ Entity ของระบบมันมี Invariant ต่างกัน Aggregate ต่างกัน Concurrency ก็ต่างกันอีก
.
ในโลก Software คือความยากมันไม่ใช่แค่คณิตศาสตร์ มันคือ Concept มหาศาล หลากหลาย Principal แต่ที่ผมจะบอกคือเรื่อง Set เนี่ยมันทำให้เรามองเห็น Domain ที่กำลังจัดการอยู่ให้ชัดขึ้น ทีนี้เราจะมอง Dependency ออก มอง Communication ออก ที่เหลือก็ไปว่ากันที่ Pattern กับ Persistence
.
ถ้าคุณแยก Domain ไม่ออก อย่าพูดถึง Design Pattern เลย ปนกันมั่วแน่นอน
ไอ้สูตร Set ที่คุณเรียนกันตอนม. ปลายนี่แหล่ะ เคสที่มันได้ใช้
.
Cohesion กับ Coupling ก็ Set
ถ้าระบุ Set ไม่ได้ Object มันก็คุยมั่วไปหมด หา Boundary ไม่เจอ
.
จริงๆ ยังมีมากกว่านี้อีก ผมยกตัวอย่างแค่ Service เดียวเอง เผื่อพอเป็นไอเดียว่าคณิตศาสตร์มันไม่ใช่แค่ผูกกับการแก้สมการอย่างเดียวมันมีมุมมองอื่น ๆ ด้วย
.
Code ที่แก้สมการในระบบมันคือ Behavior ของ Class กับของ Service ที่เราสนใจแค่นั้นเอง ว่าจะแก้ยังไง ไม่ใช่แค่หน้าที่ของ Dev แต่หมายถึงการสื่อสารระหว่าง Dev กับ Domain Expert ในด้านนั้น ๆ เพื่อร่วมกันแก้ปัญหา
.
สุดท้ายกับคำถามที่ว่า “เป็นโปรแกรมเมอร์ใช้คณิตศาสตร์กี่ %”
1. Empirical Expression
2. Numerical Expression
นี่แหล่ะสองสิ่งที่คุณจะใช้

189 Nameless Fanboi Posted ID:H.2gEPSKN8

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

190 Nameless Fanboi Posted ID:kKPvrhZOLi

>>189 ถ้าจะมาเป็น dev ทำงานจริงจำเป็นกว่า

191 Nameless Fanboi Posted ID:2IjyEbqevB

ปรึกษาหน่อยค่ะ

192 Nameless Fanboi Posted ID:On/WDCA26e

หนึ่งในเรื่องสำคัญที่หลายต่อหลายคนมองข้าม ก็คือ "พิมพ์ดีด"

ต้องฝึกให้คล่องนะ อย่างน้อยๆ นี่ 30 คำต่อนาทีขึ้นไปควรจะได้ ไม่งั้นจะ inefficient มากในการทำงาน

และแน่นอนว่าการพิมพ์ที่ดี ควรพิมพ์ได้โดยไม่ต้องมองแป้นพิมพ์เลยแม้แต่นิดเดียว

ไม่เช่นนั้นก็จะมี interruption ของกระบวนการคิดเกิดขึ้นตลอดเวลา ... สมองจะต้องทำ context switching ระหว่างคิดสิ่งที่จะต้องพิมพ์ และการมองคีย์บอร์ดตลอด ทำให้คิดอะไรซับซ้อนและต่อเนื่องลำบาก .... คิดอะไรได้ไม่เท่าไหร่ ก็ต้องเปลี่ยนโหมดมาดูแป้นพิมพ์แล้ว ...

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

โปรแกรมฝึกพิมพ์ดีดดีๆ นี่ช่วยได้เยอะมากเลย

โปรแกรมที่ผมชอบมาก ก็คือ GNU Typist (gtypist) .... ที่มีลำดับในการสอนที่ดีมาก และมีปรัชญาในการสอนที่ดีเลย ก็คือแทนที่จะเน้นไปที่พิมพ์เร็ว .... เขาจะเน้นที่จังหวะการพิมพ์ (rhythm) และความถูกต้อง .... ถ้าพิมพ์ข้อความแล้วผิดเกิน 3% นี่จะไปต่อไม่ได้ (และผิดแล้วผิดเลย แก้ไม่ได้)

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

อ่อ แล้วการคิด WPM (Words-per-Minute) ของมัน จะเอาจำนวนที่เราพิมพ์ผิดมาคิดด้วย ว่าจริงๆ แล้วเราพิมพ์ได้กี่คำต่อนาทีกันแน่

จะเห็นว่าในรูปแรก ผมพิมพ์ถูกหมด WPM ก็เป็นไปตาม Raw speed (95 WPM) แต่รูปที่สองนี่มีผิดอยู่หน่อย (2%) ทำให้แม้ว่าจะพิมพ์ที่ Raw speed 83 WPM ก็ถูก adjusted เหลือ 75

ที่สำคัญที่สุด คือมันทำบทเรียนหรือแบบฝึกหัดเองง่ายมาก ..... อย่างรูปสุดท้าย นี่ผมเอาโค้ด Haskell ที่ผมเขียนไว้สอนใน Workshop หนึ่งมาเป็นแบบฝึกหัดเลย

เอาไว้ให้พวกเด็กฝึกงานหรือพนักงานใหม่ฝึกพิมพ์ดีดไปกับสไตล์การเขียนโค้ดที่ใช้ในทีมได้เลย

193 Nameless Fanboi Posted ID:mEaJ6TxBLG

Redis ได้เงินลงทุนรอบใหม่ มูลค่ากิจการเกิน $1 billion แล้ว unicorn ของจริงช่วงนี้มีแต่สาย technical

ในไทยหาคนยังหาที่เคยใช้เยอะๆคุยด้วยได้ไม่กี่คน มันดีมากจริงๆ ยิ่ง module ที่ทำจริงจังช่วง 3-4 ปีหลังนี้ ทั้ง graph, timeseries, search คือดีทั้งหมด ถึง feature จะไม่เยอะเท่าคู่แข่งแต่ใช้ง่ายกว่ามาก เสียดายยังไม่มีโอกาสได้ลองใช้ redisAI ที่เพิ่งออกมาใหม่ไม่นาน เพราะงานตอนนี้ไม่ได้ทำเรื่อง ML, AI หรือ Data โดยตรงแล้ว

194 Nameless Fanboi Posted ID:Z0x2Ht2SpO

>>193 quote เก่าแล้วป่าววะ กูเห็นใครๆก็ใช้

195 Nameless Fanboi Posted ID:NUAlkwJ4cO

ส่วนตัวเราคิดว่าอีก 10-20 ปีข้างหน้า งานเขียนโปรแกรมจะเหมือนงานเขียนหนังสือ ที่ในปัจจุบัน ทุกคนเขียนหนังสือเป็นหมด แต่ไม่ใช่ทุกคนที่จะเป็นนักเขียนที่สามารถเขียนงานเขียนที่ดีจนทำเป็นอาชีพได้

อนาคต ทุกคนก็จะเขียนโปรแกรมเป็นหมด แต่โปรแกรมเมอร์ที่เขียนได้ดี ก็จะยังมีงานทำอยู่ดี

196 Nameless Fanboi Posted ID:RjknmBsvAI

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

"เดี๋ยวนี้สงสัยไม่สอนเรื่องนั้นเรื่องนี้"
"ทำไมไม่สอนเรื่องนั้นเรื่องนี้"
"ต้องให้ความสำคัญกับเนื้อหานั้นนี้มากกว่านี้"

ฯลฯ

ผมว่าผิดทางครับ ..... ปัญหาไม่ใช่เนื้อหา หรือการมองเห็นความสำคัญว่าจะต้องสอนหรอกครับ ......

ปัญหาใหญ่กว่านั้นคือ "วิธีการสอน" และ "วิธีการเรียนรู้" ครับ

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

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

ส่วนหนึ่งก็เพราะคนสอนก็จะถูกบังคับให้ต้องสอนเรื่องนั้นเรื่องนี้ให้มีเนื้อหาเรื่องนั้นเรื่องนี้อย่างเร่งด่วน ปีนี้ยัดเนื้อหา ปีหน้าต้องสอน อะไรแบบนี้เป็นต้น ....

คนสอนก็ทำอะไรไม่ได้ นอกจากสอนตามตัวอักษรและวิธีการในเนื้อหาแบบเป๊ะๆ เพราะตัวเองก็ไม่ได้เล่น ไม่ได้ตั้งคำถามอะไรเหมือนกัน ....

เข้าทำนอง ..... คนสอนก็ต้องจำไปสอน ท่องแบบนกแก้วนกขุนทอง พูดได้เป๊ะแต่ไม่รู้เรื่องรู้ราวรู้บริบทอะไร .... ในขณะที่คนเรียนก็เหมือนเครื่องถ่ายเอกสาร .... ที่อ่านเอกสารไปเขียนลงข้อสอบ แล้วก็ลืมไป (เครื่องถ่ายเอกสารไม่มี Hard disk ที่เก็บข้อมูลถาวร มันก็จะจำไว้แค่ช่วงเวลาที่มันต้องถ่ายเอกสารเท่านั้นแหละ หลังจากนั้น "มันก็คืนคนที่เอามาถ่ายไปหมด" -- คุ้นๆ ไหม ... "เรื่องนี้ผมคืนอาจารย์ไปหมดแล้ว")

ยิ่งเราบอกว่าต้องสอนเรื่องนั้นเรื่องนี้เพิ่มเข้าไปไม่มีที่สิ้นสุด ปัญหานี้ก็ยิ่งหนักขึ้นทุกวัน

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

ปัญหาคือ "วิธีการสอน" และ "วิธีการเรียน" แหละครับ

มีแค่นี้จริงๆ

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

[Slide Story] น้องๆ และสหายหลายต่อหลายคน ที่มาเรียนเรื่อง Maths for Working Programmers และ Functional Programming กับผม หลายคนที่ยังใกล้ชิดมหาลัยอยู่ก็พยายามจะไปบอกให้มหาลัยสอนเรื่องพวกนี้บ้าง ...

ผมก็ต้องเตือนน้องๆ และมิตรสหายเหล่านี้เสมอว่า "สอนเรื่องนี้แบบผม เรียนเรื่องนี้แบบที่น้องเรียนกับผม น้อง/คุณก็อินแล้วก็สนุกแหละครับ" ....​ "เนื้อหาพวกนี้ มีในหลักสูตรนะ เรื่องนี้อยู่ตรงนี้ เรื่องนั้นอยู่ตรงโน้น ฯลฯ" .... เห็นไหม มีนะ ไม่ใช่ไม่มี ฯลฯ

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

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

รูป: นกแก้วบนเครื่องถ่ายเอกสาร ..... รูปที่อยู่ใน presentation slide ที่ผมเคยใช้บ่อยมาก เดี๋ยวนี้ไม่ค่อยได้พูดเรื่องนี้แล้ว

197 Nameless Fanboi Posted ID:/D5kF8KFla

ใน reddit มีคนเอามาแปะ ก็เล่าไปใน reddit แล้วเอามาเล่าให้คนไทยฟังบ้าง

ที่ Wongnai ใช้ ArgoCD อยู่มันจะเป็น step แบบนี้ครับ

1. project build & push docker ใน gitlab ci
2. step สุดท้ายของ ci เรามี tool มา clone ceylon (deploy manifest) repo, create branch, update image tag, push branch แล้วเปิด merge request (MR)
3. tool มันจะ mark MR ให้ auto merge on pipeline success เป็นอันจบ pipeline ของ project
4. pipeline ของ MR ที่เข้า ceylon มี tool validate (หวังว่าจะมีเวลา open source ให้) มันจะ run ArgoCD template ได้ JSON มาแล้วโยนเข้า kubeval
(แปลว่ามี check 2 ที่ คือ Jsonnet assert สำหรับ best practice check + kubeval เช็คว่า valid)
5. MR merge เสร็จแล้ว argocd auto sync ยกเว้น prod ต้องกด sync เอง

ฉะนั้นจากในบทความนี้เราเลยไม่ค่อยเจอปัญหาเหมือนเค้า

1. ผมเข้าใจว่าเค้า clone แล้ว push master แข่งกัน มันเลย race แต่เราเปิด MR แล้วให้ gitlab merge มันเลยไม่ต้องแย่งกันเพราะเราไม่ได้ตั้งให้ rebase ก่อน merge
จะมี race ก็คือ MR project เดียวรัน 2 อันพร้อมกัน อันนี้ช่วยไม่ได้นอกจากไปตั้ง Gitlab ว่าให้ยกเลิก pipeline เก่าเมื่อมีอันใหม่กว่า (ซึ่งเราไม่ได้เปิด)
2. เราใช้ deployment monorepo แถม branch เดียวทุก env ด้วย เลยไม่มีปัญหาว่า repo เยอะ งง
ทีมบ่นอยู่บ้างว่าอยากได้ branch เพิ่มจะได้ทดลองของได้โดยไม่กระทบ prod อันนี้ยังมองๆ อยู่ว่าจะทำยังไงไม่ให้มันระเบิดแบบเค้า
3. Visibility ยากนี่เรื่องจริง มี git log ก็จริงแต่ไม่รู้ว่ากด sync ใน ArgoCD ตอนไหนต้องไปค้น ArgoCD log
4. Validation เรามี validate tool เลยชิล

ปัญหาที่ผมเจอจริงๆ น่าจะเป็นว่า

1. Rollback ยากมาก คือต้องถอย commit ออก แต่พอ change มันเป็นแค่ปรับ image tag มนุษย์ทั่วไปเข้าใจไม่ได้ว่าถอยเท่าไรถึงจะหายบั๊ก (ถอยโค้ดยังอ่าน commit message พอได้) แล้วมันหลายขั้นตอนมาก คนเลยชอบไปกดใน ArgoCD ซึ่งมันทำให้ decouple cluster state ออกจาก git state หรืออีกทีคือถอย commit ในแอพเลยแล้วรอ build ซึ่งนานมากกกกก
2. Post deploy step ทำยากมาก เช่น deploy dev เสร็จแล้วรัน automate test ไม่รู้จะเช็คยังไงเลยว่า deploy ยังไง (MR merge แล้วแต่ก็ต้องรอ sync + pod rollout) ที่ทีมทำกันอยู่มีแต่ท่า hackๆ

198 Nameless Fanboi Posted ID:0yCFcOKe8j

>>197 wongnai ไปทำไรใน reddit

199 Nameless Fanboi Posted ID:m4O69XJjXm

สองสัปดาห์ที่ผ่านมาประชุมเยอะขึ้นมากๆ แต่รู้สึกว่าได้ทำงานเป็นชิ้นเป็นอันจากการประชุม ไม่ได้รู้สึกว่ามัวแต่ประชุมไม่ได้งาน

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

ผมเริ่มเห็นว่าการประชุมแบบนี้ Effective ต่ำและกินพลังงานเยอะ ไม่ได้แปลว่าควรเลิก แต่แปลว่ามีช่องให้พัฒนาได้เยอะ

ในโดเมนการพัฒนาซอฟต์แวร์ เครื่องมือที่สร้างความมั่นใจที่ดีที่สุดคือ Working software รองลงมาคือ Demo ส่วนการทำสไลด์หรือการพูดคุยย้ำๆ ว่า โปรเจ๊กต์ยังไปได้ งานยังดี อันนี้สร้างความมั่นใจได้น้อยกว่าอย่างมาก แถมยังต้องพูดย้ำบ่อยๆ แล้วเปลืองเวลา

จะพบว่าเวลาคุณรัน Agile, Scrum, etc. แล้วคุณต้องสร้างความมั่นใจทุกๆ สองอาทิตย์ มันจะบังคับให้คุณต้องมี Demonstratable Progress ในเลเวลนั้น

และมันจะกระทบไปถึงวิธีเขียนโค้ด Process การทำงาน การวางโครงสร้าง

พอมาถึงหัวข้อนี้ ผมไม่ Buy เลยว่าพอทำ Scrum แล้วจะทำให้ Architecture ห่วย แต่มันต้องใช้ Architecture style และ Mindset ที่ต่างกัน

เช่น หลายคนเชื่อว่าคุณสมบัติของ Fundamental Architecture ที่ดีคือสิ่งที่ทำครั้งเดียวแล้วทนทานใช้ได้ตลอดกาล ซึ่งพอเปลี่ยนวิธีทำงาน คุณสมบัติที่สำคัญกว่าในการทำงานแบบ Agile (ที่มี Feedback loop สั้น) ถ้าต้องแก้ แก้ง่าย ทุกคนแก้ได้หมด เป็นคุณสมบัติที่มี Priority สูงกว่าความทนทานใช้ได้ไม่มีวันพังไม่ต้องแตะ ในโลกแบบ Agile

เขียนไปเขียนมาแตกหัวข้อไปหลายเรื่องแฮะ ขอสรุปหน่อยว่า Reflect อะไรได้บ้าง

- การประชุมเป็นเครื่องมือที่คนนิยมใช้เมื่อต้องการ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง" แต่ มันเป็นเครื่องมือที่ Effective ต่ำมาก ถ้าประชุมอันไหนมีหน้าที่แค่ "รายงานให้คนเกี่ยวข้องสบายใจ" แปลว่ามี Room for improvement เยอะมาก อย่างเลเวลแรก จากสไลด์ 30 นาที คุณเปลี่ยนเป็นทำเป็นเดโม 5 นาที ได้ความมั่นใจมากกว่าโดยใช้เวลาน้อยกว่าเยอะ ถ้าเปลี่ยนเป็นแค่ Deploy working software แล้วบอกให้คนเกี่ยวข้องมาลองเล่นเองได้ ยิ่ง Effective เลยใช่มั้ย และสิ่งที่ Effective ที่สุดคือ ทำให้เขาเชื่อมั่นจนเขาบอกเองว่า "ไม่ต้องอัพเดทพี่แล้ว พี่ไว้ใจทีม มีอะไรให้พี่ช่วยมั้ย ถ้าไม่มี พี่เอาเวลาไปทำอย่างอื่นดีกว่าว่ะ" อันนี้คือ End game และตราบใดที่ยังไม่ถึงตรงนี้ เรายังสามารถหาทางดิ้นเพื่อพัฒนาได้เรื่อยๆ

- พอพัฒนาข้อแรกมันจะมากระทบ Process การทำงาน ไปจนถึงโค้ดที่เขียนแต่ละบรรทัดเลยนะ ซึ่งไม่เป็นไร กระทบก็กระทบ ผมไม่เห็นว่าเสียหายอะไร แต่ต้องเข้าใจว่ามันกระทบ ซึ่งบางครั้งกระทบไปลึกซึ้ง ถึงนิยามว่า Practice ที่ดีไม่ดีคืออะไร Architecture ที่ดีไม่ดีคืออะไร นิยามและความเข้าใจมันจะเปลี่ยนได้

เอาจริงๆ ผมขอบคุณประสบการณ์ตัวเองและอาจารย์ที่สอนสั่งมาหลายท่านว่าธุรกิจเขาคิดอะไรกัน คือผมมีประสบการณ์ในวงการ Startup ที่มี Exposure โดยตรงกับผู้เกี่ยวข้องมาตลอด ทำให้เวลาผมเรียงลำดับความเสี่ยงที่ทำให้โปรเจ๊กต์ล้มเหลวได้ ผมเรียงว่า
1. ทำไม่ได้ทรัพยากรไม่พอ อันนั้นลำดับหนึ่ง
2. ทำไปทำมา ระหว่างทางคนลงทุนขาดความมั่นใจจนถอนทุนแคนเซิลโปรเจ๊กต์ อยู่ลำดับสอง

แล้วปัญหาที่แบบวางโครงสร้างไม่ดี วางโค้ดไม่ดี ใช้ Tech stack ผิดแล้วล้มเหลวต้องแก้ไข ผมมองว่าเป็นความเสี่ยงลำดับล่างๆ อาจจะเกิน 10 ด้วยซ้ำไปมั้งถ้าแตกหัวข้อจริงๆ

ผมเลยไม่มีปัญหากับการ Bend ตัวโค้ด สถาปัตยกรรม โครงสร้าง เพื่อแก้ความเสี่ยงข้อ 2 ทำไงก็ได้ให้ทำให้คนเกี่ยวข้องมั่นใจไม่ถอนทุน ถ้าต้องมี Automated test ก็ต้องมี ถ้าต้องมี Evolutionary architecture ก็ต้องมี ถ้าวางอะไรลงไปแล้วต้องแก้ทีหลัง ก็ต้องทำ (ตรงนี้มันเถียงกับความเข้าใจผิดของหลายๆ คนได้อีกว่า การทำ Engineering practice ห่วยๆ จะทำให้ปั่นงานเร็วกว่า มีอะไรไปอัพเดทสร้างความมั่นใจบ่อยกว่า ซึ่ง ผมว่าไม่ใช่)

ซึ่งผมมองว่ามันเสี่ยงกว่าเรื่องที่ว่าเลือก Tech stack ผิด เลือกภาษาผิด แบบคนละเรื่องเลยนะ พวกนั้นไม่ทำให้โปรเจ๊กต์พัง แค่ทำให้เหนื่อยเฉยๆ อ่ะครับ

200 Nameless Fanboi Posted ID:sGsDjKKpCs

ความเข้าใจผิดที่เห็นบ่อย

"การเลือกใช้ RDBMS แล้วทีมพัฒนาจะคิดเรื่อง Schema ให้ดี วางแผนเรื่องข้อมูลเยอะๆ แล้วเราจะได้ Structure ของข้อมูลที่ดี"

ผมคิดว่าการใช้ RDBMS โดยคาดหวังผลลัพธ์ว่าจะได้บังคับทีมพัฒนาให้คิดเรื่อง Data structure ให้ดีก่อนทำอะไร ไม่เคยได้ผลจริงเลย

อันนี้มักจะเป็นความเข้าใจของคนที่ดูแลฐานข้อมูลหรือ Infrastructure แต่ไม่ได้ร่วมงานกับทีมพัฒนา ที่ว่าพอเสนอ Field Migration แล้วถูกตั้งคำถามจากฉัน เขาจะได้คิดดีๆ ก่อนเสนอ แล้วเราจะได้มี Data schema ที่งดงามไม่ Bloat โอ้ มันช่างดี มันต้องได้ผลแน่ๆ

ในความเป็นจริงผมเห็นมาหลายระบบแล้ว พอคุณทำให้ Field Migration มันยาก คนไม่ได้คิดให้ดีก่อนเสนอ Schema change ครับ คนเขาจะพยายาม Reuse field เก่ามาใช้หลายๆ อย่างแทนครับ เพราะเขามานั่งรอคุณตั้งคำถามไม่ได้ เขามีงานที่ต้อง Deliver

สิ่งที่เกิดขึ้นคือเราจะมีฟิลด์ที่มีหลายความหมาย ซึ่งไม่ใช่การออกแบบที่ Data ที่ดีเลยแม้แต่นิดเดียว

นั่นคือ Actual consequence ไม่ใช่การที่คนคิดให้ดี แต่เป็นการที่คนขี้เกียจทำไปเลย

แต่ถ้าคนที่เสนอสิ่งนี้ ไม่ได้อยู่ในทีมพัฒนา เช่น อยู่ในองค์กรที่มี DBA แยกกันกับทีมพัฒนาอย่างสมบูรณ์จนกระทั่งไม่รู้เลยว่าข้อมูลพวกนี้ไปใช้ในส่วนไหนของซอฟต์แวร์บ้าง จะไม่รู้ไง เห็นว่า Database schema/Structure เหมือนเดิม ก็เข้าใจผิดไปว่านี่คือออกแบบ Data มาดีแล้ว

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

จนกระทั่งต้องเริ่มทำ BI ถึงจะเห็นปัญหาว่าอ้าว ฟิลด์นี้มันหมายถึงหลายอย่างเลยนี่หว่า จะเอาไป Analyze ยังไงล่ะ

RDBMS มีประโยชน์หลายอย่างมากๆ ผมก็ชอบ RDBMS แต่ผมไม่เห็นด้วยกับเคลมที่ว่า พอใช้ RDBMS แล้วจะบีบให้ทีมคิดให้ดีก่อนทำ Database schema ไม่เคยเห็นเกิดขึ้นจริงมาก่อน

นี่คือเหตุผลหนึ่งที่คนทำงาน Infra ควรจะอยู่ในทีมพัฒนา ไม่ใช่แยกกันทำงาน ฉันดูแลระบบ แกพัฒนา พอมันแยกกัน ความเข้าใจผิดก็เกิดขึ้นได้ง่ายมาก

201 Nameless Fanboi Posted ID:AKwUc3NDXR

ไปร่วมชุมนุมปลดแอกไม่ได้ว่าอะไร แต่ถ้าหัดเขียน PHP ไล่ออกจากบ้านแน่ไอ้อ้วน

202 Nameless Fanboi Posted ID:FhaoUngMmK

โดนปลุกมา zoom ฟังประชุมอันนึงคุ้มค่ามาก สรุปสั้นๆ Dev ที่เข้าใจ DeFi จะมีค่าตัวแพงมาก Dev ทั้งหลายจงไปลอง Uniswap , Compound , Sushiswap ให้เข้าใจกลไกอย่างถ่องแท้กันเถิด

203 Nameless Fanboi Posted ID:GdMXKWnKPv

ด้วยความเคารพ

Imperative “ไม่เท่ากับ” Loop
Functional “ไม่เท่ากับ” Map, Reduce

โว้ยยยยยยย

#ขอระบายหน่อย
#เจออะไรโง่ๆมา
#แค่เปลี่ยนLoopเป็นMapก็เขียนFPแล้ว

204 Nameless Fanboi Posted ID:Y2bsOizXKo

การศึกษาเรื่อง Deep Learning ในปัจจุบัน เรื่องแรกๆที่มักศึกษากันคือ "Computer Vision" ที่ใช้ Deep Learning ในการแปลผลด้วยเทคนิคต่างๆ ทำไมต้องเป็น "Computer Vision"?
ในยุค Cambrian (500+ ล้านปีก่อน) เป็นช่วงที่มีการเกิดขึ้นของสิ่งมีชีวิตที่เป็นสัตว์ (ไม่ใช่พืช) มากขึ้นอย่างชัดเจน เนื่องจากในช่วงนี้มีวิวัฒนาการที่สำคัญคือการรับรู้แสง หรือการมองเห็นนั่นเอง
การมองเห็นทำให้สัตว์ที่มีวิวัฒนาการด้านนี้เพิ่มจำนวนขึ้นอย่างมาก เนื่องจากการมองเห็นทำให้ หาอาหารได้ดีกว่า หลบหลีกศัตรูได้ดีกว่า และสามารถหาคู่เพื่อสืบเผ่าพันธ์ได้ดีกว่า ทำให้เกิดสายพันธุ์ของสิ่งมีชีวิตเกิดขึ้นมากมายอย่างเห็นได้ชัด
การจะพัฒนา Deep Learning ให้มีความฉลาด จึงเริ่มที่ Computer Vision เพราะเมื่อเครื่องจักรเข้าใจสภาพแวดล้อมในอย่างที่มนุษย์เข้าใจ (ด้วยการมองเห็น) ก็จะพัฒนาความฉลาดได้คล้ายคลึงมนุษย์ในอันดับต่อไปของการพัฒนา
เรื่องนี้ต่างจากการศึกษา Machine Learning หรือ Artificial Intelligence ในช่วงแรกที่มุ่งไปยัง "ความฉลาด" ที่มนุษย์มักคิดว่า "ฉลาด" เช่น กิจกรรมบางอย่าง แบบ เล่นหมากรุก เป็นต้น ซึ่งทำให้เราหลงทางในการพัฒนาด้าน AI ไปราวๆ 3 ทศวรรษ
บทความนี้ไม่ค่อยเกี่ยวกับ AI แต่เกี่ยวกับยุค Cambrian ที่มีความสำคัญต่อแนวคิดด้านการศึกษา AI

https://stem.in.th/kylinxia-zhangi/?fbclid=IwAR1YPs5oc1t-Nly1YGQX3sB9a7RDfA5o3HSyBUhReKTLKi2OitKmsh_YFxQ

205 Nameless Fanboi Posted ID:E2E2zlSyyd

>>204 มึงคิดได้ไงวะ แบบนี้ต้องมีการสูญพันธุ์ครั้งใหญ่ด้วยมะ พวก ai ที่เสียโอกาสจะได้มีโอกาสในการวิวัฒนาการ

206 Nameless Fanboi Posted ID:KKresiBSpf

พวก great dying ส่วนมากมันจพมาแบบสุ่ม

207 Nameless Fanboi Posted ID:Sqkl7T1fPA

>>206 ถ้ารู้ล่วงหน้ามันก็ไม่ตายกันดิคุณ

208 Nameless Fanboi Posted ID:RdjEjvbRqb

2020 Reflection - ปีแห่งการปล่อยวางความคาดหวังและอยู่กับความจริงมากขึ้น 🌧❤️

(ปกติไม่ได้เขียน แต่ก็มีคนสะกิดให้เขียน 555 แล้วก็รู้สึกว่าอ่านของคนอื่นสนุกดี อยากเขียนเก็บไว้อ่านทีหลังบ้าง)

...

📌 แบบสรุป

เป็นช่วงที่ได้หยุดพักบ้าง หลังจากทำงานเหมือนวิ่งไม่ได้หยุดมานาน เพื่อที่จะทำเป้าหมายธุรกิจให้สำเร็จ แต่ว่าเพราะหลายๆ อย่างไม่เป็นไปตามที่คาดหวังไว้ ทำให้รู้สึกผิดหวัง และเกิดความสงสัยในตัวเอง แล้วก็อยู่กับความเจ็บปวดไม่น้อย แต่ก็กัดฟันสู้มาจนธุรกิจรอดปี 2020 มาได้

โชคดีที่ได้มีโอกาสหยุดพักทบทวนตัวเอง ทำให้เห็นชัดขึ้นว่าโลกนี้มีสิ่งที่ควบคุมไม่ได้เยอะแยะ รู้สึกปล่อยวางได้มากขึ้น มีความสุขมากขึ้น และพร้อมที่จะลุยต่อ :)

...

📌 แบบยาว​ 😂

🌪 #มรสุมใหญ่เข้ามาแบบไม่ทันตั้งตัว

ด้วยความประมาทที่วางแผนทางการเงินของบริษัทไม่ดีพอ เจอ timeline การขอใบอนุญาตที่ยาวอย่างคิดไม่ถึง ประกอบกับการที่เชื่อมั่นในดีลที่ยังไม่ได้มีสัญญาชัดเจนมากเกินไป ทำให้มองข้ามความเสี่ยงที่ดีลจะล้มไป กลายเป็นต้องเจ็บหนัก เพราะรีบย้ายออฟฟิศและ scale ทีมขึ้นเร็วเกินไป ทำให้ได้เรียนรู้เรื่องความสำคัญของการวางแผนการเงินและเผื่อ worst case ไว้เลย อะไรก็เกิดขึ้นได้จริงๆ 😂

209 Nameless Fanboi Posted ID:RdjEjvbRqb

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

🛣 #ตามหาทิศทางของบริษัท
ในช่วงที่กัดฟันเพื่อทำบริษัทให้อยู่รอด ก็เริ่มเห็นว่าการ consult หรือ outsource ระบบ IT ด้านการเงินเป็นที่ที่มีความต้องการค่อนข้างสูงและสามารถทำเงินให้กับบริษัทได้ดีและเติบโตได้ระดับหนึ่งเลย

แต่ว่าเราและทีมก็ยังรู้สึกว่ามันไม่ใช่ทาง รู้สึกว่า passion ของเรา เป็นการสร้าง product ที่ได้มีโอกาสดูแล คุยกับลูกค้าและกำหนดทิศทางเองมากกว่า ทำให้รู้สึกขัดกับการรับ consult ที่ทำอยู่

👨‍💻 #ตามหาโอกาสใหม่ๆในHackathon
เพื่อที่จะเรียนรู้อะไรใหม่ๆ ในขณะเดียวกันก็จะได้รู้จักคนใหม่ๆ ก็เลยไปลงแข่ง Hackathon หลายรายการ ซึ่งก็ต้องขอบคุณเพื่อนร่วมทีมที่ทำให้ได้รางวัลใหญ่มา 2 รายการในปีที่ผ่านมา ทำให้ได้มีโอกาสได้ไปร่วมงานเพิ่มกับอีกหลายๆ Project เลย คุ้มค่ามากจริงๆ

ต้องขอบคุณคนรอบๆ ตัวเราที่นำพาเราไปเจอสิ่งดีๆ เยอะแยะเลย

⏸ #ได้มีโอกาสกลับมาอยู่กับตัวเองมากขึ้น
หลังจากรับ consult มาตลอดก็มีโอกาสได้หยุดพัก เลยคุยกับทีมให้หยุดพักกัน 2 สัปดาห์เลย หลังจากที่วิ่งไม่เคยหยุดนานมาก

ตอนนั้นก็เลยตัดสินใจไปลองปฏิบัติธรรมแบบยาวๆ ที่อยากลอง แบบที่ไม่มีมือถือหรือ internet ตลอด 10 วันเลยทำให้ได้อยู่สังเกตตัวเองมากขึ้น ได้เห็นว่าจริงๆ ตัวเองขี้โมโหกว่าที่คิดมากๆ เพราะความคิดที่ว่า สิ่งต่างๆ จะต้องเป็นไปตามคาดเสมอ พอไม่ได้ก็โกรธและเครียด ซ้ำยังโกรธตัวเองที่โกรธอีก เป็น loop ไปปป 😡

#วางคาดหวังในตัวเองและคนอื่นลง
เรารู้สึกว่าตัวเองมีความคาดหวังที่มากเกินจริง ไม่ได้มองตามความเป็นจริง อย่างการทำงาน เราก็คาดหวังว่างานต้องเสร็จเร็ว พอมันไม่เร็วอย่างที่คิดก็โกรธ แต่เราโกรธอะไรหล่ะ โกรธตัวเอง โกรธทีม? แต่ว่าเราเองก็ทำที่เต็มที่แล้ว ทำไมเราต้องโกรธละ โกรธที่ไม่ได้ทำงานเกินเวลาหรอ ก็ดูไม่ถูกต้อง...

มันก็แค่ว่ามีปัจจัยที่ควบคุมไม่ได้มากมาย ทำไมเราต้องโกรธกับผลลัพธ์ที่ควบคุมไม่ได้ละ ทำไมเราไม่โฟกัสกับปัจจัยเหตุที่ควบคุมได้แทน เช่น วางแผนให้ดีขึ้น set expectation ลูกค้าให้ดีขึ้น พอเริ่มคิดได้ ก็เริ่มแก้ปัญหาได้ถูกจุดขึ้น โกรธน้อยลง เครียดน้อยลง

🌲 #ละทิ้งและเริ่มต้นใหม่
แล้วเราก็เริ่มพับ Product เดิมลงได้ ทั้งที่ควรจะทำได้เร็วกว่านี้ เพราะการเก็บ Product ไว้ก็มีต้นทุนในการ maintain อยู่ดี ถึงจะมีคนใช้ไม่มากก็ตาม และกินเวลาที่จะไปหาโอกาสใหม่ๆ

ระหว่างนั้นก็ได้โอกาสกลับมานั่งคุยกับทีมว่าอะไรที่เราอยากทำจริงๆ อะไร ก็เลยเลือก Product ด้าน Open Financial Data เพราะเชื่อว่าจะพาเราไปถึงเป้าหมายที่วางไว้ได้

🚧 #understand_first_not_build_first
รอบนี้มาเริ่มต้นใหม่ ก็พยายามเปลี่ยนวิธีการทำงาน จากที่ได้เรียนรู้ใน Hackathon คือหลายๆ ครั้งมีแค่ mockup และ slide ก็ขายของได้ ทำไมเราต้องรอให้เราทำ product เสร็จก่อนถึงจะขายละ ถ้าเกิดมันขายไม่ได้ละ ที่ทำมาก็เสียเปล่าสิ

210 Nameless Fanboi Posted ID:RdjEjvbRqb

ก่อนหน้านี้ด้วยความเป็น developer พอคิดอะไรได้ ก็อยากสร้างไปหมด โดยไม่รู้ว่า 1) ปัญหาของกลุ่มลูกค้ามีอยู่จริงมั้ย รุนแรงแค่ไหน 2) solution ที่เรามีมันแก้ปัญหาที่เค้ามีจริงมั้ย 3) ลูกค้าพร้อมจะจ่ายให้กับ solutionที่เรามีรึเปล่า

ซึ่งพอเริ่มต้นจากการทำความเข้าใจลูกค้า ก็ทำให้เรา ออกแบบ product ได้ถูกทางขึ้นมากๆ และมีความมั่นใจขึ้น

❤️ #ได้กลับมาเรียนรู้ตัวเองมากขึ้นอีก
หลังจากนั้นก็ได้มีโอกาสเขียน reflection บ่อยขึ้น เข้า workshop นพลักษณ์ แล้วก็การได้พูดคุยกับคนหลายๆ คน ทำให้เริ่มเข้าใจตัวเองมากขึ้นอีก โดยเฉพาะในเรื่องที่เหมือนเราค่อนข้างแคร์ในภาพ และมุ่งมั่นใจเป้าหมายมากๆ จนบางทีไม่ได้มองโลกตามความเป็นจริง แต่ไปมองเป็นสิ่งที่อยากให้เป็นมากกว่า ต้องขอบคุณคนที่ตั้งคำถามให้เราได้คิดเสมอด้วยนะ :)

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

---
ขอขอบคุณทุกคนที่ได้พบเจอในปีที่ผ่านมามากจริงๆ ที่นำพาสิ่งดีๆ ช่วยให้เราได้เรียนรู้และเติบโตขึ้น ปีนี้เราจะตั้งใจเรียนรู้ เติบโตและแบ่งปันให้มากขึ้นอีกนะ 😆

211 Nameless Fanboi Posted ID:PXGSa4LBMc

ตอนนี้ไปขอดู ระบบซอฟต์แวร์เขา จะถามว่าระบบคุณนี่ PASS ไหม คือ เขาต้องอธิบายได้ว่า. Performance Availability Security Scalability ของระบบเขามีที่มาอย่างไรในการออกแบบ

บางคนใช้ container อย่างหวือหวา แต่ database ไม่ scale บางทีไม่ได้คิดถึง สมรรถนะของ disk and io subsystem บริหารผู้ใช้ไม่มี identity management ไม่ได้ลด attack surface ลง ไม่ได้ออกแบบให้ระบบ scale out ได้แต่ scale up แบบโบราณ บางที่ไม่ได้เห็นการแบ่งโมดูล การเชื่อมโยง flow และข้อมูล สารพัด ไม่ง่ายนะครับ พวกนี้ทำทีหลังยากมากมาก เช่นถ้าไม่มี role base control ต่อไปการจัดระดับการ access ของข้อมูลอาจจะทำยากหรือไม่ได้เลย
เวลาขอดูงานจะเริ่มที่ความคิดในเชิงสถาปัตยกรรมระบบเขาก่อน ถ้าเขาวางดีแสดงว่าทำเป็น ส่วนอื่นมักจะพอไปได้