Theo góc nhìn của mình thì pagespeed là “tốc độ tải trang” đã bao gồm tốc độ phản hồi từ máy chủ luôn nhé. Tốc độ phản hồi từ máy chủ liên quan đến nhiều yếu tố khác không nằm trong phạm vi bài viết này. Còn Pagespeed nói riêng là những gì xảy ra ở trình duyệt web (browser).

Tại sao tối ưu tốc độ tải trang lại quan trọng?

“Người sử dụng website cảm thấy hạnh phúc” là tiêu chí cực kỳ quan trọng! Không những có giá trị trực tiếp lên người dùng mà còn ảnh hưởng đến xếp hạng tìm kiếm của Google. Bởi vì Google cũng muốn người dùng hạnh phúc với kết quả tìm kiếm. Nên những trang web có tốc độ nhanh sẽ được Google ưu ái xếp hạng. Việc cải thiện thứ hạng tìm kiếm trên Google là cái kết cực kỳ đáng giá. Điều đó đồng nghĩa với việc website sẽ được nhiều lượt truy cập hơn, việc kinh doanh sẽ trở nên tốt hơn.

“Milliseconds Make Millions“, mili giây tạo triệu đô: cứ 0.1 giây cải thiện được thì tỉ lệ chuyển đổi (conversion rate) tăng 8%. Đây là con số không hề nhỏ, và nếu bạn thực hiện tối ưu tốc độ theo bài viết này, bạn sẽ cải thiện ít nhất 0.5 đến 1.5s, tương đương “tỉ lệ chuyển đổi” tăng từ 40%~80%. Woa!!!

Chú ý: chạy theo thành tích về điểm số của Google sẽ đánh đổi khá nhiều thời gian và công sức. Và đó là một công việc khá dài hơi và có tính chu kỳ. Tuy nhiên, kết quả thì sẽ rất ngọt ngào!

Fullstack Station Tips

Cho dù bạn có làm nội dung và SEO tốt nhưng pagespeed lại chậm thì sẽ ảnh hưởng rất nhiều đến thứ hạng tìm kiếm, cũng như trải nghiệm người dùng. Là nguyên nhân dẫn đến lượng truy cập thấp. SEO thì tất nhiên quan trọng, nhưng đầu tư vào tối ưu tốc độ tải trang pagespeed thì hiệu quả lâu dài và chắc chắn có kết quả tốt.

Khó khăn và thách thức

Khó khăn

Một điều khá lạ nhưng cũng thường xảy ra là chẳng ai quan tâm đến pagespeed khi mới phát triển trang web cả. Chỉ là sau 1 thời gian thấy thứ hạng tìm kiếm không tăng nổi, hoặc là truy cập không đạt chỉ tiêu thì chủ doanh nghiệp mới bắt đầu lôi cổ phòng marketing ra, lúc đó để ý đến pagespeed.

Rất ít chủ quản website quan tâm đến pagespeed, đó chính là khó khăn cho các bạn làm marketing nói chung và lập trình viên nói riêng. Bởi vì các con số của pagespeed gần như không liên quan đến lượt truy cập và thứ hạng tìm kiếm? Hoặc là để đánh giá KPI thì rất khó khăn. Khi bạn cải thiện tốc độ lên, đồng thời thứ hạng tìm kiếm cũng lên, vậy kết quả là do chiến lược SEO, do Google thay đổi thuật toán tìm kiếm, hay do kết quả của pagespeed?

Xác định được quả thật là rất khó, tuy nhiên bạn hãy tin tưởng vào câu “Miliseconds Make Millions” do chính Google đưa ra. Và cũng có tiêu chí xác định ROI (Return On Investment): với các thông số Lượng truy cập, Tỉ lệ chuyển đổi, Giá trị trung bình đơn hàng thì TestMySite sẽ đưa ra con số doanh thu hàng năm (annual revenue) sẽ tăng lên bao nhiêu nếu bạn cải thiện được pagespeed bao nhiêu giây. Đây là phương pháp xác định con số cụ thể biết có xứng đáng đầu tư vào việc cải thiện pagespeed hay không.

Nhưng bạn phải quán triệt một điều là tốc độ tải trang không phải là chiếc đũa thần. Nếu chất lượng nội dung không tốt thì tốc độ tải trang sẽ không có ý nghĩa gì cả. Khi các trang có chất lượng bằng nhau, thì tốc độ tải trang, trải nghiệm người dùng sẽ được ưu tiên trên hệ thống tìm kiếm. Tóm lại, làm người sử dụng hạnh phúc là tôn chỉ cao nhất!

Thách thức

Như đã nói ở trên thì bạn thường bắt tay vào việc cải thiện pagespeed khi website đã đi vào hoạt động đã lâu. Và vì cũng phải có lượng truy cập tương đối khá (nhưng bắt đầu hụt hơi?) thì mới xác định được ROI mà nên thực hiện cải thiện pagespeed hay không. Với lý do đó mà tại thời điểm bạn bắt đầu cải thiện thì hệ thống website đã như 1 bãi chiến trường :)). Đó chính là thách thức.

Vì lý do tăng trưởng, nên thường thì website sẽ đặt mục tiêu về chức năng trước. Còn các mặt khác đều là thứ yếu. Tất nhiên đó là điều dễ hiểu vì nếu không có giai đoạn đó thì bạn sẽ không có cơ hội cải thiện pagespeed đâu. Tại thời điểm này, những quy tắc pagespeed đều chỉ là 1 thứ lý thuyết suông mà thôi. Bạn phải vắt óc suy nghĩ làm sao kết hợp các quy tắc đó vào hệ thống hiện tại.

Cải thiện pagespeed với công số thấp nhất mà hiệu quả cao nhất. Đó chính là “State of the art” mà bạn phải đối mặt giải quyết. Và đó cũng chính là điều mình hi vọng giúp được các bạn trong bài viết này.

Cách đơn giản để tối ưu tốc độ tải trang

