Nhờ bác nào dân lập trình giúp ạ!

Mấy năm mới chui ra 1 cậu hs quái kiệt, nó toàn tự học mà viết phần mềm ầm ầm, ăn đứt thầy cô
Thằng cu này chuyên mày mò mod game nên dần dần kỹ năng lập trình nó tốt lên, nó nói năng các thầy cô khác dek hiểu nó nói gì cho tới khi gặp mình, may có sinh hoạt trên GVN này nên mới nói chuyện đc với nó...

 

Ku này mấy tuổi rồi thày

 

Lớp 11 bác, lớp 10 nó đã thi tin giải 1 tỉnh rồi.
Mà hài cái là ông tướng này ngồi vào máy tính là bị bố mẹ chửi. Kiểu bố mẹ không hiểu nó làm gì, cứ thấy nó cắm đầu mây tính chơi game ấy

 

Ko có gì hài cả
Dev đầu 2 thứ tóc lương mấy chục cụ bây h ngồi vào máy tính vẫn bị bố mẹ chửi như bt

 

Thằng học sinh của thầy nó sai từ thiết kế rồi.
Việc tạo phòng, room chat không ai làm qua db trung gian để client query message cả, vì như vậy db sẽ chết lập tức
Tốt nhất là thiết kế peer to peer kết hợp việc lưu lịch sử chat ở local, nếu cần đồng bộ hoá khi đổi thiết bị thì có thể hỏi trực tiếp peer còn lại.

 

Cái đấy thì mình hiểu, nhưng làm như vậy theo giáo dục thì mới là dễ tiếp cận bác ạ. Còn làm theo dạng chuyên biệt thì ko mang đc ý nghĩa giáo dục dễ tiếp cận bác ạ. Ở trình độ THPT thì xây dựng từ cơ bản client - server dễ hơn, còn peer to peer thì ban đầu hơi khó tiếp cận

 

2 cách:

1 là đổi db => khó quá bỏ qua.

Cách 2 là lưu theo timeserie và đọc log chat gần nhất khoảng 100 dòng thôi.

mỗi 1 lần kéo chuột thì load thêm, với postgres hay mảiadb thì chỉ tốn vài trăm ms đấy là ko optimize gì.

và đánh index cho trường id nếu cần.

 

Vậy nếu lúc đồng bộ thì phải đợi peer còn lại online hoặc app đó chạy nền để duyệt hả fen

 

Local thì cũng có db local để lưu mà.

Học sinh nó ko có kinh nghiệm nên dùng mysql tập trung thôi. Ngoài ra lưu ở local thì phải làm thêm tính năng đồng bộ message giữa device, trade off thôi

 

Xử lý đc rồi bác ạ, đúng là hỏi trên này là khai sáng ra ngay. Còn nhiều lúc ngồi nghĩ 1 mình không ra.
Mà cái khá thú vị là tìm trên mạng không có bàn về cái này

 

ko cần cảm ơn đâu

 

Thì việc đồng bộ ở devices mới là chuyện hiếm khi xảy ra mà 1 năm chỉ 2-3 lần là cùng, như bọn zalo nó trực tiếp cho chọn devices cũ để đồng bộ luôn.
Việc đồng bộ từ peer là kiểu chấp nhận với data không quan trọng.

 

App chat to như thằng Zalo đồ thì mình k nghĩ nó xài local toàn bộ. Zalo nó cho đồng bộ lên Drive giảm bớt tải cho nó. Vì local thì lỡ mất đt coi như mất hết toàn bộ tin nhắn, hoặc tới lúc đó lại cần phải peer còn lại có online (và vẫn lưu tin nhắn cũ) thì nó mới đồng bộ được thì cái app nó quá tệ. Tay ngang như mình nghĩ sơ còn ra lỗi trải nghiệm thì đem vô sử dụng chắc ra cả nùi lỗi nữa

 

