Khái niệm Serverless AI

Serverless là gì

Nếu bạn là người mới về Serverless thì có thể đọc thêm bài Serverless là gì để hiểu rõ thêm. Nói đơn giản, Serverless giống như môi trường thực thi một tác vụ nào đó, ví dụ như API, mà bạn chỉ cần triển khai xong là có thể sử dụng được. Bạn không cần quan tâm đến các hạ tầng, cấu hình mạng, bộ nhớ…

Điểm mạnh của Serverless là giúp cho bạn tập trung vào giải quyết vấn đề, hơn là dành thời gian cho những tác vụ không mấy vui vẻ như cập nhật hệ thống, kiểm tra khả năng lưu trữ server, kiểm tra nhật ký hệ thống (log) xem có ai tấn công không…Quan trọng hơn hết là chỉ trả tiền cho những khi mình sử dụng!

Serverless AI là gì

Serverless AI là hạ tầng máy chủ có bộ xử lý đồ họa GPU mạnh mẽ, có thể tích hợp sẵn các model AI (Llama2, Llama3, GPT3, ResNes, StableDiffusion, Whisper…)

Tại sao Serverless AI rất quan trọng cho những người nghiên cứu AI

Chi phí, chính xác là điều chúng ta quan tâm nhất đối với serverless AI. Để đầu tư một hệ thống GPU mạnh mẽ thường sẽ tốn khá nhiều chi phí ban đầu, cũng như chi phí vận hành thường xuyên. Hoặc nếu dùng cloud, bạn cũng sẽ tốn nhiều chi phí khác để vận hành, và mất thêm thời gian để quản lý. Với serverless AI, bạn có thể chỉ trả tiền cho những lúc chúng ta gọi API.

Về cơ bản thì serverless AI cũng là API được sử dụng như API để tương tác với OpenAI chẳng hạn, và OpenAI thì đã tích hợp sẵn một số model như GPT-3, GPT-4…

Một số nhà cung cấp

Cloudflare

Website: https://ai.cloudflare.com/

Danh sách các model

Text Generation @cf/meta/llama-3-8b-instruct

Text Generation @cf/mistral/mistral-7b-instruct-v0.1

Text to Image @cf/bytedance/stable-diffusion-xl-lightning

Speech Recognition @cf/openai/whisper

Image Classification @cf/microsoft/resnet-50

Text Classification @cf/huggingface/distilbert-sst-2-int8

Text Embedding @cf/baai/bge-base-en-v1.5

Translation @cf/meta/m2m100-1.2b

Runpods

Website: https://www.runpod.io/serverless-gpu

Fermyon

Website: https://www.fermyon.com/

Fullstack Station Tips

Với CloudFlare là nhà cung cấp hạ tầng khá nổi tiếng, với việc hỗ trợ nhiều model và cách sử dụng khá là dễ dàng. Chỉ cần tạo token key là bạn có thể thao tác được với các model trong CloudFlare. CloudFlare có gói miễn phí dùng thử khá hấp dẫn, được khởi tạo lại theo ngày, chứ không phải theo tháng. Nên với các ứng dụng đơn giản, thì hoàn toàn có thể sử dụng trên CloudFlare miễn phí

Với Serverless AI, bạn có thể nhanh chóng tìm hiểu và kiểm tra tính thực tiễn của các model. Thực nghiệm các ý tưởng để bắt xu hướng AI nhanh hơn!

The post Bắt kịp xu hướng AI với serverless AI appeared first on Fullstack Station.

Gatsby Js là gì?

Gastby JS là nền tảng dùng để xây dựng website và web app để hoạt động ở hiệu suất rất cao. Gatsby JS sử dụng React và Graphql là thành phần chính, trái tim của nền tảng. GatsbyJS được sử dụng khá rộng rãi và trở thành tên tuổi khá được chú ý hơn sau khi gọi vốn được 15 triệu đô ở vòng gọi vốn Series A.

Tương lai của web chính là mobile dựa trên Progressive Web App (PWA), vì vậy với sự phát triển của Javascript tạo ra xu hướng JAM stack (Javascript + API + Mockup), giúp cho việc phát triển website ngày càng thú vị và đơn giản với Gatsby Js.

Web tĩnh và sự khác biệt của GatsbyJs

Tại sao lại cần web tĩnh?

Trong bài giới thiệu Kỹ thuật lập trình website tĩnh thì mình có nói cũng khá đầy đủ rồi. Web tĩnh thật ra không hề xa lạ., về cơ bản bất kỳ 1 website “động” nào cũng đều có cơ chế cache. Website có lượng truy cập càng lớn thì càng phải có cache. Vậy cache ở đây được xem như là dữ liệu tĩnh tồn tại trên 1 khoảng đơn vị thời gian nhất định.

Cache thì có nhiều cấp độ, từ cơ sở dữ liệu, đến object cache, fragment cache (cache từng phần trên 1 trang), và cấp cuối thường là HTML cache (bỏ qua các lớp cache ở cấp độ hardware). Thì ở cấp cuối “HTML cache” cũng chính là thứ mà sản phẩm cuối cùng của Gatsby JS tạo ra. Và thông thường, thì thư mục cache này được đồng bộ ra các máy chủ khác nhau, giúp tốc độ truy cập nhanh vì bỏ qua hàng ngàn dòng code xử lý và thời gian thao tác I/O.

Một điều khá khôi hài nằm ở chỗ này, chúng ta thường thuê những máy chủ khá khủng để chạy các website mà phần lớn tài nguyên trong đó không phục vụ nhu cầu cuối cùng. Không những lãng phí mà hiệu quả về tốc độ cũng không được cao.

Sự khác biệt của Gatsby JS

Khác biệt so với web động có cache

Web động tạo cache ở thời điểm run-time, điều này đòi hỏi luôn luôn phải duy trì 1 hệ thống máy chủ có đầy đủ cơ sở dữ liệu, các công cụ hỗ trợ đi kèm. Trong khi Gatsby Js build xong ra tập tin tĩnh, thì máy chủ dùng để build có thể tắt đi, có thể giúp tiết kiệm chi phí rất tốt.

Khác biệt so với web tĩnh thuần túy

Web tĩnh thuần túy sẽ tạo ra tập tin HTML hoàn toàn cho mọi liên kết. Vì vậy nếu người dùng truy cập liên kết A, sau đó nhấn vào liên kết B, sẽ tải toàn bộ tập tin HTML của trang B. Gatsby cũng tạo ra HTML cho toàn bộ liên kết, tuy nhiên đồng thời tạo thêm tâp tin JSON nội dung của tất cả các trang. Sự khác biệt là với Gatsby, khi truy cập vào trang A và nhấn vào liên kết B, sẽ tải tập tin JSON nội dung mà trang B hiển thị. Và thông thường tập tin JSON và các tập tin JS liên quan này chỉ chiếm 30% so với 1 trang html hoàn chỉnh.

Ví dụ ở website reactjs.org, từ trang chủ đến trang Docs (Getting Started), thì các tài nguyên cần tải chiếm 12KB, trong khi đó nếu truy cập trực tiếp thì trang HTML này tải cần ~24KB (không tính các request phụ trợ khác), xét tương đối thì tối ưu được 50%.

Ưu và khuyết điểm của Gatsby Js

Hãy cùng Fullstack Station tìm hiểu về ưu và khuyết điểm của Gatsby Js là gì nhé.

Ưu điểm

Triển khai với chi phí thấp và dễ dàng

Việc tách biệt cơ sở dữ liệu và chỉ phục vụ hoàn toàn trên dữ liệu tĩnh giúp việc triển khai rất dễ dàng, có thể dùng bất kỳ máy chủ nào với chi phí rất thấp. Ví dụ với Amazon S3: 0.005$/1000 requests (PUT, COPY, POST, LIST) thì với website có 100k pages, thì mất 100*2 *0.005 = 1$ cho việc quản lý cập nhật mỗi ngày. Với 1 site có 100k pages thì chi phí cập nhật như vậy là quá rẻ. (2 ở đây được xem là mỗi trang có 2 tập tin HTML+JSON). Xem thêm Escalade Sports: From $5000 to $5/month in Hosting With Gatsby.

Tốc độ cao:

Là một framework để tạo web tĩnh (tương tự như Jekyll), tối ưu tốc độ và bảo mật cho website. Việc chuyển qua lại giữa các trang trong website cũng rất nhanh do tất cả các style, html và javascript sẽ được tải trong lần tải đầu tiên, khi người dùng ấn vào một bài viết trong trang web của bạn, nội dung mới sẽ được tải về dưới dạng JSON và hiển thị lên, không cần tải lại toàn bộ trang. Việc cấu hình các plugin cho phép tối ưu việc tải ảnh (progressive) và preload (tải trước nội dung của các liên kết người dùng có thể ghé qua) sẽ cho trang web có tốc độ cực cao.