Sử dụng mod_pagespeed chính chủ Google

Mình đã từng giới thiệu về mod_pagspeed để tăng tốc pagespeed cho website. Cách này sử dụng cho kết quả tốt mà lại dễ dàng. Tuy nhiên chỉ áp dụng với site tĩnh hoàn toàn. Các trang web có sử dụng form với crsf-token được tạo ra theo trang thì khó đạt kết quả như mong đợi.

Hơn nữa, khi áp dụng thì bạn gần như lệ thuộc hoàn toàn vào các thiết lập và cài đặt. Khó có thể tự quản lý các nhu cầu tuỳ biến cao. Mình nghĩ chỉ nên sử dụng đối với site nhỏ, hoặc site mới đang trong thời kỳ triển khai. Vì các tham số khá nhiều nên việc cấu hình khá khó khăn. Qua thời gian nâng cấp, các tập tin css và js được thêm vào nhiều thì rủi ro sẽ tăng lên. Bởi vì tự động nên cũng có khi có lỗi ngoài tầm kiểm soát.

Trang fullstackstation.com có kết quả 1.8s/Good trên testmysite cũng đang sử dụng mod_pagespeed. Mình khá hài lòng kết quả này. Tuy nhiên điểm trên Pagespeed Insights thì vẫn không được cao. Do Google mới thay đổi thuật toán tính điểm.

Sử dụng các framework/plugins hỗ trợ tốt về pagespeed

Plugins cho WordPress

Hiện tại Fullstack Station sử dụng wordpress nên mình dùng Autoptimize (nén js và css thành 1 file) và Hyper Cache (tạo cache trang thành html), kết hợp với mod_pagespeed. Về cơ bản thì những plugin cho wordpress chỉ giúp cải thiện ở một vài quy tắc. Để tối cải thiện tốc độ tải trang thì plugins là chưa đủ.

Có rất nhiều plugins cho wordpress cải thiện tốc độ nói chung, nhưng không nằm trong phạm vi bài viết này. Đơn giản nhất là chỉ cần sử dụng 2 plugins nói trên. Với các website doanh nghiệp, mình khuyến nghị nên dùng bộ lập trình của https://roots.io/. Sử dụng bộ của Roots để tạo theme cũng như quản lý các plugins 1 cách bảo mật. Khi bạn tự phát triển theme, thì sẽ dễ dàng quản lý các javascript và css hơn.

Các js framework

Với kỹ thuật code splitting, thì các framework hay thư viện hỗ trợ dựa trên webpack sẽ giúp tốc độ trang khá tốt. Cơ bản thì sẽ giúp trang tải css và js cần thiết cho việc render. Ngoài ra còn cải thiện tốc độ rất tốt với kỹ thuật tạo trang html tĩnh và động tương ứng.

Điển hình là các js framework như Gatsby.js, Ghost CMS, Next.js, Nuxt.js. Cơ chế trang tĩnh rất quan trọng, để đảm bảo tốc độ tốt nhất. Và cũng cần cơ chế tải từng phần như Gatsby để nâng cao trải nghiệm người dùng.

Các quy tắc đảm bảo tối ưu tốc độ tải trang tốt

Đơn giản (nhưng cũng đầy cam go) là bạn sử dụng Lighthouse ngay trên trình duyệt Chrome hoặc dùng Pagespeed Insights để kiểm tra và chẩn đoán từng trang. Các công cụ này sẽ đưa ra các khuyến nghị và chỉ cần làm theo là sẽ cải thiện được.

Mình cũng đã phải trải qua hàng trăm lần kiểm tra để đưa ra giải pháp tối ưu nhất cho website imitsu.jp. Và kinh nghiệm được rút ra như sau:

• Tốc độ phản hồi máy chủ nhanh: mỗi request dưới 300ms cho 4G/mobile, 100ms cho desktop, đặc biệt là trang html (Doc).
• Mỗi request (html, css, js, image): dưới 50kB cho mobile và hạn chế nhất có thể trên bản desktop.
• Hạn chế số lượng request: dưới 35 requests, càng ít càng tốt
• Cache Policy: nên để thời gian cache lâu (6 tháng~), khi bạn cần thay đổi thì thêm parameter ở URL hoặc, thay đổi tên file.
• CDN: những file tĩnh nên sử dụng CDN để tăng hiệu quả tốc độ
• Sử dụng lazyload: kỹ thuật này giúp browser không tải ảnh khi chưa sử dụng (chưa hiển thị trong viewport)
• Tối ưu tải css và javascript: css ở head và javascript file thì ở dưới phần footer, inline phù hợp.
• Sử dụng worker để xử lý các script, tính toán không cần thiết ở main thread.
• Sử dụng loại định dạng ảnh mới như WebP, JPEG 2000, …

Trên đây là một số quy tắc chủ đạo xoay quanh các tiêu chí:

• Nhanh nhất có thể
• Nhỏ, nhẹ nhất có thể
• Sử dụng đúng nơi, đúng chỗ (không thừa)

Tuy các quy tắc thì nhiều, nhưng tựu chung cũng tập trung cho các tiêu chí trên. Đảm bảo các tiêu chí trên thì dù Goole có thay đổi các tiêu chí đánh giá, thì điểm số vẫn sẽ cao.

Core web vitals

Core web vitals sẽ là tiêu chí quan trọng ảnh hưởng đến xếp hạng tìm kiếm. Do dịch corona nên tiêu chí này được dời lại 1 năm. Năm 2021 sẽ áp dụng Core Web Vitals để đánh giá xếp hạng tìm kiếm. Tiêu chí này ảnh hưởng trực tiếp đến trải nghiệm người dùng. Vì vậy bạn nên chuẩn bị cải thiện sớm nhất có thể. Vào các bài viết sau mình sẽ trình bày chi tiết hơn về Core Web Vitals.

Testmysite và Pagespeed Insight: ưu tiên tối ưu tốc độ bằng cái gì?

Sơ lược về TestMySite và Pagespeed Insights

