- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Đăng ký Replit trả phí 1 năm
Tôi đã đăng ký vì cần phải dùng thử công cụ lập trình AI, nhân dịp giảm giá Black Friday đến ngày 1/12.
Lý do tôi chọn cái này là vì máy tính của tôi không được tốt,
- Không cần cài đặt trình biên dịch hoặc thông dịch viên cục bộ, có thể chạy và kiểm tra kết quả trên trình duyệt
- Học lập trình mà không cần lo lắng về việc cấu hình môi trường.
- Dự án lập trình chung. (Tôi sẽ chia sẻ liên kết nếu muốn lập trình đôi) - Ai cần thì cứ cùng làm nhé.
- Nhận dạng và kiểm tra nhanh chóng mã.
- Dạy lập trình cho học sinh theo cách tương tác.
- Lưu trữ ứng dụng web hoặc API nhẹ.
Tới đây, tôi cũng cần quay một video hướng dẫn nữa. https://replit.com/
Xem xét thế giới. (Tin tức đa dạng)
Kinh tế
2024-11-29 (Thứ Sáu) Thường lệ buổi sáng (Hankyung) : Lãi suất Hàn Quốc giảm từ 3.25 -> 3.0% / Khoảng cách thu nhập tăng, tiêu dùng giảm / Robot mặc được X-ble Shoulder / ETF cổ phiếu điều kiện tăng trưởng 20% (người nước ngoài đang mua)
>> Cuối cùng thì nếu người nước ngoài không mua thì giá cổ phiếu sẽ không tăng.
CNTT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 thói quen cần tuân thủ để trở thành một nhà phát triển giỏi
>> Chính là điều tôi cảm nhận được khi tạo và duy trì nền tảng cụm/điều khiển từ xa, nhưng tôi không thể thực hiện được. Tôi không được sợ hãi sự thay đổi và nếu chia nhỏ như thế này thì có vẻ khả thi.
1. Hãy giữ cho các commit nhỏ đến mức bạn tự hỏi "Liệu có cần nhỏ đến vậy không?"
Bởi vì bạn không bao giờ biết khi nào bạn cần phải hoàn tác một thay đổi cụ thể. Biết chính xác vị trí của lỗi xảy ra 6 ngày trước và có thể hoàn tác chỉ commit đó mà không có xung đột hợp nhất phức tạp sẽ mang lại sự an tâm lớn. Tiêu chuẩn của tôi rất đơn giản: Mã có thể biên dịch được thì có thể commit.
2. Hãy thực hành lời khuyên của Kent Beck: "Để thực hiện thay đổi mong muốn, trước tiên hãy làm cho thay đổi đó trở nên dễ dàng (lưu ý: điều này có thể khó), sau đó thực hiện thay đổi dễ dàng đó."
"Để thực hiện thay đổi mong muốn, trước tiên hãy làm cho thay đổi đó trở nên dễ dàng (lưu ý: điều này có thể khó), sau đó thực hiện thay đổi dễ dàng đó."
Hãy làm cho hơn một nửa tổng số commit là việc tái cấu trúc. Tái cấu trúc liên tục là việc tìm kiếm và áp dụng các cải tiến có thể thực hiện trong vòng 10 phút. Nhờ những cải tiến nhỏ này, khi có yêu cầu lớn hơn, bạn có thể giải quyết chúng chỉ bằng những thay đổi nhỏ. Cần tránh việc tái cấu trúc quy mô lớn.
3. Mọi đoạn mã đều là khoản nợ.
Mã chưa được triển khai là khoản nợ trong các khoản nợ. Bạn cần phải xác minh xem mã có hoạt động chính xác không và ít nhất là không làm hỏng các chức năng khác. Kiểm thử mang lại sự tự tin và việc triển khai sản xuất mang lại sự xác nhận. Chi phí lưu trữ có thể tăng nhẹ do việc triển khai thường xuyên, nhưng việc có thể xác nhận rằng công việc cuối cùng là sự tiến bộ thực sự thì hoàn toàn xứng đáng. Một trong những nguyên tắc Agile là "Phần mềm hoạt động là thước đo chính của sự tiến bộ". Ở đây, các từ "hoạt động" và "tiến bộ" mang ý nghĩa quan trọng, vì vậy tôi đã đưa ra định nghĩa của riêng mình. "Hoạt động" có nghĩa là ở mức có thể triển khai, và nếu một đoạn mã đóng góp vào một chức năng nào đó, thì đó là "tiến bộ".
4. Hãy tự hỏi xem bạn có đang kiểm thử các chức năng của framework không. Nếu có, đừng làm thế.
Các framework đã được kiểm thử bởi những người chuyên nghiệp hơn bạn nhiều và bạn nên tin tưởng rằng móc useState() hoạt động như dự định. Nếu giữ cho các thành phần nhỏ, framework sẽ xử lý hầu hết các tác vụ cốt lõi, vì vậy bạn không cần nhiều bài kiểm thử. Thành phần càng lớn, độ phức tạp càng tăng và bạn càng cần phải viết nhiều bài kiểm thử hơn.
5. Nếu một hàm cụ thể không phù hợp ở bất kỳ đâu, hãy tạo một mô-đun (hoặc lớp hoặc thành phần) mới và tìm vị trí phù hợp sau.
Thay vì cố gắng nhét nó vào một nơi không phù hợp, tốt hơn là tạo ra một cấu trúc độc lập mới. Ngay cả trong trường hợp xấu nhất, việc nó vẫn là một mô-đun độc lập cũng không tệ.
6. Nếu không biết API nên trông như thế nào, hãy viết bài kiểm thử trước.
Điều này sẽ khiến bạn phải suy nghĩ từ quan điểm của "khách hàng", trong trường hợp này là chính bạn. Bạn có thể tìm ra những trường hợp mà bạn không thể tìm thấy nếu viết mã trước và kiểm thử sau. Bạn không cần phải quá giáo điều với TDD, và bạn có thể làm việc với các đơn vị lớn hơn (ví dụ: viết nhiều dòng mã trước khi kiểm thử vượt qua). Lượng mã ở trạng thái thất bại không nhất thiết phải luôn nhỏ. Nếu bạn biết mình đang làm gì, hãy đảm bảo rằng các nguyên tắc không làm giảm năng suất.
7. Sao chép-dán một lần thì ổn.
Đừng sao chép lần thứ hai (tức là lần sao chép thứ ba). Tại thời điểm này, bạn sẽ có đủ ví dụ để tạo ra một trừu tượng tốt. Việc tích hợp là cần thiết vì nguy cơ các triển khai cùng chức năng lại khác nhau là quá cao. Tốt hơn là có tham số hóa hơi vụng về hơn là triển khai cùng một chức năng nhiều lần. Nếu tình huống này xảy ra lại, việc cải thiện tham số sẽ dễ dàng hơn là tích hợp bốn triển khai khác nhau.
8. Thiết kế thường cũ.
Bạn có thể làm chậm tốc độ bằng cách tái cấu trúc, nhưng cuối cùng bạn vẫn phải thay đổi cách thức hoạt động. Đừng quá buồn khi phải từ bỏ những thứ mà trước đây bạn trân trọng và tự hào. Bạn đã làm hết sức mình lúc đó và không cần phải tự trách mình vì không làm hoàn hảo đến mức không cần thay đổi. Phần lớn công việc phát triển phần mềm là thay đổi phần mềm. Hãy chấp nhận điều đó và tiến lên phía trước. Không có thiết kế nào là hoàn hảo và thay đổi là cốt lõi của phát triển phần mềm. Khả năng thay đổi tốt đến đâu quyết định năng lực của bạn với tư cách là một nhà phát triển.
9. Nợ kỹ thuật có thể được phân loại thành ba loại:
1) Những thứ đang cản trở công việc hiện tại, 2) Những thứ sẽ cản trở công việc trong tương lai, 3) Những thứ có thể cản trở công việc trong tương lai. Tất cả các phân loại khác đều là tập con của ba loại này. Hãy giảm thiểu số 1 và tập trung vào số 2. Đừng bận tâm đến số 3.
10. Khả năng kiểm thử có liên quan chặt chẽ đến thiết kế tốt.
Không thể kiểm thử dễ dàng là dấu hiệu cho thấy cần phải thay đổi thiết kế. Đôi khi đó có thể là thiết kế bài kiểm thử. Ví dụ: nếu khó mock em.getRepository(User).findOneOrFail({id}), tốt hơn là tách cuộc gọi đó thành một hàm riêng biệt có thể mock hoặc viết một tiện ích kiểm thử có thể mock dễ dàng các phương thức của entity manager. Lý do bài kiểm thử không được viết là vì nó khó kiểm thử chứ không phải vì không muốn kiểm thử.
Bình luận0