Tối ưu SEO

Gatsby JS thân thiện với các công cụ tìm kiếm vì các truy cập lần đầu đối với mọi trang đều là HTML. Gatsby kết hợp cả 2 cơ chế Client rendering và Server rendering nên luôn đảm bảo SEO tốt.

Hỗ trợ Progressive Web Apps:

Thêm website của bạn vào màn hình home của di động và người dùng có thể dùng nó như một app di động luôn.

An toàn

Với toàn bộ tập tin là html và json, toàn bộ hệ thống sẽ an toàn trước các kiểu tấn công. Hơn nữa, sẽ không còn phải lo lắng gây ảnh hưởng người dùng khi cập nhật hệ thống (framework, app, database…).

Đơn giản

Thực sự bắt đầu Gatsby rất đơn giản dành cho ai đã quen với React, Graphql, Markdown… Gatsby thừa hưởng các tính năng hay của React và Graphql.

Nhược điểm

• Gatsby.js chuyên dùng để tạo website tĩnh, nên việc triển khai hệ thống bình luận và tìm kiếm thường phải dựa vào các dịch vụ bên thứ 3 như: Disqus, Algolia, Facebook…Mặc dù bạn hoàn toàn có thể tự phát triển dạng hybrid để tạo web động trong Gatsby Js.
• Hơi khó khăn để sử dụng đối với những người chưa quen React, Graphql
• Thời gian build lâu: với cái starter default mà đã build gần 2s, với những site lớn khoảng 100k ~ 1M trang, thì thời gian build tầm 10~30 phút, chưa kể thời gian triển khai và đồng bộ hoàn toàn đến tất cả các edge (các node trong CDN). Tuy nhiên vẫn có những cách khắc phục ở mục Fullstack Station Tips
• Tốn kém để chuyển đổi hệ thống hiện tại: để chuyển hệ thống sang sử dụng Gatsby JS sẽ tốn chi phí không hề nhỏ. Chúng ta cần phải cân nhắc kỹ lưỡng giữa lợi ích mà web tĩnh mang lại trong tương lai với chi phí chuyển đổi.
• Với wordpress, hay 1 nguồn nội dung khác, thì phần “hình ảnh trong bài viết” có thể không tận dụng được khả năng xử lý hình ảnh của Gatsby Js.
• Mất đi một số tính năng hay của các nền tảng khác cung cấp. Ví dụ với WordPress mình kết hợp với OneSignal, khi mỗi bài viết được xuất bản thì sẽ tự động gởi thông báo đến tất cả các người dùng đang theo dõi (subscribers).
• Triển khai cho người dùng bình thường còn phức tạp. Thật khó để sử dụng chức năng hẹn giờ xuất bản, hoặc chỉ là những cập nhật nho nhỏ.

Gatsby JS phù hợp với dự án web nào?

Dựa trên những ưu điểm của Gatsby, FS nhận thấy phù hợp với các dự án web ít thay đổi về nội dung, số lượng trang không quá lớn, tầm 10000 trang đổ lại. Các trang về tin tức có rủi ro khi cần xoá bài khẩn cấp, vì thời gian build, cache, deploy cũng không thể nhanh được. Tuy nhiên nếu có các phương án chặn link khẩn cấp từ lớp Network thì về cơ bản không vấn đề gì.

Phương thức hoạt động

Khi chạy ở mode “develop” thì bản chất Gatsby Js là một create-react-app (CRA), thừa hưởng toàn bộ tính năng của CRA như HOT RELOAD.

Sau khi build ra, thì bao gồm các file json và html, css, js, image…Chúng ta chỉ cần đưa thư mục chứa các tập tin này lên máy chủ là xong.

Một số CMS tương thích tốt với Gatsby

Đa phần các CMS đều có thể hoạt động với Gatsby thông qua API (Restful hoặc Graphql), do vậy việc sử dụng CMS nào phụ thuộc vào việc bạn sử dụng quen CMS nào nhất. Hoặc CMS nào tiện lợi nhất, hoặc là CMS bất kỳ tự phát triển. Miễn sao có API lấy nội dung là được.

Tuy nhiên, các CMS sau thì khá nổi tiếng và có plugin để lấy nội dung (từ API chuyển về dữ liệu graphql trong Gatsby)

• Netlify CMS 
• Buttercms
• Ghost
• Contentful
• WordPress
• Strapi
• Prismic

Trước khi bạn muốn sử dụng gatsby, hãy kiểm tra xem đã có plugin hỗ trợ chưa, ví dụ tìm kiếm với từ khóa “wordpress” https://www.gatsbyjs.org/plugins/?=wordpress

Fullstack Station Tips

• Gatsby tạo cho website hoạt động tốt và bền vững

The post Gatsby Js là gì appeared first on Fullstack Station.

Demo

Mình có clone thử 1 phiên bản của Fullstack Station tại đây:

https://huongdanlaptrinh.net/

Về tốc độ thì phải nói là tuyệt vời, mặc dù so sánh sẽ khập khiễng, tuy nhiên với Fullstack Station thì mình đã tối ưu rất nhiều (plugin HyperCache, Autoptimaize của WordPress, PageSpeed cho Nginx) mới có thể đạt tốc độ nhanh được. Còn với Ghost CMS thì mình không phải làm gì, mà cũng có tốc độ nhanh hơn.

Những ưu, khuyết điểm khi sử dụng Ghost làm Website / Blog

Ưu điểm

• Cài đặt dễ dàng, nhanh chóng
• Giao diện quản lý nội dung, bộ soạn thảo đơn giản, dễ sử dụng
• Hỗ trợ markdown
• Hỗ trợ lịch đăng bài viết
• Hỗ trợ SEO
• Mã nguồn mở, miễn phí
• Có công cụ quản lý Ghost CLI
• Tích hợp HTTPs miễn phí thông qua Let’s Encrypt
• Hỗ trợ API để tạo và quản lý bài viết
• Cài sẵn AMP (Accelerated Mobile Pages)
• Các bộ tích hợp phong phú, cơ bản đáp ứng đủ nhu cầu của 1 blog đơn giản, có thể tuỳ biến cao dựa vào trigger của cơ chế ITTT của Zappier (Xem thêm Huginn)
• Có thể xuất nội dung từ WordPress và nhập vào Ghost dễ dàng

Khuyết điểm

• Ít theme miễn phí
• Phần bình luận phải sử dụng tích hợp dịch vụ ngoài, khá bất tiện.
• Phần tích hợp tuy nhiều, nhưng so với WordPress thì còn thua xa, hơn nữa cứ với mổi tích hợp thì bạn phải đăng ký tài khoản của các dịch vụ ngoài, khá phiền phức. Cũng như việc dữ liệu sẽ bị phân tán, khó kiểm soát.
• Hỗ trợ tiếng Việt kém
• Khi chỉnh sửa sao giao diện phải restart lại ghost (cách khắc phục là sửa dưới máy local rồi up nguyên theme)
• Yêu cầu RAM nhiều hơn (1GB) so với WordPress (512MB)
• Mặc dù hỗ trợ xuất/nhập nội dung từ WordPress, nhưng đối với website sử dụng nhiều code như FS thì nội dung xuất ra vẫn còn nhiều lỗi. (Xem bài bị lỗi)

Chuẩn bị cài đặt Ghost CMS

Bài viết sử dụng Ubuntu 16.04 hoặc 18.10, yêu cầu máy chủ tối thiếu là 1GB RAM nếu không quá trình cài đặt có thể gặp lỗi, để khắc phục bạn sẽ phải bổ sung thêm Swap RAM bằng 4 lệnh sau:

dd if=/dev/zero of=/var/swap bs=1k count=1024k
mkswap /var/swap
swapon /var/swap
echo '/var/swap swap swap default 0 0' >> /etc/fstab

Các phần chuẩn bị cho máy chủ mới

Sau khi đăng nhập vào thì user mặc định là ubuntu, lúc này ta cần tạo thêm một user khác để cài đặt Ghost.

# Thêm user mới 
sudo adduser <user>
# Cấp quyền sudo cho user bạn mới tạo bằng lệnh sau.
sudo usermod -aG sudo <user>
# Đăng nhập vào user mới tạo bằng lệnh.
su <user>

Theo khuyến cáo của Ghost, thì bạn nên tránh tạo user có tên ghost, để tránh trùng lăp và hiểu lầm sau này.

# Đảm bảo máy chủ luôn có các thư viện mới nhất
sudo apt-get update
sudo apt-get upgrade

Trường hợp đã có nginx thì bỏ qua bước này:

