Tran Duc Thang

Mọi người cho mình hỏi, ở môi trường production thì có nên sử dụng Docker không?

Việc nên dùng hay không tùy thuộc vào quy mô, tính chất của sản phẩm, cũng như khả năng vận hành của bạn là chính thôi.

• Ví dụ như bạn có một product nhỏ, tất cả các services chạy trên 1 server, thì có thể cài đặt thẳng mysql, php ... trên server đó luôn thôi, chẳng cần đến Docker làm gì cả. Ngược lại bạn có một services lớn, phải thiết kế để có thể scale dễ dàng khi cần thiết, thì lúc đó bạn có thể nghĩ đến Docker. Docker thật sự tỏa sáng khi bạn muốn chạy một hệ thống microservices trên production gồm nhiều server khác nhau, có thể auto deploy và auto scale theo từng service một, chẳng hạn.
• Còn phụ thuộc vào khả năng vận hành tức là thiết kế hệ thống deploy bằng docker trên production sẽ khó khăn hơn, bạn cần đảm bảo có đủ effort, cũng như hiểu rõ về những gì mình sẽ làm, cũng như những bài toán mà mình có thể sẽ gặp phải ...

Việc cài trực tiếp từng service trên server so với sử dụng docker thì việc nào sẽ tốt hơn (performance, security,...).

Về cơ bản thì hệ thống deploy bằng Docker sẽ tốn nhiều resource phần cứng hơn so với hệ thống thông thường chạy thẳng các services trên máy host. Còn nói về performance tổng thể của product của bạn, thì cũng còn tùy thuộc vào product đó lớn đến thế nào, và cách bạn thiết kế server ra sao. Một hệ thống lớn deploy bằng Docker có khả năng scale tốt, vẫn có thể có performance tốt hơn so với hệ thống có giải pháp scale không phù hợp khi chạy các dịch vụ trên máy host.

Security thì mình không có ý kiến, nó phụ thuộc nhiều hơn vào bản thân ứng dụng của bạn, cũng như cách bạn config và sử dụng Docker hay php, nginx, mysql ... như thế nào, chứ bản thân Docker thì mình nghĩ không có vấn đề gì về bảo mật lớn cả (nếu có thì một sản phẩm Open Source lớn được cả thế giới sử dụng như Docker thì cũng sẽ được fix ngay thôi, chỉ cần update lên version mới hơn là được)

Và nếu sử dụng Docker thì sẽ cần phải lưu ý điều gì cho môi trường production?

Một số bài toán mà bạn sẽ gặp phải khi dùng Docker trên Production:

