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

C: ผมทำได้ทั้ง DBA+BackEnd+Middle Ware+Linux Engineer+Cloud Architecture แบบนี้ขึ้นขบวนต่อต้านได้ไหม!?

ผมก็ไม่ไว้ใจแอปของ Meta เหมือนกันเลยไม่ใช้ และเลือกใช้ผ่าน Chrome ใน Secure Folder เท่านั้น

ปี 2025 ที่ไหนสักแห่ง..

A: Spring, React, Android, iOS เอาคนเดียวครับ
B: ให้แต่ละอย่างอย่างละหนึ่งคน รวมเป็นสี่คนใช่ไหมครับ?
A: บอกว่าเอาคนเดียวไง
B:

มนุษย์จะไปรู้อะไร!

หางานโหดจริงครับ แต่ถ้ามองอีกมุม มันก็เหมาะสุด ๆ สำหรับการทำบริการคนเดียวเหมือนกัน...

บอกแล้วบอกอีกว่าอย่าทำแบบนี้ แต่พวกนี้ก็ยังมีแบบหนึ่งในสิบที่ทำอยู่ดี -_-

ขอบคุณสำหรับบทความดีๆ ครับ
ผมเองก็อยากใช้ชีวิตเป็นนักพัฒนาเดี่ยวแบบนี้เหมือนกันครับ

ผมคิดว่าวิธีสื่อสารทั่วไประหว่างเว็บกับแอปในไฮบริดแอปคือการใช้ API ที่ฝั่ง OS และเบราว์เซอร์มีให้ ซึ่งมักเรียกว่า bridge ครับ ผมมองว่า local web server ไม่ใช่สิ่งจำเป็น
สาเหตุที่การใช้ local web server ตรงนั้นกลายเป็นปัญหา น่าจะเป็นเพราะมันเปิดช่องให้เกิดช่องโหว่แบบที่สามารถเข้าถึงพอร์ต localhost จาก Chrome โหมดไม่ระบุตัวตน แล้วทำลายความเป็นนิรนามของผู้ใช้ได้ เป็นต้น ถ้าเทคโนโลยีแบบนี้เป็นสิ่งจำเป็นสำหรับไฮบริดแอปจริง ๆ .. ไฮบริดแอปก็ควรหายไปเสียเถอะครับ

ขอบคุณสำหรับฟีดแบ็กที่รวดเร็วครับ~

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

ดูเหมือนว่าเกาหลีก็มีสถานการณ์คล้ายกันครับ สำหรับการหางาน น่าจะได้เปรียบกว่าถ้าเป็นสาขาอื่นควบคู่กับทักษะการเขียนโค้ด เช่น ชีววิทยา+ทักษะโค้ดดิ้ง ด้วยการพัฒนาของเฟรมเวิร์กและคลาวด์หลากหลาย รวมถึงการมาของเครื่องมือ LLM ที่ทำให้การเข้าถึงการเขียนโค้ดง่ายขึ้น (เหมือนในอดีตที่เปลี่ยนจากแอสเซมบลี -> C -> Python) ดูเหมือนว่านอกจากทักษะการเขียนโค้ดแล้ว จะต้องทำอย่างอื่นเป็นด้วย ถึงจะเข้าสู่ตลาดการจ้างงานได้ครับ

ขอปรบมือให้เลย!

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

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

เป็นบทความที่ดีนะ ~

อ๋อ ผมแก้ปัญหาได้ด้วยวิธีอื่นแล้วครับ ขอบคุณมาก!

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

ให้ .topic_contents มี min-width: 0 ก็แก้ได้แล้วครับ min-width นี่ชวนปวดหัวจริง ๆ...

น่าจะเป็นเพราะมีตาราง เลย์เอาต์บนมือถือเลยพังครับ