thichhoc.com: Cầu dừa đủ xoài

Lời nói đầu Chúc mấy bạn năm mới vui vẻ nhiều sức khỏe Tóm tắt Cuối thu 2022, mình thấy tên miền thichhoc.com trống và quyết định mua tên miền này cho youtube channel của mình. Mình muốn viết một bản cầu dừa đủ xoài trước, sau đó sẽ cải tiến thêm. Mục đích chính

Lời nói đầu

Chúc mấy bạn năm mới vui vẻ nhiều sức khỏe

Tóm tắt

Cuối thu 2022, mình thấy tên miền thichhoc.com trống và quyết định mua tên miền này cho youtube channel của mình. Mình muốn viết một bản cầu dừa đủ xoài trước, sau đó sẽ cải tiến thêm. Mục đích chính là để cho những khán giả của kênh mình có thể test lại kiến thức sau mỗi bài học và mục đích phụ là để mình học hỏi cách implement một dự án như thế nào. Sau vài tháng lăng tăng học hỏi và thử nhiều thứ, cuối cùng mình cũng xong một bản nháp và đang chạy thich hoc beta để test và implement cũng như fix những thứ còn sót lại như thông báo, mail, fix bug, cải thiện cms,… Trong bài viết này, mình chia sẻ lại cho các bạn quá trình mình đã tự implement một trang web như thế nào.

Viết use case

Tại sao không nhảy vào và code luôn cho khoẻ, mà phải cần viết use case. Lí do là khi có use case, bạn sẽ viết test case dễ và chính xác hơn đồng thời sẽ có cái nhìn tổng quan về app của mình ngay từ đầu. Tại sao viết code rồi viết test case thì không chính xác bằng viết test case trước? Đơn giản là khi bạn viết code, bạn đã có cái flow logic trong đầu mình và khi viết test, bạn sẽ có xu hướng viết test để chỉ cover những cái logic đó. Ngược lại, nếu viết use case tốt, bạn sẽ có tổng quan chính xác task đó cần làm gì, role nào và acceptance criteria là gì dưới góc nhìn của role đó. Sau đó viết test thì bạn sẽ cover những case đó rồi xong đó implement code thì code bạn dường như đã cover đầy đủ những case mà bạn quan tâm.

Những khó khăn khi mình viết use case đó là chưa quen lắm, viết hơi ngáo. Với lại chưa có kinh nghiệm nhiều nên những cái ticket không như plan đã đề ra. Lấy ví dụ như mình có plan là sẽ tự implement cms xong vào tháng 1 năm 2023. Nhưng mà tháng 1 năm 2023 thì mình đã xong cms lâu rồi lí do là mình dùng filament cms, mình chỉ cần tinh chỉnh lại theo case của mình là xong. Qua việc viết use case, mình học được bài học đó là nếu nhu cầu của mình giống với những case phổ biến và lâu đời rồi thì nên tìm một giải pháp có sẵn và tinh chỉnh theo ý muốn của mình. Nếu mình cần viết một cms xịn, giao diện đẹp, nhiều logic phức tạp thì mình sẽ tự viết, còn đơn giản là chỉ thêm xoá sửa sương sương thì giống như case của mình, mình sẽ dùng cái có sẵn và tinh chỉnh lại.

Vẽ ERD diagram

Vẻ ERD là thứ theo mình khá là quan trọng khi start một dự án vì nó sẽ cho chúng ta tầm nhìn tổng quan về database của mình. Có những bảng nào, có normalize chưa, có chỗ nào cần tối ưu hay không, những relationship có ok chưa, có thật sự cần bảng này hay không, vân vân và mây mây. Có một kinh nghiệm nhỏ là nếu dùng Laravel mình sẽ dùng ERD hoặc database diagram vì trong Laravel, muốn dùng thuộc tính nào đó thì bạn sẽ gọi trực tiếp tên cột ra như $user->email. Còn khi dùng Symfony thì mình sẽ ưu tiên vẽ class diagram vì Symfony dùng doctrine, mà doctrine là PHP object nên vẽ class diagram sẽ cho cái nhìn tổng quan là thuộc tính nào cần thiết trong class đó. Sau khi vẽ xong diagram thì mình check lại lần nữa xem nó có đáp ứng được những use case mình đã viết không, có chỗ nào tối ưu được không. Sau đó thì mình tiếp tục bước tiếp theo.

Chọn stack

Đương nhiên là SPA vì giờ ai cũng viết SPA. Nói vậy thôi chứ chọn stack thì không nên chọn theo trend mà phải chọn theo nhu cầu. Nhu cầu lúc đó của mình muốn cái gì đó nhanh gọn lẹ. Muốn nhanh gọn lẹ thì tốt nhất nên viết trong một cái ecosystem của nó, viết nhanh hơn và deploy cũng dễ hơn nên Laravel + Blade + Tailwindcss là ok rồi. Mà mình muốn nó interactive xíu nên mình dùng TALL stack.

Bắt đầu implement

