ผมคิดว่าในสตาร์ตอัป ไมโครเซอร์วิสก็มีข้อดีอยู่มากเหมือนกัน อย่างแรกเลยคือข้อดีของการใช้ monorepo นั้นผมแนะนำมากจริง ๆ

• เมื่อทิศทางของผลิตภัณฑ์มีการเปลี่ยนแปลง ในไมโครเซอร์วิสจุดที่ต้องแก้ไขจะชัดเจนและน้อยกว่าแบบโมโนลิธิก ผมคิดว่านี่เป็นข้อดีที่ใหญ่มากจริง ๆ
• ในยุคของการพัฒนาด้วย AI หน่วยย่อยเล็ก ๆ ของไมโครเซอร์วิสพัฒนาได้ง่ายกว่าผ่าน AI (ไม่ได้หมายความว่าโมโนลิธิกทำไม่ได้)
• ผมยอมรับว่าภาระของ CI/CD มีอยู่ แต่ก็มีบริการที่ถูกยุติไปตั้งแต่ยังอยู่ในขั้นกำหนดทิศทาง สุดท้ายแล้วต่อให้ค่อยสร้างตอนที่กำหนดทิศทางได้ชัดเจนแล้ว ก็แทบจะเป็นระดับคัดลอกวางและสร้างเสร็จได้ภายในหนึ่งสัปดาห์
• โอเพนซอร์สที่แต่ละภาษามีจุดแข็งนั้นค่อนข้างชัดเจน เช่น ทำ Security และ business logic ด้วย Java และทำ AI ด้วย Python ในโครงสร้างแบบไมโครเซอร์วิสจะสามารถใช้โอเพนซอร์สได้ให้มากที่สุด

เราคงใช้ชีวิตโดยออกห่างจากโลกที่ประกอบด้วย 1 กับ 0 ไม่ได้แม้แต่วันเดียวแล้วสินะ.... ฟังดูไม่ใช่เรื่องของคนอื่นเลย...

การจำกัดขอบเขตของงานเรียกว่า scoping ความสามารถก็คือการทำ scoping ให้ดีเพื่อให้ชนะได้

เคยได้ยินแต่ digital detox แต่เพิ่งเคยได้ยิน digital botox เป็นครั้งแรกเลย 5555
ก่อนหน้านี้ผมสงสัยว่า Starlink ทำงานเป็นรูปธรรมแบบไหนบ้าง ตอนนี้ข้อสงสัยคลี่คลายไปเยอะเลยครับ

ย่านความถี่ที่ได้รับการคุ้มครองซึ่งกล่าวถึงในบทความนี้คือ 1400-1427 MHz และไม่ได้รวมแค่การสังเกตดินหรือมหาสมุทรตามที่บทความกล่าวถึงเท่านั้น แต่ยังรวมถึงคลื่นวิทยุจากก๊าซไฮโดรเจนในดาราจักรที่ใช้สังเกตในวิทยุดาราศาสตร์ด้วย (1420.405 MHz)
ดังนั้น การรบกวนทางอิเล็กทรอนิกส์อย่างรุนแรงที่เกิดขึ้นในความขัดแย้งทางทหารจึงทำให้การทำวิทยุดาราศาสตร์เป็นไปได้ยากมาก

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

• SMAP Maps: Radiometer RFI

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

