ผมรู้สึกเหนื่อยล้ากับปลั๊กอินจำนวนมากของ Obsidian
เลยเปลี่ยนไปใช้ Reflect และพอใจมากครับ

 

ช่วงหนึ่งผมเริ่มจับ TS น้อยลงไปแล้ว แต่พอเห็นข่าวแบบนี้ก็เริ่มสนใจขึ้นมาอีกนะ?

 

ผมเลยกันเวลาบ่ายวันศุกร์ไว้เป็นเวลาพัฒนาส่วนตัวไปเลยครับ!

 

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

 

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

 

จีนกำลังพุ่งแรงจริง ๆ นะ

 

ส่วนตัวแล้วบางกรณี ts มี type ที่ซับซ้อนมากจนแทบจะถอดใจไปเลย (สุดท้ายก็เขียนเป็น any ไปซะงั้น) แบบนี้คงเป็นเพราะผมยังเข้าใจภาษาไม่มากพอใช่ไหม? แล้วก็ขึ้นอยู่กับสถานการณ์ บางทีก็เสียเวลาไปเยอะมากแค่เพื่อจะกำจัดเส้นแดงจริง ๆ

 

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

 

ตอนที่เคยไปอาศัยอยู่ที่เซี่ยงไฮ้ชั่วคราวราว 1 ปี ผมเคยไปเที่ยวหางโจวอยู่ครั้งหนึ่ง (ตอนนั้นเหมือนไปดูการแสดงอะไรสักอย่าง) เมืองก็สะอาด วิวทะเลสาบซีหูก็ดี เลยคิดว่าเป็นเมืองที่น่าอยู่มากจริง ๆ ตอนนี้ดูเหมือนว่าจะกลายเป็นสถานที่ที่เหมาะกับการทำธุรกิจด้วยเหมือนกันนะครับ

 

ยังไม่มีข้อมูลเกี่ยวกับประสิทธิภาพภาษาเกาหลี แต่พอลองดึงมาใช้ดูก็เหมือนไม่แย่นะ

 

ถ้ามีฟังก์ชันหลบเลี่ยงการป้องกันมาโครได้.. ก็น่าจะกลายเป็นผู้ชนะของตลาดครับ

 

ดูเหมือนว่าประเด็นถกเถียงจะร้อนแรงพอสมควรจน Anders Hejlsberg เข้ามาคอมเมนต์ด้วยตัวเองเลย

https://github.com/microsoft/typescript-go/…

 

คนหนึ่งที่อยากให้คอมไพล์ด้วย TypeScript แล้วได้ผลลัพธ์ออกมาเป็นไบนารีได้ทันที

 

ขอบคุณสำหรับการแนะนำข้อมูลดี ๆ ครับ

 

SWC มุ่งเน้นไปที่การสร้างโค้ด JavaScript ที่เข้ากันได้แบบเดียวกับ Babel และรวมไฟล์เข้าด้วยกัน ส่วนสิ่งนี้มุ่งเน้นไปที่การแปลงโค้ด TypeScript เป็น JavaScript หรือตรวจสอบข้อผิดพลาด

 

ความรู้สึกคล้ายกับประสบการณ์ของผมเลยครับ

  • เวลาต้องเขียนโค้ดที่เรียบง่ายแต่จำได้ยาก (เช่น การจัดการไฟล์อินพุต/เอาต์พุต, การจัดการคอนเทนเนอร์ เป็นต้น)
  • ตอนที่เกิดข้อผิดพลาดตอนคอมไพล์หรือรันไทม์ แล้วอยากรู้ว่านี่คือ error อะไรและโค้ดส่วนไหนเป็นสาเหตุ
  • เวลาที่อยากเขียนฟังก์ชันใหม่โดยอิงจากฟังก์ชันที่เขียนไว้แล้วและคล้ายกัน แต่เพิ่มความสามารถที่ต่างออกไปเล็กน้อย
  • เวลาที่อยากเปลี่ยนโค้ดที่พึ่งพาไลบรารีหนึ่งไปใช้อีกไลบรารีหนึ่ง หรือแทนที่ด้วยฟังก์ชันที่เขียนเอง
  • เวลาที่ต้องการไกด์ว่าควรพัฒนาอย่างไรเพื่อสร้างฟีเจอร์บางอย่าง หรือทำงานในสภาพแวดล้อมเฉพาะ

ในเคสแบบข้างต้นช่วยประหยัดเวลาไปได้มากทีเดียวครับ หลายครั้งก็หาไม่ค่อยเจอด้วยชุด Google+Stack Overflow และโดยเฉพาะใน Stack Overflow พอมีคำตอบหนึ่งมา ก็มักจะมีคอมเมนต์โต้แย้งตามมาเยอะเสมอ แถมบางทีก็เป็นวิธี implement ของเวอร์ชันเก่าที่ไม่ควรใช้แล้ว อะไรทำนองนั้น เลยมีหลายครั้งที่น่าหงุดหงิดมาก...

 

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

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