Java เตรียมลดเวลารอหลังเปิดระบบ ด้วย JEP 544 ใน JDK 28

OpenJDK รายงานว่าแคชแบบใหม่ลดเวลาเริ่มแอปได้ราว 65–80% ในชุดทดสอบของตัวเอง แปลว่าแอปที่ทดสอบใช้เวลาเปิดน้อยลงมากเมื่อเทียบกับการไม่ใช้แคช โดยข้อเสนอ JEP 544 ซึ่งเตรียมโค้ดให้พร้อมล่วงหน้า มีสถานะ Targeted สำหรับ JDK 28 หรือชุดเครื่องมือ Java รุ่นที่เป็นเป้าหมาย ตาม หน้า JEP และ ข่าว InfoQ วันที่ 5 ตุลาคม

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

สรุป 30 วินาที: เกิดอะไรขึ้น

JEP คือเอกสารข้อเสนอปรับปรุง Java ส่วน AOT หรือ Ahead-of-Time คือการทำงานบางอย่างไว้ก่อนเปิดใช้งานจริง สำหรับข่าวนี้ งานที่ย้ายไปทำล่วงหน้าคือการแปลงคำสั่งของแอปให้เป็นโค้ดที่หน่วยประมวลผลใช้ได้โดยตรง พร้อมปรับให้ทำงานเร็วขึ้น แล้วเก็บไว้เรียกใช้ครั้งถัดไป ตาม OpenJDK

InfoQ รายงานเมื่อวันที่ 5 ตุลาคมว่าข้อเสนอนี้ขยับจาก Proposed to Target มาเป็น Targeted แปลจากสถานะเดิมที่เสนอให้เข้ารุ่น มาเป็นรุ่นเป้าหมายที่ระบุแล้ว หน้าเอกสารต้นทางก็แสดงสถานะเดียวกัน แต่สถานะนี้ยังไม่เท่ากับประกาศว่า Java รุ่นดังกล่าวเปิดให้ใช้ทั่วไปแล้ว ตาม InfoQ และ OpenJDK

แนวทางนี้ใช้การรันฝึก หรือ training run ให้แอปทำงานก่อน เพื่อเก็บผลเตรียมไว้ใน AOT cache ซึ่งก็คือไฟล์สะสมข้อมูลสำหรับเปิดแอปครั้งต่อไป เมื่อใช้งานจริง ระบบจึงหยิบโค้ดที่ปรับไว้มาใช้ได้ทันทีในส่วนที่เข้ากัน และยังปรับโค้ดใหม่ระหว่างทำงานได้ ตาม JEP

ข่าวนี้จึงเหมาะกับการเริ่มประเมินของทีมพัฒนามากกว่าการสั่งให้ทุกคนอัปเดตทันทีครับ InfoQ ระบุว่ามี JDK รุ่นทดลองล่วงหน้า หรือ early-access ให้ทดสอบแล้ว แต่แหล่งที่อ่านยังไม่ได้ให้วันเปิดใช้ทั่วไปของรุ่นเป้าหมาย ตาม ข่าวรอบล่าสุด

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

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

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

ทำงานยังไง

HotSpot JVM คือระบบที่รันโปรแกรม Java และจัดการงานเบื้องหลังให้โปรแกรม ช่วงแรกมันอ่านคำสั่งรูปแบบกลางของ Java แล้วสังเกตว่าส่วนไหนถูกเรียกบ่อย จากนั้น JIT หรือ Just-in-Time ซึ่งคือการแปลงโค้ดขณะใช้งาน จะสร้างคำสั่งสำหรับเครื่องที่กำลังรันอยู่ ตาม คำอธิบายของ OpenJDK

ข้อดีของ JIT คือมันปรับตามงานจริงได้ หากรูปแบบคำขอเปลี่ยน ระบบสามารถเลิกใช้โค้ดที่ปรับไว้เดิม แล้วสร้างโค้ดที่เหมาะกับงานใหม่ การปรับตัวนี้ช่วยรักษาประสิทธิภาพเมื่อแอปไม่ได้รับงานแบบเดิมตลอดเวลา ตาม JEP

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

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

พื้นฐานของแคชนี้มีมาก่อนแล้ว JDK 24 เพิ่มการเก็บผลโหลดและเชื่อมส่วนประกอบของโปรแกรม แปลว่ารอบถัดไปลดงานเตรียมส่วนเหล่านั้นได้ ตาม ประวัติใน JEP ต่อมา JDK 25 เพิ่มข้อมูลพฤติกรรมการทำงาน แปลว่าระบบมีข้อมูลช่วยตัดสินใจปรับโค้ดตั้งแต่เริ่มรัน ตาม เอกสารเดียวกัน

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

จุดหักมุม: เตรียมล่วงหน้าได้ แต่ต้องเตรียมให้ตรงงาน