ผมเลยลองหาสาเหตุว่าทำไมมีแค่ญี่ปุ่นที่เป็นแบบนั้น และพบว่าต้นเหตุคือเครื่องรับโทรทัศน์ผ่านดาวเทียมดิจิทัลที่แพร่หลายในญี่ปุ่น
ญี่ปุ่นยุติการออกอากาศทีวีแอนะล็อกในเดือนกรกฎาคม 2011 และในเดือนธันวาคมปีเดียวกันก็เพิ่มช่อง BS ดิจิทัลผ่านดาวเทียมเป็น 24 ช่อง สัญญาณโทรทัศน์ผ่านดาวเทียมนี้ใช้ความถี่สูงถึง 12 GHz ซึ่งเป็นภาระหากให้อุปกรณ์ประมวลผลโดยตรง จึงมีการแปลงภายในเป็น IF (ความถี่กลาง) เพื่อประมวลผล
ปัญหาคือในกรณีของช่อง 21 ความถี่หลังการแปลงเป็นความถี่กลางอยู่ที่ 1415-1450 MHz ซึ่งทับซ้อนกับย่านความถี่ที่ได้รับการคุ้มครองที่กล่าวถึงข้างต้น และดูเหมือนว่ามาตรฐานที่เกี่ยวข้องของญี่ปุ่นในเวลานั้นจะยังไม่เข้มงวดเท่าปัจจุบัน
ผลคือมีเครื่องรับและเครื่องขยายสัญญาณกระจายที่ปล่อยคลื่นรั่วในย่านดังกล่าวอยู่เล็กน้อยจำนวนหลายล้านเครื่องกระจายอยู่ทั่วญี่ปุ่น จนทำให้เกิดปัญหานี้ขึ้น ปริมาณคลื่นรบกวนที่รั่วจากอุปกรณ์แต่ละเครื่องยังอยู่ภายในค่ามาตรฐาน แต่เมื่อมีอุปกรณ์หลายล้านเครื่องทำงานพร้อมกัน ย่านความถี่นั้นทั้งย่านก็ได้รับผลกระทบ
แม้ว่าหลังปี 2018 กระทรวงกิจการภายในและการสื่อสารของญี่ปุ่นจะเข้มงวดมาตรฐานการผลิตและการติดตั้งเครื่องรับโทรทัศน์ผ่านดาวเทียมมากขึ้น และให้เงินอุดหนุนสำหรับการเปลี่ยนเครื่องรับรุ่นเดิม แต่ปัญหานี้ก็ยังคงไม่ได้รับการแก้ไขจนถึงทุกวันนี้

แหล่งที่มาของเนื้อหาเกี่ยวกับญี่ปุ่น:

• SMOS RFI EXPERIENCE IN THE 1400-1427MHz PASSIVE BAND DUE TO RADIATIONS AT INTERMEDIATE FREQUENCY OF SATELLITE HOME-TV RECEIVERS

ว้าว... เคยได้ยินแต่ชื่อ Starlink พอได้เห็นรีวิวจากการใช้งานจริงแล้วก็น่าทึ่งมากเลยครับ อ่านเพลินมาก!

OpenSearch เกิดขึ้นในปี 2021 หลังจาก Elasticsearch เปลี่ยนไลเซนส์ โดยมีเป้าหมายที่จะเป็นตัวทดแทนที่เข้ากันได้ แม้จะเข้ากันได้ค่อนข้างมาก โดยเฉพาะเวอร์ชัน 1.x กับ Elasticsearch 7.10 แต่ก็ไม่ใช่โซลูชันแบบแทนที่ได้ทันทีอย่างสมบูรณ์ Elasticsearch ได้พัฒนาต่อไปอีกและมีฟีเจอร์กับการปรับแต่งที่มากกว่า โดยเฉพาะใน Kibana และ aggregations ประสิทธิภาพขึ้นอยู่กับแอปพลิเคชัน โดยทั้งสองสร้างบน Lucene ผู้ใช้บางรายพบว่า OpenSearch ช้ากว่าและฟอร์กของ Kibana มีบั๊ก แม้ Elasticsearch จะกลับมาเป็นโอเพนซอร์สอีกครั้ง (AGPLv3) ในเดือนกันยายน 2024 แต่บางคนก็ยังชอบ OpenSearch เพราะความเป็นโอเพนซอร์สอย่างแท้จริงและการรองรับจาก AWS แม้การค้นหาแบบเวกเตอร์จะเป็นจุดแตกต่างสำคัญ แต่การใช้งานในสเกลใหญ่ต้องบริหาร RAM อย่างรอบคอบ ท้ายที่สุดแล้ว การเลือกใช้งานขึ้นอยู่กับความต้องการเฉพาะ โดยทั้งสองมีทั้งจุดแข็งและจุดอ่อน ผมกำลังทำงานกับ OpenSearch ร่วมกับ Davidayo https://www.davidayo.com เครื่องมือ AI ทรงพลัง "AskPromptAI" https://askpromptai.com.