Pagespeed Insights là gì?

Pagespeed Insights là công cụ đo lường tốc độ tải trang pagespeed của một site sử dụng dữ liệu thực tế của người dùng trên Chrome kết hợp dữ liệu từ Lab (công cụ kiểm tra như Lighthouse). Từ kết quả đo lường, Pagespeed Insights sẽ đưa ra các chẩn đoán và khuyến nghị giúp tối ưu tốc độ tải trang/pagespeed.

Nhìn vào bảng biểu trên thì dễ dàng nhận ra Largest Contentful Paint (LCP) và Total Blocking Time là 2 tiêu chí có trọng số cao nhất. Đó cũng chính là tiêu chí nên tập trung giải quyết, sẽ được đề cập chi tiết trong các bài viết sau. Pagespeed Insights sử dụng Lighthouse để kiểm tra, nên bạn chỉ cần sử dụng Lighthouse và làm theo các khuyến nghị tối ưu tốc độ là được. Kết quả điểm số ở Lighthouse sẽ có chênh lệch so với Pagespeed Insights, cũng như chính bản thân Pagespeed Insights qua các lần kiểm tra khác nhau. Lý do là tốc độ kết nối vào máy chủ trang web tuỳ thuộc vị trí địa lý mà bị ảnh hưởng, A/B Test hoặc quảng cáo trên trang.

Testmysite là gì?

TestMySite là công cụ đo lường tốc độ tải trang thực tế trên điện thoại di động, đo lường chính ở tốc độ 4G hoặc 3G cho các nước chưa phổ biến 4G, hoặc đối tượng sử dụng trang web đó chỉ sử dụng mạng 3G. TestMySite cung cấp báo cáo dành riêng cho người làm tiếp thị (marketing) hoặc lập trình viên là khác nhau. Với mục đích cho người đọc báo cáo dễ hiểu, chứ các nguyên tắc cơ bản chủ yếu thì vẫn như phần trên mình đã trình bày.

Ngoài thông số tốc độ tải trang cho toàn site (thống kê theo tháng), TestMySite có 3 chức năng chủ yếu như sau:

• Cho phép kiểm tra tốc độ tải trang ở kết nối 4G từng đường dẫn URL riêng biệt, tối đa 10 đường dẫn
• So sánh số liệu với trang web đối thủ
• Cung cấp số liệu tính toán ROI

Nên ưu tiên Testmysitehay Pagespeed Insights?

Về cơ bản thì 2 công cụ này cùng phản ánh kết quả của pagespeed. Mặc dù thông số có khác nhau, nhưng mình đánh giá TestMySite tốt hơn ở góc độ thống kê hàng tháng theo thời gian (giây). Bạn sẽ biết được site của mình trong tháng trước đó nhanh hơn hay chậm hơn. Còn Pagespeed Insights cũng có thống kê nhưng là có đạt chuẩn của “Core web vital” hay không.

Theo chiến lược “Mobile First” mà hầu hết mọi người đang hướng tới, thì TestMySite đánh đúng trọng tâm hơn. Còn Pagespeed Insights không có kết quả toàn site, nên cũng ít ý nghĩa hơn. Hơn nữa thì kết quả của Pagespeed Insights cũng trùng lắp với Lighthouse, nên nếu bạn đã cải thiện theo Lighthouse thì kết quả tối ưu tốc độ cũng sẽ được phản ánh tốt trên Pagespeed Insights. Và cũng phản ánh lên TestMySite.

Fullstack Station Tips

• Bóp băng thông: thông số 4G dùng để test của Google là 1,638.4 Kbps, với độ trễ là 150 ms. Vì vậy khi bạn test phiên bản mobile, phải dùng thông số này thì mới chính xác. Mặc dù tốc độ xử lý của CPU vẫn mạnh hơn nhiều so với Moto G4.
• Tốc độ của máy chủ, dung lượng từng tập tin và số lượng request là rất quan trọng. Thông số tối ưu là dưới 100ms cho trang (HTML) với dung lượng ~50kB, và ~35 requests cho toàn bộ hình ảnh, css, js. Mỗi tập tin đều dưới 50kB là lý tưởng, dưới 100kB là chấp nhận được.

• Đừng quá phụ thuộc vào bất kỳ 1 công cụ nào để đánh giá hiệu suất website. Luôn sử dụng các công cụ kiểm tra tốc độ khác nhau như Pingdom hay GTMetrix để kiếm tra chúng ta áp dụng có hiệu quả hay không.
• Điểm số tầm 75~ cho mobile và 85~ cho desktop là một kết quả khá tốt. Nếu bạn tập trung vào điểm số quá nhiều, chỉ để lên 90~ mà bỏ qua các cơ hội phát triển các chức năng khác cho dịch vụ thì không nên cho lắm. Nếu có nhiều nhân lực thì triển khai, không phải suy nghĩ.

Bài viết này đã sơ lược hầu hết các quy tắc cần thiết để tối ưu tốc độ tải trang pagespeed. Các bài viết sau mình sẽ trình bày chi tiết và các thủ thuật để cải thiện. Các bạn nhớ đăng ký theo dõi để xem bài mới sớm nhất nhé.

The post Tối ưu tốc độ tải trang: “mili giây tạo triệu đô $$$” appeared first on Fullstack Station.

Cấu trúc thư mục

Giả sử chúng ta có cấu trúc thư mục như sau:

.
├── Dockerfile
├── app
│   ├── db.py
│   └── main.py
├── requirements.txt
├── test.db #RISKY, đừng bao giờ lưu trữ dữ liệu trong container.

Với nội dung của Dockerfile như sau:

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.7

COPY requirements.txt /app/requirements.txt
WORKDIR /app
RUN pip install -r requirements.txt
COPY ./app /app

Ở đây, bạn chú ý file requirements.txt được tách riêng COPY trước, mục đích là để Docker không cần phải build lại layer này nếu không có gì thay đổi. Như vậy, Docker sẽ tận dụng lại cache của các layer cũ và việc build sẽ nhanh hơn rất nhiều. (Tham khảo tại đây). File requirements.txt sẽ chứa các package được sử dụng trong api.

