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

 

ระบบแบบกระจายอย่าง flink จำเป็นต้องคงไว้ซึ่ง HA ด้วยการมี rack 2~3 ชุด และดูเหมือนว่าพอผนวกกับ kubernetes แล้วก็เหมือนจะรับประกัน HA ได้ แต่สุดท้ายก็คงต้องคิดเรื่องทรัพยากรของ kube slave node อยู่ดี เลยสงสัยว่าเขาจัด node ที่รันแต่ flink แยกไว้หรือเปล่า (ถ้า flink มีโหลดสูง ก็น่าจะมีปัญหา slave node ล่มได้)
ในมุมแบบนั้น การใช้ kubernetes มีข้อดีอะไรบ้างไหม?

อีกอย่าง ถ้าใช้ window function ใน flink ข้อมูลระหว่างนั้นจะถูกเก็บไว้ในหน่วยความจำ ทำให้คำสั่ง SQL join ทำงานได้ แต่ถ้ามองในแง่ trade-off ก็เลยทำให้คิดว่า flink เป็นตัวเลือกที่ดีจริงหรือเปล่า ถ้าเวลาผ่านไปแล้ว SQL + job ขนาดใหญ่ขึ้นเรื่อยๆ แล้ว job ตายขึ้นมา ผลกระทบก็คงมหาศาล..

ผมเองก็สงสัยเหมือนกันว่า ถ้าอยู่ในสถานการณ์ที่ต้อง join กันตั้งแต่ data source ชั้นบนสุด จะมีวิธีไหนที่ไม่ใช้ flink แล้วลดระดับมาจัดการที่ application level ได้บ้าง.

 

เป็นการถกเถียงที่ยอดเยี่ยมครับ

 

คิดดูแล้ว ผมเองก็แนะนำ philosophy of sw design ของ John ให้กับรุ่นน้องอยู่เหมือนกัน แต่ไม่ได้แนะนำ clean code เป็นพิเศษเลย

 

ว้าว เพิ่งลองเปิดใช้ GitHub app สำหรับรีวิว PR ให้เมื่อกี้เองครับ น่าสนใจว่าจะเป็นยังไงนะ

 

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

 

ว่ากันว่ามันก็แค่ทำตาม docx ตรง ๆ
จริง ๆ แล้วตอนที่ MS เปลี่ยนจาก doc เป็น docx ก็ทำแบบนั้นเหมือนกัน

 

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

 

อืม... ก็สงสัยอยู่ว่ามันจะทำให้การพัฒนาที่ปลอดภัยด้านชนิดข้อมูลมากกว่า TS หรือเปล่า

 

ผมก็คิดว่าเป็นซอฟต์แวร์ที่ยอดเยี่ยมอยู่เหมือนกัน จนกระทั่ง Han/Geul 97 ออกมา

 

ขอบคุณสำหรับบทความดี ๆ ครับ อยากให้ไฟล์ที่สร้างจาก AWS (เช่น รายงาน) เป็น HWP แต่มีข้อมูลอ้างอิงที่เกี่ยวข้องค่อนข้างน้อยจึงทำได้ยาก ตอนนี้กำลังใช้ Word อยู่ครับ หากมีเอกสารที่พอจะใช้อ้างอิงได้ รบกวนขอลิงก์ด้วยครับ

 

ก็น่าจะให้การฝึกของ AI เน้นไปที่ PDF แล้วทำตัวแปลงหรือทำเอกสาร Hancom Hangul เป็น PDF ให้ดี ๆ จะดีกว่าไหมครับ 555

 

เมื่อเทียบกับ MS Word หรือ Libre Office แล้ว ผมรู้สึกว่า Hancom Hangul ใช้งานสะดวกกว่ามากในการทำเอกสารให้ออกมาตามรูปแบบที่ต้องการ ส่วนการเผยแพร่ก็ทำเป็น PDF ได้อยู่แล้ว

แน่นอนว่าอาจเป็นเพราะผมคุ้นเคยกับ Hancom Hangul มากกว่า เลยรู้สึกแบบนั้นด้วยครับ

 

ก่อนหน้านี้เคยได้ยินมาว่า hwpx คือการคลายไบนารีของ hwp ออกมาเป็น xml แบบตรง ๆ แล้วค่อยบีบรวมเป็น zip
แต่อย่างน้อยก็ยังพออ่านได้...

 

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

 

อย่าลืมว่า Clean Code ไม่ใช่เป้าหมาย แต่เป็นเครื่องมือ

 

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