# Cài đặt Nginx server trên ubuntu.
sudo apt-get install nginx
# Cho phép kết nối http/https trên firewall bằng lệnh sau
sudo ufw allow 'Nginx Full'

Trường hợp đã có Mysql thì bỏ qua bước này:

# Cài đặt MySQL
sudo apt-get install mysql-server
# Sau khi cài đặt MySQL bạn cần làm các bước sau để đặt mật khẩu cho root user.chạy lệnh
sudo mysql
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
quit
# đăng nhập lại vào user bạn đã tạo từ đầu
su <user> 

# Cài đặt NodeJS:
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bashsudo apt-get install -y nodejs
# Cài đặt Ghost CLI:
sudo npm install ghost-cli@latest -g

Sau khi cài ghost CLI thành công là bạn đã có một server đầy đủ các thành phần cần thiết để cài đặt Ghost.

Bắt đầu cài đặt Ghost CMS bằng Ghost CLI

Tạo một thư mới để chứa Ghost bằng lệnh sau (tên thư mục các bạn tự chọn ở đây mình chọn là huongdanlaptrinh.)

sudo mkdir -p /var/www/huongdanlaptrinh

Cài đặt quền sở hữu cho thư mục mới tạo

sudo chown <user> /var/www/huongdanlaptrinh

Cấp quyền cho thư mục mới tạo

sudo chmod 775 /var/www/huongdanlaptrinh

Vào thư mục mới tạocd /var/www/huongdanlaptrinh mục cài đặt ghost phải hoàn toàn trống nếu không quá trình cài Ghost sẽ không thể bắt đầu.

Tiến hành cài đặt Ghost

ghost install

Sau khi chạy lệnh “Ghost Install” quá trình cài đặt sẽ bắt đầu bằng những câu hỏi sau

• Blog URL.
  Nhập chính xác domain của bạn đã chuẩn bị sẵn, ở đây mình đãdùng domain huongdanlaptrinh.net
• MySQL hostname
  dòng này các bạn nhập localhost, hoặc địa chỉ máy chủ database.
• MySQL username
  sử dụng username mặc đinh là root, hoặc bất kỳ username của db đã tạo
• MySQL password
  mật khẩu cho user root  hoặc của username tương ứng các bạn đã tạo ở bước chuẩn bị server.
• Ghost database name
  chọn tên bất kì và ghost sẽ tự tạo database cho bạn, thường thì ghost sẽ gợi ý như huongdanlaptrinh_prod
• Set up a ghost MySQL user?
  tạo thêm user cho MySQL 
• Set up NGINX?
  nên chọn yes và Ghost sẽ tự cấu hình Nginx cho bạn, rất đơn giản.
• Set up SSL?
  Nếu bạn đầu bạn chọ URL có đường dẫn http các bạn nên bỏ qua bước này và cài đặt sau cũng được. Nếu URL có đường dẫn https các bạn chọn yes Ghost-CLI sẽ tự động cài đặt SSL từ Let’s Encrypt cho website của bạn.
• Set up systemd?
  nên chọn yes ở bước này.
• Start Ghost?
  chọn yes để chạy Ghost và website của bạn đã online.

Bậy giờ website đã online và bạn có thể bắt đầu bằng cách đăng nhập vào dashboard của Ghost bằng đường dẫn huongdanlaptrinh.net/ghost. Như vậy là phần cài đặt hoàn thành trong vòng tầm khoảng 15 phút, đây là con số ấn tượng.

Bạn sẽ cần khởi tạo 1 tài khoản quản trị, tài khoản đầu tiên mặc định là chủ sở hữu (owner)

Đây là hình ảnh phía trong phần quản lý nội dung với nội dung được xuất ra từ WordPress.

Fullstack Station Tips

Xét ở góc độ blog đơn giản, thì Ghost CMS vượt trội hơn về tốc độ, cũng như các giao diện đẹp mà không cần phải tối ưu, cấu hình nhiều. Hơn nữa, với các website có sử dụng auto ads Adsense thì layout cũng sẽ bị làm hết đẹp. Nên nếu bạn không có ý định đặt ads, thì Ghost CMS sẽ phù hợp hơn.

Ghost CMS rất phù hợp cho hướng đi làm branding cho cá nhân, tạo cảm giác chuyên nghiệp cho website. Đối với Fullstack Station thì mình không có ý định chuyển sang Ghost CMS, vì mình sử dụng được nhiều tính năng của WordPress phù hợp hơn.

The post Giới thiệu Ghost CMS appeared first on Fullstack Station.

Streamlit là công cụ được xây dựng với mục đích dành cho Machine Learning Engineer, tạo ra giao diện web như Jupyter notebook. Điểm đặc biệt khác với Jupyter notebook là Streamlit không phải hiển thị code, giúp cho bạn có thể tạo ra sản phẩm có tính hoàn thiện cao.

Trong bài “Tại sao nên học Python“, mình đã giới thiệu về ưu điểm của Python. Bài này sẽ giới thiệu thêm 1 ứng dụng khác. Về cơ bản có thể hiển thị kết quả từ python ra web, nên có thể sử dụng để tạo app bất kỳ với python.

Các tính năng cơ bản

Các tính năng thường được sử dụng ở streamlit là các biểu đồ, đồ thị, bản đồ, hình ảnh, âm thanh, video… bạn có thể xem toàn bộ tính năng ở đây: https://streamlit.io/components

Sau hơn 5 năm phát triển nền tảng Streamlit, giờ đây đã có rất nhiều tính năng được thêm vào khá đặc biệt như WebRTC, Code Editor…hoặc là các kết nối vào các nền tảng khác như SQL, CockroachDB, AirTable, Google Sheets…

Với những tính năng hiện tại

Một số tính năng hữu ích nâng cao

Cache

Cache được lưu trữ theo mỗi trạng thái của thiết lập điều này giúp cho ứng dụng không cần phải chạy lại cho từng người dùng khác nhau.

Để đảm bảo được cache hoạt động đúng, thì trong hàm sử dụng cache, không được dùng các hàm của streamlit. Các chức năng có thể nên dùng cache như: tải file, xử lý tính toán cho kết quả.

Session State

Sesstion State được sử dụng cho mục đích lưu trữ thông tin và chia sẽ dữ liệu giữa các script trong cùng 1 ứng dụng, ví dụ như thông tin đăng nhập của người dùng. Tuy nhiên, dữ liệu đó không chia sẽ giữa các tab trong cùng 1 trình duyệt và sẽ bị xóa nếu refresh lại trang.

Sesstion State dùng kiểu dữ liệu từ điển (key-value) để lưu trữ và mặc dù khá ít được sử dụng nhưng đối với các trường hợp như thông tin có tính chất phiên làm việc thì khá quan trọng. Widgets tự quản lý state riêng của mình, nên session state không liên quan đến state của widget nhé.

Streamlit Cloud

Với Streamlit Cloud thì bạn có thể triển khai ứng dụng của mình lên máy chủ của Streamlit hoàn toàn miễn phí, với điều kiện là mã nguồn lưu trữ công khai trên Github. Sau khi triển khai xong, bạn có thể tùy chọn cho mình một đường dẫn URL kiểu “xyz.streamlit.io/repo-name”

Fullstack Station Tips

Thường các công ty lớn hay sử dụng các công cụ phân tích/biểu thị dữ liệu như Redash, hay cho vào data warehouse rồi viết lại các dashboard khá mất thời gian. Như redash thì độ linh động cũng không cao cho lắm, còn tự làm dashboard thì khá là vất vả lấy yêu cầu rồi làm frontend, backend này nọ. Cuối cùng thì kết quả cũng chỉ là đưa dữ liệu lên, cho phép người dùng tìm kiếm, lọc dữ liệu theo 1 số tiêu chí nào đó. Điều này đối với streamlit thì khá phù hợp và tiện lợi khi chỉ cần 1 ngôn ngữ duy nhất là Python.

The post Streamlit: Công cụ chuyên dụng cho ứng dụng phân tích dữ liệu với Python【Cập nhật 2024】 appeared first on Fullstack Station.

Cập nhật 04/2024: Serverless AI là gì?

Serverless là gì?

Serverless là môi trường, nền tảng thực thi ứng dụng và dịch vụ mà không phải quan tâm đến máy chủ. Ứng dụng serverless không cần phải  quan tâm việc phân bổ, quản lý tài nguyên của hệ điều hành, và bỏ qua các vấn đề về nâng cấp và bảo mật. Với khái niệm là chỉ cần tập trung phát triển sản phẩm, việc còn lại về vận hành sẽ để nền tảng này đảm nhiệm.