มีพูดไว้เล็กน้อยในคอมเมนต์เหมือนกัน แต่สาย beam/otp นี่ค่อนข้างยืดหยุ่นและดีทีเดียวครับ ในกรณีของ Gleam นั้น ด้วยการผสานไวยากรณ์ที่ดีของทั้ง go และ rust เข้ากับเสถียรภาพของ beam เลยกลายเป็นภาษาที่น่าประทับใจมากพอสมควร อยากลองค่อย ๆ เอามาใช้กับโปรเจ็กต์ขนาดเล็กดูเหมือนกันครับ

WA!(SM)

ถ้าแบ่งทีมยิบย่อยเกินไป แม้แต่การมารวมตัวกันเพื่อแลกเปลี่ยนความเห็นก็จะกลายเป็นงานใหญ่มหาศาล

Astro : เผยแพร่ JavaScript ให้น้อยที่สุด
Astro 3.0 เปิดตัว

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

บริษัทที่แม้แต่เอนจินยังทำออกมาได้ไม่ดี ก็มาทำเรื่องไร้สาระครบทุกแบบเลยสินะ 555

+1
คงได้ลองชิม Next.js มาแล้วสินะ 555

ฟังดูมีเหตุผลนะ 555

แอนิเมชันก็ดีนะ แต่มีหลายหน้าที่ทำให้สายตาไปโฟกัสที่แอนิเมชันมากกว่าเนื้อหา

โดยเฉพาะถ้าแอนิเมชันถึงขั้นรบกวนจังหวะการอ่าน ก็ทำให้หงุดหงิดตั้งแต่ก่อนจะเริ่มอ่านเลย

เป็นเนื้อหาที่น่าประทับใจมากจริง ๆ!
มีเคล็ดลับหลายอย่างที่นำไปใช้ในงานจริงได้ทันทีเลย ขอบคุณที่แบ่งปันนะครับ ☺️

การประยุกต์ใช้ The One-Person Framework ในทางปฏิบัติ
บรรลุผู้ใช้ 2 ล้านคนด้วยทีมพัฒนาหญิง 1 คน
สองบทความข้างต้นก็เป็นสิ่งที่เกิดขึ้นได้เพราะมี Rails เหมือนกัน เลยรู้สึกว่าช่วงนี้มีคนพูดถึง Rails กันมากขึ้นนะครับ

เหตุใด Ruby on Rails จึงยังคงสำคัญ - วิธีที่เครื่องมือเก่ายังคงอยู่รอดในโลกของ Next.js
เหตุผลที่เลิกใช้ Next.js แล้วกลับไปหา Ruby on Rails และ Inertia.js
Rails for Everything - พลังของ Rails สำหรับทุกสิ่ง

ดูเหมือนว่าการเลือกงานที่สามารถประกาศชัยชนะได้ว่า "เสร็จแล้ว (Done)" ก็เป็นทักษะสำคัญอย่างหนึ่งเช่นกัน

ที่บริษัทของเราไม่ได้เอา AI editor รุ่นใหม่ ๆ อย่าง Cursor มาใช้ แต่ใช้ LLM แค่ประมาณติดตั้ง continue extension บน VS Code แล้วใช้งานเท่านั้นครับ/ค่ะ คิดว่าอีกสัก 2~3 ปี ถ้ามี code editor ที่กลายเป็นตัวหลักออกมาแล้ว ค่อยนำมาใช้ตอนนั้นก็น่าสนใจเหมือนกัน...