Em vừa đọc bài về trade off a viết thì tìm được bài này của anh thấy hay quá. Anh cho em hỏi là giữa việc lên lab và việc đi thực tập thì nên chọn con đường nào ạ. Do tình hình dịch bệnh phải học onl cả năm ở nhà nên em thấy thời gian bây giờ cũng khá gấp.
giờ mình bị thêm 1 lỗi này mà không fix được ,định dùng cmd upload lên heroku 1 trang web,nhưng khi gõ heroku login nó bị lỗi này ,lỗi này do host,hay do heroku cli,hay lỗi cmd,lỗi máy tính,mình mở cmd trong thư mục documents của phân vùng c ổ đĩa
Hello b, mình có làm việc tại Việt Nam trước, tầm khoảng hơn 2 năm. Nếu bạn muốn đi thì tầm 2 năm kinh nghiệm là đẹp, luyện thêm Tiếng Anh giao tiếp tại VN trước nhé.
@koyoy ,mình fix lỗi đó được rồi nhưng lại bị 1 lỗi khác khi dùng git upload thư mục document trong phân vùng c tức c:/user/docuemtns vào lúc mình gõ heroku git:remote -a tên app thì nó báo cannot open spawn
với a thì a k set các ràng buộc mà chuyển lên quản lí ở app, đồng ý với các cao nhân của e. Chậm là 1 phần, cái nữa là phải đọc sql để biết nó làm thế nào. Nếu thể hiện luôn trên code thì rất tiện.
a chưa làm tiki hay shopee nên kb họ có dùng orm không. Nhưng để quyết định có dùng orm k thì có mấy ý cần nắm thế này. ORM chắc chắc là tiện, nhưng tốc độ k thể bì với query tay, vì sao lại chậm hơn thì a nghĩ chắc em nắm được. Đại khái là ORM là 1 thứ generic, r wrap khá nhiều level, chưa kể còn phải hiểu rõ frmwk mới biết cách tối ưu. Nhưng ưu điểm của nó là rất tiện lợi, không cần to tay. Thế nên nếu dự án vừa và nhỏ thì cứ quẩy ORM thôi. Dự án lớn và không quan tâm nhiều đến tốc độ, và trình độ các dev chưa đồng đều, chưa cao thì việc bỏ ORM k đơn giản. Còn các cty product lớn a nghĩ họ sẽ có hướng đi riêng.
kiểu này cách thức nó na ná giống EAV model a nói phía trên. A nói về cách triển khai chứ k phải về mặt ý nghĩa. Nói thật là a cũng k dùng kiểu này vì chắc chắn là chậm hơn kiểu n-n truyền thống với table trung gian, t2 là nó k phải 1 thứ gì đấy common cho mn, và t3 là lợi ích nó đem lại k nhiều so với những painful mà nó tạo ra
đúng là mysql và postgres cũng cho phép lưu json và query.
việc cái này có những thứ giống cái kia là điều dễ hiểu vì cả 2 đều nhận thấy ưu điểm của nhau và cố gắng cải tiến cái của mình. Ví dụ sql cũng có thể lưu và query json, và mongodb cũng có lookup gần tương tự như join của sql. Nó gọi là những thứ bổ sung để powerful hơn.
Còn mấu chốt vẫn nằm ở sql và relation. Dù mongo có join nhưng k thể nào = join của sql và dù sql có thể lưu json nhưng những data đó chỉ là extra field thôi, thay vì việc có 5 - 7 extra column thì tống nó vào json và lưu ở 1 column. Ngoài những thứ ở mục 3 mình viết ở trên thì còn cần dựa trên tính chất của database để quyết định. Ví dụ relationdb thì strong consistence (ACID), phù hợp với những bài toán yêu cầu sự chính xác cao: nghiệp vụ liên quan đến ngân hàng, giao dịch... Còn non-relationdb thì ưu tiên về tốc độ và k cần chính xác ngay (BASE), phù hợp với bài toán yêu cầu tốc độ hơn là sự chính xác: web đọc báo, chat chit...
THẢO LUẬN
@nghiepit you're welcome. có gì ủng hộ cho a kiếm con keyboard gõ bài cho nuột em ơi :v
like bài cho a kiếm con keyboard em ơi
Bác có source code github k , tui làm giống bác bị lỗi chữ ký gì đó,
Bổ ích
Bài viết hay, thêm phần 2 đi thanh niên
@datbv Cảm ơn anh đã chia sẻ ạ 😗
sắp có phần thực hành chưa a ơi =))) hóng
Em vừa đọc bài về trade off a viết thì tìm được bài này của anh thấy hay quá. Anh cho em hỏi là giữa việc lên lab và việc đi thực tập thì nên chọn con đường nào ạ. Do tình hình dịch bệnh phải học onl cả năm ở nhà nên em thấy thời gian bây giờ cũng khá gấp.
Bài viết rất hay, mong bạn sẽ ra thêm bài nữa kể về môi trường làm việc bên Sing nhé. Có khó khăn hay rào cản gì k?
@bunny.pi.green pro ơi sao trong bài này phần OrbitControls mình k thấy nó hoạt động nhỉ. https://codepen.io/bunnypi04/pen/VwaVzow
bạn ơi có soft nào dùng cho window 10 32 bit và dễ dùng không,máy mình không cài docker được
giờ mình bị thêm 1 lỗi này mà không fix được ,định dùng cmd upload lên heroku 1 trang web,nhưng khi gõ heroku login nó bị lỗi này ,lỗi này do host,hay do heroku cli,hay lỗi cmd,lỗi máy tính,mình mở cmd trong thư mục documents của phân vùng c ổ đĩa
Với cả, để tìm đường đi Sing thì bạn phải có network tốt trên LinkedIn nữa nha
Hello b, mình có làm việc tại Việt Nam trước, tầm khoảng hơn 2 năm. Nếu bạn muốn đi thì tầm 2 năm kinh nghiệm là đẹp, luyện thêm Tiếng Anh giao tiếp tại VN trước nhé.
@koyoy ,mình fix lỗi đó được rồi nhưng lại bị 1 lỗi khác khi dùng git upload thư mục document trong phân vùng c tức c:/user/docuemtns vào lúc mình gõ heroku git:remote -a tên app thì nó báo cannot open spawn
sau khi ra trường anh đã làm việc tại việt nam bao nhiêu năm rồi sang sin hay là sang ngay ạ
Cài Laragon lên windows Server để làm webserver ổn không bạn?
@devil_boom_129 ,thế à,máy mình cài hdh win10 win 32 bit làm thế nào để cài heroku không bị lỗi
a xin phép trả lời theo ý của a nhé
với a thì a k set các ràng buộc mà chuyển lên quản lí ở app, đồng ý với các cao nhân của e. Chậm là 1 phần, cái nữa là phải đọc sql để biết nó làm thế nào. Nếu thể hiện luôn trên code thì rất tiện.
a chưa làm tiki hay shopee nên kb họ có dùng orm không. Nhưng để quyết định có dùng orm k thì có mấy ý cần nắm thế này. ORM chắc chắc là tiện, nhưng tốc độ k thể bì với query tay, vì sao lại chậm hơn thì a nghĩ chắc em nắm được. Đại khái là ORM là 1 thứ generic, r wrap khá nhiều level, chưa kể còn phải hiểu rõ frmwk mới biết cách tối ưu. Nhưng ưu điểm của nó là rất tiện lợi, không cần to tay. Thế nên nếu dự án vừa và nhỏ thì cứ quẩy ORM thôi. Dự án lớn và không quan tâm nhiều đến tốc độ, và trình độ các dev chưa đồng đều, chưa cao thì việc bỏ ORM k đơn giản. Còn các cty product lớn a nghĩ họ sẽ có hướng đi riêng.
kiểu này cách thức nó na ná giống EAV model a nói phía trên. A nói về cách triển khai chứ k phải về mặt ý nghĩa. Nói thật là a cũng k dùng kiểu này vì chắc chắn là chậm hơn kiểu n-n truyền thống với table trung gian, t2 là nó k phải 1 thứ gì đấy common cho mn, và t3 là lợi ích nó đem lại k nhiều so với những painful mà nó tạo ra
đúng là mysql và postgres cũng cho phép lưu json và query. việc cái này có những thứ giống cái kia là điều dễ hiểu vì cả 2 đều nhận thấy ưu điểm của nhau và cố gắng cải tiến cái của mình. Ví dụ sql cũng có thể lưu và query json, và mongodb cũng có lookup gần tương tự như join của sql. Nó gọi là những thứ bổ sung để powerful hơn.
Còn mấu chốt vẫn nằm ở sql và relation. Dù mongo có join nhưng k thể nào = join của sql và dù sql có thể lưu json nhưng những data đó chỉ là extra field thôi, thay vì việc có 5 - 7 extra column thì tống nó vào json và lưu ở 1 column. Ngoài những thứ ở mục 3 mình viết ở trên thì còn cần dựa trên tính chất của database để quyết định. Ví dụ relationdb thì strong consistence (ACID), phù hợp với những bài toán yêu cầu sự chính xác cao: nghiệp vụ liên quan đến ngân hàng, giao dịch... Còn non-relationdb thì ưu tiên về tốc độ và k cần chính xác ngay (BASE), phù hợp với bài toán yêu cầu tốc độ hơn là sự chính xác: web đọc báo, chat chit...