Thực hiện build image

Phần này đơn giản thôi, sau khi đã có Dockerfile rồi, thì tiến hành build image với lệnh:

 docker build -t test-fastapi-image .

Việc build khá nhanh, tuy nhiên phần image gốc nặng gần 1Gb nên nếu mạng chậm bạn phải chờ 1 chút.

Tiến hành thực thi

Sau khi build xong nếu không có vấn đề gì thì chạy thử xem nhé:

docker run -d --name my-fastapi-container -p 8000:80 test-fastapi-image

Ở đây mình map port 8000 (máy chủ) vào port 80 (của container), sau đó máy chủ sẽ dùng nginx như 1 proxy chuyển request vào container.

Với lệnh trên thành công, chúng ta truy cập tại địa chỉ IP của “máy chủ” ví dụ 127.0.0.1:8000 sẽ có kết quả của API như việc chạy ở bước development uvicorn main:app --reload, hoặc các tài liệu tương tác trực quan như http://127.0.0.1:8000/docs hay http://127.0.0.1:8000/redocs . Điểm quan trọng là chúng ta đã build thành công docker cho api, việc tiếp theo sẽ đưa image lên môi trường production. Việc đưa image lên production có nhiều cách và sẽ được nói trong một bài viết khác.

Fullstack Station Tips

• Phần docker cho FastAPI được làm rất tốt, nên việc deploy sau này sẽ rất dễ dàng, chỉ đơn giản là lặp lại các thao tác build, deploy mà không cần phải quan tâm các phần khác như sử dụng hypercorn hay unicorn, bao nhiêu workers…
• Nhiều bạn hay sử dụng pip freeze > requirements.txt để tạo file “requirements.txt”, đây là cách không đúng vì các package dùng cho quá trình development khác với production, không dùng chung. Thường sẽ có base.txt cho các package chung và các môi trường khác nhau như local.txt, production.txt.

The post FastAPI: triển khai bằng Docker appeared first on Fullstack Station.

Trước khi tìm hiểu PHP 8, nếu bạn chưa biết PHP 7 có gì mới, thì hãy xem bài này.

Đế chế PHP

PHP là ngôn ngữ lập trình của năm 2004 (theo Tiobe Index), đã trải qua 25 năm (từ 1994) phát triển, chỉ duy nhất 1 lần đạt danh hiệu “Ngôn ngữ lập trình của năm” của Tiobe (tuổi đời PHP>Tiobe), tuy nhiên độ phủ cao với việc luôn nằm trong top 10 ngôn ngữ lập trình được sử dụng và những thành tựu mà PHP mang lại cho lập trình web thật to lớn với 79% website sử dụng PHP (theo w3techs). PHP là một đế chế hùng mạnh!

Những công ty lớn sử dụng PHP

Các công ty Google, Yahoo, Facebook, Wikipedia, WordPress đều sử dụng PHP, và đặc biệt nhất có lẽ là Facebook mạng xã hội lớn nhất hiện nay, sử dụng PHP ngay trong những ngày đầu và đã tạo ra ngôn ngữ Hack tương thích với PHP, và vẫn còn lượng lớn mã code sử dụng PHP cho đến nay.

Liệu PHP có biến mất?

PHP sẽ tồn tại ít nhất 10 năm nữa, mình tin là như vậy. Phải nói PHP giúp chúng ta tạo ra web rất nhanh và cần ít kinh nghiệm, cũng như các điều kiện để vận hành đơn giản nhất. Đó là lý do vì sao các công ty lớn ở trên vẫn còn sử dụng PHP, và khoảng 79% website đang sử dụng PHP, vậy tại sao phải lo PHP sẽ biến mất?

Dù công nghệ nào ra đời, công ty nào ra đời họ cũng cần có 1 website, là bộ mặt, là nơi kết nối mọi người. Hãy nhớ: mạng xã hội chỉ là nơi chia sẽ thông tin tóm lược, website là nơi chứa thông tin chi tiết. Còn website, còn PHP!

So sánh PHP với Node và Python, thì hiện tại Python đang khá mạnh. Tuy nhiên, PHP vẫn hơn Nodejs, và chỉ thua Python không nhiều lắm.

Đế chế PHP sẽ còn tồn tại lâu lắm, nếu bạn còn lập trình PHP thì hãy xem thêm bài “Những lỗi lập trình viên PHP hay mắc phải“

PHP 8 sẽ có Just In Time (JIT)

Just In Time (JIT) là gì

“JIT” viết tắt cho Just In Time. JIT là một kĩ thuật giúp hệ thống tối ưu lại những đoạn code.

Jit compiler chạy sau khi chương trình được khởi tạo và biên dịch lại những đoạn code (thường là bytecode hoặc là một dạng tương tự để các Virtual Machine có thể hiểu được) giúp cho ứng dụng chạy nhanh hơn. Jit có thể truy xuất vào các câu truy xuất tại thời điểm “Runtime” trong khi các compiler khác không thể và từ đó chọn lọc được ra những function mà thường xuyên được sử dụng từ đó có thể tối ưu giúp chương trình thực thi hiệu quả và nhanh hơn.

Zeev, một trong những core developer của PHP đã có một demo khá là trực quan cho những gì JIT có thể mang lại.

Tại sao PHP cần JIT

PHP đã phát triển hết mức có thể

Đã có rất nhiều cải tiến cho PHP từ phiên bản 7.0 như tối ưu HashTable (một kiến trúc lưu trữ data trong php), đặc biệt tối ưu Zend VM cho opcodes và nhiều chức năng khác (xem thêm bài tìm hiểu PHP 7). Sau tất cả những cải tiến đó, PHP đã đến cực đại để có thể phát triển thêm. Vì vậy PHP 8 với JIT có thể sẽ là người thay đổi cuộc chơi.

