ก็เพราะยังไม่เคยเจอโปรเจ็กต์ Electron ที่ทำได้ดีจริง ๆ ไง ~
... เหมือนกำลังจะพูดแบบนั้นเลยนะ 555

 

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

 

เรื่องนี้เชื่อมโยงกับมาตรฐานกฎหมายแรงงานของแต่ละประเทศพอสมควร... บริษัทจำนวนมากในสหรัฐฯ ก็มักใช้วิธีเวียนกันเข้าเวร และถ้าช่วงไหนไม่สะดวกก็สลับลำดับกันไป เป็นเรื่องปกติ เพราะมันเหนื่อยพอสมควร... บางบริษัทก็มีทีมที่รับผิดชอบ on-call โดยเฉพาะ
ในยุโรป แค่เพราะลักษณะงานเปลี่ยนไป หรือเพราะเป็นการทำงานนอกเวลา ก็มักแทบจะต้องมีค่าตอบแทนแยกต่างหาก
ส่วนบ้านเรา ด้วยผลของระบบเงินเดือนแบบเหมารวม ก็เลยมักทำกันแบบพอประมาณ ทั้งที่ on-call ก็เป็นการทำงานอย่างชัดเจน แต่กลับถูกทำให้ดูเหมือนว่าเงินชดเชยสำหรับช่วงเวลาดังกล่าวเป็นสวัสดิการเสียมากกว่า

 

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

 

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

ถ้าคุณเป็นนักพัฒนาที่ใช้แอปโอเพนซอร์สขนาดเล็กถึงกลางและบิลด์ใช้เอง
บนอุปกรณ์ของ Apple แค่จะ sideload ก็ต้องเจลเบรกด้วยการอาศัยช่องโหว่ แบบนั้นใช้ Android ไปเลยยังสะดวกกว่า

 

ของเราคือ ค่ารอเวรจ่ายครึ่งหนึ่งของค่าจ้างรายชั่วโมง, สนับสนุนค่าโทรคมนาคม, และเวลาที่ต้องเข้าไปช่วยจะคิดเป็น OT 1.5 เท่า

 

> พูดกันตรง ๆ ตอนนี้ต่อให้พัฒนา Java ก็ไม่ได้จำเป็นต้องใช้ผลิตภัณฑ์ของ JetBrains เสมอไป

ตรงส่วนนี้... ค่อนข้างเห็นด้วยได้ยากนิดหน่อยนะ ฮือ...

 

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

 

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

[ลบลิงก์]

 

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

 

เป็นบทความที่ให้คำตอบกับความกังวลที่กำลังคิดอยู่ในช่วงนี้ ขอบคุณมากที่แบ่งปันบทความดี ๆ แบบนี้

 

ผมคอมไพล์ lsp เองแล้วใช้งานอยู่ พอเปลี่ยนเป็น Go ก็รู้สึกได้ชัดเลยว่าการใช้ทรัพยากรลดลง

 

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

 

โอ้ สุดยอด ในที่สุดก็มา...!!!

 

ช่วงนี้แค่ย้าย js ไป rust / go เพื่อเพิ่มประสิทธิภาพก็กำลังเป็นกระแสนิยม

 

ตอนรีแฟกเตอร์บ่อย ๆ มีหลายครั้งที่การพาร์สโค้ดฝั่ง tsserver ช้าจนทั้งเอดิเตอร์ค้างไปเลย หวังว่าจะออกมาเร็ว ๆ เพื่อจะได้หลุดพ้นจากความทรมานนี้สักที

 

ผมรู้สึกว่าทุกคนพูดกันไปโดยไม่ได้คำนึงถึง structural typing กันหรือเปล่า
ถ้าจะเขียนใหม่เป็นภาษาแบบ nominal typing อย่าง C# หรือ Rust ก็คงไม่ง่าย เพราะต้องเปลี่ยนโครงสร้างพื้นฐานของโปรเจ็กต์ไปมากเกินไป
ในบรรดาภาษาที่ใช้ structural typing ถ้าจะให้ประสิทธิภาพสูงกว่า JS เดิมได้ ก็คงมีแค่ C++ หรือไม่ก็ Go แต่ถ้าคำนึงถึงเรื่องผลิตภาพด้วย ก็แทบไม่มีทางเลือกอื่น