Thoughtworks Technology Radar ฉบับที่ 26 (PDF 39 หน้า)

จุดเด่นคือการทำภาพและอธิบายเทรนด์ล่าสุดในด้านเทคนิค/เครื่องมือ/แพลตฟอร์ม/ภาษาและเฟรมเวิร์กสำหรับการพัฒนา โดยแบ่งเป็น 4 ระดับคือ Hold/Assess/Trial/Adopt

ตลาดประหลาด: เศรษฐศาสตร์ของโอเพนซอร์สที่กำลังเปลี่ยนแปลง

• เราเป็นแฟนของ "The Cathedral and the Bazaar" ของ Eric Raymond แต่เมื่อมีความพยายามทำเชิงพาณิชย์เข้ามา สถานการณ์ก็เปลี่ยนไปอย่างซับซ้อน
• กรณีอย่าง ElasticSearch vs. OpenSearch หรือ Docker Desktop
• ในทางกลับกัน Facebook สนับสนุนเงินทุนให้ Presto ในฐานะผลิตภัณฑ์โอเพนซอร์ส ทำให้ผู้ดูแลโครงการยังคงถือครอง IP และเมื่อพวกเขาออกจากบริษัทก็รีแบรนด์เป็น Trino จึงกล่าวได้ว่าเราได้รับประโยชน์จากการลงทุนของ Facebook
• เมื่อมีโครงสร้างพื้นฐานสำคัญจำนวนมากขึ้นที่บริษัทต่างๆ ไม่ได้ให้ทุนสนับสนุน สถานการณ์ก็ยิ่งสับสนมากขึ้น
• อย่างที่เห็นจากกรณี Log4j เรามักจะตระหนักได้ก็ต่อเมื่อเกิดบั๊กด้านความปลอดภัยสำคัญ ว่าเราพึ่งพาแรงงานที่ไม่ได้รับค่าจ้างของนักพัฒนาโอเพนซอร์สมากเพียงใด
• ในบางกรณี การสนับสนุนเงินให้ผู้ดูแลโครงการสมัครเล่นผ่าน GitHub Sponsor หรือ Patreon ก็เป็นรางวัลที่มากพอจะสร้างความแตกต่างได้
• สำหรับบางคน สิ่งนี้กลับทำให้รู้สึกเหมือนมีภาระความรับผิดชอบเพิ่มเข้ามาในงานประจำวัน จนนำไปสู่ภาวะหมดไฟ
• เราสนับสนุนซอฟต์แวร์อย่างเต็มที่ แต่ก็รู้ว่าเศรษฐศาสตร์กำลังยิ่งแปลกขึ้นเรื่อยๆ และไม่มีทางออกง่ายๆ ในการหาสมดุลที่ถูกต้อง

นวัตกรรมด้านห่วงโซ่อุปทานซอฟต์แวร์

• เหตุการณ์อย่างข้อมูลรั่วไหลของ Equifax, การโจมตี SolarWinds และช่องโหว่ Log4J เกิดจากการกำกับดูแลห่วงโซ่อุปทานที่หละหลวม
• ตอนนี้ทีมต่างๆ เริ่มตระหนักแล้วว่า การตรวจสอบและจัดการ dependency ของโครงการต้องเป็นส่วนหนึ่งของแนวปฏิบัติทางวิศวกรรม
• Supply chain Levels for Software Artifacts (SLSA)
• CycloneDX : Bill of Materials สำหรับ Software / SaaS / Operations
• Syft : เครื่องมือ CLI โอเพนซอร์สสำหรับสร้าง Software Bill of Materials
• แฮกเกอร์กำลังอาศัยคุณลักษณะความไม่สมมาตรของการโจมตีและการป้องกันในด้านความปลอดภัยมากขึ้นเรื่อยๆ
• ผู้โจมตีต้องหาช่องโหว่ให้เจอเพียงจุดเดียว แต่ผู้ป้องกันต้องปกป้องพื้นผิวการโจมตีทั้งหมด
• ความพยายามในการยกระดับความปลอดภัยของซัพพลายเชนจึงมีความสำคัญต่อการปกป้องระบบให้ปลอดภัย

ทำไมนักพัฒนาจึงยังพัฒนา State Management ใน React กันต่อไป?

