Swift ก็ดีนะ แต่ Swift ที่ถูกทอดทิ้งจะกลับมามีชีวิตอีกครั้งได้ไหม..

 
  • iPhone วางจำหน่ายหลายสี
  • เทรนด์คือฮาร์ดแวร์เรียบง่าย และออกแบบให้ปรับแต่งความเป็นส่วนตัวได้ในซอฟต์แวร์
 

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

 

ขอบคุณสำหรับบทความดี ๆ

 

ผมเองก็กำลังทรุดโทรมจากชีวิตการทำงานประจำอยู่เหมือนกัน แต่โปรเจกต์ข้างกายก็ยังคอยวนเวียนอยู่ในหัวตลอด ดู YouTube ก็ไม่สนุกแล้ว... จะเรียนอะไรก็ไม่สนุก และพอเปลี่ยนโน้ตบุ๊กครั้งนี้แล้วก็กะว่าจะลองทำ side project ด้วย Flutter ดูครับ :)

 

ผมคิดว่าในสถานการณ์ที่ไม่รู้ว่านักพัฒนาจะใช้ React ภายใต้ข้อจำกัดแบบใด เอกสารทางการก็ควรเขียนให้อยู่ในสภาพแวดล้อมที่ใกล้เคียงกับ vanilla มากที่สุด

 

React ไม่จำเป็นต้องใช้กับเฟรมเวิร์กที่อิงกับ React เสมอไป เพราะสามารถใช้ร่วมกับเว็บเฟรมเวิร์กที่สร้างด้วยภาษาอื่น ๆ ได้หลากหลาย (เช่น Go, Rust, Java เป็นต้น)
-> จริง ๆ แล้วเพราะเหตุนี้เอง ผมจึงคิดว่าอย่างน้อยในส่วน get started ของเอกสารทางการ React ก็น่าจะแนะนำให้ใช้แค่ React โดยพยายามไม่พึ่งพา dependency อื่นให้มากที่สุด

 

ดูเหมือนว่าจะเหมาะกับ Apple Silicon ที่มี RAM เหลือพอ หรืออุปกรณ์ตระกูล NPU มากกว่า ถ้าจะใช้กับเซิร์ฟเวอร์ GPU ล้วน ๆ แม้แต่โมเดลสเปกขั้นต่ำก็ยังต้องใช้การควอนไทซ์แบบ int4 และต้องมี H100 อยู่ดี..

 

จริง ๆ แล้วสเปกขั้นต่ำรวมการทำ quantization ด้วยก็แทบจะเป็น A100 อยู่แล้ว แต่ประสิทธิภาพก็ยังค่อนข้างก้ำกึ่งอยู่ดี ฮือๆ

 

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

 

คงต้องลองติดตั้งมาใช้ดูครับ

 

ฮ่าๆๆๆๆๆๆๆๆๆ

 

ฮ่าๆ เห็นด้วยเลย

 

มีอะไรที่ดีกว่า google gemma3 ไหม?

 

มันจะเร็วกว่า Cuda wrapper ที่มีอยู่เดิมอย่าง Cupy, pytorch ไหมนะ ข้อดีของ Cupy กับ torch คือ API แทบจะเหมือนกับ numpy มาก เลยสามารถย้ายโค้ดทดสอบที่เขียนด้วย numpy มาใช้ได้แทบไม่ต้องออกแรงมาก อันนี้คงต้องลองใช้ดูก่อนครับ

 

เป็นเรื่องที่ไม่เคยคิดมาก่อนเลย... เรื่องแบบนี้ก็มีด้วยเหรอ นี่มันเรื่องสยองจริง ๆ

 

เรื่องนี้น่าอึดอัดตรงที่
แบบเดิม: คิด => โค้ด (ช้า) => ดีบัก
AI: คิด => เขียนพรอมป์ต์อย่างประณีต => โค้ด (พริบตาเดียว) => ดีบัก
แต่ปกติแล้ว การเขียนความคิดของตัวเองออกมาเป็นโค้ดมันเร็วกว่าการเอาไปเขียนเป็นพรอมป์ต์ไม่ใช่เหรอ? ยกเว้นเวลาที่ทำเรื่องที่เป็นที่รู้จักกันดีมากอยู่แล้ว.. ในส่วนที่ความน่าเชื่อถือสำคัญ ยังไงสุดท้ายพอเขียนเสร็จก็ต้องไล่ดูตรรกะด้วยตาอยู่ดี เลยฝากให้ทำแทนทั้งหมดก็ไม่ได้ และพอฝากไปก็เหมือนขาดจิตสำนึกในวิชาชีพด้วย

 

ความเร็วช่วงแรกนี่จริงหรือเปล่า? ช้าเกินไปนะ...