PHP dành cho những tác vụ khác

Nói tới PHP, ta nghĩ ngay tới một ngôn ngữ dành cho phát triển Web. Tuy nhiên, những tác vụ liên quan tới việc tính toán cần sử dụng CPU ở cường độ cao thì ít khi được sử dụng. Với việc đưa vào hỗ trợ JIT, PHP có thể được sử dụng cho nhiều mục đích khác không phải web, có thể tập trung vào CPU nơi mà lợi ích về hiệu năng là rất quan trọng.

Phát triển các tính năng khác cho PHP

Với việc sử dụng JIT, đội ngũ phát triển có thể sử dụng chính PHP để tạo ra các tính năng mới thay vì sử dụng ngôn ngữ C mà không có sự khác biệt quá nhiều về hiệu năng. Điều này giúp cho giảm thiểu sự ảnh hưởng trong việc quản lý bộ nhớ, tràn bộ nhớ và các vấn đề liên quan tương tự khi phát triển dựa trên C.

Cần làm gì để trở thành lập trình viên PHP giỏi?

Vì điều kiện để trở thành lập trình viên PHP tương đối thấp và khả năng triển khai website bằng PHP đơn giản nên thường thì lập trình viên PHP là lập trình viên tồi, vì tính mì ăn liền, đơn giản, uyển chuyển của ngôn ngữ. Nhiều lập trình viên rất ghét PHP, đặc biệt là các bạn từ các ngôn ngữ C, C++, Java, Rust, Go (static typed), hãy “kệ người ta”, đừng bắt con cá leo cây, nó sẽ tưởng mình ngu cả đời, đây là website là đất diễn của PHP. Sau đây là một số tiêu chí và định hướng để trở thành lập trình viên và lập trình viên PHP giỏi mà mình tổng hợp muốn chia sẽ với các bạn.

Kỹ năng lập trình

Kỹ năng lập trình bao gồm thuật toán, cấu trúc và dữ liệu, kiến thức về hệ thống, lập trình hướng đối tượng OOP, kỹ thuật tối ưu, kỹ thuật viết code sạch, sáng sủa, khả năng viết test, unit test. Những kỹ năng này thì lập trình viên cho mảng nào cũng cần (Xem thêm Các chiêu thức trong lập trình).

Cao hơn thì quản lý máy chủ, CI/CD; quản lý, sử dụng vận hành docker, ví dụ sử dụng docker trong môi trường phát triển. Nghiên cứu về bảo mật (xem Công cụ tìm lỗi bảo mật)

Hiểu rõ ngôn ngữ PHP

Bạn cần nắm vững các hàm, cách thức tối ưu trong PHP, hạn chế các lỗi mà lập trình viên PHP hay mắc phải, ví dụ Các lỗi khi làm việc với mysql lập trình viên PHP, hay phân biệt isset(), is_null(), empty().

Phải sử dụng các công cụ như PHPMD, PHPCS để viết code hiệu quả, tăng cường tính dễ đọc, dễ bảo trì, hiệu quả thực thi cho code.

Sử dụng framework hiệu quả

Có rất nhiều PHP Framework như: CodeIgniter, Zend, Symfony, Laravel, Yii,.. cao hơn là CMS như WordPress, Joomla, Drupal… Sử dụng framework hay CMS nào là cái duyên của mỗi người, ví dụ bạn thích mà công ty đang không sử dụng thì cũng chịu. Ví dụ mình chưa bao giờ sử dụng Laravel, hơi sốc khi biết Laravel nắm khoảng ~40% thị phần PHP Framework nhưng tới giờ vẫn chưa có dự án nào dùng Laravel.

Việc biết, sử dụng nhiều framework là không tốt, vì kiến thức bị phân mảnh. Kiến thức từ các framework thực sự khá khác biệt nên khó tận dụng được kinh nghiệm từ framework trước. Bạn cần xác định rõ con đường mình muốn đi ra sao, nếu muốn đi làm việc tại quốc gia nào, thì tìm hiểu framework thịnh hành tại quốc gia đó. Tốt nhất là đừng chạy theo framework, đừng nghe ai đó nói Framework này tốt, cái kia tốt. Tập trung 1 cái thôi, rồi học các kỹ năng lập trình thêm.

Fullstack Station Tip

Có nên học PHP không?

Mình có dự án đầu tiên, công việc đầu tiên và đi làm việc ở Nhật nhờ ngôn ngữ lập trình PHP, tất nhiên đó là câu chuyện của 10 năm trước, nhưng với sự phát triển khá mạnh mẽ của WordPress, công việc bằng ngôn ngữ lập trình PHP sẽ rất nhiều. Ít nhất là hiện tại ở Nhật Bản, PHP vẫn được ưu chuộng và khá dễ kiếm việc.

Vì vậy câu trả lời là có.

Ngoài ra, kế hoạch ra đời PHP 8 minh chứng cho sự phát triển không dừng lại của PHP. Mặc dù trong lĩnh vực không phải là web, thì PHP không thực sự mạnh, nhưng PHP 8 có thể sẽ thay đổi cuộc chơi. PHP 7 được ra mắt đã giúp PHP lấy điểm trở lại trong lĩnh vực lập trình web với tốc độ cải thiện hơn 50% so với 5. PHP 8 sẽ còn nhanh hơn PHP 7, vậy còn gì tuyệt hơn?

Ngày nay, sự phát triển của công nghệ quá nhanh chóng, trào lưu AI và Blockchain nở rộ, việc học PHP có thể được xem như lỗi thời. Nhưng mình nghĩ công nghệ gì cũng cần phải no bụng đã, PHP là lựa chọn không hề tệ để dễ dàng kiếm việc. Việc làm trong AI và Blockchain không hề đơn giản, có thể lương cao, nhưng cạnh tranh cũng rất khốc liệt. Mài dũa kỹ năng lập trình với PHP, rồi học tiếp thêm các ngôn ngữ khác, công nghệ khác tuỳ theo nhu cầu và thời điểm.