แต่แคชไม่ได้รู้ล่วงหน้าว่าลูกค้าจะทำอะไรทุกครั้งครับ OpenJDK ตั้งสมมติฐานว่ารอบฝึกเป็นแหล่งข้อมูลที่ดีสำหรับงานจริง ถ้างานจริงต่างออกไป ระบบยังสร้างโค้ดใหม่ด้วย JIT ได้ ประโยชน์จากสิ่งที่เตรียมไว้จึงขึ้นกับความใกล้เคียงของงาน ตาม ส่วน Risks and Assumptions

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

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

เรื่องเงิน / ผลกระทบ

สิ่งที่วัดได้ในข่าวนี้คือเวลาเริ่มแอป ไม่ใช่ส่วนลดค่าเครื่องครับ OpenJDK ทดสอบกับแอปที่สร้างจากเฟรมเวิร์กยอดนิยม บนระบบ Linux/x64 ที่มีหน่วยประมวลผลสองคอร์ แปลว่าเครื่องทดสอบมีทรัพยากรประมวลผลจำกัด เพื่อจำลองสถานการณ์บริการย่อยที่งานแปลงโค้ดอาจแย่งเวลาจากตัวแอป ตาม ส่วน Performance

แคชเดิมที่ยังไม่เก็บโค้ด AOT ลดเวลาเริ่มได้ราว 50–70% ตามผลทดสอบจาก OpenJDK แหล่งเดียว แปลว่าข้อมูลที่เตรียมไว้ก่อนหน้านี้ก็ช่วยได้อยู่แล้ว ตาม JEP ผลของแคชที่เพิ่มโค้ด AOT ในชุดทดสอบเดียวกันจึงเป็นการต่อยอดประโยชน์เดิม ไม่ควรอ่านว่าเป็นความเร็วของทุกงานในแอป

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

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

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

สถานะที่ต่างกันเป็นคนละช่วงเวลา InfoQ ฉบับวันที่ 28 กันยายนรายงานว่าอยู่ขั้น Proposed to Target และคาดว่าการทบทวนจะจบวันเดียวกัน ตาม ข่าวรอบก่อน ส่วนฉบับวันที่ 5 ตุลาคมรายงาน Targeted ตาม ข่าวรอบถัดมา เมื่อเทียบกับ หน้า JEP จึงเป็นความคืบหน้า ไม่ใช่สองสำนักยืนยันสถานะขัดกัน

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

ฝั่งทักท้วงอยู่ในรายละเอียดการทดสอบ ใน PR หรือคำขอรวมโค้ดของ OpenJDK ผู้ร่วมทบทวนชื่อ RealFYang รายงานการทดสอบล้มเหลวบน Linux/x86 เมื่อเปิดตัวเลือกแสดงสถิติ ส่วน vnkozlov ตอบว่าจะพยายามทำให้เกิดปัญหาซ้ำและแก้ไข ตาม บทสนทนาใน GitHub นี่เป็นข้อทักท้วงที่มีตัวตนเกี่ยวกับความถูกต้อง ไม่ใช่คำประกาศคัดค้านแนวทาง AOT ทั้งหมด

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

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

แล้วเราควรทำอะไร

คนทั่วไป พนักงาน และเจ้าของร้านที่ใช้บริการสำเร็จรูป

1. ยังไม่ต้องเปลี่ยนเครื่องเพราะข่าวนี้ ถ้าบริการที่ใช้มีปัญหาหลังเริ่มระบบ ให้จดว่างานไหนช้าและเกิดเมื่อไร เพื่อคุยกับผู้ดูแลด้วยเหตุการณ์ที่ตรวจสอบได้
2. หากผู้ขายอ้างตัวเลขจากข่าว ให้ขอผลวัดของงานคุณโดยตรง แยกเวลาเปิดระบบ เวลาพร้อมรับงาน และเวลาตอบคำขอออกจากกัน เพราะ OpenJDK วัดประโยชน์ของ startup และ warmup
3. สำหรับเจ้าของกิจการ ให้ถามผู้ดูแลก่อนว่าระบบใช้ Java หรือไม่ และความช้าอยู่ในส่วนไหน อย่าเพิ่มงบอัปเกรดเพียงเพราะอ่านชื่อรุ่นใหม่แล้วคาดว่าจะแก้ปัญหาได้ทั้งหมด

ทีม IT และทีมดูแลระบบ

