Có vẻ đây là một vấn đề khó tránh khỏi vì cấu trúc buộc phải nhét logic vào bên trong YAML.
Bài viết trên dường như cũng đưa ra câu trả lời đại khái như bên dưới, và tôi cũng nghĩ rằng nếu thay phần script bằng Dagger thì đó có lẽ mới là đáp án đúng.
"Đừng để GitHub Actions quản lý logic; hãy trực tiếp kiểm soát script, còn Actions chỉ nên gọi các script đó thôi"
Có vẻ không dễ thấy các mô hình TTS mã nguồn mở có hỗ trợ tiếng Hàn.
Trước đây có Kokoro-82M từng được nói là hỗ trợ tiếng Hàn, nhưng tôi nghe nói chất lượng có vẻ không tốt lắm,
thoáng tìm thử thì thấy bảo nếu làm bằng GPT-Sovits hoặc dùng thứ như Edge-TTS thì cũng cho ra kết quả khá ổn.
Dạo này đang vibe coding nên nghĩ là nếu ghép với Whisper thì có vẻ sẽ ra được thứ gì đó thú vị, nhưng lại chưa nghĩ ra ý tưởng nào haha
Trong lĩnh vực hệ thống nhúng, người ta còn lập trình với cả việc tính đến kích thước cache line của phần cứng. Vấn đề có lẽ nằm ở chỗ lập trình viên có thể tối ưu hóa đến cực hạn trên ngôn ngữ được bao xa, cùng với hiệu năng của thư viện chuẩn và trình biên dịch. Dù sao thì cả hai đều hỗ trợ mức thấp, nên khác biệt về một chút overhead có lẽ cũng chỉ ở mức không đáng kể. Vì vậy đây có vẻ không phải là một cuộc tranh luận quá có ý nghĩa.. Nếu cần tối ưu hóa đến mức cực hạn thì cuối cùng vẫn phải có sự can thiệp của con người. Vì trình biên dịch không hoàn hảo như ta nghĩ.
Dù sao thì, so với việc người bình thường chỉ bấm đại vài cái, nếu người có kiến thức về sáng tác và sự sáng tạo biết cách tận dụng thì đẳng cấp sẽ khác hẳn, đúng không?
GitHub Actions chỉ nên làm việc thiết lập môi trường (OS, build toolchain, …) và chạy script (shell, Python, bat, ps1…). Dù GitHub có bị sập thì chỉ cần có đủ môi trường là phải có thể build ở bất cứ đâu. Dạo này nhìn workflow GitHub Actions thấy đến mức này mà vẫn phải lục tìm để dùng những thứ như vậy sao. Ngày xửa ngày xưa(?) Ansible cũng từng như thế rồi thất bại.
Tôi nghĩ Rust sẽ trở thành lựa chọn thay thế cho C++ hơn là cho C. C gần như là ngôn ngữ duy nhất (có lẽ cũng là cuối cùng) mà người ta có thể đoán được trình biên dịch sẽ tạo ra mã như thế nào…
Có vẻ đây là một vấn đề khó tránh khỏi vì cấu trúc buộc phải nhét logic vào bên trong YAML.
Bài viết trên dường như cũng đưa ra câu trả lời đại khái như bên dưới, và tôi cũng nghĩ rằng nếu thay phần script bằng Dagger thì đó có lẽ mới là đáp án đúng.
"Đừng để GitHub Actions quản lý logic; hãy trực tiếp kiểm soát script, còn Actions chỉ nên gọi các script đó thôi"
Astro là sự trở lại với những giá trị nền tảng của web
Astro 3.0 phát hành
Astro: Triển khai JavaScript ở mức tối thiểu
Sau thương vụ Claude mua lại Bun, có vẻ như những tin vui vẫn liên tiếp đến. Giờ đây có lẽ họ sẽ có thể tập trung vào dự án một cách ổn định hơn.
Thật là một tin tốt.
Hay đấy, quản lý lịch sử hội thoại bằng cả FTS lẫn vector.
Redis thì tốt đấy.
Bài liên quan - 장시간 실행되는 자율 코딩의 확장
Bài viết rất sâu sắc, tôi cứ đọc đi đọc lại mãi.
https://ywc.life/posts/vercel-react-best-practice
Tôi đã thử dịch toàn bộ bài viết.
Có vẻ không dễ thấy các mô hình TTS mã nguồn mở có hỗ trợ tiếng Hàn. Trước đây có Kokoro-82M từng được nói là hỗ trợ tiếng Hàn, nhưng tôi nghe nói chất lượng có vẻ không tốt lắm, thoáng tìm thử thì thấy bảo nếu làm bằng GPT-Sovits hoặc dùng thứ như Edge-TTS thì cũng cho ra kết quả khá ổn.
Dạo này đang vibe coding nên nghĩ là nếu ghép với Whisper thì có vẻ sẽ ra được thứ gì đó thú vị, nhưng lại chưa nghĩ ra ý tưởng nào haha
Trong lĩnh vực hệ thống nhúng, người ta còn lập trình với cả việc tính đến kích thước cache line của phần cứng. Vấn đề có lẽ nằm ở chỗ lập trình viên có thể tối ưu hóa đến cực hạn trên ngôn ngữ được bao xa, cùng với hiệu năng của thư viện chuẩn và trình biên dịch. Dù sao thì cả hai đều hỗ trợ mức thấp, nên khác biệt về một chút overhead có lẽ cũng chỉ ở mức không đáng kể. Vì vậy đây có vẻ không phải là một cuộc tranh luận quá có ý nghĩa.. Nếu cần tối ưu hóa đến mức cực hạn thì cuối cùng vẫn phải có sự can thiệp của con người. Vì trình biên dịch không hoàn hảo như ta nghĩ.
Không rõ có xử lý tốt tiếng Hàn hay không.
Trung bình thì tôi không rõ ngôn ngữ nào là nhanh nhất, nhưng có vẻ độ phân tán của C++ sẽ là lớn nhất.
Và bức ảnh đầu tiên thật sự trông như một cảnh trong phim thuộc thể loại hậu tận thế vậy.
Có phải bạn cố ý làm vậy đúng không, hừ hừ.
Dù sao thì, so với việc người bình thường chỉ bấm đại vài cái, nếu người có kiến thức về sáng tác và sự sáng tạo biết cách tận dụng thì đẳng cấp sẽ khác hẳn, đúng không?
Bản thân trang web gốc đã rất hay rồi, nhưng vẫn chưa có bản dịch tiếng Hàn.
task_plan.mdcũng giống với cách tôi đang dùng hiện tại. Nếu được tự động hóa thì sẽ tiện hơn rất nhiều.GitHub Actions chỉ nên làm việc thiết lập môi trường (OS, build toolchain, …) và chạy script (shell, Python, bat, ps1…). Dù GitHub có bị sập thì chỉ cần có đủ môi trường là phải có thể build ở bất cứ đâu. Dạo này nhìn workflow GitHub Actions thấy đến mức này mà vẫn phải lục tìm để dùng những thứ như vậy sao. Ngày xửa ngày xưa(?) Ansible cũng từng như thế rồi thất bại.
Tôi nghĩ Rust sẽ trở thành lựa chọn thay thế cho C++ hơn là cho C. C gần như là ngôn ngữ duy nhất (có lẽ cũng là cuối cùng) mà người ta có thể đoán được trình biên dịch sẽ tạo ra mã như thế nào…