Tham khảo

https://react-etc.net/entry/php-8-0-0-release-date-and-jit-status

The post PHP 8: đợi chờ là hạnh phúc? appeared first on Fullstack Station.

Tại sao nên xài docker

Thú thật, mình cũng từng như bạn, không chịu rời bỏ cái môi trường lập trình đang chạy ngon lành trên máy của mình, cho đến một ngày…Đơn giản là đời làm lập trình có nhiều dự án, mỗi dự án yêu cầu môi trường, cấu hình khác nhau, rồi môi trường lập trình trên máy cũng khác. Ví dụ, trên máy dùng VSCode dùng phần rộng PHP đòi phải PHP 7, nhưng dự án A chỉ chạy trên 5.6, dự án B chỉ chạy trên PHP 7.2. Ngoài ra còn có nhiều tổ hợp công nghệ như kết hợp với Mysql hay Postgres, Elasticsearch…không phải mọi thứ đều cài lên máy chạy cùng lúc rất cực để quản lý và không hiệu quả.

Ngoài ra, một số thư viện cài đặt thỉnh thoảng có trục trặc với máy vì phải build lại, việc các thư viện chỉ chạy trên một vài version tương thích thường xuyên xảy ra. Điều này khiến cho bạn mất khá nhiều thời gian cho việc quản lý môi trường lập trình của mình, đây là điều nên tránh, hãy tập trung năng lượng cho công việc chính, còn môi trường phát triển hãy để docker lo.

Giới thiệu Lando

Lando là một nền tảng miễn phí, mã nguồn mở, đa nền tảng dựa trên docker dành cho lập trình viên, cải thiện môi trường làm việc bằng cách gom tổ hợp công nghệ bạn sử dụng thành 1 file cấu hình, thiết lập môi trường lập trình dễ dàng hơn bao giờ hết.

Homepage: https://devwithlando.io

Nói một cách ngắn gọn, nếu bạn biết WAMP hoặc MAMP, thì Lando là ông nội của 2 thằng này. Ví dụ lập trình

Các tổ hợp, ngôn ngữ đã được hỗ trợ

Ngôn ngữ

Các ngôn ngữ sau đã được hỗ trợ:

• dotnet
• go
• node
• php
• python
• ruby

Tổ hợp

Các tổ hợp đã được cấu hình sẵn:

• Backdrop
• Drupal 6
• Drupal 7
• Drupal 8
• Joomla
• Laravel
• MEAN
• LAMP
• LEMP
• Pantheon
• WordPress

Các dịch vụ

Các dịch vụ sau cũng được hỗ trợ:

• apache
• elasticsearch
• mailhog
• mariadb
• memcached
• mongo
• mssql
• mysql
• nginx
• phpmyadmin
• postgres
• redis
• solr
• tomcat
• varnish

Tại sao nên dùng Lando

Nếu bạn tìm thấy một trong các công nghệ, dịch vụ, ngôn ngữ lập trình được hỗ trợ và liệt kê ở trên “quen thuộc” với công việc hàng ngày của mình, thì bạn đã có lý do sử dụng Lando.