Vì nó easy quá ấy bạn
Mà các vấn đề về performance thì thường chỉ cần xử lý trong môi trường doanh nghiệp, khi đó có các senior thì hỏi cái ng ta chỉ cho luôn
Còn tìm trên mạng chủ yếu là các bố tự học, tự vọc => như ông nào trang trc vừa nói đó, thường mindset là chạy đc là đc, hoặc tìm cách show qua qua demo là xong, chứ ko cần chau chuốt hoặc hiểu sâu nhiều lắm.

 

Còn tuỳ mục tiêu của app là gì nữa á, còn vs các app chat phổ biến như FB, zalo.... thì làm như này là đi ngược lại với tư duy thu thập dữ liệu của các doanh nghiệp lớn.
Họ bỏ tiền ra ko phải để làm cái app mượt mà technical xịn xò nhất cho client sử dụng, mà là để thu thập dữ liệu, nên việc lưu DB là nhất định phải có.
Thậm chí phải lưu luôn và ngay trong trường hợp cần chạy bot kiểm duyệt, và phải lưu hợp lý để có thể dễ dàng phân tích tổng hợp bất cứ lúc nào.
Tránh DB lăn ra chết thì cũng có rất nhiều cách mà.
Học peer to peer cho cố xong ra môi trường doanh nghiệp lại chả đc áp dụng bao h, cứ học chắc DB cho hữu dụng :v

Cũng giống câu chuyện thay nhiên liệu hoá thạch ấy, giải pháp thì có 1 rổ hay ho xịn xò nhưng để vọc vạch chơi chơi thôi, động đến bài toán kinh tế là lại thành khó ngay.

 

Vấn đề của Zalo là tiền đầu tư cho server của nó ít quá nên phải làm vậy để giảm tải server.

 

Đúng rồi, bản chất là nó quá dễ thật, nghĩ chút à ra nhưng kiểu như lúc gặp gút mắc, ít người nhiều lúc nghĩ lan man

 

Tôi không phản đối việc trải nghiệm tệ nhé, nhưng cần phải xem ở góc nhìn của usecase.
Việc dùng db để recover nên là fallback cuối cùng vì 3 lý do:
1. Việc này không xảy ra thường xuyên ( không ai đổi devices 3 lần/ngày cả ).
2. Tốn perf của server.
3. Data chat là rác, không recover được khi chuyển devices thì mọi người cũng tặc lưỡi dùng tiếp chứ mấy ai phát điên lên vì mất tin nhắn đâu

Còn bọn zalo có lưu lại lịch sử chat chứ, nhưng mà nó không public hoặc không cho bên recover tiếp cận thôi.

 

Trẻ con giờ nhiều đứa giỏi lắm.
Tớ 5 năm trước từng mentor cho 1 thằng ku học lớp 10 nhưng kiến thức lập trình tương đương đám đại học năm 2-3, 2 năm sau nó du học mỹ và quán quân cái giải khỉ gì của FB và được Momo mời về làm việc fulltime...
Hiện đang có thằng cháu đang cấp 2 mà nó làm game thi được giải nhất tỉnh rồi.

 

Vì là đi thi mà fen, nếu bị hỏi thì đâu thể nói là: Dạ em biết mấy trường hợp đó nó vậy đó, nó có thể trải nghiệm tệ, nó có không thể recover tốt tại vì ít ai đổi device (đổi đt, lên pc, lên laptop), với em sợ tốn tài nguyên server, và tin nhắn ng dùng toàn tin rác thôi có mất ngta cũng k quan tâm lắm. Nên em quyết định chỉ code ra sản phẩm như vậy để dự thi thôi.

Tụi bây giờ nó học kinh vãi đạn ra ấy. Có thằng em họ bên vợ mới cách đây 4 năm còn học cấp 2, dẫn nó ra sài gòn đi đường sách nó mua cuốn "tư duy phản biện" với mấy cuốn học thuật gì nữa là hơi xoắn não với nó rồi. Năm nay vô đh nó thủ khoa đầu vào đánh giá năng lực đại học quốc gia luôn, ở trọ chung với thằng giải nhất nhì toán quốc gia đc tuyển thẳng. Qua trọ nó hỏi mấy cái lập trình áp lực vãi đạn