• เมื่อเฟรมเวิร์กได้รับความนิยม ก็เป็นเรื่องปกติที่จะมีชุดเครื่องมือออกมาเพื่อแก้ข้อบกพร่อง และต่อมาก็รวมเครื่องมือที่ได้รับความนิยมเข้าด้วยกัน
• แต่ React State Management ดูเหมือนจะไม่เป็นไปตามแนวโน้มทั่วไปนี้
• นับตั้งแต่ Redux เปิดตัว ก็ยังมีเครื่องมือและเฟรมเวิร์กที่จัดการ state ในแนวทางที่แตกต่างออกมาอย่างต่อเนื่อง
• ไม่แน่ใจว่าเหตุผลคืออะไร แต่ลองคาดเดาดูได้ว่า..
• เป็นเพราะการแตกแขนงตามธรรมชาติที่ ecosystem ของ JavaScript ชื่นชอบหรือไม่?
• เป็นข้อบกพร่องพื้นฐานของ React หรือไม่?
• เป็นปัญหาที่สนุกและจัดการได้ง่าย เหมาะกับการทดลองของนักพัฒนาหรือไม่?
• หรือเป็นเพราะความไม่สอดคล้องเชิงโครงสร้างที่คงอยู่เสมอ ระหว่างรูปแบบการอ่านเอกสาร (เว็บเบราว์เซอร์) กับการสร้าง interaction ของแอปพลิเคชันบนเอกสารเหล่านั้น?
• แม้จะไม่รู้ว่าทำไมมันถึงยังออกมาเรื่อยๆ แต่เราก็ตั้งตารอความพยายามครั้งถัดไปในการแก้ปัญหาถาวรนี้

การผจญภัยที่ไม่สิ้นสุดของมาสเตอร์ดาต้าแคตตาล็อก

• มีความพยายามอย่างต่อเนื่องในการรวบรวมและจัดหมวดหมู่ข้อมูลภายในองค์กร แต่ก็ทำได้ยากเพราะความซับซ้อน ความซ้ำซ้อน และความกำกวม
• มีเครื่องมืออัจฉริยะอย่าง Collibra และ Datahub ปรากฏขึ้น
• เครื่องมือเหล่านี้มอบแนวทางที่สอดคล้องกันสำหรับ data lineage และ metadata โดยรวม และสามารถขยายไปสู่ governance/management/publishing ได้
• ขณะเดียวกันก็มีความเคลื่อนไหวที่มุ่งออกจากแนวทางรวมศูนย์นี้ ไปสู่การกำกับดูแลและการค้นหาแบบ federated บนสถาปัตยกรรม data mesh

[ Techniques ]

Adopt

1. Four key metrics
2. Single team remote wall

Trial

3. Data mesh
4. Definition of production readiness
5. Documentation quadrants
6. Rethinking remote standups
7. Server-driven UI
8. Software Bill of Materials
9. Tactical forking
10. Team cognitive load
11. Transitional architecture

Assess

12. CUPID
13. Inclusive design
14. Operator pattern for nonclustered resources
15. Service mesh without sidecar
16. SLSA
17. The streaming data warehouse
18. TinyML

Hold

19. Azure Data Factory for orchestration
20. Miscellaneous platform teams
21. Production data in test environments
22. SPA by default

[ Platforms ]

Trial

23. Azure DevOps
24. Azure Pipeline templates
25. CircleCI
26. Couchbase
27. eBPF
28. GitHub Actions
29. GitLab CI/CD
30. Google BigQuery ML
31. Google Cloud Dataflow
32. Reusable workflows in Github Actions
33. Sealed Secrets
34. VerneMQ

Assess

35. actions-runner-controller
36. Apache Iceberg
37. Blueboat
38. Cloudflare Pages
39. Colima
40. Collibra
41. CycloneDX
42. Embeddinghub
43. Temporal

[ Tools ]

Adopt

44. tfsec

Trial

45. AKHQ
46. cert-manager
47. Cloud Carbon Footprint
48. Conftest
49. kube-score
50. Lighthouse
51. Metaflow
52. Micrometer
53. NUKE
54. Pactflow
55. Podman
56. Sourcegraph
57. Syft
58. Volta
59. Web Test Runner

Assess

60. CDKTF
61. Chrome Recorder panel
62. Excalidraw
63. GitHub Codespaces
64. GoReleaser
65. Grype
66. Infracost
67. jc
68. skopeo
69. SQLFluff
70. Terraform Validator
71. Typesense

[ Languages & Frameworks ]

Adopt

72. SwiftUI
73. Testcontainers

Trial

74. Bob
75. Flutter-Unity widget
76. Kotest
77. Swift Package Manager
78. Vowpal Wabbit

Assess

79. Android Gradle plugin - Kotlin DSL
80. Azure Bicep
81. Capacitor
82. Java 17
83. Jetpack Glance
84. Jetpack Media3
85. MistQL
86. npm workspaces
87. Remix
88. ShedLock
89. SpiceDB
90. sqlc
91. The Composable Architecture
92. WebAssembly
93. Zig

[dodok8]

ผมสงสัยว่า <성당과 시장> คืออะไรเลยลองค้นดู ปรากฏว่าฉบับแปลแบบอีบุ๊กก็เปิดให้อ่านฟรีด้วยนะครับ เมื่อไม่นานมานี้ก็มีกรณีของ faker.js กับ color.js เหมือนกัน ดังนั้นประเด็นว่าโอเพนซอร์สจะหารายได้อย่างไร (และจะยั่งยืนได้อย่างไร) กำลังกลายเป็นเรื่องสำคัญมากขึ้นเรื่อย ๆ ในยุคนี้ที่พวกเราพึ่งพาระบบนิเวศโอเพนซอร์สกันอย่างมากแล้ว