Như ví dụ mình có nói ở trên, việc có nhiều dự án quả thật là rất phức tạp để quản lý môi trường lập trình. Mình đảm nhiệm các dự án trong công ty từ nhỏ đến lớn với các ngôn ngữ như Go, Python, Nodejs, PHP thì Go và Python là ít gặp trục trặc nhưng PHP thì nhiều, và nhiều nhất là Nodejs vì Nodejs ra phiên bản mới liên tục. Dự án cũ 2,3 năm trước thì xài công nghệ, phiên bản cũ tới lúc mình cập nhật máy và thư viện liên quan thì khi quay lại dự án cũ nó không chạy :((. Và mất thời gian chỉnh sửa môi trường làm việc như vậy vài lần, đến mức độ mình thấy sợ. Từ khi có Lando, khi muốn chạy dự án nào, chỉ cần: `lando start` là xong.

Các tính năng nổi bật của Lando:

• Sao chép tương tự môi trường production cho máy bạn
• Quy chuẩn hoá mọi trường lập trình của đội ngũ đa nền tảng OSX, Window, Linux
• Tuỳ chỉnh hoặc mở rộng công cụ, cấu hình triển khai
• Chạy CI test trên máy của bạn.
• Sử dụng môi trường duy nhất cho tất cả các dự án
• Tích hợp với nhà cung cấp dịch vụ hosting như Pantheon

Mặc dù bạn có thể nhận ra là Docker Compose cũng có tính năng tương tự, tuy nhiên có một vài sự khác biệt:

• Lando là một lớp trừu tượng đã làm giảm bớt tính phức tạp khi cấu hình các container bằng cách sử dụng “công thức” (recipes) cho một số stack phổ biến.
• Lando cung cấp nhiều phương thức giúp lập trình viên chạy những dòng lệnh phức tạp, các bước build, … và tự động hoá các dịch vụ mà không cần tinh chỉnh Dockerfiles
• Lando quản lý một số tác vụ cài đặt phức tạp được yêu cầu để có một Docker Composer tốt như proxy, nice urls, cross-application netwroking.
• Ngoài ra, bạn vẫn có thể tuỳ biến dễ dàng Docker Compose.

Nói 1 cách khác, Lando đã giúp đơn giản hoá Docker Compose cho một số tác vụ, stack phổ biến. Chỉ cần 1 câu lệnh, các dịch vụ đi kèm đều được khởi tạo, mất chưa đầy 2 phút là bạn có thể chạy được stack.

Bắt tay vào thực hành Lando

Mình không muốn nói phần này nhiều, chỉ cần sau khi bạn cài đặt Docker, Lando thì bạn chỉ mất 5 phút để tạo 1 dự án WordPress, Laravel, Drupal, Joomla hay LAMP, LEMP bất kỳ chỉ việc sử dụng công thức đã liệt kê ở trên.

5 phút đơn giản chỉ là tạo cái file .lando.yml, đây là file mẫu dùng cho WordPress (dùng với Bedrock/Sage sẽ được giới thiệu ở bài khác)

name: seikeidenron
recipe: wordpress
proxy:                
  nginx:              # Tuỳ chọn: nếu bạn bỏ qua cấu hình này thì Lando sẽ chạy ở seikeidenron.lndo.site
    - seikeidenron.localhost
  theme:              # Tuỳ chọn: ở đây mình phát triển thêm theme của wordpress thì sẽ cần tới node
    - localhost:3000
config:
  php: '7.2'
  via: nginx
  webroot: web
  database: mariadb
  xdebug: true

# Đoạn này cần để thiết lập node
services:
  theme:
    type: node
    services:
      ports:
        - 3000:3000
tooling:
  yarn:
    service: theme

Xong file trên thì chỉ cần lando start là mọi thứ chạy, quá nhanh quá nguy hiểm.

Fullstack Station Tips

Các công thức có sẵn đa phần đều có phần database riêng lẻ, tuy nhiên nếu các dự án của bạn đều sử dụng mysql chẳng hạn, thì hãy sử dụng database server của máy bạn, chứ không phải database server của docker. Như vậy thì việc sử dụng Lando sẽ trở nên nhanh chóng hơn, nhất là đối với các dự án đang giai đoạn lập trình. Ở phần kết nối db thì thay vì bạn dùng localhost thì hãy đổi thành host.docker.internal, đây chính là máy host, máy chính của bạn.

The post Docker thực chiến: môi trường phát triển appeared first on Fullstack Station.

Progressive Web App – PWA là tổ hợp đặc tính kỹ thuật để phát triển ứng dụng web cấp tiến/hiện đại do kỹ sư của Google phát triển từ 2015, sử dụng các tính năng tiên tiến của web để xây dựng ứng dụng web giống với ứng dụng di động mà ứng dụng web thường không làm được: ví dụ gởi thông báo (push notification) mà không cần mở trình duyệt. Progressive ở đây còn được hiểu là lũy tiến (không ngừng phát triển) khi người sử dụng ứng dụng web đó càng lâu theo thời gian, thì ứng dụng web đó càng trở nên mạnh mẽ hơn.

PWA giúp tải trang web một cách nhanh chóng, thậm chí trên mạng chậm không ổn định (3G), gửi thông báo (push notification), có thể cài đặt biểu tượng lên màn hình điện thoại như một biểu tượng ứng dụng di động, có thể hoạt động ngoại tuyến (offline/không phụ thuộc mạng internet), và có thể chạy được trên mọi trình duyệt.

Đặc tính của PWA

Một trang web được gọi là PWA khi thỏa mãn các điều kiện sau đây:

• Tiến bộ (Progressive) – hoạt động đối với mọi người dùng mà không quan tâm trình duyệt được sử dụng (nói ngắn gọn là chạy được trên mọi trình duyệt) vì nó được xây dựng với nguyên lý cốt lõi là tiến bộ tăng cường.
• Responsive – phù hợp với bất kỳ kích cỡ màn hình: máy tính để bàn, điện thoại di động, máy tính bảng hay bất cứ thiết bị nào trong trong lai – có sử dụng trình duyệt web
• Khả năng kết nối độc lập (Connectivity independent) – khả năng kết nối được tăng cường bởi service-workder giúp ứng dụng web có thể hoạt động offline hoặc trên mạng chất lượng thấp.
• App-like – như một ứng dụng di động để người dùng tương tác bao gồm giao diện, tương tác và trình đơn điều hướng (người dùng sử dụng các trình đơn này để sử dụng thay cho các trình đơn điều hướng (Back/Forward) của trình duyệt)
• Làm mới (Fresh) – luôn luôn cập nhật nhờ service-worker
• An toàn (Safe) – sử dụng HTTPS để ngăn chặn snooping và đảm bảo nội dung đã không bị giả mạo.
• Dễ dàng phát hiện (Discoverable) –  là nhận biết như một “ứng dụng” nhờ W3C đăng ký kê khai và dịch vụ, cho phép công cụ tìm kiếm dễ dàng
• Re-engageable – kết nối người dùng dễ dàng hơn với tính năng.
• Installable – cho phép người dùng đánh dấu ứng dụng web lên trên màn hình điện thoại để dễ dàng truy cập lại sau đó, bỏ qua sự rắc rối của việc cài đặt ứng dụng.
• Linkable – Dễ dàng chia sẻ thông qua URL, ứng dụng di động không thể làm được điều này.

PWA đối với tương lai của lập trình web và ứng dụng di động

Có thống kê cho rằng, ứng dụng di động mất đi 20% người sử dụng tiềm năng khi phải mất nhiều thao tác (tìm kiếm trên chợ ứng dụng, cài đặt, mở ứng dụng) mới có thể dùng được thứ họ cần. Đối với PWA, chỉ cần mở đường dẫn ở trình duyệt là có thể sử dụng như 1 ứng dụng bình thường. Khi người dùng mở lại đường dẫn cũ (hay vào lại website) – “bằng trình duyệt“, trang web sẽ đề nghị người dùng cài đặt 1 biểu tượng lên màn hình điện thoại, và kể từ lúc này người dùng sử dụng biểu tượng ở màn hình điện thoại để mở “ứng dụng” mà “không cần trình duyệt“, nghĩa là sẽ không thấy khung chứa đường dẫn, không có bookmark, các nút điều hướng…, tất cả chỉ là nội dung/giao diện của ứng dụng web “phủ toàn bộ màn hình điện thoại”, như hình dưới đây:

PWA của Financial Times từ biểu tượng trên màn hình điện thoại

Hình bên trái ứng dụng PWA của Financial Times mình mở từ biểu tượng ở màn hình điện thoại, hình bên phải là mở bằng trình duyệt sẽ bao gồm những nút bấm có sẵn của trình duyệt. Như vậy, từ đây bạn có thể sử dụng như một ứng dụng trên điện thoại một cách bình thường mà không hề có sự khác biệt nào so với một ứng dụng native, vẫn có thể gởi thông báo (push notification), lưu trữ (ví dụ tin tức bạn quan tâm, hoặc hình ảnh, video…).

PWA kết hợp những ưu điểm của web và ứng dụng di động để tạo ra web thế hệ mới mạnh mẽ, đặc biệt nhất là đối với những trang web cung cấp thông tin. Mình sử dụng thường xuyên các ứng dụng sau để đọc tin: Thanh Niên, Tuổi Trẻ, Dân Trí, VNExpress, trong các ứng dụng này thì VNExpress có thao tác mượt và giao diện tốt nhất, sau đó là ứng dụng của báo Tuổi Trẻ, còn ứng dụng của báo Thanh Niên thì mình không thể xem được nội dung bài viết – có lẽ bị một đoạn mã quảng cáo nào đó cấm truy cập từ nước ngoài, báo Dân Trí thì giao diện không được chuyên nghiệp, bắt mắt cho lắm…và điều mình muốn nói ở đây là họ đã sử dụng một nguồn lực có thể nói là lớn để xây dựng ứng dụng di động (mình theo dõi báo Thanh Niên từ lâu và thấy không dưới 3 lần thay đổi/cập nhật lớn ứng dụng – nhưng tác dụng thì không cảm thấy tăng mấy), và theo mình là lãng phí hơn so với việc xây dựng ứng dụng web PWA. Hầu hết các chức năng của HTML5 hiện nay, đều đáp ứng các chức năng mức cần thiết cho một ứng dụng trên điện thoại di động, do vậy việc xây dựng 1 ứng dụng di động là cần xem xét kỹ.

Mình từng suy đoán “React Native là tương lai của lập trình ứng dụng di động“, nhưng với sự mạnh mẽ của PWA có thể sẽ chiếm 1 thị phần không nhỏ trong thời gian tới trong lĩnh vực lập trình ứng dụng di động, mặc dù PWA vẫn có một số yếu điểm khi so với ứng dụng native:

• Tài nguyên trong ứng dụng di động được đóng gói sẵn, do vậy sẽ ít tốn thời gian hơn với PWA, nên sẽ chạy nhanh hơn
• Thiếu các chức năng đặc trưng của thiết bị như NFC, Bluetooth, Gia tốc kế, con quay hồi chuyển…
• Không được phép truy cập danh bạ, mở khóa màn hình điện thoại…

Các ông lớn trình duyệt web, họ nghĩ gì?

Đối với Safari/iOS thì hạn chế còn nhiều hơn (thanks to whatwebcando.today):

Tuy nhiên, Apple cũng đang suy nghĩ về kế hoạch để có thể đưa Service Worker vào lõi của trình duyệt Safari, nhưng như bạn có thể thấy với PWA của Financial Times , trên iOS vẫn sử dụng được một cách bình thường (họ không sử dụng Service Worker, họ đã sử dụng AppCache từ lâu, nên mình nghĩ họ đang tiếp tục sử dụng AppCache), do vậy không cần thiết phải lo là bạn sử dụng PWA có chạy được trên iOS hay không, vấn đề là phải cần nhiều nguồn lực hơn một chút – nhưng so với việc  xây dựng ứng dụng di động thì không là gì cả. Còn đối với Chrome, bạn không cần phải lo nghĩ, luôn luôn đáp ứng PWA 100%!

Đối với ứng dụng Hybrid

Đối với những tính năng mà PWA đang có, nếu bạn đang có kế hoạch xây dựng ứng dụng di động hybrid (dựa trên Cordova/Phonegap chẳng hạn) thì bạn cần dừng lại, hãy xem bạn đang xây dựng ứng dụng gì, PWA có đáp ứng được không? Về cơ bản, ứng dụng Hybrid được bao bọc bởi trình duyệt web, và được cung cấp thêm các API để tương tác với hệ điều hành mà web không làm được, nhưng thực tế là hầu hết ứng dụng sử dụng các API đó không nhiều, trong khi đó việc build ra ứng dụng hybrid thực tế cũng không hề dễ dàng, bạn phải biết build, code signing, cửa hàng ứng dụng, xây dựng hệ thống gởi thông báo (push notification)…

Cá nhân mình cho rằng, thời của ứng dụng Hybrid sắp qua, nếu muốn lập trình:

• ứng dụng di động sử dụng chung mã nguồn: PWA
• ứng dụng di động Native chủ yếu là javascript: React Native (Xem thêm: Javascript làm được gì, 30 ngày ví dụ thực tế của React Native)
• ứng dụng phức tạp: thuần native (Swift/iOS, Java/Android, C#(Xamarin)/Window)

Fullstack Station Tips

Với những tính năng mạnh mẽ và tiện lợi mà PWA mang lại, cùng với sự hỗ trợ tích cực từ Google, cũng như động thái đáng ghi nhận từ Apple sức mạnh của Trình duyệt web ngày càng tăng, thì PWA sẽ mang lại tương lai tươi sáng cho những trang web cung cấp thông tin lớn, và đó chính là cơ hội cho lập trình viên web biết nắm bắt cơ hội này. Mình tin chắc rằng, khi bạn nắm được những kiến thức, kinh nghiệm mà PWA yêu cầu, thì sẽ có cơ hội để gia nhập những công ty lớn, vì chỉ họ mới có nhu cầu, nguồn lực để làm ứng dụng theo PWA được mà thôi.

Tham khảo

https://medium.com/dev-channel/why-progressive-web-apps-vs-native-is-the-wrong-question-to-ask-fb8555addcbb

https://ada.is/blog/2016/06/01/yet-another-progressive-webapp-post/

https://www.smashingmagazine.com/2016/08/a-beginners-guide-to-progressive-web-apps/

The post Progressive Web App (PWA) ảnh hưởng đến tương lai ngành lập trình web như thế nào appeared first on Fullstack Station.