Điều quan trọng và khác biệt nhất trong serverless là bạn chỉ trả tiền khi và chỉ những phần bạn sử dụng. Giả sử bạn có một máy chủ ảo, thì thường sẽ được tính tiền trọn gói bao gồm thời gian chạy 24/7 trong 1 tháng, CPU và RAM, băng thông, lưu trữ. Bạn vẫn sẽ phải trả tiền hàng tháng đều đặn cho dù cái máy chủ ảo đó không chạy, hoặc chỉ sử dụng 5~10% công suất thì bạn vẫn phải trả trọn gói. Hiểu một cách nôm na, thì serverless như gói cước điện thoại được tính theo block giây, gọi bao nhiêu tính tiền bấy nhiêu, còn máy chủ ảo thường thì phải trả tiền thuê bao hàng tháng dù có phải sử dụng hay không.

Ưu và nhược điểm của serverless

Ưu điểm

Xây dụng ứng dụng serverless đồng nghĩa với việc bạn chỉ tập trung vào sản phẩm cốt lõi thay vì phải lo lắng về việc quản lý và vận hành nhiều máy chủ hoặc thời gian chạy, dù trên nền tảng đám mây hay tự xây dựng hệ thống máy chủ. Sự cắt giảm công sức tổng thể này sẽ giúp cho các nhà phát triển dành thời gian và năng lượng để tập trung vào việc xây dựng các sản phẩm tuyệt vời có quy mô linh hoạt và ổn định cao.

Không cần quản lý máy chủ: Bạn sẽ không cần cung cấp hay duy trì bất kỳ máy chủ nào. Sẽ không cần phần mềm hoặc thời gian chạy để cài đặt, nâng cấp hoặc quản trị.

Thay đổi quy mô một cách linh hoạt: Ứng dụng của bạn sẽ có khả năng thay đổi quy mô tự động hoặc bằng cách điều chỉnh dung lượng thông qua việc chuyển đổi đơn vị sử dụng (ví dụ: thông lượng, bộ nhớ) thay vì với máy chủ độc lập thì sẽ phức tạp hơn.

Độ sẵn sàng cao: Ứng dụng serverless có độ sẵn sàng tích hợp và dung sai cao. Bạn sẽ không cần tạo kiến trúc cho các khả năng này do các dịch vụ chạy ứng dụng đã cung cấp cho ứng dụng theo mặc định. Ngoài ra, có để chọn trung tâm dữ liệu (một hoặc nhiều nơi) để triển khai sản phẩm một cách dễ dàng.

Tiết kiệm chi phí: chi phí gần như bằng 0 sau khi triển khai nếu bạn không có request nào (hoặc không có hành động gọi hàm), còn sử dụng bao nhiêu thì tính tiền bấy nhiêu.

Khuyết điểm

Serverless là một ý tưởng tuyệt vời nhưng không hoàn hảo, serverless có những vấn đề riêng mà bạn cũng phải suy nghĩ trước khi quyết định sử dụng:

Độ trễ: Hiệu suất có thể là một vấn đề, chính bản thân mô hình này có thể gây ra độ trễ lớn hơn trong quá trình các nguồn tài nguyên điện toán phản ứng lại với lệnh của các ứng dụng. Nếu khách hàng yêu cầu hiệu suất cao thì việc sử dụng các máy chủ ảo được phân bổ sẽ là một lựa chọn ưu việt hơn.

Gỡ lỗi (Debug): Công việc giám sát và gỡ lỗi của serverless computing cũng khá khó khăn. Việc bạn không sử dụng một nguồn tài nguyên máy chủ thống nhất làm cho cả hai hoạt động này gặp nhiều trở ngại. (Tin tốt là công cụ này sẽ dần được để cải thiện xử lý giám sát và gỡ lỗi tốt hơn trong môi trường không máy chủ.). Ngoài ra, để giám sát thường cần có 1 thêm các công cụ tương ứng nền tảng đó, chi phí có thể phát sinh thêm.

Giới hạn về bộ nhớ, thời gian: các nhà cung cấp đều giới hạn tài nguyên ở các mức cố định về bộ nhớ và thời gian thực thi (timeout). Giả sử timeout tối đa là 5 phút, nếu bạn chạy quá 5 phút, quá trình thực thi sẽ bị ngắt. Về bộ nhớ, thì sẽ thiết lập mỗi mức khác nhau tuỳ nhà cung cấp, AWS có memory là 3008MB (sẽ được cấp CPU cao tương ứng), nếu ứng dụng yêu cầu bộ nhớ lớn thì sẽ không đáp ứng được. Liên quan đến vấn đề bộ nhớ này, thì cũng cần phải lưu tâm lúc lập trình nên tối ưu tốt, để tiết kiệm chi phí.

Phụ thuộc nhà cung cấp: bạn không thể muốn chạy phiên bản của phần mềm, nền tảng chính xác như bạn muốn. Ví dụ Nodejs bạn cần 10.x nhưng nhà cung cấp chỉ hỗ trợ đến 8.x, thì bạn sẽ không sử dụng được nền tảng này. Như vậy, trước khi sử dụng, bạn cần cân nhắc các nền tảng được hỗ trợ.

Chi phí ngầm: tuỳ nhà cung cấp có tính hay không, nhưng cơ bản là sẽ phát sinh chi phí lưu trữ mã nguồn, băng thông, và chi phí về lưu trữ dữ liệu (tuỳ ứng dụng có sử dụng hay không, ví dụ DynamoDB, RDMS … thì sẽ được tính riêng). Mặc dù, tuy không nhiều nhưng nếu không tối ưu, các phần chi phí ngầm sẽ còn cao hơn cả chi phí cho serverless.

Thời gian để nghiên cứu: trước đây bạn phải học cách sử dụng, quản lý máy chủ thì giờ đây bạn cũng cần thời gian để học để quản lý các tài nguyên trong serverless, mặc dù ko phải quá khó như quản lý máy chủ, nhưng không thể không tính. Ví dụ bạn sẽ mất thời gian để hiểu về cách sử dụng CloudFormation, IAM policies, quản lý cấu hình về stage, region, memory của Functions…

Khi nào nên sử dụng serverless

Có rất nhiều trường hợp có thể ứng dụng được serverless, điểm chung là tất cả những ứng dụng không dính dáng đến điểm yếu của serverless

Websites và APIs: hoàn toàn có thể xây dựng 1 website hoặc API, website có thể là động hoặc là bán tĩnh (bán tĩnh nghĩa là nguồn gốc file là tĩnh, nhưng dùng route động). Thường thì người ta hay xây dựng Restful API với serverless, nhưng mình thích áp dụng cho Graphql hơn, vì Restful có thể trả về dữ liệu không dùng tới nhưng mình phải trả tiền băng thông (Xem thêm Graphql là gì).

Xử lý đa phương tiện: các thao tác xử lý hình ảnh, video với yêu cầu không quá cao như cắt, nén, định dạng kích thước ảnh, tạo ảnh thumbnail, hoặc chuyển đổi bộ mã của video để phù hợp với thiết bị tương ứng.

Xử lý sự kiện: có thể đóng vai trò như 1 công tắc cầu giao để thực hiện một loạt các hành động khác khi được kích hoạt tuỳ theo sự kiện.

Xử lý dữ liệu: tuỳ theo ngữ cảnh mà có thể ứng dụng như chatbot, IoT,… lý do mà serverless thích hợp với mảng này vì với chatbot hay IoT chúng ta không biết khi nào dữ liệu sẽ tới, khi nào sẽ cần xử lý dữ liệu nên chúng ta không cần phải xây dựng máy chủ luôn luôn chạy và lãng phí ở thời gian chờ.

So sánh một số nhà cung cấp hàng đầu

Hiện nay có rất nhiều nhà cung cấp dịch vụ giúp bạn tạo ra các functions sử dụng mô hình serverless một cách khá dễ dàng:

• AWS Lambda: nói về thị phần cung cấp hạ tầng cloud hiện nay thì AWS vấn đang dẫn đầu và họ cũng đưa ra dịch Lambda để người dùng có thể sử dụng và tạo ra các functions trên mô hình serverless. Khi kết hợp với các dịch vụ khác như API Gateway, S3,.. thì có thể tạo được một API server hay một hệ thống tự động xử lí khi có file upload lên S3. AWS Lambda hỗ trợ khá nhiều ngôn ngữ như Node.js, Java, C#, Python,…
• Google Cloud Function: hỗ trợ ngôn ngữ khá đa dạng (Nodejs, Go, Python, Java, PHP, .NET Core)
• Azure Functions: hàng của Microsoft, hỗ trợ C#, JavaScript, F#, Python, Batch, PHP, PowerShell

Còn nhiều nhà cung cấp khác như Kubeless, Fn,… tuy nhiên 3 ông ở trên có lẽ có thị phần lớn nhất và được quan tâm hơn. Ở dưới là chi tiết so sánh 1 số thông số giữa AWS Lambda, Google Cloud Function và Azure Function