CMS thì không có gì để nói, tinh chỉnh lại theo case của mình là xong. Còn phần app, cần học thêm livewire, alpine và tailwindcss. Tóm tắt lại cho 3 tools như sau. Tailwindcss giúp bạn style trang web của mình dễ và flexible hơn, hỗ trợ tốt, có thể tự implement design system cho mình. Alpine là thư viện js nhỏ gọn, viết giống giống với vue mà có vẻ còn nhẹ hơn với đơn giản hơn vue nữa, tuy nhiên mình không thích việc viết thẳng logic với data vào trong html lắm. Livewire, tốt cho SEO, viết interactive mà không cần tự viết javascript, có điều viết ngáo ngáo là nó gọi ajax xuống server mệt nghỉ dẫn đến performance chậm, component cha thay đổi thì component con không thay đổi, cần tạo event để component con lắng nghe và thay đổi và không dùng virtual dom, phần thay đổi năng hay nhẹ thì tuỳ thuộc vào component to hay nhỏ.

Test

Màu mè viết use case, phân tích tại sao viết use case chứ lại lười viết test. Thôi implement lần đầu thì coi nó hoạt động sau đã, hứa với lòng lần sau sẽ viết test trước. Nhưng giờ muốn test app thì cái quan trọng là seed data, seed data thật tẹo. Kiểu mình sẽ seed 1000 user, 10 khoá học, một số course đuợc enroll, một số course đuợc hoàn thành một số thì không, tương tự cho quiz, rồi seed câu hỏi, câu trả lời, câu trả lời đúng. Sau đó, manual test, không có gì to lớn, test có bug thì ghi lại rồi tạo nhánh để fix

Containerize và CI/CD

Containerize lại cho nghệ nghệ thôi, đơn giản là tạo một image để build xong rồi chép cái đóng code mới build sang một image khác để serve cho nhẹ nhàng hơn. Ở bước containerize này thì mình cần học về web server là nginx, hoặc cách serve một trang web, rồi đăng kí https, đơn giản vậy thôi. Tiếp theo cần chuẩn bị một con instance để có thể deploy web và setup domain trỏ về con instance này, mình dùng EC2 của Amazon để chạy và mua domain name từ nhà cung cấp mắt bão. Sau đó thì mình implement CI/CD trong github actions. Không đao to búa lớn, chỉ đơn giản là khi mà code mới đuợc đẩy lên nhánh main thì sẽ build image, đẩy lên github package, sau đó chép docker-compose vào instance EC2, rồi vào instance EC2, pull image mới build về, chạy docker-compose up -d, clean image cũ đi. Mở cổng 80 trên instance EC2. Còn về file .env thì mình chép một file .env riêng gồn những config cho production trên EC2 instance và map nó vào service nên không cần copy từ .env.example ở trên EC2 instance.

Bước cuối là implement một trang html đơn giản để thông báo với mọi người về trang beta.thichhoc.com. Và trang html này sẽ deploy cho domain thichhoc.com.

Đánh giá

Chạy lighthouse và page speed insight để đánh giá trang web
image.png
Ok, tạm ổn. Không có gì cần làm nhiều ở bước này.

Check it

Trang chính: https://www.thichhoc.com/

Trang beta: https://beta.thichhoc.com/

Những thứ cần cải thiện

Sau khi viết xong, thì mình cảm thấy tự tin hơn và muốn cho nó professional xíu, cũng như học hỏi nhiều xíu nên đây là danh sách những thứ mình sẽ làm tiếp theo sau khi research trên internet:

  • Bỏ alpine và livewire, chuyển sang dùng Nextjs. Mục đích để luyện skill, học hỏi công nghệ mới.
  • Chỉnh luồng CI/CD để chạy test, hiện tại chỉ có build thôi. Và deploy lên nhiều môi trường. Mình muốn là khi code merge vào stage thì nó tự động deploy lên stage.thichhoc.com và dừng lại, đợi sự đồng ý của mình thì sẽ deploy lên thichhoc.com.
  • Viết test cho laravel api, viết unit test và intergration test

Kết lại

Đó là quá trình mình tự implement trang web của mình, mong là chia sẽ của mình sẽ giúp ích cho các bạn.

Nguồn: viblo.asia

Bài viết liên quan

WebP là gì? Hướng dẫn cách để chuyển hình ảnh jpg, png qua webp

WebP là gì? WebP là một định dạng ảnh hiện đại, được phát triển bởi Google

Điểm khác biệt giữa IPv4 và IPv6 là gì?

IPv4 và IPv6 là hai phiên bản của hệ thống địa chỉ Giao thức Internet (IP). IP l

Check nameservers của tên miền xem website trỏ đúng chưa

Tìm hiểu cách check nameservers của tên miền để xác định tên miền đó đang dùn

Mình đang dùng Google Domains để check tên miền hàng ngày

Từ khi thông báo dịch vụ Google Domains bỏ mác Beta, mình mới để ý và bắt đầ