PHP Day 2012 – Hà Nội – Building Zingme News Feed System – Châu Nguyễn Nhật Thanh
Comment đáng chú ý của bạn: Thinh Tran Duy
Hôm mình cũng tham gia, có một số điểm mà mình cho rằng hệ thống này còn yếu kém (zing me version 3):
– Đầu tiên là dùng integrated database cho feed item, thật ra đây chỉ là cách giải quyết tạm thời, thứ nhất là vấn đề chung của các IDB là bảo mật điều này là hiển nhiên, thứ 2 là do bản chất của IDB nên vô hình chung bắt worker đảm nhiệm luôn việc truy vấn dữ liệu như vậy sẽ không tận dụng được hiệu suất
– Điểm yếu thứ 2 mình muốn nói đến là anh Thanh cứ nhắc đi nhắc lại việc zm dùng push, nhưng thực sự thì push của zm cũng chỉ là một dạng Pseudo Push chứ chưa thực sự là push. Về mặt bản chất thì push của zm chỉ là Pull với thời gian timeout thấp, mình có về view code thì thấy js version 3 dùng ajax GET với timeout là 3s.
– Cuối cùng là việc có nên ứng dụng websocket không? Mình nhớ là có một bạn đứng lên hỏi là push của anh Thanh là dùng push engine hay là websocket, anh Thanh trả lời rằng họ sử dụng push engine để hỗ trợ cho cách trình duyệt phiên bản thấp chưa có websocket, thực ra mình không đồng ý khoản này mục đích của websocket hay là dùng ajax cũng chỉ là fetch data, ta có thể linh động chuyển đổi giữa websocket và ajax cho các trình duyệt trong khi mã nguồn cũng chỉ khác nhau khoảng 5 dòng lệnh.
Vấn đề còn lại của websocket là phía server. Thật ra lúc đó mình rất buồn cười khi thấy anh Thanh với bạn đứng lên hỏi cự cãi qua lại việc bên zm có ai biết NodeJS hay Erlang không? Mình thấy buồn cười là bởi vì họ cho rằng cứ websocket là phải nodeJS hay erlang, trong khi quên mất rằng bản chất của websocket cũng là socket, trong khi anh Thanh quảng cáo đi quảng cáo lại là họ có một đội ngũ khá là “pro” C/C++
Việc implements websocket thực ra là không khó, bản thân mình đã từng implements websocket bằng Python, trong khi Python không hỗ trợ sẵn websocket. Và thực sự là nó chạy rất tốt, chả kém cạnh so với NodeJS hay Erlang gì cả. Hơn nữa việc triển khai websocket cũng không có gì khó khăn cả, bởi vì hệ thống của họ hiện tại viết bằng C, mình có thể cho websocket chạy song song, chỉ khác port thôi, mọi thứ sẽ vẹn cả đôi đường.
Suy cho cùng thì ngôn ngữ cũng chỉ là một công cụ thôi, nếu người lập trình viên nắm vững được nó cùng với nghĩ ra được các giải pháp thì không phải lo lắng rằng bạn đang nắm giữ ngôn ngữ nào, nó có hỗ trợ tính năng abc hay không? Nó làm việc xyz có được hay không?… Tất cả là do bạn thôi.
Nguồn: https://millionwordsite.com/
Xem thêm bài viết khác: https://millionwordsite.com/giai-tri/
À, mình không nói là NodeJS hỗ trợ sẵn websocket hay không, mà chỉ buồn cười khi cái bạn đứng lên hỏi với anh Thanh cự cãi qua lại rằng bên zing me có lập trình viên NodeJS hay Erlang nào không? Trong khi anh Thanh quảng cáo họ đang chơi với hệ thống bằng C thì mình nghĩ không có gì khó khăn để triển khai thêm một cái websocket cả, và không phải như anh Thanh nói là tìm một người biết NodeJS khó hơn là dừng "nhân tài" có sẵn của anh ấy.
cảm ơn cách nhìn của bạn (nhưng bạn trả lời ai thế? chắc là trả lời bạn Thinh Tran Duy?)
Nhầm lẫn một chút là bình thường mà. Có gì mà phải bắt lỗi lặt vặt, tỏ ra thông thái vậy :D. Bắt lỗi thì mình cũng bắt lỗi được bạn. Nodejs hay bất kì ngôn ngữ nào cũng chả ai đi hỗ trợ websocket cả. Tất cả đều chỉ có TCP/IP socket gọi dịch vụ của hệ điều hành. Hỗ trợ websocket ở đây là có ai đó dùng ngôn ngữ và cài đặt nó như 1 thư viện thôi chứ có phải Nodejs hỗ trợ sẵn Websocket đâu. Nếu bạn không thích tự cài đặt thì google cái ra cả đống thư viện cho Java, Python đã cài đăt websocket.
Hôm 15 có đi xem nhưng mà em nên coi Building Facebook App chứ không xem cái này. Nhưng mà thực sự là xem cũng không hiểu gì cả ! 😀
Cám ơn Thầy và anh Thanh !
Suy cho cùng thì ngôn ngữ cũng chỉ là một công cụ thôi, nếu người lập trình viên nắm vững được nó cùng với nghĩ ra được các giải pháp thì không phải lo lắng rằng bạn đang nắm giữ ngôn ngữ nào, nó có hỗ trợ tính năng abc hay không? Nó làm việc xyz có được hay không?… Tất cả là do bạn thôi.
Do giới hạn 500 chars trong comment của Youtube nên comment của mình hơi khó đọc, mong mọi người thông cảm 😀
Việc implements websocket thực ra là không khó, bản thân mình đã từng implements websocket bằng Python, trong khi Python không hỗ trợ sẵn websocket. Và thực sự là nó chạy rất tốt, chả kém cạnh so với NodeJS hay Erlang gì cả. Hơn nữa việc triển khai websocket cũng không có gì khó khăn cả, bởi vì hệ thống của họ hiện tại viết bằng C, mình có thể cho websocket chạy song song, chỉ khác port thôi, mọi thứ sẽ vẹn cả đôi đường.
Vấn đề còn lại của websocket là phía server. Thật ra lúc đó mình rất buồn cười khi thấy anh Thanh với bạn đứng lên hỏi cự cãi qua lại việc bên zm có ai biết NodeJS hay Erlang không? Mình thấy buồn cười là bởi vì họ cho rằng cứ websocket là phải nodeJS hay erlang, trong khi quên mất rằng bản chất của websocket cũng là socket, trong khi anh Thanh quảng cáo đi quảng cáo lại là họ có một đội ngũ khá là "pro" C/C++
Cuối cùng là việc có nên ứng dụng websocket không? Mình nhớ là có một bạn đứng lên hỏi là push của anh Thanh là dùng push engine hay là websocket, anh Thanh trả lời rằng họ sử dụng push engine để hỗ trợ cho cách trình duyệt phiên bản thấp chưa có websocket, thực ra mình không đồng ý khoản này mục đích của websocket hay là dùng ajax cũng chỉ là fetch data, ta có thể linh động chuyển đổi giữa websocket và ajax cho các trình duyệt trong khi mã nguồn cũng chỉ khác nhau khoảng 5 dòng lệnh.
Điểm yếu thứ 2 mình muốn nói đến là anh Thanh cứ nhắc đi nhắc lại việc zm dùng push, nhưng thực sự thì push của zm cũng chỉ là một dạng Pseudo Push chứ chưa thực sự là push. Về mặt bản chất thì push của zm chỉ là Pull với thời gian timeout thấp, mình có về view code thì thấy js version 3 dùng ajax GET với timeout là 3s.
Hôm mình cũng tham gia, ngồi phía dưới định ném đá nhưng mà các bạn khác ném đá dữ quá mình tranh ném không được, có một số điểm mà mình cho rằng hệ thống này còn yếu kém (zing me version 3):
– Đầu tiên là dùng integrated database cho feed item, thật ra đây chỉ là cách giải quyết tạm thời, thứ nhất là vấn đề chung của các IDB là bảo mật điều này là hiển nhiên, thứ 2 là do bản chất của IDB nên vô hình chung bắt worker đảm nhiệm luôn việc truy vấn dữ liệu như vậy sẽ không tận dụng được hiệu suất
mà cũng chưa hiểu bạn tiếc cái gì? vì clip thì đã được share rồi
đi nghe trực tiếp cũng có cái không bằng xem clip, đó là clip có thể xem đi xem lại được, nhưng cái cũng có cái hơn (phải trực tiếp đi mới so sánh được)
Kinh nghiệm thực tế quý báu.
Thank thầy đã share.
Biết thế hôm trước em đã đi nghe, tiếc quá.