เมื่อพิจารณาในด้านความปลอดภัย ผมยังคงคิดว่าจำเป็นต้องแยก Web Server / เซิร์ฟเวอร์ WAS ออกจากกัน ไม่ได้มีอะไรเปลี่ยนไปแม้จะอยู่ในสภาพแวดล้อมแบบ cloud-native ก็ตาม Backend อย่าง WAS ไม่ควรอยู่ในเลเยอร์ที่ผู้ใช้สามารถเชื่อมต่อได้โดยตรง
ยังมีความหมายอยู่ไหมที่จะต้องรู้แนวคิดของเว็บเซิร์ฟเวอร์ / WAS เพื่อการวางแผนแบ็กเอนด์?
ในยุคที่ Java EE, php, CGI กำลังได้รับความนิยม การแบ่งแยกแบบนั้นก็ถือว่าเหมาะสมอยู่ แต่ทุกวันนี้ภาษาส่วนใหญ่ก็มักมี http server ในตัวอยู่แล้ว และเมื่อแนวคิดอย่าง ALB, API Gateway, CDN, Object Storage ได้ถือกำเนิดขึ้นและกลายเป็นเรื่องปกติ ยุคสมัยก็ได้เปลี่ยนไปแล้ว
ในทางกลับกัน หากไม่มีบริบททางประวัติศาสตร์ แนวคิดเรื่อง Web Server กับ WAS ที่แตกต่างจากปัจจุบันอย่างมากนั้น ไม่ใช่แนวคิดที่เหมาะสมอีกต่อไปแล้ว และผมรู้สึกว่ามันอาจยิ่งสร้างความสับสนให้กับผู้เริ่มต้นมากขึ้นเสียด้วย
ตอนนี้มีทั้ง ALB และ CDN ที่ทำในส่วนที่อยากให้เว็บเซิร์ฟเวอร์ทำให้อยู่แล้ว ผมเลยไม่ค่อยเข้าใจว่าทำไมยังต้องยึดติดกับสิ่งนั้นอยู่ พวกคุณมีกรณีด้านความปลอดภัยอะไรบ้างไหมที่ในทางปฏิบัติสามารถป้องกันได้เพราะมีเว็บเซิร์ฟเวอร์อยู่?
เมื่อพิจารณาในด้านความปลอดภัย ผมยังคงคิดว่าจำเป็นต้องแยก Web Server / เซิร์ฟเวอร์ WAS ออกจากกัน ไม่ได้มีอะไรเปลี่ยนไปแม้จะอยู่ในสภาพแวดล้อมแบบ cloud-native ก็ตาม Backend อย่าง WAS ไม่ควรอยู่ในเลเยอร์ที่ผู้ใช้สามารถเชื่อมต่อได้โดยตรง
เห็นด้วยครับ คิดว่าการสอนหลักการ 12-factor app และแพตเทิร์น cloud-native น่าจะใช้งานได้จริงมากกว่า ตัวคอนเซปต์เองก็เก่าเกินไปแล้ว
ดูเหมือนว่านี่จะกลายเป็นรากฐานของการเขียนโปรแกรมด้วย AI บนภาษาธรรมชาติ
ยังมีความหมายอยู่ไหมที่จะต้องรู้แนวคิดของเว็บเซิร์ฟเวอร์ / WAS เพื่อการวางแผนแบ็กเอนด์?
ในยุคที่ Java EE, php, CGI กำลังได้รับความนิยม การแบ่งแยกแบบนั้นก็ถือว่าเหมาะสมอยู่ แต่ทุกวันนี้ภาษาส่วนใหญ่ก็มักมี
http serverในตัวอยู่แล้ว และเมื่อแนวคิดอย่าง ALB, API Gateway, CDN, Object Storage ได้ถือกำเนิดขึ้นและกลายเป็นเรื่องปกติ ยุคสมัยก็ได้เปลี่ยนไปแล้วในทางกลับกัน หากไม่มีบริบททางประวัติศาสตร์ แนวคิดเรื่อง Web Server กับ WAS ที่แตกต่างจากปัจจุบันอย่างมากนั้น ไม่ใช่แนวคิดที่เหมาะสมอีกต่อไปแล้ว และผมรู้สึกว่ามันอาจยิ่งสร้างความสับสนให้กับผู้เริ่มต้นมากขึ้นเสียด้วย
ในประเทศเราก็มีการเฝ้าระวังและเซ็นเซอร์โดยอ้างเหตุผลว่าปิดกั้นคอนเทนต์ผิดกฎหมาย แต่ในความเป็นจริงไม่ได้มีอะไรเปลี่ยนไปเลยแม้แต่อย่างเดียว
พอเห็นว่ายังทำได้แค่บล็อกโดเมนกับ IP แบบที่ใช้กันได้ผลตั้งแต่ช่วงต้นยุค 2000 ก็อดขำไม่ได้จริงๆ
ปกติแล้วโจทย์อัลกอริทึมก็มักจะมีเงื่อนไขด้าน time/space complexity กำกับอยู่ไม่ใช่เหรอ? การบอกว่าให้แก้ด้วย constraint solver ได้ จริง ๆ แล้วก็แสดงได้แค่ว่ามีความสามารถในการแปลงโจทย์ให้อยู่ในรูป constraint เท่านั้นเอง... แต่ผมก็ยังไม่ค่อยแน่ใจว่านั่นเป็นทักษะที่จำเป็นต่อการทำงานจริงแค่ไหนนะ...
นี่แหละข้ออ้างของการเซ็นเซอร์ที่ใช้ได้ผลเสมอ
เรื่องแบบนี้ผมก็พยายามกันไว้ด้วยพรอมป์ต์ไม่ให้ประมวลผล แต่ก็ยังเอาไม่ค่อยอยู่เลยครับ 555 เลยแก้เป็นงานมือไว้แล้วครับ
ดูเหมือนว่าบอตจะดึงเนื้อหาบทความมาไม่ได้ เลยใส่ไว้แค่ข้อความว่าเข้าถึงถูกปฏิเสธ...
จริง ๆ แล้วก็มีเครื่องมือที่ทำได้แค่เก็บข้อมูลอยู่มากมาย แต่สิ่งสำคัญคือการทำงานร่วมกันอย่างการกรอกอัตโนมัติ
ตั้งแต่ GPT5 เป็นต้นมา ดูออกเลยว่ากำลังพยายามฝืนดันประสิทธิภาพขึ้นด้วยการใช้การให้เหตุผล แต่ดูแล้วแม้แต่แบบนั้นก็ยังไม่ง่ายเหมือนกัน คำตอบที่จริง ๆ แค่หยุดไว้ระดับพอเหมาะก็น่าจะพอ เดี๋ยวนี้กลับยาวเป็นหลายสิบบรรทัด เลยรู้สึกหนักเกินไปมากครับ T_T
บรรดากลุ่มเผด็จการขนาดมหึมาสมคบกันเพื่อสอดส่องผู้คนนับร้อยล้านคน... ฟังดูเหมือนนิยายไซไฟสยองขวัญ แต่สิ่งที่น่าตกใจก็คือมันกำลังเกิดขึ้นจริงในโลกความเป็นจริง
ถ้าเป็นที่ที่สามารถพูดความเห็นคัดค้านได้อย่างอิสระ ก็คงมีแนวโน้มน้อยกว่า แต่ถ้าเป็นที่ที่ยึดติดกับ 'ความสัมพันธ์' ก็คิดว่าน่าจะมีแนวโน้มแบบนั้นมากกว่า
ถ้าคุณอยากทำความรู้จักกับ PFAS แบบสั้น ๆ ขอแนะนำวิดีโอ YouTube นี้: https://youtu.be/D1I008W7_OQ
ค่อนข้างน่ากังวลทีเดียว
เป็นเครื่องมือที่สะดวกมากและดีมาก
ไม่ต้องมานั่งหา API parameters ทีละตัวและลงมือทำเองทุกจุด ก็น่าจะทำให้พัฒนาได้สะดวกขึ้นเยอะเลยครับ
ผมใช้ k9s อยู่เหมือนกันครับ
ตอนเห็นครั้งแรกเมื่อ 2~3 ปีก่อน รู้สึกว่ามีกลิ่นอายแบบ mdir เลยชอบ และพอใช้จริงก็ค่อนข้างดีด้วยครับ
ชื่อน่าสนุกดีครับ 555
ข้อดีของ Spec Kit ของ GitHub คือสามารถใช้ได้กับ GitHub Copilot ด้วย
เพราะสร้างโดย GitHub เอง ก็คงเป็นเรื่องธรรมดา? แต่ก่อนหน้านี้เครื่องมืออื่น ๆ หลายตัวมักอิงกับ Claude