- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
สมัครสมาชิก Replit แบบชำระเงินเป็นเวลา 1 ปี
ผมสมัครสมาชิกเพราะว่าอยากลองใช้เครื่องมือ AI สำหรับการเขียนโปรแกรม และเพราะมีส่วนลด Black Friday จนถึงวันที่ 1 ธันวาคม
เหตุผลที่เลือกใช้เพราะผมไม่มีคอมพิวเตอร์ที่ดีพอ
- ไม่จำเป็นต้องติดตั้งคอมไพเลอร์หรืออินเทอร์เพรเตอร์ลงบนเครื่อง สามารถรันและตรวจสอบผลลัพธ์ได้จากเบราว์เซอร์
- เรียนรู้การเขียนโปรแกรมได้โดยไม่ต้องกังวลเรื่องการตั้งค่าสภาพแวดล้อม
- โครงการเขียนโปรแกรมร่วมกัน (ถ้าผมแชร์ลิงก์ เราสามารถ pair programming ด้วยกันได้) - ใครก็ได้ที่ต้องการสามารถทำร่วมกันได้
- การสร้างต้นแบบและทดสอบโค้ดอย่างรวดเร็ว
- สอนการเขียนโปรแกรมให้นักเรียนในลักษณะแบบโต้ตอบ
- การโฮสต์เว็บแอปพลิเคชันหรือ API ที่มีน้ำหนักเบา
ต่อไปนี้ผมคงต้องลองทำวิดีโอด้วยสิ่งนี้ดูบ้าง https://replit.com/
มาดูโลกกันเถอะ (ข่าวสารต่างๆ)
เศรษฐกิจ
2024-11-29 (ศุกร์) กิจวัตรตอนเช้า (Hankyung) : อัตราดอกเบี้ยของเกาหลีลดลงจาก 3.25% เป็น 3.0% / ความเหลื่อมล้ำทางรายได้เพิ่มขึ้น การบริโภคลดลง / X-ble Shoulder (หุ่นยนต์สวมใส่) / ETF หุ้นกลุ่มเฉพาะทางวิ่งขึ้น 20% (คนต่างชาติซื้อ)
>> ในที่สุด ถ้าคนต่างชาติไม่ซื้อ ราคาหุ้นก็ไม่มีทางขึ้นเลย
ไอที
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 นิสัยที่ควรปฏิบัติเพื่อเป็นนักพัฒนาที่ดี
>> นี่คือสิ่งที่ผมรู้สึกได้ขณะสร้างและดูแลแพลตฟอร์ม telematics / cluster แต่ผมก็ไม่สามารถปฏิบัติตามได้อย่างถูกต้อง เราต้องไม่กลัวการเปลี่ยนแปลง และถ้าเราแบ่งมันออกเป็นส่วนเล็กๆ อย่างที่นี่ เราก็ทำได้
ต้นฉบับ : ภาษาเกาหลี , ภาษาอังกฤษ
1. รักษาขนาดของการ commit ให้เล็กที่สุดเท่าที่จะทำได้ จนกระทั่งคุณคิดว่า "ขนาดนี้มันเล็กเกินไปหรือเปล่า?"
เพราะคุณไม่รู้ว่าเมื่อไหร่จะต้องย้อนกลับการเปลี่ยนแปลงบางอย่าง การที่รู้ตำแหน่งที่แน่นอนของบั๊กที่เกิดขึ้นเมื่อ 6 วันก่อน และสามารถย้อนกลับเฉพาะ commit นั้นได้โดยไม่มีการ merge conflict ที่ซับซ้อนนั้น ทำให้รู้สึกโล่งใจมาก มาตรฐานของผมนั้นง่ายมาก คือโค้ดที่คอมไพล์ได้ก็สามารถ commit ได้
2. ปฏิบัติตามคำกล่าวของ Kent Beck: "เพื่อการเปลี่ยนแปลงที่ต้องการ ให้เริ่มต้นด้วยการทำให้การเปลี่ยนแปลงนั้นง่ายขึ้นก่อน (ข้อควรระวัง: สิ่งนี้อาจทำได้ยาก) จากนั้นจึงทำการเปลี่ยนแปลงที่ง่ายขึ้นนั้น"
"เพื่อการเปลี่ยนแปลงที่ต้องการ ให้เริ่มต้นด้วยการทำให้การเปลี่ยนแปลงนั้นง่ายขึ้นก่อน (ข้อควรระวัง: สิ่งนี้อาจทำได้ยาก) จากนั้นจึงทำการเปลี่ยนแปลงที่ง่ายขึ้นนั้น"
ให้ refactoring เป็นมากกว่าครึ่งหนึ่งของการ commit ทั้งหมด การ refactoring อย่างต่อเนื่องหมายถึงการค้นหาและนำการปรับปรุงที่สามารถทำได้ภายใน 10 นาทีมาใช้ การปรับปรุงเล็กๆ น้อยๆ เหล่านี้จะช่วยให้คุณสามารถแก้ไขปัญหาได้ด้วยการเปลี่ยนแปลงเล็กๆ น้อยๆ เมื่อมีข้อกำหนดที่ใหญ่ขึ้นมาในภายหลัง คุณควรหลีกเลี่ยงการ refactoring ในระดับใหญ่
3. โค้ดทุกบรรทัดคือหนี้สิน
โค้ดที่ไม่ได้ใช้งานคือหนี้สินชนิดหนึ่ง คุณต้องตรวจสอบให้แน่ใจว่าโค้ดทำงานได้อย่างถูกต้องและอย่างน้อยก็ไม่ทำให้ฟังก์ชันอื่นๆ เสียหาย การทดสอบจะช่วยเสริมสร้างความมั่นใจ และการ deploy สู่ production จะช่วยยืนยัน การ deploy บ่อยๆ อาจทำให้ค่าใช้จ่ายในการโฮสต์เพิ่มขึ้นเล็กน้อย แต่ก็คุ้มค่าที่จะได้เห็นว่างานล่าสุดนั้นเป็นความก้าวหน้าที่แท้จริง หลักการหนึ่งของ Agile คือ "ซอฟต์แวร์ที่ใช้งานได้คือมาตรวัดความคืบหน้าที่สำคัญ" ในที่นี้คำว่า 'ใช้งานได้' และ 'ความคืบหน้า' มีความหมายสำคัญ ผมจึงได้กำหนดความหมายของตัวเองขึ้นมา 'ใช้งานได้' หมายถึงระดับที่สามารถ deploy ได้ และโค้ดที่ส่งผลต่อฟังก์ชันใดๆ คือ 'ความคืบหน้า'
4. ลองถามตัวเองดูว่าคุณกำลังทดสอบฟังก์ชันของเฟรมเวิร์กอยู่หรือเปล่า ถ้าใช่ อย่าทำ
เฟรมเวิร์กได้รับการทดสอบแล้วโดยผู้เชี่ยวชาญมากกว่าคุณมาก และคุณควรเชื่อถือว่า hook useState() ทำงานได้ตามที่ตั้งใจไว้ การรักษาขนาดของคอมโพเนนต์ให้เล็กจะทำให้เฟรมเวิร์กจัดการงานหลักๆ ส่วนใหญ่ได้ ดังนั้นจึงไม่จำเป็นต้องมีการทดสอบมากนัก ถ้าคอมโพเนนต์ใหญ่ขึ้น ความซับซ้อนก็จะเพิ่มขึ้น และคุณต้องเขียนการทดสอบมากขึ้น
5. ถ้าฟังก์ชันใดๆ ไม่เข้ากับที่ใดเลย ให้สร้างโมดูล (หรือคลาสหรือคอมโพเนนต์) ใหม่และค้นหาตำแหน่งที่เหมาะสมในภายหลัง
การสร้างโครงสร้างใหม่ที่เป็นอิสระนั้นดีกว่าการพยายามใส่ลงในตำแหน่งที่ไม่เข้ากัน แม้ในกรณีที่แย่ที่สุด โมดูลอิสระก็ไม่เลวร้ายอะไร
6. ถ้าไม่รู้ว่า API ควรมีหน้าตาเป็นอย่างไร ให้เขียนการทดสอบก่อน
สิ่งนี้จะทำให้คุณคิดในมุมมองของ "ลูกค้า" ซึ่งในกรณีนี้ก็คือตัวคุณเอง คุณอาจจะพบกรณีที่ไม่พบถ้าคุณเขียนโค้ดก่อนแล้วจึงทดสอบทีหลัง ไม่จำเป็นต้องยึดติดกับ TDD มากเกินไป และคุณสามารถทำงานกับหน่วยที่ใหญ่ขึ้นได้ (เช่น การเขียนโค้ดหลายบรรทัดก่อนที่การทดสอบจะผ่าน) ปริมาณโค้ดที่อยู่ในสถานะล้มเหลวไม่จำเป็นต้องน้อยเสมอไป ถ้าคุณรู้ว่าคุณกำลังทำอะไรอยู่ อย่าให้หลักการมาขัดขวางประสิทธิภาพการทำงาน
7. การคัดลอกและวางครั้งเดียวก็โอเคแล้ว
อย่าทำซ้ำครั้งที่สอง (กล่าวคือ การคัดลอกครั้งที่สาม) เพราะถึงตอนนั้นคุณจะมีกรณีศึกษาเพียงพอที่จะสร้างการ abstract ที่ดีได้แล้ว ความเสี่ยงที่การใช้งานฟังก์ชันเดียวกันจะแตกต่างกันนั้นสูงเกินไป จึงจำเป็นต้องมีการรวมเข้าด้วยกัน การทำให้พารามิเตอร์ดูไม่ค่อยสวยนั้นดีกว่าการใช้งานฟังก์ชันเหมือนกันหลายๆ ครั้ง ถ้ามีเหตุการณ์แบบนี้เกิดขึ้นอีก การปรับปรุงพารามิเตอร์จะง่ายกว่าการรวมการใช้งาน 4 ครั้งที่แตกต่างกัน
8. การออกแบบมักจะล้าสมัย
การ refactoring สามารถชะลอความเร็วได้ แต่ในที่สุดคุณก็ต้องเปลี่ยนวิธีการทำงาน อย่าเสียใจมากเกินไปเมื่อต้องทิ้งสิ่งที่เคยหวงแหนและภูมิใจในอดีต ในตอนนั้นคุณได้ทำอย่างเต็มที่แล้ว และไม่จำเป็นต้องตำหนิตัวเองที่ทำไม่ได้อย่างสมบูรณ์แบบจนไม่จำเป็นต้องเปลี่ยนแปลง การพัฒนาซอฟต์แวร์ส่วนใหญ่เป็นการเปลี่ยนแปลงซอฟต์แวร์ ยอมรับมันและก้าวไปข้างหน้า การออกแบบที่สมบูรณ์แบบนั้นไม่มีอยู่จริง และการเปลี่ยนแปลงคือหัวใจสำคัญของการพัฒนาซอฟต์แวร์ ความสามารถในการเปลี่ยนแปลงได้อย่างเชี่ยวชาญคือสิ่งที่กำหนดความสามารถของนักพัฒนา
9. หนี้สินด้านเทคโนโลยีสามารถแบ่งออกได้เป็น 3 ประเภท:
1) สิ่งที่ขัดขวางงานปัจจุบัน 2) สิ่งที่จะขัดขวางงานในอนาคต 3) สิ่งที่อาจขัดขวางงานในอนาคต การจำแนกประเภทอื่นๆ ทั้งหมดเป็นส่วนย่อยของสามประเภทนี้ ลดข้อ 1 ให้เหลือน้อยที่สุดและให้ความสำคัญกับข้อ 2 อย่าสนใจข้อ 3
10. ความสามารถในการทดสอบมีความเกี่ยวข้องอย่างใกล้ชิดกับการออกแบบที่ดี
การที่ทดสอบได้ยากหมายความว่าคุณต้องเปลี่ยนการออกแบบ บางครั้งการออกแบบนั้นอาจเป็นการออกแบบการทดสอบ ตัวอย่างเช่น ถ้าการ mock em.getRepository(User).findOneOrFail({id}) ทำได้ยาก คุณควรแยกการเรียกใช้เป็นฟังก์ชันแยกต่างหากที่สามารถ mock ได้ หรือเขียนยูทิลิตี้การทดสอบเพื่อให้สามารถ mock เมธอด Entity Manager ได้ง่ายขึ้น เหตุผลที่ไม่มีการเขียนการทดสอบไม่ใช่เพราะไม่อยากเขียน แต่เป็นเพราะเขียนได้ยาก
ความคิดเห็น0