Xây dựng hệ thống để trở thành nhà cung cấp serverless

Vì sự nổi trội về ưu điểm của serverless, nên hiện nay cũng đã có một số mã nguồn mở để xây dựng thành nền tảng cung cấp serverless

https://www.serverless.com/

OpenFaaS – Serverless Functions Made Simple

https://github.com/openfaas/faas

FireCracker – Secure and fast microVMs for serverless computing

https://github.com/firecracker-microvm/firecracker

Mình thì chỉ quan tâm tới việc xài thôi, nên không tìm hiểu được ở mảng này.

Fullstack Station Tips

Ngày nay khi mà các công cụ hỗ trợ lập trình viên tập trung vào việc xây dựng sản phẩm càng nhiều, thì rõ ràng chính lập trình viên chính là những người hưởng lợi nhất. Serverless là tương lai của những lập trình viên độc lập, khi không còn phụ thuộc vào phần cứng, máy chủ nữa.

Serverless giúp cho chúng ta không còn lo về chi phí duy trì máy chủ, không còn lo khi sản phẩm chưa có doanh thu đã phải trả tiền duy trì. Cho dù serverless là không hoàn hảo, nhưng với những ưu điểm nhiều hơn khuyết điểm và khả năng ứng dụng rộng lớn, serverless là một mảnh đất màu mỡ cho bạn phát triển.

Bạn không cần phải cân nhắc nhiều giữa các nền tảng, hãy chọn nền tảng nào bạn đã có kiến thức, hoặc được khuyến mại – giảm chi phí sử dụng. Các nhà hạ tầng luôn luôn phát triển, nên ngoại trừ về đặc điểm ngôn ngữ, các nhà cung cấp đều tương đương nhau. Hãy tập trung vào sản phẩm của mình là tốt rồi, khi có rào cản – tức là đã đạt giới hạn của sản phẩm – cũng có nghĩa là đã có thể có doanh thu, lợi nhuận thì lúc này mới nên tìm hiểu thêm để chuyển qua hệ thống cung cấp serverless khác là ổn nhất.

Quan điểm của Fullstack Station là đa năng, gọn nhẹ và không phụ thuộc, muốn trở thành lập trình viên độc lập thì càng nên học và ứng dụng serverless.

Tham khảo:

http://tech.vtijapan.co.jp/serverless-gioi-thieu-chung-chung/

https://serverless.com/learn/use-cases/

https://www.alibabacloud.com/blog/4-use-cases-of-serverless-architecture_593862

https://epsagon.com/the-best-5-use-cases-for-the-serverless-beginner/

The post Serverless là gì? Hãy sẵn sàng với serverless! appeared first on Fullstack Station.

Xu hướng của Graphql

Biểu đồ của Google Trends cho thấy Graphql đang có xu hướng tăng đều trong thời gian qua chứng tỏ Graphql đang phát triển tốt. Mặc dù Graphql không quá nóng bỏng như các frontend React/Vue/Angular với lượng người sử dụng lớn, nhưng điều đó không có nghĩa là Graphql nhận được ít sự quan tâm của mọi người, tuy rằng vẫn có những lý do:

• Graphql được Facebook giới thiệu về đặc tả, không công khai mã nguồn, điều này khiến cho cộng đồng lập trình viên dù yêu thích thì cũng phải mất  khoảng thời gian nghiên cứu và triển khai.
• Firebase được coi như là đối thủ của Graphql về công nghệ và khá mạnh mẽ, tích hợp tốt vào cả web, mobile…tuy nhiên vẫn có điểm yếu khi so với Graphql. Firebase sẽ cạnh tranh với những dịch vụ cung cấp Graphql như Graphcool hoặc Scraphold sẽ nói ở bên dưới.
• Google đã mua lại Firebase, do vậy hiện tại có lẽ không có 1 ông lớn nào đứng đằng sau những server graphql cả.
• Đã quá quen thuộc với REST có lẽ là lý do chính khiến mọi người còn cẩn trọng với công nghệ mới (thật ra cũng đã hơn 2 năm rồi, mới gì nữa :D), hơn nữa lợi ích mà graphql mang lại so với REST thì thật sự cũng chưa quá lớn.

Một số vướng mắc có thể bạn hiểu chưa đúng về Graphql

• Để sử dụng Graphql tôi phải bỏ api REST đi: không đúng, bạn hoàn toàn có thể sử dụng song song cả REST và Graphql, Graphql có thể sử dụng kết quả từ REST, tuy nhiên điều này có thể làm api bị chậm hơn. REST hay Mongodb, Mysql, MsSql, Oracle đối với Graphql chỉ là 1 nguồn dữ liệu, Graphql tổng hợp các nguồn này lại được với nhau.

Các dịch vụ Backend as a Service dành cho Graphql

Hiện tại có 2 dịch vụ cung cấp Graphql là  GraphqlCool và Scraphold, chi phí tương đối rẻ.

Mình đã từng sử dụng qua GraphqlCool và thấy dịch vụ này khá tốt (giao diện, tài liệu tốt, độ hoàn thiện cao, miễn phí các chức năng serverless – function as a service), tuy nhiên chỉ trong một thời gian ngắn thì bắt đầu bộc lộ một số nhược điểm:

• Tốc độ phản hồi hỗ trợ thấp, tất nhiên mình cũng chỉ sử dụng gói miễn phí dành cho lập trình viên nên việc hỗ trợ không được nhanh cũng là điều dễ hiểu. Bạn có thể sử dụng diễn đàn của graphcool để được hỗ trợ bởi các thành viên khác.
• Việc tích hợp các dịch vụ khác còn hạn chế, hiện tại chỉ có Algolia, Auth0, DIGITS (sắp ngưng sử dụng). Tuy nhiên bạn hoàn toàn có thể tích hợp các dịch vụ khác thông qua function serverless, ví dụ gởi tin nhắn đến Slack, hoặc gởi email thì hoàn toàn dễ dàng.
• GraphCool có tích hợp xác thực tài khoản bằng Email-Password của chính họ, chính vì vậy mà họ chiếm luôn 2 trường “name” và “email” trong type User, mình tự suy đoán chuyện này vì cứ sử dụng 2 trường đó cho type User là bị lỗi, sử dụng các tên khác hoặc sử dụng cho type khác thì được. Mình có tìm thêm tài liệu nhưng không thấy ở chỗ nào nói về chuyện này cả. Nói chung không thích chuyện này, vì 3rd-party chỉ nên là tùy chọn, sử dụng hay không là quyền của khách hàng.

GraphCool đã mã nguồn mở framework của họ tại https://github.com/graphcool/framework, mục đính chính là để triển khai lên dịch vụ Graphcool dễ dàng hơn nhưng cũng có thể tự tạo server riêng (sử dụng Docker), khi mình thử dùng bằng docker thì bị lỗi nên chưa đưa ra đánh giá được.

Hướng dẫn tạo Graphql-Server

Cheatsheet

Trước tiên, bạn hãy xem cheatsheet sau để hiểu cơ bản về các khái niệm của Graphql

Bài viết phần tiếp theo sẽ đi vào chi tiết tạo Graphql Server như thế nào

Fullstack Station Tips

Các nguồn tài nguyên dành cho graphql

https://github.com/chentsulin/awesome-graphql

https://www.howtographql.com

https://graphql.org

The post Hướng dẫn tạo Graphql Server một cách dễ dàng – Phần 1 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.

Website tĩnh là gì

Website tĩnh là web không có nội dung thay đổi liên tục trong khoảng thời gian ngắn, chỉ toàn là html, javascript và css thôi. Không hề có kết nối API nào cả, nên dĩ nhiên máy chủ không có cơ sở dữ liệu. Nếu bạn sử dụng Github thì có thể biết tới Github Page, chúng ta viết bằng markdown và được máy chủ tạo (generate) thành html, hoàn toàn là website tĩnh.

Nói đến đây, chắc hẳn bạn nào đang theo dõi blog này cũng đều nghĩ “ồ, thật đơn giản, chỉ là môn học lập trình web cơ bản”, vì chắc bạn cũng đã từng học rồi. Với lại trong thế giới phẳng phát triển nhanh chóng như hiện nay, thì web tĩnh thiệt là lạc hậu, tuy nhiên sẽ là sai lầm nếu bạn chưa hiểu rõ web tĩnh có những ưu khuyết điểm đối với website của mình như thế nào. Chúng ta thường ưu tiên phát triển website động, đơn giản là vì nó nhanh, ngay cả blog này cũng sử dụng wordpress, nhanh gọn lẹ. Tuy nhiên, đó cũng chính là lỗ hổng bảo mật mà web động mang lại. Hơn nữa, khi website đạt đến một độ lớn nhất định nào đó, nằm top 1000 của VN chẳng hạn, thì vấn đề máy chủ bắt đầu trở nên phức tạp và tốn kém. Việc triển khai cân bằng tải (mức máy chủ, cơ sở dữ liệu, tài nguyên tĩnh) trở nên khó khăn hơn rất nhiều.