1. ทบทวนขั้นตอนสร้าง AOT cache เดิมให้เข้าใจก่อน โดยดูว่าทีมเก็บข้อมูลจากรอบฝึกอย่างไร ข้อเสนอใหม่นี้ต่อยอดขั้นตอนเดิม ไม่ได้กำหนดกระบวนการ AOT ใหม่ ตาม JEP
2. ทดลองด้วย JDK 28 early-access ในสภาพแวดล้อมทดสอบ แปลว่าใช้รุ่นเป้าหมายที่ยังอยู่ช่วงทดลอง ไม่ใช่ย้ายบริการจริงทันที InfoQ รายงานว่ามีบิลด์ทดลองแล้ว แต่ควรตรวจฟีเจอร์ในบิลด์ที่เลือกก่อนวัด
3. เตรียมงานฝึกให้ครอบคลุมคำขอที่สำคัญ แล้ววัดเวลาเปิดและช่วงอุ่นเครื่อง เปรียบเทียบกับกรณีไม่ใช้แคช รวมถึงกรณีใช้แคชแต่ไม่โหลดโค้ด AOT เอกสารมีทางปิดการโหลดโค้ดเพื่อประเมินผลส่วนนี้โดยเฉพาะ ตาม OpenJDK
4. ตรวจความตรงกันของหน่วยประมวลผลและตัวจัดการหน่วยความจำ พร้อมตรวจว่าโค้ดถูกโหลดจริง เอกสารระบุว่ารายงานการแปลงโค้ดสามารถแสดงทั้งการโหลด AOT และการสร้าง JIT ได้ ตาม หัวข้อสังเกตการใช้แคช
5. ทดสอบกรณีแคชใช้ไม่ได้ด้วย โดยเฉพาะถ้าตั้งให้ต้องมีแคชที่ตรงเงื่อนไข เพราะโหมดบังคับใช้แคชจะรายงานข้อผิดพลาดและออกจากโปรแกรมเมื่อเงื่อนไขไม่ผ่าน ตาม JEP ความพร้อมให้บริการจึงควรอยู่ในผลทดสอบด้วย

นักพัฒนา

1. เริ่มจากแอปเดิมก่อน เป้าหมายของข้อเสนอคือไม่ให้ต้องแก้โค้ดแอปหรือชุดโค้ดที่ใช้ร่วมกัน ตาม OpenJDK อย่าเพิ่งเขียนระบบใหม่เพื่อให้เข้ากับชื่อฟีเจอร์
2. ลองงานที่ต่างจากรอบฝึก แล้วดูว่าระบบกลับไปปรับโค้ดระหว่างรันได้อย่างไร พร้อมบันทึกขนาดแคชและเงื่อนไขเครื่อง เพื่อให้ทีมดูแลใช้ผลทดลองต่อได้จริง
3. ถ้าพบปัญหา ให้เก็บเงื่อนไขที่ทำให้เกิดซ้ำและรายงานตามช่องทางที่โครงการกำหนด InfoQ ระบุให้ผู้พัฒนารายงานบั๊กผ่าน Java Bug Database หรือฐานข้อมูลข้อผิดพลาดของ Java

ผมมองว่า…

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

ผมมองว่าการคุยกับเจ้าของกิจการควรเริ่มจากความพร้อมรับงานหลังเปิดระบบ มากกว่าประโยคว่าอัปเกรดแล้วเร็วขึ้น การทดลองที่ดีควรบอกทั้งเวลาที่ดีขึ้น เงื่อนไขที่ไม่ได้ประโยชน์ และต้นทุนเตรียมแคช ส่วนทีมที่อยากอ่านประเด็น Java ต่อ มีบทความเกี่ยวข้องเรื่อง JEP 539: Strict Field Initialization ให้ติดตามอีกมุม

ปิดท้าย: สิ่งที่ต้องจับตา

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

บริการที่คุณใช้ทำงานประจำ มีงานไหนที่ช้าชัดที่สุดหลังระบบเพิ่งเปิดหรือกลับมาใช้งานได้?

Recap

• เกิดอะไรขึ้น: ข้อเสนอเก็บโค้ดที่ปรับแล้วไว้ใช้ตอนเปิดแอป มีสถานะ Targeted สำหรับรุ่นเป้าหมาย ตาม OpenJDK
• ตัวเลขที่จำ: ลดเวลาเริ่มราว 65–80% แปลว่าเปิดแอปทดสอบเร็วขึ้นเมื่อเทียบกับไม่ใช้แคช เป็นผลจาก OpenJDK แหล่งเดียว ตาม JEP
• ใครทักท้วง: RealFYang รายงานปัญหาทดสอบ ขณะที่ mhaessig ให้ความเห็นเชิงบวกกับโค้ดที่ทบทวน ยังสรุปสถานะทุกปัญหาจากไฟล์นี้ไม่ได้ ตาม GitHub
• ยังไม่รู้: วันเปิดใช้ทั่วไป ผลกับระบบของคุณ และแผนใช้ของผู้ให้บริการไทย
• กระทบคุณ: อาจลดเวลารอหลังเริ่มบริการที่ใช้ Java แต่ต้องวัดกับงานจริงก่อนคาดหวังผลหรือจัดงบ
• จับตา: ความพร้อมในรุ่นทดลอง ความตรงกันของเครื่อง และผลเมื่อรูปแบบงานเปลี่ยน
• แหล่งอ้างอิง: 1 — OpenJDK, 2 — InfoQ ล่าสุด, 3 — GitHub PR, 4 — InfoQ รอบก่อน