• Bạn sẽ monitor các services bên trong từng Container như thế nào?
• Code mới sẽ được deploy ra sao? Làm thế nào để auto deploy với zero-downtime? Làm thế nào để rollback khi quá trình deploy gặp lỗi?
• Dữ liệu sẽ được backup như thế nào?
• Các service như Cronjob, Queue Job sẽ được chạy ra sao?
• Khi các service như PHP, Nginx ... hay bản thân Docker cần update version, thì cần phải xử lý như thế nào?
• Các persistent data (database, users' upload data) sẽ được lưu trữ và quản lý như thế nào?
• Lưu trữ và quản lý logs của containers ra sao?
• Các kiến thức về Docker's orchestration khi cần scale trên multiple servers

Và có thể còn nhiều bài toán khác nữa ... (^^;) Tùy từng sản phẩm mà có thể sẽ phát sinh yêu cầu cần giải quyết các bài toán khác nhau ...

Bạn có thể thử một vài cách sau xem sao:

• Thử đổi sang port khác xem có chạy được hay không? Nếu chuyển sang 8080 mà chạy được, thì lúc này vấn đề đúng là do bạn không có quyền chạy ở Port 80 (thử lại bằng cách chạy với quyền administrator xem sao), hoặc Port 80 đang có service khác chạy rồi Còn nếu chuyển sang 8080, hay 8000, 9000 mà vẫn đều bị lỗi, thì là do Apache của bạn được cài đặt không đúng, hay có lỗi gì với hệ điều dành dẫn đến bị crash khi khởi động rồi
• Check xem có services nào đang chạy ở port 80 hay không? Trên Windows có một công cụ của hệ điều hành là Resource Monitor, bạn có thể chạy từ ô Run bằng cách gõ lệnh resmon, sau đó vào tab Network để check danh sách Listening Ports, xem có Port 80 hay không.

P/S: Bạn nên chuyển sang dùng Linux thì hơn

Thực sự thì mỗi cây mỗi hoa, mỗi nhà mỗi cảnh, có những người bỏ học rồi họ thành công, nhưng cũng có nhiều trường hợp thì thất bại, nên vấn đề này chắc cũng không thể có một câu trả lời rõ ràng được rồi Do cũng không nắm rõ được tình hình học tập hay chuyên môn của em nên cũng không dám đưa ra lời khuyên xem nên "bỏ học đại học" hay không, nhưng xoay quanh vấn đề "học đại học có thực sự quan trọng không?" thì anh có một vài suy nghĩ như thế này, em có thể tham khảo

• Hiện tại thì xã hội cũng đã có cái nhìn thoáng hơn về việc học đại học, so với hơn chục năm về trước, khi mà người người nhà nhà đều coi trọng "bằng cấp", hay phải vào làm ở "công ty nhà nước". Làm ở lĩnh vực CNTT này, em có thể lựa chọn rất nhiều công ty mà họ cũng chẳng mấy quan tâm đến "bằng cấp" của em. Cái quan trọng là năng lực của em khi làm việc, đó mới là cái quyết định "giá trị" của bản thân em, chứ không phải là một tấm bằng đại học. Bản thân anh từng quen biết và làm việc cùng rất nhiều bạn cũng chưa tốt nghiệp đại học, hay thậm chí tốt nghiệp đại học thật đấy, nhưng mà tốt nghiệp các chuyên ngành lại ... không liên quan gì đến CNTT cả Tức là các bạn ý còn chả học gì liên quan đến IT ở trên trường đại học, ra trường rồi mới tính chuyển nghề làm IT, nhưng rồi sau vài ba năm vẫn code không hề thua kém ai trong team cả, cũng đảm nhận những vị trí rất là quan trọng trong tổ chức ...
• Nói vậy cũng không có nghĩa học đại học là vô ích, ngược lại anh thấy rất vẫn rất là quan trọng. Ở đại học em sẽ học được rất nhiều thứ (mặc dù có cả những thứ không cần thiết, mình sẽ ... chả dùng bao giờ ). Đôi khi cứ quá tập trung vào việc đi làm sớm thì có thể em sẽ không bao giờ có cơ hội được biết đến, và học chúng.
• Nhìn chung đi intern, đi thực tập, đi làm từ sớm cũng có cái hay của nó, em sẽ được làm project thực tế, được trải nghiệm cách làm một sản phẩm nó sẽ như thế nào, được học và trực tiếp sử dụng những kỹ thuật mà sau này sẽ dùng chính trong công việc của mình, nhưng cùng với đó, em sẽ bị bó hẹp lại chỉ trong những gì mình được giao cho làm. Ngược lại, học trên trường đại học thì em sẽ "được" (hay "bị", tùy theo từng cách hiểu, ở từng thời điểm) bắt học nhiều thứ khác nhau, có cái em sẽ cần ngay trong công việc, có cái thì chưa cần (nhưng ít nhất em cũng biết về nó, cũng biết mình đã từng học nó, để sau này có vấn đề gì có thể tìm lại, học lại). Học đại học thì cũng thường thiên về lý thuyết hơn, nên với nhiều người nó sẽ khô khan và nhàm chán hơn, ví dụ như những lý thuyết về lập trình hướng đối tượng, lý thuyết về cơ sở dữ liệu ... Nhưng về sau, những lý thuyết mà em học được đó sẽ có thể sẽ giúp em hiểu sâu hơn, và dễ dàng tìm ra cách giải quyết hơn cho nhiều vấn đề phức tạp đấy Áp lực về điểm số, về thi cử mà trường học đôi lúc sẽ khiến mọi người cảm thấy chán nản, nhưng đôi lúc sẽ giúp em có thêm động lực để học những cái mới (được dạy ở trên trường), thứ mà để mọi người "tự học" thì thường sẽ khó mà có được động lực như vậy.
• Anh mở đầu bằng suy nghĩ bằng cấp không mấy quan trọng thế thôi, nhưng không phải nó không có ý nghĩa gì, có được bằng đại học thì vẫn hơn nhiều việc không có chứ Đối với những bạn trẻ, chưa có nhiều kinh nghiệm, thì điểm số trên trường đại học, hay bằng đại học có thể coi là một trong những thước đo hữu ích nhất mà một nhà tuyển dụng có thể sử dụng để đánh giá năng lực của các em. Bởi thực ra họ cũng chả có gì khác mà họ có thể đánh giá được khi nhìn vào CV cả. Nhìn CV một bạn tốt nghiệp loại giỏi ở trường A, trường B nổi tiếng thì hầu hết các nhà tuyển dụng sẽ đánh giá cao hơn những bạn không hề có thông tin gì phần này rồi. Thế nên, nếu không lựa chọn việc tiếp tục học đại học, thì em có thể lựa chọn theo học các khóa đào tạo của các trung tâm đào tạo lập trình chẳng hạn, vừa sẽ được dạy những kiến thức thực hành nhiều hơn, hay có thêm thông tin để mà ghi vào CV để chứng minh mình cũng từng được đào tạo bài bản, chứ không phải tất cả đều là tự mày mò ..., để từ đó có thể gửi CV tiếp cận được với nhiều công việc chất lượng cao hơn. Đương nhiên, cái em cần ghi nhớ đó là dần dần theo thời gian thì chính những thành tích của em trong công việc sẽ trở thành yếu tố tốt nhất để em có thể PR cho bản thân mình.
• Ngành CNTT luôn thay đổi không ngừng, với tốc độ rất nhanh. Những gì em tự học ngày hôm nay có thể sau vài tháng nữa sẽ trở nên lỗi thời. Thế nên dù có lựa chọn việc tiếp tục học đại học đi chăng nữa thì những kiến thức đó sẽ không thể nào đủ. Ngoài ra em vẫn cần phải tự học thêm cái này cái kia, tự trải nghiệm điều này điều kia. Em mới chỉ 20 tuổi, thời gian phía trước vẫn còn dài, không có gì phải vội đâu.

Để nói ra nữa thì chắc còn dài và còn nhiều chuyện để nói lắm, nhưng để tổng kết lại câu trả lời cho câu hỏi của em thì anh nghĩ rằng: Học đại học là quan trọng, tuy nhiên đó không phải là cách duy nhất. Có nhiều nơi khác có thể giúp em học được nữa, từ công ty nơi mình làm việc, cho đến các trung tâm dạy lập trình, hay tại chính phòng ngủ của mình. Nếu em thực sự cảm thấy học ở trên trường không còn đem lại giá trị gì cho bản thân mình nữa, và cảm thấy mình đã tìm thấy được những cách "học" khác hiệu quả hơn, thì cứ tiếp tục thử sức xem sao Về cơ bản, cần luôn luôn học hỏi, để bản thân mình hôm nay hiểu biết nhiều hơn, tiến bộ hơn hôm qua là được. Chứ đừng vì cán việc học trên trường, vì muốn đi làm, mà 3 tháng sau quay lại nhìn lại bản thân thấy không thay đổi gì cả, là lúc đó em cần phải xem xét lại quyết định của bản thân xem sao.

Nếu đã dùng Cron job rồi thì bạn chạy thẳng vào command PHP mà gửi mail thôi chứ sao trong code PHP lại cần gọi exec() với shell_exec() làm gì nhỉ

Không biết cụ thể bạn đang xây dựng chức năng gửi mail như thế nào, dùng thư viện gì, hay viết trên framework gì vậy, bạn có thể nói rõ thêm được không, để mọi người có thể đưa ra những lời khuyên chính xác hơn

Do ở title của câu hỏi thì bạn đặt là "Học PHP hiệu quả", nhưng nội dung bên trong thì lại kết lại bằng "các bạn cho mình lời khuyên cách học hiểu quả thuật toán", nên cũng không rõ bạn đang muốn tập trung vào phần nào nữa

Học về thuật toán đương nhiên cũng có những cái hay và cái lợi ích riêng của nó, giúp bạn phát triển thêm tư duy, hay giải quyết nhiều vấn đề về coding. Bạn có thể tìm đọc các cuốn sách về Algorithm, hay các cuốn Cấu trúc dữ liệu và giải thuật. Đây là một vấn đề cơ bản nên có rất nhiều sách, giáo trình bằng cả tiếng Anh lẫn tiếng Việt, bạn cứ thử tìm mua xem sao nhé Cái quan trọng nữa là học phải đi đôi với hành, bạn có thể vào những trang luyện tập về giải thuật, như https://code.viblo.asia/ chẳng hạn, để làm thử các bài tập trên đó, cũng như để học tập và rèn luyện thêm.

Còn về vấn đề học PHP thì lộ trình ôn lại từ đầu, từ các khái niệm basic của lập trình, đến các khái niệm OOP, cho đến PHP cơ bản, rồi Laravel như của bạn mình thấy cũng là hợp lý, bạn có thể tiếp tục theo đuổi. Trên Viblo cũng có rất nhiều bài viết có thể hỗ trợ bạn học hỏi thêm về những phần này, bạn có thể tìm đọc thêm:

• https://viblo.asia/p/lap-trinh-huong-doi-tuong-oop-trong-php-phan-1-gGJ59gyaZX2
• https://viblo.asia/p/lap-trinh-huong-doi-tuong-oop-trong-php-phan-2-XL6lAXODZek
• https://viblo.asia/p/lap-trinh-huong-doi-tuong-voi-php-va-nhung-dieu-can-biet-phan-1-GrLZDbzV5k0
• https://viblo.asia/p/lap-trinh-huong-doi-tuong-voi-php-va-nhung-dieu-can-biet-phan-2-Eb85oXq0K2G
• https://viblo.asia/p/lap-trinh-huong-doi-tuong-voi-php-va-nhung-dieu-can-biet-phan-3-bJzKmWBPl9N
• https://viblo.asia/p/php-nhung-dieu-can-biet-MLzGObjnvpq
• https://viblo.asia/p/laravel-beauty-recipes-best-practices-6BAMYk9Evnjz
• ...

Có một cách đơn giản thế này để cho phép bạn duyệt 2 phần tử liên tiếp trong vòng lặp for, bạn thử xem có hiệu quả không

• Tạo một biến previous gắn bằng rỗng.
• Chạy vòng for, check nếu previous là rỗng, thì gán previous bằng giá trị lấy ra hiện tại, rồi next
• Từ vòng lặp tiếp theo, bại sẽ có giá trị previous và giá trị hiện tại để xử lý, xử lý logic xong thì gán tiếp previous bằng giá trị hiện tại.

Như vậy trong vòng for bạn đã có thể check được 2 phần tử liên tiếp rồi

Từ version 6, thì Laravel follow theo các tiêu chuẩn của Semantic Versioning nên cách đặt tên cũng thay đổi so với ngày trước.

Cụ thể, tên version của Laravel sẽ theo quy tắc MAJOR.MINOR.PATCH, với

• MAJOR là version lớn, được release kèm theo sự thay đổi về API khiến code của version cũ không hoạt động
• MINOR là version nhỏ, được release kèm theo những chức năng mới, nhưng đảm bảo tính backwards compatible, tức code cũ vẫn sẽ hoạt động
• PATCH version là release bao gồm bug fixes

Tức là bạn có thể hiểu:

• Các bản release lớn sẽ có tên là số tăng dần từ 6.0.0 đến 7.0.0 rồi sắp tới sẽ là 8.0.0, 9.0.0 . Từ 6 lên 7 kéo theo nhiều thay đổi khiến bạn buộc phải update codes của mình.
• Bản 7.1.0 là bản update nhỏ cho 7.0.0 , bản update này bổ sung thêm các tính năng, nhưng vẫn phù hợp với code cũ, nên bạn có thể update từ 7.0.0 lên 7.1.0 mà không gặp vấn đề gì.
• Bản 7.1.1 là bản update có chứa các bản vá cho các lỗi được tìm ra ở phiên bản 7.1.0 , update sẽ không mang lại tính năng mới gì, nhưng sẽ giúp code base của framework hoạt động ổn định hơn.
• 6.X là tên để chi toàn bộ các phiên bản bắt đầu 6. Như 6.0.0, 6.2.0 hay 6.3.4 thì đều gọi chung là 6.X ... Tương tự như vậy, 7.X là viết tắt cho toàn bộ các phiên bản đầu 7.

Bạn có thể tìm hiểu thêm về Semantic Versioning thông qua bài viết sau trên Viblo: https://viblo.asia/p/semver-and-tags-version-924lJMMmZPM

Carbon thì được tích hợp trực tiếp trong Laravel, cũng như có thể sử dụng ngay với các trường là datetime trong instance của Eloquent rồi, thế nên bạn cứ thế mà dùng thôi, gần như không cần setup gì cả. Ví dụ như yêu cầu trong bài toán của bạn là "hiển thị danh sách giao dịch theo thời gian" thì bạn có thể sort theo trường created_at của bảng chứa các giao dịch, rồi khi hiển thị ra có thể dùng các hàm của Carbon để format lại ngày tháng cho dễ nhìn.

Về cách sử dụng Carbon, bạn có thể tham khảo một vài bài viết dưới đây trên Viblo:

• https://viblo.asia/p/carbon-thao-tac-voi-thoi-gian-that-don-gian-LzD5dxRd5jY
• https://viblo.asia/p/xu-ly-datetime-de-dang-hon-voi-thu-vien-carbon-trong-laravel-6J3ZgOmWZmB

Theo như thông báo lỗi thì có vấn đề ở package tedious, có vẻ package này viết bằng typescript và nó require plugin @babel/transform-typescript để build code, nhưng bạn đang chưa có plugin này. Bạn thử cài đặt bằng câu lệnh npm hay yarn xem sao

npm install @babel/plugin-transform-typescript
// hoặc 
npm install -g @babel/plugin-transform-typescript

Dùng API nhưng chưa tìm được thông tin API

Cái này bạn phải tự tìm cách mày mò thôi, có thể là ngồi phân tích file javascript của họ, hoặc là vào những trang mà mình cần lấy thông tin, xong mở Google Console, tab Network lên để xem hệ thống gọi lên những API nào, rồi điều tra dần thôi, chứ những trang này họ cũng không public API của mình ra đâu.

Xử lý DOM ở trang nhac.vn nhưng không thấy thông tin số lượt nghe như ở các trang zing mp3 và nhaccuatui

Mình cũng vừa vào trang nhac.vn xem thử, thì đúng là họ không hề show ra thông số số lượt nghe. Mà đã không show ra ở phía frontend rồi thì khả năng bạn có thể lấy được nó là cực kỳ thấp, bởi có thể họ còn không thống kê, hoặc có thống kê nhưng không có một public API nào để lấy được cả.

Bạn chỉ có thể cầu cho là bên nhac.vn vốn có thông tin đó, server vốn trả về thông tin đó nhưng bên frontend chưa thiết kế giao diện để hiển thị ra mà thôi (lúc đó bài toán quay trở về vấn đề trước, là tìm ra các API của service), nhưng mình nghĩ có rất ít khả năng này

Theo như những gì mình biết, thì mình xin giải đáp về các vấn đề bạn liệt kê ở trên như sau

Nếu website của bạn có máy chủ đặt tại Việt Nam, khách truy cập cũng chủ yếu đến từ Việt Nam thì việc sử dụng CloudFlare làm chậm đi tốc độ tải trang của bạn do ảnh hưởng bởi chất lượng đường truyền quốc tế

Check trên graph Cloud Flare network thì bạn sẽ thấy CloudFlare đã có 2 trung tâm dữ liệu ở Hà Nội và TP Hồ Chí Minh. Lục lại một chút từ thông báo Ten new data centers: Cloudflare expands global network to 165 cities thì họ đã mở 2 data centers này từ cuối năm 2018 rồi bạn ạ, thế nên cũng không phải quá lo lắng về việc người dùng Việt Nam sẽ phải access ra server nước ngoài khi truy cập vào trang web của bạn nhé

Uptime website của bạn ngoài phụ thuộc vào máy chủ hosting còn bị phụ thuộc vào độ ổn định của CloudFlare.

Cái này thì đúng, do các request đều đi qua CloudFlare trước khi đến được với server của bạn. Thế nên nếu CloudFlare lăn ra chết, thì người dùng sẽ không thể truy cập vào dịch vụ của bạn được, ngay cả khi service của bạn vẫn đang hoạt động bình thường. Vào tháng 7 năm ngoái từng xảy ra sự cố CloudFlare gặp lỗi, dẫn đến tất cả dịch vụ dùng CloudFlare, ước tính lên đến gần 10% số trang web trên toàn thế giới, rơi vào tình trạng không thể truy cập được.

• https://techcrunch.com/2019/06/24/cloudflare-outage-affecting-numerous-sites-on-monday-am/
• https://genk.vn/cloudflare-gap-su-co-khien-hang-loat-website-khong-the-truy-cap-duoc-20190702221130577.chn

Nhưng phải nói đây là sự kiện rất hy hữu bạn ạ. :v

Sử dụng CloudFlare thì không ai có thể biết được IP máy chủ của bạn. Điều này sẽ giúp bạn tránh được các Hacker dòm ngó tấn công local attack? Nhưng vấn đề thực sự nằm ở chỗ nếu website của bạn không bảo mật kĩ thì kiểu gì bạn cũng sẽ bị tấn công không bằng cách này thì bằng cách khác.

Câu này thì phần sau hoàn toàn đúng, vấn đề bảo mật thì vẫn phụ thuộc vào bạn là chủ yếu. Ý trước là CloudFlare sẽ giúp che giấu thông tin về địa chỉ IP của bạn thì cũng đúng, bởi mọi request từ phía người dùng sẽ đều đi qua CloudFlare, và máy client sẽ chỉ biết đến IP của CloudFlare mà thôi. Tuy nhiên, bạn vẫn có thể bị lộ IP của server của mình, nếu bạn từng trỏ domain vào thẳng server của mình trước đó. Hiện cũng có một số dịch vụ hay công cụ cung cấp chức năng reveal IP thực của service có dùng CloudFlare. Chúng làm được như vậy bởi trước khi dùng CloudFlare, các service kia từng trỏ domain vào thẳng server, và những bản ghi này có thể được lưu lại bởi một vài các dịch vụ, và có thể truy ngược lại lịch sử để lấy ra. Ví dụ như bạn có thể sử dụng https://securitytrails.com/ để tìm lại lịch sử record DNS của một domain, từ đó tìm ra được IP của server của dịch vụ đó, trước khi nó chuyển sang CloudFlare.

Bởi thế, nếu cần che giấu hoàn toàn IP của mình, thì bạn cần phải transfer thẳng domain về CloudFlare ngay khi mua xong domain, hoặc đổi hẳn IP của server, hay chuyển server, sau khi bắt đầu sử dụng CloudFlare.

Và bạn cũng sẽ không bao giờ biết được IP thật sự của khách khi truy cập vào website của bạn.

Cái này thì sai. CloudFlare cho phép bạn lấy được thông tin về IP của client thông qua các header như CF-Connecting-IP, True-Client-IP hoặc X-Forwarded-For. Bạn cần config thêm ở phía web server của mình là hoàn toàn có thể log được lại hết client IP mà không gặp vấn đề gì.

Bạn có thể tìm hiểu thêm tại đây:

• https://support.cloudflare.com/hc/en-us/articles/206776727-What-is-True-Client-IP-
• https://support.cloudflare.com/hc/en-us/articles/200170986-How-does-Cloudflare-handle-HTTP-Request-headers-
• https://support.cloudflare.com/hc/en-us/sections/200805497-Restoring-Visitor-IPs

Cả thế giới truy cập vào website của bạn thông qua một vài dải IP của CloudFlare. Điều này 100% khiến firewall của máy chủ hiểu lầm rằng CloudFlaređang tấn công vào máy chủ của bạn. Nguyên nhân do một vài IP của CloudFlare có luồng dữ liệu ra vào máy chủ quá lớn. Mình đã phân tích và chứng minh được rằng trường hợp nhiều bạn gặp lỗi “Site Offline” trong khi máy chủ vẫn bình thường là do Firewall đã tự động block hết ip của CloudFlare. Thử tưởng tượng xem một máy chủ Share Hosting mà có nhiều website cùng sử dụng CloudFlare thì nó sẽ tệ thế nào ?

Cái này thì bạn chỉ cần add IP của CloudFlare vào whitelist trên server của mình, để nó không block CloudFlare là được

Mặc dù được quảng cáo là giảm thiểu thiệt hại khi bị tấn công từ chối dịch vụ (DDoS) nhưng vô hình chung khi sử dụng CloudFlare chúng ta lại gặp được những vấn đề rất bất lợi. Cụ thể bạn sẽ không thể nào biết được địa chỉ thật sự của hacker. Nếu không sử dụng CloudFlare trường hợp hacker dùng 1 máy tính tấn công vào website của bạn, HP chỉ cần chặn IP đó ở firewall là xong. Nhưng khi sử dụng CloudFlare luồng dữ liệu đi tới máy chủ của bạn quá lớn, CloudFlare sẽ phân luồng dữ liệu đó ra nhiều luồng với nhiều địa chỉ IP khác nhau. Vô tình điều này sẽ làm máy chủ của bạn sập nhanh hơn, quản trị bối rối hơn do có quá nhiều IP của CloudFlare cùng tấn công vào Website của bạn (tất nhiên nó cũng được giảm thiểu theo quảng cáo của CloudFlare).

Như đã chia sẻ ở trên, bạn có thể config ở phía web server của mình để nhận về IP thực của client, nên bạn vẫn sẽ có thể phân tích, và ban những IP thực đó, từ phía server của mình.

Chỉ cần bật Captcha lên là bạn có thể ngăn chặn mọi cuộc tấn công DDOS ? Bạn đừng nhầm, Hacker có những công cụ rất tốt có thể vượt qua được cả reCaptcha. Trong trường hợp DDOS thông thường website của bạn vẫn cứ bị ảnh hưởng như thường.

Cái cuối này thì có vẻ không liên quan gì đến CloudFlare cho lắm nhỉ

Trên đây là một số chia sẻ của mình, hy vọng có thể giúp ích được cho bạn

MySQL và NoSQL (cụ thể em đang dùng cassandra) hoạt động riêng biệt hay chung ạ

Không rõ ý bạn về việc "hoạt động riêng biệt hay chung" tức là thế nào (^^;) Ngoài ra ví dụ so sánh của bạn cũng sai sai, MySQL là tên một phần mềm cơ sở dữ liệu quan hệ (RDBMS - Relational Database Management System), còn NoSQL thì là tên một loại cơ sở dữ liệu, có thể hiểu là phi quan hệ, để thể hiện sự khác biệt với dạng cơ sở dữ liệu quan hệ thông thường.

Về cơ bản thì hệ thống cơ sở dữ liệu quan hệ sử dụng SQL (Structured Query Language - Ngôn ngữ truy vấn có cấu trúc) để truy vấn và duy trì cơ sở dữ liệu. Một số hệ thống cơ sở dữ liệu quan hệ phổ biến có thể kể đến là MySQL, MariaDB, SQLite, PostgreSQL, Microsoft SQL Server ...

NoSQL thì là dạng cơ sở dữ liệu phi quan hệ, tức nó không có các cấu trúc bảng, hay quan hệ giữa các bảng như hệ cơ sở dữ liệu quan hệ. Mộ số hệ thống NoSQL phổ biến có thể kể đến MongoDB, Cassandra, CouchDB ...

Thế nên quay trở lại câu hỏi của bạn về việc chúng "hoạt động riêng biệt hay chung" thì do chúng là những khái niệm khác nhau, chỉ những phần mềm khác nhau, nên đương nhiên là sẽ chạy độc lập với nhau rồi. Còn trong một hệ thống chúng có thể "hoạt động chung với nhau không?" thì câu trả lời là có. Có những service chỉ sử dụng MySQL, có những service chỉ sử dụng MongoDB, nhưng cũng có những service sử dụng cả hai, không có vấn đề gì cả. Tất cả chỉ phụ thuộc vào mục đích, ý đồ và mong muốn của người sử dụng thôi

Bạn có thể tham khảo thêm một số bài viết dưới đây để hiểu thêm về những khái niệm ở trên nhé:

• https://viblo.asia/p/so-sanh-mongodb-va-mysql-Qbq5QWWEZD8
• https://viblo.asia/p/the-sql-vs-nosql-difference-mysql-vs-mongodb-63vKj2WxK2R
• https://viblo.asia/p/nhung-diem-khac-biet-giua-sql-va-nosql-gGJ59b4rKX2
• https://viblo.asia/p/nhung-diem-khac-biet-giua-sql-va-nosql-gDVK2WPjZLj

Bạn thử mở file mới với mode là append xem sao

writer = ExcelWriter('VFdsdoichieu.xlsx', mode='a')

Hầu hết các view engine, hay template engine, hiện tại đều có cơ chế mặc định là escape hết các ký tự HTML đặc biệt, như >, <, &, ", ' và việc này sẽ giúp bạn render dữ liệu ra mà không thực thi mã script, giúp tránh được lỗi XSS. Đấy là một chức năng của template engine mà bạn đang sử dụng trong project của mình.

Tuy nhiên, theo mình thấy một mình chức năng như vậy vẫn là chưa đủ đâu, điều quan trọng là bạn cần phải luôn ghi nhớ rằng, "đừng bao giờ tin tưởng vào dữ liệu của người dùng". Với những project lớn, phức tạp, có nhiều logic, đôi khi hacker có thể lợi dụng những kẽ hở rất nhỏ, để thực thi được XSS đấy. Như hiện tại thì hầu hết các framework, với các template engine hiện đại đều có chức năng defult là escape special characters rồi, nhưng XSS vẫn xuất hiện đều dặn, và luôn là một trong những nghiêm trọng của các hệ thống. Việc phòng chống nó, cuối cùng, cũng là phụ thuộc vào kinh nghiệm và năng lực của developer thôi

Có vẻ là bạn đang hỏi về các HTTP Methods nhỉ Nếu là vậy thì tên method phải là PUT chứ không phải là PUSH đâu

GET, POST, PATCH, PUT, DELETE là 5 methods cơ bản dùng để gọi phía server Restful. Bạn có thể tìm hiểu thêm về REST cũng như các HTTP Methods này thông qua một số bài viết sau trên Viblo:

• https://viblo.asia/p/rest-101-rest-restful-api-E375zRqq5GW
• https://viblo.asia/p/cau-chuyen-cua-restful-api-Qpmle24N5rd
• https://viblo.asia/p/tim-hieu-ve-restful-bWrZnLvQ5xw
• https://viblo.asia/p/tim-hieu-ve-restful-924lJM4zZPM
• https://viblo.asia/p/tim-hieu-ve-restful-web-service-OEqGj5JNM9bL

Chuẩn REST có quy định rõ ràng như thế nào là một resource controller, và phải dùng method nào cho từng action trong controller đấy.

Cụ thể thì với action index để lấy ra list dữ liệu, bạn cần gửi request lên server với method GET, hay với action store để lưu dữ liệu, bạn cần gửi request lên server với method POST, để sửa dữ liệu thì bạn cần dùng method PUT hoặc PATCH (PUT để sửa toàn bộ record, trong khi PATCH thường dùng trong trường hợp sửa 1 phần của record), để xoá dữ liệu thì cần method DELETE.... Chỉ cần bạn gọi lên server với Method khác với quy định (ví dụ như dùng method POST để update dữ liệu chẳng hạn) thì sẽ nhận về lỗi 405 (Method not allowed)

Đương nhiên, đây là tiêu chuẩn của REST, bạn có thể tuân theo hoặc không. Bạn vẫn có thể code theo kiểu dùng GET để tạo dữ liệu, vẫn có thể dùng POST để xoá dữ liệu, và hệ thống vẫn sẽ chạy. Tuy nhiên, đã là tự code theo ý mình thì về sau bạn có thể sẽ gặp rất nhiều vấn đề về chất lượng code, về bảo mật, sẽ rất khó trong việc làm document, hay trao đổi với các thành viên khác trong development team (ví dụ như bạn làm theo chuẩn của REST về HTTP Method, thì chỉ cần bảo với thành viên khác một câu là gọi API để tạo dữ liệu đi, là teammate của bạn sẽ biết ngay cần phải gọi đến URL nào, với method là gì ... )

Ngoài ra, bạn nên đọc thêm bài này, để hiểu rõ hơn về những lợi ích khác của REST, bên cạnh HTTP Method được define rõ ràng ra

Đa kế thừa bạn có thể hiểu đơn giản là một class có thể kế thừa từ nhiều hơn 1 class khác. Hiểu theo nghĩa này thì PHP, hay Java đều không hỗ trợ đa kế thừa (do khi khai báo class, bạn chỉ có thể extends từ duy nhất 1 class khác). Ngôn ngữ OOP hỗ trợ đa kế thừa phổ biến nhất, thì có lẽ là C++ và Python.

Mặc dù không hỗ trợ việc kế thừa từ nhiều class cùng một lúc, nhưng PHP (hay Java) đi theo một cách khác để hỗ trợ một vài tính chất của đa kế thừa, thông qua Interface (một class có thể implements nhiều hơn 1 Interface). Ngoài ra PHP còn có khái niệm Trait, cũng có thể sử dụng để thể hiện một vài tính chất của đa kế thừa. Nhưng về cơ bản, thì nó vẫn khác với khái niệm đa kế thừa được thể hiện trên C++ hay Python

Bạn có thể tham khảo bài viết của một bạn khác từng chia sẻ trên Viblo: https://viblo.asia/p/he-thong-viblo-code-challenge-duoc-xay-dung-nhu-the-nao-WAyK8d39KxX cũng như những thảo luận ở phần comment trong bài viết đó

Nhìn chung bạn sẽ cần phải tìm hiểu/sử dụng các công nghệ sau:

• Một framework để làm backend (API). Ví dụ như Laravel (PHP), hay Rails (Ruby), Django (Python) ...
• Một framework/library để viết frontend. Đơn giản thì có thể dùng jQuery là chính, view có thể dùng luôn engine của các web framework ở trên cũng được. Hoặc không thì bạn có thể tách riêng Backend / Frontend ra và dùng Reactjs, Vuejs ...
• Docker để tạo môi trường cô lập, để compile hay chạy code trong đó

Bạn có thể dùng Homebrew để cài đặt php

brew install php@7.1

Ý tưởng rất hay em ạ

P/S:

Thi thoảng đọc được mấy bài đấy mình hay tự hỏi: "Làm sao để viết được những bài viblo tuyệt vời vậy nhỉ ?". Mình toàn nhủ thì các bạn ý giỏi quá, mình theo không nổi, thôi di dịch bài cho lẹ 😦.

Trước hết, hãy cố gắng bứt mình ra khỏi cái suy nghĩ "mình theo không nổi, thôi di dịch bài cho lẹ" đã em ạ. Dịch một bài có thể đem lại hiểu biết cho em nhất thời lúc đó, nhưng nếu những nội dung ấy không phải do chính em viết ra theo ý hiểu của mình, thì nó mãi mãi không phải là kiến thức của em. Mấy hôm sau hay mấy tuần sau em sẽ quên ngay thôi ...

Trong lúc em ngồi dịch những "kiến thức của người khác", thì xung quanh em, những bạn khác đang miệt mài ngồi viết ra những "kiến thức của bản thân mình", và cứ thế, em sẽ lại quanh quẩn trong cái suy nghĩ "mình theo không nổi, thôi di dịch bài cho lẹ" mà thôi.

Có một câu nói rất hay là "Trong lúc bạn đang cố gắng, thì đâu đó ngoài kia, những người giỏi hơn bạn, họ cũng đang cố gắng". Vì thế, để làm được những điều như họ, em cần phải cố gắng hơn nữa

Để dùng được font thì trước tiên bạn cần phải define @font-face trong CSS trước cơ

Ví dụ như đây là một file CSS mà Google Font define sẵn cho mình dùng https://fonts.googleapis.com/css?family=Noto+Sans+JP&display=swap bạn có thể tham khảo

P/S: Font Noto Sans CJK JP khá là nặng, và việc dùng nó trên web có thể đem lại trải nghiệm không tốt, như tăng thời gian tải trang (^^;) Bạn có thể dùng bản web font Noto Sans JP, hình như cũng giống cái Noto Sans CJK JP thì phải , được Google cung cấp ở đây https://fonts.google.com/specimen/Noto+Sans+JP?selection.family=Noto+Sans+JP (mặc dù cái Noto Sans JP này vẫn rất nặng :v)

Google họ cũng define sẵn css rồi, mình chỉ cần import vào mà dùng thôi

<link href="https://fonts.googleapis.com/css?family=Noto+Sans+JP&display=swap" rel="stylesheet">

body {
  margin: 0;
  padding: 0;
  font-family: 'Noto Sans JP', sans-serif;
}