Nếu bạn đã cảm thấy như vậy thì tôi xin lỗi. Tôi nghĩ rằng mỗi người sẽ có kỳ vọng khác nhau khi đọc tiêu đề. Tuy vậy, đúng là cần viết tiêu đề sao cho rõ ràng nhất có thể để nội dung mà người đọc kỳ vọng được thống nhất hơn. Tôi sẽ lưu ý điều này.
Ngoài ra, mong bạn hãy xem bài này tách biệt với bài trước. Ở bài trước, tôi đã dùng 2 tài khoản không sử dụng để thử upvote nên bị gắn cờ. Đây hoàn toàn là lỗi của tôi, và tôi muốn nói rõ rằng đó không phải là vấn đề của bản thân bài viết.
Xin chào! Trước hết, mình thực sự cảm ơn bạn đã để lại bình luận góp ý.
Mình đánh giá rằng GIN index không cần thiết trong trường hợp này! Hiện tại, API gợi ý tự động hoàn thành từ khóa tìm kiếm chỉ cần chính term. Không cần biết term đó thuộc những article nào.
Ngược lại, trong API tìm kiếm, mình đang sử dụng một loại index tương tự GIN index. Mình tận dụng paradeDB, một extension của Postgres, để dùng BM25 index.
Trong bài viết không đề cập chi tiết, nhưng hiện tại mình đang chỉ định và sử dụng riêng ExecutorService. Tuy vậy, như bạn đã nói, về sau mình cũng sẽ cân nhắc cách tiếp cận reactive hoặc virtual thread!!
Tôi cũng đã vào blog đọc bài gốc rồi. Tôi cảm thấy có phần chênh lệch giữa tiêu đề và nội dung thực tế. Những chức năng anh triển khai hay hướng cải thiện mà anh nói đến thực ra đều là các phần đã được hiện thực và phản ánh trong nhiều dự án mã nguồn mở có sẵn từ trước; còn phần anh làm là nâng cấp chức năng tìm kiếm vốn ban đầu chỉ được triển khai rất đơn giản trong chính dịch vụ của mình. Nhưng nếu chỉ nhìn tiêu đề thì lại tạo cảm giác như thể anh đã cải tiến thuật toán một cách quy mô lớn vậy,, Bài trước của anh cũng từng bị gắn cờ là quảng bá, nên tôi nghĩ khi viết bài có lẽ anh cần cân nhắc thêm một chút.
Không rõ anh/chị đã cân nhắc thử dùng chỉ mục GIN thay cho chỉ mục lower() chưa. Dù sao cũng đã dùng raw SQL bằng JdbcTemplate, vậy nhân tiện thử FTS thì sao?
Cách bất đồng bộ dùng CompletableFuture.supplyAsync() nếu không chỉ định riêng ExecutorService thì cũng sẽ dùng commonPool của ForkJoinPool, nên
nếu số người dùng truy cập đồng thời tăng đến mức commonPool dùng thay cho request thread bị lấp đầy (số lõi CPU - 1) thì có thể sẽ không chịu nổi.
Phần này có lẽ sẽ được giải quyết gọn gàng hơn nếu chuyển sang mô hình reactive hoặc nâng phiên bản JVM để đưa virtual thread vào.
Chọn vấn đề — tìm ra vấn đề mà người ta thực sự muốn trả tiền để giải quyết -> tôi không ngờ công cụ chụp màn hình xray mà mình làm gần đây lại nhận được nhiều sự quan tâm đến vậy
Có lẽ điều quan trọng là tìm ra sự bất tiện, tạo ra thứ gì đó để giải quyết nó và cho mọi người biết.
Nếu chỉ cần vibe coding là có thể kiếm tiền dễ đến vậy…
thì cứ thế mà kiếm tiền đi… sao còn lên Twitter, YouTube rồi đi dạy khóa học?
Người viết cuốn sách “Kiếm 100 triệu won mỗi tháng bằng đầu tư chứng khoán” liệu có thật sự đang kiếm 100 triệu won mỗi tháng nhờ chứng khoán không? Nếu đúng là vậy thì tại sao người đó lại đi viết mấy thứ như sách? Tại sao còn đi khắp nơi làm diễn giả đặc biệt, tại sao còn làm YouTube? Là vì muốn trở thành ánh sáng soi đường cho những nhà đầu tư nhỏ lẻ u mê sao?
Hiện tôi đang dùng loại 40 inch, nên 52 có vẻ quá lớn.
Ngay cả trong phần bình luận trên Hacker News cũng tranh cãi xem nên dùng nhiều màn hình hay chỉ một màn hình kiểu này, nhưng giờ với tôi thì một màn hình như thế này lại tiện hơn.
Nếu bạn đã cảm thấy như vậy thì tôi xin lỗi. Tôi nghĩ rằng mỗi người sẽ có kỳ vọng khác nhau khi đọc tiêu đề. Tuy vậy, đúng là cần viết tiêu đề sao cho rõ ràng nhất có thể để nội dung mà người đọc kỳ vọng được thống nhất hơn. Tôi sẽ lưu ý điều này.
Ngoài ra, mong bạn hãy xem bài này tách biệt với bài trước. Ở bài trước, tôi đã dùng 2 tài khoản không sử dụng để thử upvote nên bị gắn cờ. Đây hoàn toàn là lỗi của tôi, và tôi muốn nói rõ rằng đó không phải là vấn đề của bản thân bài viết.
Xin chào! Trước hết, mình thực sự cảm ơn bạn đã để lại bình luận góp ý.
Mình đánh giá rằng GIN index không cần thiết trong trường hợp này! Hiện tại, API gợi ý tự động hoàn thành từ khóa tìm kiếm chỉ cần chính
term. Không cần biếttermđó thuộc những article nào. Ngược lại, trong API tìm kiếm, mình đang sử dụng một loại index tương tự GIN index. Mình tận dụng paradeDB, một extension của Postgres, để dùng BM25 index. Trong bài viết không đề cập chi tiết, nhưng hiện tại mình đang chỉ định và sử dụng riêngExecutorService. Tuy vậy, như bạn đã nói, về sau mình cũng sẽ cân nhắc cách tiếp cận reactive hoặc virtual thread!!Làm sao có thể phát hiện những thứ như thế này trong dự án nhỉ? Có vẻ như chỉ chạy AI thì cũng khó mà biết được..
Nhìn những trường hợp như vậy, tôi cũng nghĩ rằng mình muốn học hỏi và nhất định tự mình trải nghiệm thử.
Mấy bức ảnh này là sao vậy... wow... trông như tranh sơn thủy vậy.
Tôi cũng đã vào blog đọc bài gốc rồi. Tôi cảm thấy có phần chênh lệch giữa tiêu đề và nội dung thực tế. Những chức năng anh triển khai hay hướng cải thiện mà anh nói đến thực ra đều là các phần đã được hiện thực và phản ánh trong nhiều dự án mã nguồn mở có sẵn từ trước; còn phần anh làm là nâng cấp chức năng tìm kiếm vốn ban đầu chỉ được triển khai rất đơn giản trong chính dịch vụ của mình. Nhưng nếu chỉ nhìn tiêu đề thì lại tạo cảm giác như thể anh đã cải tiến thuật toán một cách quy mô lớn vậy,, Bài trước của anh cũng từng bị gắn cờ là quảng bá, nên tôi nghĩ khi viết bài có lẽ anh cần cân nhắc thêm một chút.
Hay đấy, nhưng sẽ tốt hơn nếu trong lúc làm có kèm luôn địa chỉ tài nguyên đích nữa. Chứ cứ cài đại thì cũng không được haha
Không rõ anh/chị đã cân nhắc thử dùng chỉ mục GIN thay cho chỉ mục
lower()chưa. Dù sao cũng đã dùng raw SQL bằngJdbcTemplate, vậy nhân tiện thử FTS thì sao?Cách bất đồng bộ dùng
CompletableFuture.supplyAsync()nếu không chỉ định riêngExecutorServicethì cũng sẽ dùngcommonPoolcủaForkJoinPool, nênnếu số người dùng truy cập đồng thời tăng đến mức
commonPooldùng thay cho request thread bị lấp đầy(số lõi CPU - 1)thì có thể sẽ không chịu nổi.Phần này có lẽ sẽ được giải quyết gọn gàng hơn nếu chuyển sang mô hình reactive hoặc nâng phiên bản JVM để đưa virtual thread vào.
Rất đồng cảm.
Thực ra là đã cho thấy rất thành công rằng các nhà phát triển vẫn chưa thể bị sa thải được~
Tôi đồng cảm..
Chọn vấn đề — tìm ra vấn đề mà người ta thực sự muốn trả tiền để giải quyết -> tôi không ngờ công cụ chụp màn hình xray mà mình làm gần đây lại nhận được nhiều sự quan tâm đến vậy
Có lẽ điều quan trọng là tìm ra sự bất tiện, tạo ra thứ gì đó để giải quyết nó và cho mọi người biết.
Kết quả thành công = này lũ lãnh đạo, nghĩa là các người vẫn chưa thể sa thải bọn tôi đâu
Gần đây Supertonic cũng đã tung ra một model hỗ trợ cả tiếng Hàn, thử tìm xem nhé.
Mình cũng đã thử làm một thư viện kiểu
딸깍용!https://www.npmjs.com/package/easy-supertonic-tts
Thật mỉa mai khi dùng parq vốn dành cho xử lý phân tán với mục đích xử lý trên một máy đơn.
kkk
Nếu chỉ cần vibe coding là có thể kiếm tiền dễ đến vậy…
thì cứ thế mà kiếm tiền đi… sao còn lên Twitter, YouTube rồi đi dạy khóa học?
Người viết cuốn sách “Kiếm 100 triệu won mỗi tháng bằng đầu tư chứng khoán” liệu có thật sự đang kiếm 100 triệu won mỗi tháng nhờ chứng khoán không? Nếu đúng là vậy thì tại sao người đó lại đi viết mấy thứ như sách? Tại sao còn đi khắp nơi làm diễn giả đặc biệt, tại sao còn làm YouTube? Là vì muốn trở thành ánh sáng soi đường cho những nhà đầu tư nhỏ lẻ u mê sao?
Đúng kiểu thứ mình đang muốn, tuyệt vời.
Hiện tôi đang dùng loại 40 inch, nên 52 có vẻ quá lớn.
Ngay cả trong phần bình luận trên Hacker News cũng tranh cãi xem nên dùng nhiều màn hình hay chỉ một màn hình kiểu này, nhưng giờ với tôi thì một màn hình như thế này lại tiện hơn.
https://github.com/twinstae/graphqlite-ts
Mình đã thử làm binding
bun sqlite + ffitheo kiểu vibe cùng với LLM. Dù sao thì nó cũng chạy được. (Đúng là một thế giới tuyệt vời)Có vẻ sẽ rất hợp để làm PoC nhỉ haha
Ồ... trước đó tôi cũng đang làm phần triển khai gì đó, giờ có lẽ nên lấy cái này làm khung.