This article is exactly what I've been researching. Previously, I only used geo_point for simple distance searches around a location, so when faced with the requirement to draw a polygon to filter data by area, I was quite confused. After switching to geo_shape, I realized how powerful it is, especially for tracking or route mapping problems. I once tried building a system to store movement paths similar to the map movement in the game PolyTrack , needing to check if an object was within a defined area. That's when geo_shape with polygons and multi-polygons proved extremely useful. It's true that ES isn't just powerful for full-text search; its geo querying capabilities are also well worth exploring.
When I first started making small games, separating update() and draw() really helped me keep things organized and avoid weird bugs. It reminds me of how smooth timing feels in the FNF game, where the logic and visuals stay in sync even when performance drops a bit.
Vẫn chưa thực sự hiểu rõ lý do của bác khi không dùng Eloquent. Việc tránh withoutGlobalScope thực ra cũng rất đơn giản. Dùng query thuần giống như bác đang trở về thời kì đồ đá vậy @@ Không đáng để đánh đổi.
Cảm ơn bạn đã góp ý 😁
Mình khá đồng ý với quan điểm AI nên là công cụ hỗ trợ hơn là thay thế hoàn toàn con người. Sau thời gian dùng đủ lâu, mình cũng thấy AI mạnh nhất khi được dùng như một trợ lý hỗ trợ, chứ không phải giao hoàn toàn công việc cho nó.
Có lẽ ý mình trong bài không phải là AI tệ, mà là nhiều người đang kỳ vọng nó ở những phần cần judgement, context và trách nhiệm thực tế — trong khi đó lại là phần con người vẫn phải đứng ra gánh nhiều nhất.
Haha cảm ơn bác @duchai2k đã kéo em về mặt đất nhé 😅 Chắc tại đọc cuốn quá nên em hơi hưng phấn dùng từ 'master' nghe hơi đao to búa lớn.
Ý em ở đây là bài viết hệ thống lại bản chất rất tốt để anh em có cái gốc vững. Đúng như bác nói, thực tế phần lớn dự án bây giờ đều qua Spring hay các lib Async bọc hết rồi, mấy khi tự tay gõ synchronized hay dùng Lock. Nhưng cá nhân em thấy có những case hệ thống bị nghẽn Thread Pool hoặc dính Concurrency Bug ngầm, nếu không có cái nền tảng này thì đọc log hay thread dump đúng là như nhìn bức vách.
Dù sao cũng cảm ơn góc nhìn thực chiến rất hay của bác, lý thuyết kết hợp với tư duy design thực tế như bác nói mới là chuẩn bài!
Bài viết tâm huyết quá. Nhưng mình nghĩ quan điểm của bạn đã sai ngay từ đầu: AI nên là thứ hỗ trợ, chứ không phải thứ thay thế con người. Bạn kì vọng quá cao và giao vai trò sai cho nó dẫn đến kết luận là AI tệ. Trong khi với vai trò là công cụ hỗ trợ, mình thấy AI làm rất tốt.
Mình thấy hơi “overhype” một chút 😅
Đúng là Concurrency trong Java quan trọng thật, nhưng nói đọc một bài là có thể “nắm vững bản chất” để tránh Race Condition hay Deadlock thì hơi lý tưởng hóa. Mấy vấn đề này trong thực tế thường đến từ design sai hoặc thiếu kinh nghiệm debug hơn là chỉ thiếu kiến thức lý thuyết.
Ngoài ra, cũng không phải dự án nào cũng cần “master” concurrency. Nhiều case business bình thường, dùng framework (Spring, thread pool, async abstractions, reactive lib…) đúng cách là đã handle được phần lớn rồi, không cần tự mình “đụng chạm” sâu đến low-level synchronization.
Bài viết tốt thì vẫn đáng đọc, nhưng mình nghĩ nên nhìn nhận nó như một tài liệu tham khảo nền tảng thôi, chứ chưa đủ để “tự tin chiến đấu” trong production đâu @bullpig
Cảm ơn tác giả đã có 1 bài viết đáng đọc! @ngocbach99
Haha, bẫy self-invocation này anh em dev Java hầu như ai cũng từng sập ít nhất một lần bác ạ. Cứ gắn @Transactional mà nó không rollback mới tá hỏa đi lật tung code lên tìm hiểu 😆. B nhớ đón đọc phần 2 nhé, mình sẽ bóc tách tiếp cách xử lý triệt để mấy case lươn lẹo này của cô Thư ký
Cảm ơn một đánh giá cực kỳ có tâm, multithread luôn là một chủ đề gây trầm cảm. Ở phần tiếp theo, mình sẽ đi sâu hơn vào cách vận hành của các loại Lock và Thread Pool để giải quyết mấy bài toán kinh điển như Deadlock hay Race Condition. Bác nhớ đón đọc nhé
Tất nhiên rồi, bài này mới là khởi động để anh em nắm được cái hồn của kiến trúc thôi. Còn những phần 'khoai' hơn như đi sâu vào Redis Cluster, Sentinel, hay các trick tối ưu memory, xử lý concurrency... mình xin phép hẹn bác ở các bài viết chuyên sâu sau nhé.
Bài viết hệ thống kiến thức rất tốt, cực kỳ hữu ích cho các bạn đang muốn master mảng Concurrency trong Java. Đa luồng xem lý thuyết thì hay nhưng khi vào dự án thực tế rất dễ dính mấy lỗi kinh điển như Race Condition hay Deadlock nếu không nắm vững bản chất như thế này. Cảm ơn tác giả, upvote và bookmark chờ phần tiếp theo!
THẢO LUẬN
😁😁cảm ơn bạn đã đọc và góp ý 😋
@nqubao1312 về điều này mình hoàn toàn đồng ý.
bài viết dài nhưng lan man quá
cảm ơn nhé!!!
This article is exactly what I've been researching. Previously, I only used geo_point for simple distance searches around a location, so when faced with the requirement to draw a polygon to filter data by area, I was quite confused. After switching to geo_shape, I realized how powerful it is, especially for tracking or route mapping problems. I once tried building a system to store movement paths similar to the map movement in the game PolyTrack , needing to check if an object was within a defined area. That's when geo_shape with polygons and multi-polygons proved extremely useful. It's true that ES isn't just powerful for full-text search; its geo querying capabilities are also well worth exploring.
When I first started making small games, separating update() and draw() really helped me keep things organized and avoid weird bugs. It reminds me of how smooth timing feels in the FNF game, where the logic and visuals stay in sync even when performance drops a bit.
Vẫn chưa thực sự hiểu rõ lý do của bác khi không dùng Eloquent. Việc tránh withoutGlobalScope thực ra cũng rất đơn giản. Dùng query thuần giống như bác đang trở về thời kì đồ đá vậy @@ Không đáng để đánh đổi.
Cảm ơn bạn đã góp ý 😁 Mình khá đồng ý với quan điểm AI nên là công cụ hỗ trợ hơn là thay thế hoàn toàn con người. Sau thời gian dùng đủ lâu, mình cũng thấy AI mạnh nhất khi được dùng như một trợ lý hỗ trợ, chứ không phải giao hoàn toàn công việc cho nó. Có lẽ ý mình trong bài không phải là AI tệ, mà là nhiều người đang kỳ vọng nó ở những phần cần judgement, context và trách nhiệm thực tế — trong khi đó lại là phần con người vẫn phải đứng ra gánh nhiều nhất.
Haha cảm ơn bác @duchai2k đã kéo em về mặt đất nhé 😅 Chắc tại đọc cuốn quá nên em hơi hưng phấn dùng từ 'master' nghe hơi đao to búa lớn.
Ý em ở đây là bài viết hệ thống lại bản chất rất tốt để anh em có cái gốc vững. Đúng như bác nói, thực tế phần lớn dự án bây giờ đều qua Spring hay các lib Async bọc hết rồi, mấy khi tự tay gõ synchronized hay dùng Lock. Nhưng cá nhân em thấy có những case hệ thống bị nghẽn Thread Pool hoặc dính Concurrency Bug ngầm, nếu không có cái nền tảng này thì đọc log hay thread dump đúng là như nhìn bức vách.
Dù sao cũng cảm ơn góc nhìn thực chiến rất hay của bác, lý thuyết kết hợp với tư duy design thực tế như bác nói mới là chuẩn bài!
Bài viết tâm huyết quá. Nhưng mình nghĩ quan điểm của bạn đã sai ngay từ đầu: AI nên là thứ hỗ trợ, chứ không phải thứ thay thế con người. Bạn kì vọng quá cao và giao vai trò sai cho nó dẫn đến kết luận là AI tệ. Trong khi với vai trò là công cụ hỗ trợ, mình thấy AI làm rất tốt.
@huydev007 ráng đi em =))
bài viết hay, respect tác giả
@hhoang a viet bai bang ai ak sao a viet nhanh the e ko doc kip=))
Mình thấy hơi “overhype” một chút 😅 Đúng là Concurrency trong Java quan trọng thật, nhưng nói đọc một bài là có thể “nắm vững bản chất” để tránh Race Condition hay Deadlock thì hơi lý tưởng hóa. Mấy vấn đề này trong thực tế thường đến từ design sai hoặc thiếu kinh nghiệm debug hơn là chỉ thiếu kiến thức lý thuyết. Ngoài ra, cũng không phải dự án nào cũng cần “master” concurrency. Nhiều case business bình thường, dùng framework (Spring, thread pool, async abstractions, reactive lib…) đúng cách là đã handle được phần lớn rồi, không cần tự mình “đụng chạm” sâu đến low-level synchronization. Bài viết tốt thì vẫn đáng đọc, nhưng mình nghĩ nên nhìn nhận nó như một tài liệu tham khảo nền tảng thôi, chứ chưa đủ để “tự tin chiến đấu” trong production đâu @bullpig Cảm ơn tác giả đã có 1 bài viết đáng đọc! @ngocbach99
Bài viết hữu ích
Haha, bẫy self-invocation này anh em dev Java hầu như ai cũng từng sập ít nhất một lần bác ạ. Cứ gắn @Transactional mà nó không rollback mới tá hỏa đi lật tung code lên tìm hiểu 😆. B nhớ đón đọc phần 2 nhé, mình sẽ bóc tách tiếp cách xử lý triệt để mấy case lươn lẹo này của cô Thư ký
Cảm ơn một đánh giá cực kỳ có tâm, multithread luôn là một chủ đề gây trầm cảm. Ở phần tiếp theo, mình sẽ đi sâu hơn vào cách vận hành của các loại Lock và Thread Pool để giải quyết mấy bài toán kinh điển như Deadlock hay Race Condition. Bác nhớ đón đọc nhé
Tất nhiên rồi, bài này mới là khởi động để anh em nắm được cái hồn của kiến trúc thôi. Còn những phần 'khoai' hơn như đi sâu vào Redis Cluster, Sentinel, hay các trick tối ưu memory, xử lý concurrency... mình xin phép hẹn bác ở các bài viết chuyên sâu sau nhé.
Bài viết hệ thống kiến thức rất tốt, cực kỳ hữu ích cho các bạn đang muốn master mảng Concurrency trong Java. Đa luồng xem lý thuyết thì hay nhưng khi vào dự án thực tế rất dễ dính mấy lỗi kinh điển như Race Condition hay Deadlock nếu không nắm vững bản chất như thế này. Cảm ơn tác giả, upvote và bookmark chờ phần tiếp theo!
Cảm ơn b, hơi dài chút, nhưng mình thích kiểu tổng hợp thế này hơn là chia thành nhiều phần