ganadist 2025-03-12 | ความคิดเห็นหลัก | ใน: การสร้างแอป Android ในปี 2025 (dev.to) ในฐานะคนที่ลงเอยมาเป็นวิศวกร build ของแอป Android แบบไม่รู้ตัว ขอลองฝากความเห็นไว้หน่อย.. > ระบบ build : gradle ถึงจะใหญ่หรือซับซ้อนมากแค่ไหน ก็ต้องใช้ gradle อยู่ดี... (มองไกล) มีโปรเจ็กต์ด้านล่างนี้กำลังดำเนินอยู่เพื่อปรับปรุงประสิทธิภาพการ build ของ gradle ในโปรเจ็กต์ที่ใหญ่หรือซับซ้อนมาก ดังนั้นถ้าคุณใช้ gradle กับโปรเจ็กต์ขนาดใหญ่ ก็ควรเตรียมการย้ายล่วงหน้าไว้จะดีกว่า https://docs.gradle.org/current/userguide/configuration_cache.html https://docs.gradle.org/current/userguide/isolated_projects.html > โครงสร้างโมดูล : แยกตาม feature ส่วนตัวผมมองว่าไม่มีเหตุผลจำเป็นที่จะต้องเปิดเผย architectural layer ออกมาที่ระบบ build ในกรณีของแอปที่ผมดูแลอยู่ ผมทำให้ build system มองเห็นโมดูลเป็น feature-api / feature-impl feature-app : data model หรือ interface ที่เชื่อมกับโมดูลอื่น feature-impl: implementation จริงของ feature ถ้าจัดแบบนี้ การเปลี่ยนโค้ดใน feature-impl จะไม่ส่งผลต่อโมดูลอื่นที่อ้างอิง feature-api (แยก dependency ออกจากกัน) จึงช่วยได้มากทั้งกับ incremental build และการเพิ่ม build cache hit rate > unit test - junit 4 เรื่องนี้ดูเหมือนว่าการตัดสินใจของ Google จะมีบทบาทค่อนข้างมาก https://issuetracker.google.com/issues/127100532 สำหรับ Android Platform นั้น JUnit3 (ที่ดูเหมือน JUnit4) และ framework ทดสอบของเครื่องมือ build Android ทำงานบนพื้นฐาน JUnit4 โดย Google ระบุชัดว่าไม่มีแผนจะย้ายไป JUnit5 แต่ screenshot testing plugin ที่เพิ่งเปิดตัวล่าสุด กลับ อิงกับ JUnit5 ครับ. jsh5782 2025-03-12 | ความคิดเห็นหลัก | ใน: Seven39 - แอปโซเชียลมีเดียที่เปิดให้ใช้เพียงวันละ 3 ชั่วโมงในช่วงเย็น (seven39.com) น่าจะเป็น Clubhouse นะครับ ผมเองก็นึกถึงอันนั้นขึ้นมาพอดีเหมือนกัน wedding 2025-03-12 | ความคิดเห็นหลัก | ใน: Seven39 - แอปโซเชียลมีเดียที่เปิดให้ใช้เพียงวันละ 3 ชั่วโมงในช่วงเย็น (seven39.com) ช่วงนี้ดูเหมือนบริการที่จำกัดจำนวนครั้งหรือเวลาจะกลับมาฮิตกันอีกแล้ว แต่ก็แอบคิดว่าอาจจะดังวูบขึ้นมาแล้วก็ซาไปเหมือนแอปแนวพูดคุยคล้ายการกระจายเสียงที่เคยฮิตเมื่อไม่นานมานี้ ซึ่งจำชื่อที่แน่ชัดไม่ได้เหมือนกันนะ kingori 2025-03-12 | ความคิดเห็นหลัก | ใน: การสร้างแอป Android ในปี 2025 (dev.to) โห เป็นเกียรติของตระกูลฮัตเลยนะ bbulbum 2025-03-12 | ความคิดเห็นหลัก | ใน: Seven39 - แอปโซเชียลมีเดียที่เปิดให้ใช้เพียงวันละ 3 ชั่วโมงในช่วงเย็น (seven39.com) ทราฟฟิกน่าจะกระจุกตัวมหาศาลเฉพาะในช่วงเวลานั้น คงต้องมีการจัดการที่มีประสิทธิภาพนะครับ wogns3623 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) กังวลว่าต่อไปอาจละเลยการดูแลโค้ดเบส TypeScript ที่มีอยู่เดิมหรือเปล่า aa1567 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) การพัฒนาภาษา C# ไม่ได้หยุดลงเสียทีเดียว แต่รู้สึกว่ามีเฟรมเวิร์กที่ใช้ C# หลายตัวถูกปล่อยปละละเลยมากเกินไป halfenif 2025-03-12 | ความคิดเห็นหลัก | ใน: Goravel - เฟรมเวิร์ก Go ที่ได้รับแรงบันดาลใจจาก Laravel (github.com/goravel) กำลังลองทดสอบอยู่ และให้ความรู้สึกเหมือนชุดรวมมิตรแบบครบเครื่องเลยครับ kallare 2025-03-12 | ความคิดเห็นหลัก | ใน: ศิลปะแห่งการโฟกัสของทีมวิศวกรรม: ทำน้อยลงแต่ทำได้มากกว่า (resources.github.com/developer-productivity) มีบทความลักษณะคล้ายกันถูกพูดซ้ำอยู่เรื่อย ๆ แต่ความโลภของมนุษย์นั้นไม่มีที่สิ้นสุด และเราก็ทำพลาดแบบเดิมซ้ำ ๆ ถ้าอยากสร้างทีมที่ทำผลงานได้ยอดเยี่ยม จงเรียกร้องความพยายามแค่ 85% 6 ความเชื่อฝังหัวที่ทำลายการพัฒนาผลิตภัณฑ์ การที่ CPU ของคอมพิวเตอร์มีโหลด 100% ไม่ใช่เรื่องปกติ แต่พอเป็นโหลดงานของมนุษย์ 100% กลับสรุปกันว่า...ต้องขยันให้มากขึ้น brainer 2025-03-12 | ความคิดเห็นหลัก | ใน: การสร้างแอป Android ในปี 2025 (dev.to) อืม.. พูดนอกเรื่องหน่อยว่าในช่วงไม่กี่ปีที่ผ่านมา มีการพบปรากฏการณ์แปลก ๆ ที่สตาร์ตอัปส่วนใหญ่ไปทาง Flutter ขณะที่บริษัทใหญ่ ๆ อย่าง META, OpenAI กลับไปทาง native.. tsboard 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) ก็จริงครับ ความรู้สึกของนักพัฒนา .NET เองก็พอเข้าใจได้เหมือนกัน... tsboard 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) เป็นข่าวที่น่ายินดี! น่าแปลกที่ภาษา TypeScript ของ MS ดูเหมือนจะตัดสินใจเลือกสิ่งที่คาดไม่ถึงจริง ๆ อยู่หลายอย่าง ต่างจาก Dart ของ Google ที่พยายามจะมาแทนที่ JS สำหรับ MS แล้วนี่แทบจะเป็นโปรเจ็กต์โอเพนซอร์สชิ้นแรก ๆ และการเลือกแนวทางที่พยายามเข้ามาเสริม JS ก็ดูเป็นการตัดสินใจที่ชาญฉลาดมาก อีกทั้งในครั้งนี้ แม้บริษัทเองก็น่าจะมีภาษาของตัวเองอยู่มากมาย แต่การเลือก Go ของ Google สำหรับภาษาที่ใช้พอร์ตเป็นเนทีฟก็น่าประหลาดใจเช่นกัน riki3 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) นักพัฒนา .NET และ Rust ดูเหมือนจะไม่พอใจกันมากเลย xguru 2025-03-12 | ความคิดเห็นหลัก | ใน: อัปเดตเฟิร์มแวร์ของเครื่องพิมพ์ HP ทำให้ใช้งานไม่ได้ และยังเกิดปัญหาไม่สามารถใช้ตลับหมึก HP ได้ (arstechnica.com) Brother, การอัปเดตเฟิร์มแวร์แบบบังคับที่ทำให้ไม่สามารถใช้ตลับหมึกเครื่องพิมพ์จากผู้ผลิตรายอื่นได้ galadbran 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) เอ๊ะ แต่ฝั่ง deno น่าจะมีทูลเชนที่สร้างบน Rust อยู่แล้วไม่ใช่เหรอ... ทำไมจู่ ๆ กลายเป็น Go ล่ะ? illiil1lii 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) ผมเคยมีประสบการณ์ว่าเวลาใช้ generic type ที่ประกอบด้วยการเรียกซ้ำแบบ recursive มันช้าจนต้องใช้ทางเลือกอื่น ถ้าเร็วขึ้น 10 เท่า ก็คาดหวังได้เลยว่าส่วนแบบนี้น่าจะดีขึ้นด้วย tujuc 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) เธรดอภิปรายเรื่องทำไมถึงต้องเป็น Go น่าสนใจดีนะครับ https://github.com/microsoft/typescript-go/discussions/411 ยังมีเรื่องที่ต้องคิดอีกเยอะ... ethanhur 2025-03-12 | ความคิดเห็นหลัก | ใน: Glue: คนที่คอยทำให้องค์กรเดินหน้าไปได้อย่างเงียบๆ (stdy.blog) หลายคนจบลงที่ข้อ 4 ซึ่งน่าเสียดายมาก ยอมแพ้และทำแค่สิ่งที่ระบุไว้ใน job ladder เท่านั้น clastneo 2025-03-12 | ความคิดเห็นหลัก | ใน: TypeScript เร็วขึ้น 10 เท่า (devblogs.microsoft.com) เขียนด้วย Go~ tsboard 2025-03-12 | ความคิดเห็นหลัก | ใน: การสร้างแอป Android ในปี 2025 (dev.to) พอดีปีนี้กำลังจะลองทำแอป Android อยู่พอดี เลยเป็นแนวทางที่มีประโยชน์มากครับ 555 โหลดความคิดเห็นเพิ่มเติม
ในฐานะคนที่ลงเอยมาเป็นวิศวกร build ของแอป Android แบบไม่รู้ตัว ขอลองฝากความเห็นไว้หน่อย..
> ระบบ build : gradle
ถึงจะใหญ่หรือซับซ้อนมากแค่ไหน ก็ต้องใช้ gradle อยู่ดี... (มองไกล)
มีโปรเจ็กต์ด้านล่างนี้กำลังดำเนินอยู่เพื่อปรับปรุงประสิทธิภาพการ build ของ gradle ในโปรเจ็กต์ที่ใหญ่หรือซับซ้อนมาก ดังนั้นถ้าคุณใช้ gradle กับโปรเจ็กต์ขนาดใหญ่ ก็ควรเตรียมการย้ายล่วงหน้าไว้จะดีกว่า
> โครงสร้างโมดูล : แยกตาม feature
ส่วนตัวผมมองว่าไม่มีเหตุผลจำเป็นที่จะต้องเปิดเผย architectural layer ออกมาที่ระบบ build
ในกรณีของแอปที่ผมดูแลอยู่ ผมทำให้ build system มองเห็นโมดูลเป็น feature-api / feature-impl
ถ้าจัดแบบนี้ การเปลี่ยนโค้ดใน feature-impl จะไม่ส่งผลต่อโมดูลอื่นที่อ้างอิง feature-api (แยก dependency ออกจากกัน) จึงช่วยได้มากทั้งกับ incremental build และการเพิ่ม build cache hit rate
> unit test - junit 4
เรื่องนี้ดูเหมือนว่าการตัดสินใจของ Google จะมีบทบาทค่อนข้างมาก
แต่ screenshot testing plugin ที่เพิ่งเปิดตัวล่าสุด กลับ อิงกับ JUnit5 ครับ.
น่าจะเป็น Clubhouse นะครับ ผมเองก็นึกถึงอันนั้นขึ้นมาพอดีเหมือนกัน
ช่วงนี้ดูเหมือนบริการที่จำกัดจำนวนครั้งหรือเวลาจะกลับมาฮิตกันอีกแล้ว แต่ก็แอบคิดว่าอาจจะดังวูบขึ้นมาแล้วก็ซาไปเหมือนแอปแนวพูดคุยคล้ายการกระจายเสียงที่เคยฮิตเมื่อไม่นานมานี้ ซึ่งจำชื่อที่แน่ชัดไม่ได้เหมือนกันนะ
โห เป็นเกียรติของตระกูลฮัตเลยนะ
ทราฟฟิกน่าจะกระจุกตัวมหาศาลเฉพาะในช่วงเวลานั้น คงต้องมีการจัดการที่มีประสิทธิภาพนะครับ
กังวลว่าต่อไปอาจละเลยการดูแลโค้ดเบส TypeScript ที่มีอยู่เดิมหรือเปล่า
การพัฒนาภาษา C# ไม่ได้หยุดลงเสียทีเดียว แต่รู้สึกว่ามีเฟรมเวิร์กที่ใช้ C# หลายตัวถูกปล่อยปละละเลยมากเกินไป
กำลังลองทดสอบอยู่ และให้ความรู้สึกเหมือนชุดรวมมิตรแบบครบเครื่องเลยครับ
มีบทความลักษณะคล้ายกันถูกพูดซ้ำอยู่เรื่อย ๆ แต่ความโลภของมนุษย์นั้นไม่มีที่สิ้นสุด และเราก็ทำพลาดแบบเดิมซ้ำ ๆ
การที่ CPU ของคอมพิวเตอร์มีโหลด 100% ไม่ใช่เรื่องปกติ แต่พอเป็นโหลดงานของมนุษย์ 100% กลับสรุปกันว่า...ต้องขยันให้มากขึ้น
อืม.. พูดนอกเรื่องหน่อยว่าในช่วงไม่กี่ปีที่ผ่านมา มีการพบปรากฏการณ์แปลก ๆ ที่สตาร์ตอัปส่วนใหญ่ไปทาง Flutter ขณะที่บริษัทใหญ่ ๆ อย่าง META, OpenAI กลับไปทาง native..
ก็จริงครับ ความรู้สึกของนักพัฒนา .NET เองก็พอเข้าใจได้เหมือนกัน...
เป็นข่าวที่น่ายินดี! น่าแปลกที่ภาษา TypeScript ของ MS ดูเหมือนจะตัดสินใจเลือกสิ่งที่คาดไม่ถึงจริง ๆ อยู่หลายอย่าง ต่างจาก Dart ของ Google ที่พยายามจะมาแทนที่ JS สำหรับ MS แล้วนี่แทบจะเป็นโปรเจ็กต์โอเพนซอร์สชิ้นแรก ๆ และการเลือกแนวทางที่พยายามเข้ามาเสริม JS ก็ดูเป็นการตัดสินใจที่ชาญฉลาดมาก อีกทั้งในครั้งนี้ แม้บริษัทเองก็น่าจะมีภาษาของตัวเองอยู่มากมาย แต่การเลือก Go ของ Google สำหรับภาษาที่ใช้พอร์ตเป็นเนทีฟก็น่าประหลาดใจเช่นกัน
นักพัฒนา .NET และ Rust ดูเหมือนจะไม่พอใจกันมากเลย
Brother, การอัปเดตเฟิร์มแวร์แบบบังคับที่ทำให้ไม่สามารถใช้ตลับหมึกเครื่องพิมพ์จากผู้ผลิตรายอื่นได้
เอ๊ะ แต่ฝั่ง deno น่าจะมีทูลเชนที่สร้างบน Rust อยู่แล้วไม่ใช่เหรอ... ทำไมจู่ ๆ กลายเป็น Go ล่ะ?
ผมเคยมีประสบการณ์ว่าเวลาใช้ generic type ที่ประกอบด้วยการเรียกซ้ำแบบ recursive มันช้าจนต้องใช้ทางเลือกอื่น ถ้าเร็วขึ้น 10 เท่า ก็คาดหวังได้เลยว่าส่วนแบบนี้น่าจะดีขึ้นด้วย
เธรดอภิปรายเรื่องทำไมถึงต้องเป็น Go น่าสนใจดีนะครับ
https://github.com/microsoft/typescript-go/discussions/411
ยังมีเรื่องที่ต้องคิดอีกเยอะ...
หลายคนจบลงที่ข้อ 4 ซึ่งน่าเสียดายมาก
เขียนด้วย Go~
พอดีปีนี้กำลังจะลองทำแอป Android อยู่พอดี เลยเป็นแนวทางที่มีประโยชน์มากครับ 555