Ưu và khuyết của website tĩnh

Mặc dù gọi là lạc hậu, nhưng đây vẫn là cốt lõi của web, tất cả những gì hiển thị đến người dùng là html, css, js và phim, hình ảnh. Web tĩnh cũng có ưu điểm và khuyết điểm tương ứng với nhu cầu của website. Độ bảo mật của website tỉ lệ nghịch với chức năng tương tác của người dùng, có nghĩa là càng cho người dùng tương tác với với máy chủ (POST, PUT, DELETE) thì bảo mật càng thấp, tất nhiên ngay cả phương thức GET cũng chứa đầy nguy hiểm với các tham số đi kèm. Chúng ta xem danh sách ưu khuyết điểm của kỹ thuật lập trình web tĩnh sau:

Khuyết điểm

• Khó cập nhật tức thì nội dung, giả sử có sai sót trong nội dung thì thời gian cập nhật sẽ lâu hơn so với web động
• Trang web đơn thuần 1 chiều, không có tương tác từ người dùng

Ưu điểm

• Tốc độ nhanh nhất, bạn dễ dàng áp dụng các kỹ thuật Pagespeed
• An toàn nhất, loại trừ yếu tố bị tấn công từ bên trong máy chủ, việc tấn công 1 trang web tĩnh chỉ mở duy nhất port 80, 443 là rất khó, nếu không nói là không thể (trừ trường hợp lỗi của web server như Nginx, Apache thì cũng khá là hiếm).
• Nhu cầu cấu hình máy chủ thấp, nên chi phí máy chủ thấp, cũng như các chi phí vận hành, bảo trì, sao lưu dự phòng.

Mặc dù có khuyết điểm, nhưng với ưu thế tuyệt đối về ưu điểm, và áp dụng cho phần lớn các website hiện nay. Ngoại trừ các website mang tính chất trao đổi nhiều như diễn đàn, hỏi đáp/thảo luận, thương mại điện tử, trò chơi trực tuyến, và hầu hết dịch vụ có tính chất trực tuyến. Vì đặc tính cập nhật theo thời gian, nên không thể sử dụng kỹ thuật lập trình web tĩnh được, còn các loại website khác (xem tiếp phần bên dưới) đều có thể áp dụng được.

Những loại website nào nên áp dụng

Hầu hết website đều có thể áp dụng được, đặc biệt là những loại website tương tác 1 chiều như Tin tức, Giới thiệu sản phẩm, Blog đều có thể sử dụng kỹ thuật web tĩnh để tăng cường hiệu quả. Những website thể loại diễn đàn như tinhte, webtretho nếu có ấn phẩm riêng, tức là những bài viết tuyển chọn, có biên tập tạo thành bài đọc 1 chiều cũng đều có thể sử dụng web tĩnh, không nhất thiết phải dùng web động.

Các website hiện nay đa phần đều có cho phép người dùng phản hồi, góp ý kiến, chức năng này nên tách riêng ra thành một dịch vụ riêng (nằm ở máy chủ khác độc lập), nằm ở 1 cụm máy chủ khác (xem mục Mô hình triển khai bên dưới), hoặc sử dụng các dịch ngoài như Facebook Comment, Google+, Disqus là đủ. Nói đến đây, bạn cũng có thể liên tưởng đến phân quyền người dùng trong hệ thống, có những tài nguyên chỉ cho phép đọc, hoặc tài khoản dùng để kết nối database cũng có thể chia làm 2 loại: đọc và ghi (bao gồm thêm, xóa, sửa). Nếu bạn là dân lập trình web PHP, cũng có thể xem thêm qua bài Những lỗi lập trình viên PHP hay mắc phải, trong đó có đề cập đến 1 số lỗi liên quan bảo mật để hạn chế những rủi ro không đáng.

