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

หวังว่าคุณจะสร้างบริการดี ๆ แล้วนำมาแชร์กันนะครับ 🙇🏻‍♂️

 

ขอบคุณมากครับ! แม้จะยังมีเนื้อหาที่ต้องขัดเกลาอีกมาก แต่ก็ขอบคุณที่ติดตามอ่านกันอย่างดีครับ

 

โอ้ ทำได้ดีมากจริงๆ ครับ/ค่ะ ผม/ฉันยังไม่ค่อยชำนาญเลย เลยจัดการเมนูแบบซ้อนกันไม่ค่อยได้ แต่ starlight ช่วยได้ดีมากจริงๆ

 

สวัสดีครับ/ค่ะ พอมาเห็นทีหลังว่ามีคอมเมนต์เพิ่มขึ้นเยอะมากแบบนี้ เลยอยากมาเขียนเล่าความรู้สึกไว้ครับ/ค่ะ

ในบล็อกผม/ฉันจะเขียนเนื้อหาเกี่ยวกับการย้ายจาก Native มาเป็น Flutter เป็นหลักนะครับ/คะ ไว้ถ้ามีโอกาสอาจจะเขียนเป็นบทความอีกครั้ง แต่ขอแชร์แบบสั้น ๆ ไว้ก่อน

ในช่วงประมาณ 3 วัน มีผู้เข้าชมสะสมราว 3,000 คน และมียอดดูหน้าเพจมากกว่า 50,000 ครั้งครับ/ค่ะ

มีเรื่องน่าเศร้านิดหน่อยที่ทำให้ผม/ฉันตัดสินใจเปิดโปรเจ็กต์นี้ต่อสาธารณะครับ/ค่ะ

ช่วงหลังมานี้ ที่บริษัทที่ผม/ฉันทำงานอยู่เกิดปัญหาเรื่องการปรับโครงสร้างเล็กน้อย แม้ว่าผม/ฉันจะยังอยู่ต่อ แต่ในบรรดาคนที่ทำงานด้วยกัน มีบางส่วนที่ต้องย้ายงาน และผม/ฉันก็อยากแนะนำสิ่งที่ทีมของเราถนัดให้กับบริษัทอื่นที่ใช้ Flutter ด้วย แน่นอนว่าผม/ฉันสามารถบอกได้ว่าคนในทีมที่กำลังจะย้ายงานนั้นทำได้ถึงระดับนี้ครับ/ค่ะ

พื้นฐานของเนื้อหานี้สร้างขึ้นจากไกด์ภายในที่ผม/ฉันกับเพื่อนร่วมทีมเคยเขียนไว้ในบริษัท และเทคโนโลยีที่เคยใช้ในโปรเจ็กต์ของบริษัท เดิมทีตั้งใจจะทำเป็นคู่มือ onboarding สำหรับสมาชิกใหม่ของทีม แต่ตอนนี้ไม่มีโอกาสได้ใช้ภายในแล้ว จึงเปิดเผยทั้งหมดเป็นสาธารณะครับ/ค่ะ

ยังมีหลายส่วนที่ขาดอยู่และมีอีกหลายเรื่องที่ยังไม่ได้ครอบคลุม ขอบคุณมากนะครับ/คะที่ชื่นชอบกัน 🙇🏻‍♂️

แล้วก็มีแบบสอบถามเพื่อปรับปรุงหน้าเพจด้วย หากมีเวลาช่วยตอบกันจะขอบคุณมากจริง ๆ ครับ/ค่ะ

https://tally.so/r/w559Vv

 

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

 

ผมก็เห็นด้วยในส่วนนี้เหมือนกัน ถ้าลอจิกที่เพิ่มเข้าไปใน HTML ไม่ใช่ vanilla แต่เป็น syntax เฉพาะของตัวเอง นั่นเป็นอุปสรรคใหญ่ แม้การทำ UI แบบง่าย ๆ จะไม่มีปัญหา แต่ถ้าลอจิกซับซ้อนขึ้น ก็จะต่างกันในแง่ความยืดหยุ่นในการพัฒนา และมองข้าม learning curve ไม่ได้

 

ได้อ่านบทความที่น่าสนุกเพราะคุณเลย! ขอบคุณครับ

 

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

 

ฟังดูเหมือนเป็นเรื่องราวว่าทำไม Julia ถึงถือกำเนิดขึ้นนะครับ แม้จะต้องศึกษาไลบรารีต่าง ๆ แต่ในแง่ที่มันช่วยแก้ปัญหาหลายอย่างของ NumPy ได้ ก็ดูเป็นตัวเลือกที่น่าสนใจมากจริง ๆ ครับ

 

ถ้าใช้ vectorization ของ numpy ไม่เก่ง ประสิทธิภาพก็พังได้เลยครับ การต้องเขียนโดยคำนึงถึงเรื่องพวกนั้นทั้งเครียดและยากครับ

 

ดูเหมือนว่าแต่ละคนจะมีรสนิยมต่างกัน แต่สำหรับผม ผมชอบ .map((item) => <li>) ของ JSX ที่จัดการด้วย vanilla JS มากกว่า &lt;li for&gt; ของ Angular, Vue ฯลฯ (รวมถึงไลบรารีพวกนี้? มาร์กอัป?)

 

https://tech.kakao.com/posts/700 ผมรู้สึกว่าโพสต์นี้เป็นตัวอย่างที่ดีของ Vibe Coding และดูเหมือนว่าบริบทจะคล้ายกันครับ ผมเองก็เห็นด้วยกับสิ่งที่คุณเขียนไว้ครับ

 

ผมไม่ชอบ NumPy

ดูเหมือนไลบรารี Python ที่ค่อนข้างเก่า ๆ จะมีปัญหาคล้าย ๆ กันหมด

 

แล้วข้อ 3 ล่ะ? -> เป็นเรื่องการรองรับรีซอร์สครับ

ด้านบนผมใส่หมายเลขเป็น 1, 2, 4, 5 แต่ใน Markdown มันเปลี่ยนเป็น 1234 อัตโนมัติเลยครับ

 

เราเคยเล่นเกม^นี้มาแล้ว!

^ การฝึกให้กด “ใช่” แบบไม่คิดกับ ActiveX

 

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