เมื่อพิจารณาในด้านความปลอดภัย ผมยังคงคิดว่าจำเป็นต้องแยก Web Server / เซิร์ฟเวอร์ WAS ออกจากกัน ไม่ได้มีอะไรเปลี่ยนไปแม้จะอยู่ในสภาพแวดล้อมแบบ cloud-native ก็ตาม Backend อย่าง WAS ไม่ควรอยู่ในเลเยอร์ที่ผู้ใช้สามารถเชื่อมต่อได้โดยตรง
ยังมีความหมายอยู่ไหมที่จะต้องรู้แนวคิดของเว็บเซิร์ฟเวอร์ / WAS เพื่อการวางแผนแบ็กเอนด์?
ในยุคที่ Java EE, php, CGI กำลังได้รับความนิยม การแบ่งแยกแบบนั้นก็ถือว่าเหมาะสมอยู่ แต่ทุกวันนี้ภาษาส่วนใหญ่ก็มักมี http server ในตัวอยู่แล้ว และเมื่อแนวคิดอย่าง ALB, API Gateway, CDN, Object Storage ได้ถือกำเนิดขึ้นและกลายเป็นเรื่องปกติ ยุคสมัยก็ได้เปลี่ยนไปแล้ว
ในทางกลับกัน หากไม่มีบริบททางประวัติศาสตร์ แนวคิดเรื่อง Web Server กับ WAS ที่แตกต่างจากปัจจุบันอย่างมากนั้น ไม่ใช่แนวคิดที่เหมาะสมอีกต่อไปแล้ว และผมรู้สึกว่ามันอาจยิ่งสร้างความสับสนให้กับผู้เริ่มต้นมากขึ้นเสียด้วย
คงต้องเพิ่มเนื้อหาในคาบเรียนอัลกอริทึมกันแล้วล่ะ 555
มองยังไงก็ไม่มีเรื่องเกี่ยวกับเกาหลีอยู่เลย ไม่เข้าใจว่าทำไมจู่ ๆ ถึงพูดเรื่องการเมืองเกาหลีขึ้นมา
กรุณาออกจากเว็บไซต์นี้ไป คุณที่เอาแต่คิดเรื่องการเมืองแบบนี้ไม่เป็นที่ต้องการของคอมมูนิตี้นี้
เวลาสูบบุหรี่ไฟฟ้าแล้วดันลืมไว้ที่ไหนสักแห่ง หรืออยู่ระหว่างเดินทาง... ก็ไม่ค่อยอยากซื้อเครื่องเพิ่มอีกเครื่องหรือกลับไปสูบบุหรี่มวน แต่ก็ยังอยากเติมนิโคติน สุดท้ายเลยมักจะไปหาที่ร้านสะดวกซื้อ
เท่าที่ดูจากสิ่งที่คุณพูดมา คุณดูเหมือนเป็นคนที่อยู่ในโลกอินเทอร์เน็ตมานาน และไม่สามารถสื่อสารกับผู้คนในชีวิตจริงได้อย่างเหมาะสม
อย่าเอาแต่นั่งอยู่ในห้องแล้วเขียนคอมเมนต์แบบนี้เลย ลองออกไปพบเจอโลกภายนอกและใช้ชีวิตด้วยการปฏิสัมพันธ์กับ "ผู้คนจริง ๆ" ดูบ้าง
เหตุการณ์ของ Edward Snowden ยังสดใหม่อยู่เลย แต่กลับต้องมาเห็นคอมเมนต์ทำนองว่าเผด็จการอะไรนั่นแม้กระทั่งที่นี่ หรือว่าเป็นพวก 2-jjik? ได้โปรดอย่าเอาแต่เขียนโค้ดอยู่ในห้องอย่างเดียว ลองออกไปดูโลกข้างนอกหลาย ๆ ที่บ้างเถอะ ~
SKT ออกข่าวประชาสัมพันธ์มาบอกว่าไม่ใช่ แต่จะจริงแค่ไหนกัน...
น่าจะใกล้เคียงกับลิควิดกลาสที่เคยเห็นบนเว็บมากที่สุดแล้ว
ไม่นานมานี้ odiff ที่ถูกเขียนใหม่จาก ocaml เป็น zig ก็น่าสนใจให้ลองดูเช่นกัน เร็วกว่า pixelmatch 6 เท่า
เป็นประเด็นที่เอามาปรับใช้กับเกาหลีได้พอดีเลยนะครับ
หมายความว่า หาก ALB ทำหน้าที่แทนเว็บเซิร์ฟเวอร์ในเชิงฟังก์ชัน และผู้ใช้ไม่สามารถเข้าถึงแบ็กเอนด์อย่าง WAS ได้โดยตรง ก็ถือว่าตรงตามการจัดโครงสร้างสภาพแวดล้อมความปลอดภัยแบบเดิมใช่ไหมครับ และบริการจำนวนมากก็ยังคงทำงานอยู่บนสภาพแวดล้อม on-premises กันอยู่มากด้วยครับ
ผมสนุกกับทั้งโปรเจกต์และบทความมาก อ่านเพลินมากครับ แต่พอรู้ว่ามีสิ่งที่เรียกว่าบุหรี่ไฟฟ้าแบบใช้แล้วทิ้งอยู่ด้วยก็รู้สึกตกใจมาก และคิดว่านี่มันไม่โอเคเลยนะ..
ได้ยินข่าวลือกันไปทั่วแล้วว่าเป็นความซุ่มซ่ามระดับประเทศของเกาหลี
ตอนนี้มีทั้ง 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 เท่านั้นเอง... แต่ผมก็ยังไม่ค่อยแน่ใจว่านั่นเป็นทักษะที่จำเป็นต่อการทำงานจริงแค่ไหนนะ...