Đối với loại website có tài khoản người dùng, có thể chia ra thành 2 loại server khác nhau, một máy chủ chứa dữ liệu chỉ đọc bao gồm tài nguyên tĩnh có thể truy xuất ở chế độ công cộng (public – http://tên-miền.com), một máy chủ chứa dữ liệu có thể thay đổi ở cơ sở dữ liệu nằm riêng (Ví dụ: http://my.tên-miền.com)

Kỹ thuật lập trình Server Side Include (SSI)

Kỹ thuật thêm (include) tài nguyên từ nhiều tập tin khác nhau không có gì mới khi bạn sử dụng ngôn ngữ lập trình động (PHP, Python, Ruby, Js hay .Net). Tuy nhiên, kỹ thuật SSI bằng webserver lại ít được biết đến, vì nó không nằm trong các chương trình giảng dạy, hoặc nếu có thì hầu như không được chú ý. Với kỹ thuật web tĩnh, máy chủ web chỉ cài đặt duy nhất web server mà không có hỗ trợ ngôn ngữ động, không PHP, không Nodejs, không Ruby, … (Mặc dù có thể cài đặt  để chạy ở chế độ cli, còn ngoài ra các request đến server đều được trả về bằng tập tin tĩnh hết, tuy nhiên mình khuyến nghị không nên cài nếu không cần thiết)

Giống nhau

• Đều là hành động thêm một tập tin khác

Khác nhau

• Ngôn ngữ lập trình động có thể include tập tin cùng loại, hoặc tập tin html
• SSI chỉ có thể include html, nhưng đặc biệt là có thể include “kết quả xử lý” từ ngôn ngữ động

Ví dụ xét đoạn mã SSI của Nginx sau:

<!--# include virtual="http://server-B/remote/body.php?argument=value" wait="yes" -->

Đoạn mã trên được sử dụng trong 1 tập tin của server A, và lấy nội dung trả về từ server B, sau đó trả về cho khách. Đây chỉ là ví dụ để bạn hình dung về việc include, chứ trong thực tế thì cách include như trên ảnh hưởng đến tốc độ của máy chủ. Nếu như hai máy chủ được nằm trong 1 cụm chung data-center thì tốc độ cũng gọi là chấp nhận.

Qua ví dụ này, bạn cũng có thể thấy rõ là cấu trúc động-tĩnh hoàn toàn có thể ăn khớp với nhau, cũng giống như quảng cáo gắn trên mỗi trang, thay đổi theo thời gian, bài viết, đối tượng…thì cũng gọi là động rồi (động ở đây sử dụng javascript để lấy dữ liệu – khác với kỹ thuật SSI nhé). Vậy nên phân chia tài nguyên, nhiệm vụ cho từng máy chủ là rất cần thiết, vừa nâng cao hiệu quả hoạt động, tốc độ tốt lại bảo mật hơn.

Sử dụng cho Nginx: http://nginx.org/en/docs/http/ngx_http_ssi_module.html

Sử dụng cho Apache: https://httpd.apache.org/docs/current/howto/ssi.html

Công cụ

Hiện tại đã có một website tập hợp tất cả các công cụ mã nguồn mở:

https://www.staticgen.com/

Bạn chỉ cần sử dụng các công cụ trên tương ứng với framework và ngôn ngữ lập trình. Công cụ đó sẽ tạo ra file tĩnh, và bạn chỉ cần thiết lập cơ chế đồng bộ tuỳ theo độ lớn của website.

Nếu hệ thống là tự lập trình ra, thì chắc là khó có công cụ đáp ứng đúng, vì vậy phải tốn công sức để tạo ra html từ hệ thống. Tuy nhiên, kỹ thuật này thì không có gì khó khăn cả, quan trọng là bạn có áp dụng hay không mà thôi.

Mô hình triển khai máy chủ

Mô hình

Mô hình này ở trên được triển khai với 6 (hoặc 8 nếu tách database) máy chủ, bao gồm:

• 2 máy chủ sử dụng HA Proxy cấu hình nhỏ gọn để cân bằng tải, không cần cũng được, tuy nhiên đối với website lớn thì rất cần thiết.
• 2 máy chủ chỉ cài đặt máy chủ web (Nginx hoặc Apache) đơn giản nhất, không cài thêm bất cứ module nào nếu bạn không thực sự nắm chắc sự cần thiết.
• 2 máy chủ chính dùng để cái hệ thống quản lý (CMS, Blog, …), được đặt trong một lớp mạng riêng với 2 máy chủ web ở trên. Và chỉ đồng bộ dữ liệu 1 chiều từ 2 máy chủ (Main System) lên máy chủ web (Static files server). Để đạt độ bảo mật an toàn thì 2 máy chủ này chỉ được phép truy cập từ mạng nội bộ.
• 2 máy chủ chứa database cài đặt cơ chế Replicator (Master-Slave hoặc cả 2), nếu tình hình tài chính eo hẹp, có thể thu gọn 2 máy chủ này vào 2 máy chủ Main System.
• Các đường kết nối màu xanh và đỏ chỉ sự tương tác 1 chiều, đây là điều rất quan trọng để giảm thiểu các con đường, phương thức tấn công. Đường màu đen được diễn tả tương tác 2 chiều, ví dụ một truy vấn (request)  [GET] từ người dùng và phản hồi (response) từ máy chủ.

Mô hình ở trên được áp dụng cho công ty cần độ bảo mật cao, tốc độ và an toàn dữ liệu. Thường được sử dụng cho các công ty tài chính cỡ vừa, với công ty thuộc lĩnh vực ngân hàng thì cần mô hình tốt hơn chút.

Tuy nhiên, các công ty dù hệ thống lớn ra sao vẫn sử dụng kỹ thuật lập trình web động, rất ít công ty nghĩ đến web tĩnh như một cách bảo mật và tối ưu tốc độ.

Mô hình rút gọn của mô hình trên chỉ còn 2 máy chủ: 1 Main System và 1 cho Static files server. Vẫn hoạt động với nguyên tắc đồng bộ 1 chiều từ Main System -> Static files server.

Nguyên tắc, cơ chế đồng bộ

• Chủ động: máy chủ Main Server xác định khi nào có nội dung mới (Xuất bản/Publish) để đồng bộ lên máy chủ Static files Server. Việc xác định này có thể dễ dàng làm được với việc ra lệnh từ Main System.
• Bị động: máy chủ Main Server sử dụng cronjob để đồng bộ lên Static files Server định kỳ theo khoảng n giây định sẵn. Thường là khoảng 10 phút, hoặc 30 phút…tất cả tuỳ theo mức độ tần suất cập nhật nội dung của nghiệp vụ.

Kết luận

Các công ty lớn thường đầu tư vào hệ thống phần cứng mà ít chú trọng đến giải pháp phần mềm, thường cho ra việc ngân sách phình lên một cách không cần thiết. Với việc áp dụng giải phép phần mềm với kỹ thuật lập trình web tĩnh được trình bày ở đây, chi phí có thể giảm đi một nửa mà tốc độ được cải thiện lên ít nhất là gấp đôi. Hơn nữa, với sức mạnh của các hệ thống Cloud mạnh như Google Cloud và Amazon thì việc phân tầng lớp mạng giữa các server trong cùng hoặc khác nhóm là rất dễ dàng.

Như vậy, lợi ích của kỹ thuật lập trình web tĩnh làm cho việc xây dựng hệ thống web trở nên an toàn hơn, tốc độ cao và tiết kiệm chi phí. Hi vọng qua bài này, sẽ có nhiều đơn vị quản lý website cũng như các bạn lập trình web có cái nhìn về kỹ thuật mang lại nhiều điều tốt như vậy.

The post Kỹ thuật lập trình web tĩnh để nâng cao bảo mật website appeared first on Fullstack Station.

Môi trường phát triển

Tại sao Docker phổ biến: Sự lên ngôi của Microservices

Rõ ràng trên thị trường về môi trường phát triển, hai cái tên Vagrant và Docker là quá quen thuộc. Tuy nhiên, với sự tiện lợi của microservice mà Docker mang lại, lợi thế cũng như thị phần của Docker ngày càng phát triển, với bằng chứng là các hội thảo về Docker diễn ra trên toàn thế giới khá thường xuyên. Trong khi đó Vagrant lại khá im hơi lặng tiếng, điều đó chứng tỏ việc cộng đồng nhanh nhạy với công nghệ đã có quyết định cho riêng mình: Docker!

Chúng ta cùng nhìn lại xu thế phát triển của công nghệ, khi mà cloud đã trở nên quá phổ biến và tất cả mọi cá nhân tổ chức hầu hết đều có sử dụng cloud, mà có cloud thì có microserices. Microservice ở đây có 2 thành phần: Một là microservice là 1 sản phẩm có tính năng rất nhỏ, ví dụ như  API có chức năng phát hiện ngôn ngữ (đưa vào 1 đoạn văn bản, sẽ trả về ngôn ngữ gì), trong một sản phẩm hoàn chỉnh sẽ rất cần những API riêng lẻ này, và chúng là microservices. Hai là microservices mà liên quan đến Docker, chính là những container nhỏ có nhiệm vụ khác nhau, chạy những dịch vụ có tính tương tác lẫn nhau: web server, database, file,… trong cùng 1 server, hoặc khác server với các dịch vụ riêng lẻ.

Do tính chất mở rộng (scale), phân tán (distributed) của sản phẩm là bất định, bạn có thể bắt đầu với chỉ một vài dịch vụ đơn giản, với con server Vultr, DigitalOcean giá 5$, sau đó tuỳ theo mức độ phát triển mà nâng cấp lên, với mình sẽ chọn nhiều server giá rẻ cho nhiều dịch vụ khác nhau, hơn là chọn 1 con cấu hình khủng và cài đặt tùm lum thứ lên đó.

Module bundler: Webpack

Quả là một sự thiếu sót khi không đề cập đến webpack trong bài viết đầu năm, với sự phát triển ngày càng mạnh mẽ của frontend framework, thì việc webpack trở nên phổ biến trong bất kỳ dự án frontend cũng là điều dễ hiểu. Với webpack bạn có thể có sự hỗ trợ lập trình nhanh chóng với HMR (Hot Module Replacement) cũng như áp dụng kỹ thuật Time Traveling giúp cho việc lập trình frontend trở nên nhanh hơn bao giờ hết

Frontend Framework

Trong nửa cuối năm 2016, cũng như dự đoán cho 2017, đây vẫn là những cái tên được nhắc đến nhiều nhất.

Angular 2

Angular 2 đã thoát khỏi kiếp Beta, và hiện tại đã có bản RC5, tuy nhiên theo mình thì đây là tốc độ khá chậm của Angular 2. Mặc dù hứa hẹn ra mắt vào giữa năm 2016, tuy nhiên hiện tại thì vẫn không có một thông tin chính thức nào có thể biết ngày ra mắt chính thức cả. Tuy nhiên, bạn vẫn đã có thể sử dụng ngay bản RC vì các API sẽ không thay đổi, điều lưu ý là có thể gặp lỗi trong quá trình phát triển.

ReactJs

ReactJs đã có một đột phá ngoạn mục thì nhảy phiên bản từ 0.14.x lên 15.x (lý do thì bạn có thể đọc ở đây). Điều quan trọng là Reactjs đã hoạt động ổn định ở mức thành phẩm khá lâu, nên việc sử dụng 0.14 hay 15 đều không ảnh hưởng đến dự án, tuy nhiên cần quan tâm đến mức tương thích của các package mà bạn sử dụng thêm vào.

Mặc dù vẫn công nhận React là phần View của một dự án frontend, tuy nhiên với những gói do cộng đồng phát triển như React Router, Redux (đây là lý do vì sao Facebook đưa React/React Native thành mã nguồn mở), thì bộ ba React/React Router/Redux đã hợp thành MVC hoàn chỉnh. Dù Redux không phải dành riêng cho React, nhưng việc Angular đã có Model, thì việc gắn thêm Redux ít nhiều cũng có ảnh hưởng.

Web Component

Web component vẫn chưa phát huy thế mạnh của mình để gây chú ý lớn đến giới lập trình frontend, phần View hiện tại đã có React ở vị thế độc tôn nên việc dự án Polymer làm mưa làm gió sẽ còn nhiều khó khăn.

Ngôn ngữ lập trình

Swift 3: bị trễ hẹn, và lần hẹn kế tiếp là cuối năm 2016

PHP7: mặc dù đã ra mắt gần được 1 năm, nhưng thật sự những hiệu ứng mà PHP7 mang lại thực sự chưa cao. Một phần là do số lượng code được viết bằng PHP5 khá nhiều, cũng như sự tương thích của PHP7 đối với các công nghệ khác, đặc biệt là MongoDB dẫn tới nhiều khó khăn trong việc sử dụng PHP7 trong môi trường sản phẩm thực tế.

Javascript: vẫn sẽ phát triển mạnh mẽ với ngữ pháp trong sáng, mạnh mẽ của ES6, cùng với sự hỗ trợ của FlowType thì bạn sẽ vẫn làm được nhiều thứ từ mobile, desktop, server, web.

Go/Golang: mình dành sự chú ý đến Golang gần đây vì điểm mạnh về concurrency (sử dụng để build Docker và Google App Engine), mặc dù cú pháp có vẻ dễ học hơn Java và chạy nhanh hơn Java một chút, nhưng chỉ có giá trị đối với người từ thế giới ngôn ngữ lập trình động (PHP, Javascript, Python, Perl, Ruby…), chứ còn các bạn nắm vững anh cả như Java, C, C++ thì cũng chẳng ý nghĩa gì. Nếu bạn đang sử dụng ngôn ngữ lập trình động, hãy thử nghiên cứu Golang, dù sao thì tuổi đời Golang còn khá trẻ và với sự phát triển của cloud thì Golang có tương lai khá sáng sủa (Concurrency thường chi được cấp phát bởi OS, Golang là ngôn ngữ duy nhất hiện nay có khả năng này)

Lập trình ứng dụng di động

Nếu bạn đọc bài Lập trình ứng dụng di động với công nghệ của Facebook sẽ thấy React Native sẽ là một xu thế mạnh mẽ. Tuy nhiên không vì vậy mà các framework khác như Ionic, Kendo, Onsen, Sencha không có chỗ đứng của riêng mình.

React Native có điểm yếu là hiện tại chỉ hỗ trợ cho iOS và Android, và vì tính chất Native nên tính tái sử dụng cũng không thể đạt cao được. Ví dụ, với ứng dụng mang tính chất Native, nếu bạn ghiền/sử dụng Material Design thì phù hợp cho Android, nhưng nếu build luôn cho iOS thì một số thứ sẽ bị choải, hoặc bị pha hỗn hợp, ở đây mình xét đến yếu tố Native UI, tất nhiên nếu app là Hybrid thì cũng phải chịu cảnh tương tự, nhưng ở mức độ ít hơn nhiều, và giao diện thường cũng đồng nhất hơn.

Tổng kết

Với những kỹ thuật nêu trên, năm 2016 sẽ không còn gì bất ngờ. Bạn có thể chọn cho mình một con đường để theo đuổi, và sẽ có giá trị cho đến hết năm 2017. Thời gian đủ để học, xây dựng sản phẩm và kiếm tiền, nếu không thành công, thì nên từ bỏ nền tảng, kiến thức cũ để khai phá thứ mới hơn.

The post Xu hướng công nghệ lập trình web và mobile nửa cuối năm 2016 appeared first on Fullstack Station.

Huginn là gì

Huginn là hệ thống xây dựng các “điệp viên” thực hiện các tác vụ một cách tự động cho bạn trên thế giới internet. Các điệp viên này đúng theo tên gọi: dò tìm, giám sát các nội dung, thu thập sự kiện, tổng hợp lại và báo cáo cho bạn những gì đang xảy ra một cách chủ động. Cách báo cáo thì rất đa dạng: từ tin nhắn SMS, Email, Push Notification, Slack, hay cả Message Queue (MQTT)…rất nhiều !!!

Huginn và Muninn là tên của 2 con quạ đậu trên vai của thần Odin, hàng ngày thần Odin cho chúng bay đi từ lúc rạng sáng sớm để thu thập tin tức, sự kiện và trở về lúc trời tối để kể cho thần Odin tất cả những gì chúng biết trong ngày hôm đó!

Trang chủ dự án: https://github.com/cantino/huginn

Chỉ cần cài đặt khá là đơn giản trên Heroku (gói miễn phí) là bạn đã có trong tay một công cụ rất mạnh!

Hệ thống được viết bằng Ruby, nhưng bạn không cần phải biết ngôn ngữ này, hầu hết các chức năng, agent thông dụng đã có sẵn, bạn chỉ cần biết Javascript hoặc CoffeeScript để tuỳ chỉnh, hoặc tính toán, xử lý dữ liệu nếu cần (Đa phần là không cần). Nếu bạn muốn tạo một agent nào đó mà Huginn chưa có thì bạn mới cần phải biết Ruby, tuy nhiên theo mình thì cũng khá hiếm, vì nếu nhu cầu quá phức tạp thì chắc là phải tuỳ chỉnh khá nhiều, khi đó nên chăng tự viết một hệ thống riêng, còn với Huginn thì chỉ sử dụng là đủ.

Bạn có thể làm được gì khi có Huginn trong tay?

• Giám sát thời tiết và thông báo cho bạn “nếu trời mưa vào ngày mai”, đừng quên mang dù nhé
• Liệt kê những gì đang xảy ra trên Twitter và tổng hợp báo cáo cho bạn những chủ đề mà bạn quan tâm ví dụ như “Machine learning”, “Reactjs”, “Euro 2016”, …
• Kiểm tra thông tin lịch trình chuyến bay hay tìm kiếm các món đồ, sản phẩm bạn quan tâm mà giảm giá trên Amazon, Ebay…
• Thu thập nội dung website và giám sát khi nào nó thay đổi, có thể dùng đề xuất XML, JSON của một website bất kỳ
• …
• Nói chung là Huginn làm được nhiều thứ, những gì liên quan đến internet mà nó có thể truy cập được (xong bước dữ liệu) và kế tiếp là xử lý dữ liệu và làm gì tiếp nữa thì nó phụ thuộc vào nhu cầu và khả năng sáng tạo của bạn

Đặc điểm thú vị

• Kết nối các dịch vụ như Adioso, HipChat, Basecamp, Growl, FTP, IMAP, Jabber, JIRA, MQTT, nextbus, Pushbullet, Pushover, RSS, Bash, Slack, StubHub, translation APIs, Twilio, Twitter, Wunderground…
• Có thể gởi và nhận webhooks
• Chạy hàm Javascript hoặc CoffeeScript
• Có mô hình diễn tả rõ ràng các luồng của Agent

Một vài hình ảnh:

Ví dụ cụ thể

Đây là vài ví dụ mình có thể chia sẽ được từ những mô hình mình đã áp dụng:

• Kiểm tra tên miền: kiểm tra thời hạn của tên miền, báo cáo khi có bất kỳ sự thay đổi nào và thông báo trước thời điểm hết hạn của tên miền, mục đích là để giám sát các tên miền của mình, không để cho nó hết hạn, hai là “theo dõi” một số tên miền ưng ý “của người ta”, nếu chủ sở hữu không gia hạn thì mình sẽ chủ động…Chức năng này mình cài đặt với Slack, và mở website, app Slack mỗi khi ngồi máy tính, do vậy được báo cáo tức thì mỗi khi có bất kỳ sự thay đổi tên miền nào, hoặc trước xyz ngày hết hạn
• Công ty mình sở hữu gần 20 website tin tức, hầu hết không có XML, hoặc có mà không tương thích với SmartNews. Công ty có nhu cầu đưa các website tiếp cận Smartnews, nhưng việc thay đổi XML để phù hợp với chuẩn Smartnews cho tất cả website khá là tốn chi phí, vì do các đơn vị khác nhau thực hiện, hoặc đã ngưng hợp đồng. Nhờ có Huginn mà mình xây dựng hệ thống giám sát các website của công ty, tự động xuất ra file XML tương thích với Smartnews mỗi khi website có bài viết mới một cách tự động. Cũng như xuất ra chuẩn RSS 2.0 để các trình đọc RSS sử dụng.
• Cũng từ cách thức giám sát website trên, mình cũng đã tạo dựng ra hệ thống theo dõi các website về giáo dục, của các trường mầm non, nhà trẻ nhằm phục vụ dự án Kidsquare, bạn biết là mấy website dạng này không có người chăm sóc nên rất ít khi được cập nhật, mà đã khi cập nhật thì mình sẽ biết ngay :D. Nếu bạn xâu dựng hệ thống thu thập sự kiện, thì Huginn sẽ là trợ thủ đắc lực!

Kết

Huginn là hệ thống tương tự như IFTTT (If This Then That) nhưng mạnh hơn với khả năng rút trích thông tin và kết nối đa dạng. Nắm bắt được thông tin và xử lý một cách tự động thay cho bạn, với thời đại của IoT (Internet of Things) sắp tới, thì việc ra lệnh dựa theo điều kiện nào đó và gởi tín hiệu thông qua các giao thức được hỗ trợ khá nhiều của Huginn sẽ giúp cho bạn kiểm soát thế giới “của mình” tốt hơn. Chúc bạn có nhiều ý tưởng với hệ thống điệp viên này!

P/S:Bài viết này chỉ giới thiệu về sự tồn tại của một hệ thống … rất hay, hữu ích. Nếu sự quan tâm về chủ đề này đủ lớn thì mình sẽ viết hướng dẫn chuyên sâu hơn, hãy like và share để giúp mình có động lực để viết tiếp nhé

The post Hệ thống điệp viên Huginn: Thế giới trong tầm tay appeared first on Fullstack Station.