Đối với lĩnh vực eCommerce, việc cạnh tranh thị phần liên tục mở ra thách thức về đổi mới công nghệ cho mỗi doanh nghiệp. Không dừng lại ở những tính năng độc đáo, mới lạ, mỗi thương hiệu cũng cần chú trọng việc cá nhân hóa sản phẩm và nâng cao trải nghiệm người dùng trên website. PWAs (Progressive Web Apps) mang đến lợi thế của một website hoạt động tương tự native apps, thích hợp hiển thị đa kênh, tối ưu hóa khả năng tiếp cận người dùng dễ dàng trên di động, từ nhiều nguồn đa dạng và phù hợp với bối cảnh headless commerce lên ngôi trong ngành bán lẻ.
Đối với lập trình viên, việc chủ động tìm hiểu xu hướng công nghệ mới như PWA luôn là điều đúng đắn. Tiếp nối thành công từ workshop đầu tiên, Workshop số 2 của Sutunam, với sự đồng hành của TopDev, các chuyên gia công nghệ sẽ giải đáp sâu hơn về kỹ thuật và cách thức triển khai PWAs. Đặc biệt các bạn lập trình đang làm trong lĩnh vực eCommerce sẽ tìm được cho mình một số chú ý về UI/UX khi phát triển PWA cho website thương mại điện tử.
Các chuyên đề và Chuyên gia nào sẽ đồng hành cùng bạn vào workshop ngày 10/12/2020:
1. Introduction to PWA architecture ► Diễn giả: Việt Thái – Lập trình viên Senior về Javascript, Sutunam Vietnam
2. Share capabilities – How thing’s going with PWA? ► Diễn giả: Thanh Tùng – Lập trình viên Senior về Javascript, Sutunam Vietnam
3. Performant components through customization ► Diễn giả: Maya, thành viên Core team Storefront-UI, Israel
Tham gia workshop, bạn sẽ “bỏ túi” những kiến thức thú vị
– Tổng quan về cấu trúc của PWAs. Các hướng tiếp cận và tính năng cần thiết để thiết kế và xây dựng một ứng dụng PWA.
– Góc nhìn cụ thể hơn (kèm demo) để hiểu về cách thức hoạt động về cách chia sẻ dữ liệu trong PWAs.
– Vài nét về giải pháp PWA của headless frontend dành cho các nền tảng e-commerce tối ưu nhất thời điểm hiện tại. Ta cũng sẽ tìm hiểu một số chú ý trong khi tùy biến thiết kế cho các tình huống đặc thù trong e-commerce.
– Hiểu rõ cách tạo ra một UI library cho phép tùy chỉnh các component một cách tự do nhất có thể, trong khi vẫn có thể bảo đảm tối ưu hiệu suất và khả năng mở rộng?
Đối tượng: các lập trình viên, PM và những người làm trong lĩnh vực lập trình, thương mại điện tử. Vì số lượng chỗ ngồi có hạn, bạn vui lòng đăng ký sớm để giữ những slots cuối cùng nhé!
Bài viết được sự cho phép của tác giả Trần Hữu Cương
Chạy file jar giống như một service trên Ubuntu (Linux).
Trong bài này chúng ta sẽ thực hiện chạy 1 ứng dụng java (file .jar) trên ubuntu giống như 1 service (chạy ngầm). Tức là chúng ta có thể start, stop nó giống như 1 service hay có thể thể lựa chọn khởi động cùng hệ thống, xem log …
Giả sử mình có 1 file jar là spring-boot-hello.jar nằm trong folder /home/cuongth/workspace . Bây giờ mình sẽ thực hiện chạy file jar này giống như 1 service.
Bước 1: Tạo một service
Ở đây mình sẽ tạo 1 service với tên là spring-boot-hello. Do đó mình cần tạo file spring-boot-hello.service trong folder /etc/systemd/system với nội dung sau:
spring-boot-hello.service
[Unit]Description=Demo Spring Boot Hello[Service]User=cuongth# The configuration file application.properties should be here:#change this to your workspaceWorkingDirectory=/home/cuongth/workspace#path to executable.#executable is a bash script which calls jar fileExecStart=/bin/bash /home/cuongth/workspace/spring-boot-hello.shSuccessExitStatus=143TimeoutStopSec=10Restart=on-failureRestartSec=5[Install]WantedBy=multi-user.target
Trong đó:
Description: mô tả service
User: user dùng để chạy service
ExecStart: lệnh chạy script (ở đây mình chạy file bash ở vị trí: /home/cuongth/workspace/spring-boot-hello)
Để tạo file trên các bạn có thể dùng lệnh vi, rồi copy nội dung trên vào là được. (hoặc dùng text editor như nano, gedit…)
sudo vi /etc/systemd/system/spring-boot-hello.service
Ở đây mình dùng lệnh java để chạy file spring-boot-hello.jar, hiện trên máy mình đang cài java ở folder /opt/java/jdk1.8.0_241. Các bạn sửa lại thành folder chứa java trên máy của các bạn là ok.
Trong file spring-boot-hello.jar của mình là 1 web app đã nhúng sẵn tomcat và chạy trên port 8081, sau khi start service thì truy cập đường dẫn http://localhost:8081 sẽ có kết quả như sau:
Bước 4: Xem log
Để xem log của service ta dùng lệnh sau:
sudo journalctl --unit=my-webapp . See real-time logs by using the -f option.
If you want to trim them, use -n <# of lines> to view the specified number of lines of the log:
sudo journalctl -f -n 1000 -u spring-boot-hello
Trong đó:
-f: xem log realtime (log thay đổi gì sẽ hiện ra luôn)
-n: hiển thị số dòng log từ thời điểm hiện tại về trước đó
-u: tên service
Kết quả:
Để stop lại service ta dùng lệnh:
sudo systemctl stop spring-boot-hello
Để không cho service khởi động cùng hệ thống ta dùng lệnh:
Hiện nay, “Microservices” là một trong những thuật ngữ hay từ khóa phổ biến nhất (buzz-words) trong lĩnh vực kiến trúc phần mềm. Bạn có thể tìm thấy khá nhiều tài liệu giới thiệu và nói về những nguyên tắt cũng như lợi ích của microservices, tuy nhiên khá ít tài liệu hướng dẫn cách áp dụng microservices trong những hoàn cảnh thực tế.
Ứng dụng phần mềm doanh nghiệp được thiết kế để đáp ứng nhiều yêu cầu kinh doanh của doanh nghiệp. Do đó, các phần mềm cung cấp hàng trăm các tính năng và tất cả những tính năng này đều được gói trong một ứng dụng monolithic. Ví dụ: ERPs, CRMs hay nhiều phần mềm khác chứa hàng trăm tính năng. Việc triển khai, sửa lỗi, mở rộng và nâng cấp những phần mềm khổng lồ này trở thành một cơn ác mộng.
Kiến trúc hướng dịch vụ (Service Oriented Architecture – SOA) được thiết kể để giải quyết một phần của vấn đề bằng cách giới thiệu khái niệm “service”. Một dịch vụ (service) là một nhóm tổng hợp các tính năng tương tự trong một ứng dụng. Do đó trong SOA, ứng dụng phần mềm được thiết kế như một tổ hợp của các dịch vụ. Tuy nhiên, với SOA, giới hạn hay phạm vi của một dịch vụ khá là rộng và được định nghĩa khá “thô” (coarse-grained). Việc này khiến các services cũng có thể trở nên quá to và phức tạp.
Hình 1: Monolithic architecture
Trong phần lớn trường hợp, dịch vụ trong SOA là độc lập nhưng chúng lại được triển khai chung. Tương tự như ứng dụng monolithic, những dịch vụ này to và phức tạp lên theo thời gian vì thường xuyên thêm các tính năng. Và thế là những ứng dụng này lại trở thành một mớ các dịch vụ monolithic, cũng không còn khác mấy so với kiến trúc nguyên khối thông thường.
Hình 1 thể hiện một ứng dụng gồm nhiều services. Những services này được triển khai cùng một lúc vào 1 ứng dụng lớn. Dù bên trong có gồm các services thì đây là một ứng dụng monolithic. Một số tính chất của kiến trúc nguyên khối (Monolithic Architecture):
Được thiết kế, phát triển và triển khai theo một khối duy nhất.
Ứng dụng monolithic phức tạp và to gây khó khăn cho việc bảo trì, nâng cấp và thêm tính năng mới.
Khó áp dụng phát triển kiểu Agile.
Phải triển khai lại toàn bộ hệ thống dù chỉ cập nhật hay nâng cấp một phần.
Mở rộng: phải mở rộng cả khối ứng dụng, gặp khó khăn nếu có các yêu cầu về tài nguyên khác nhau (ví dụ một service yêu cầu thêm CPU, service khác lại yêu cầu nhiều memory).
Độ tin cậy: một service không ổn định có thể sập cả hệ thống.
Khó đổi mới: ứng dụng monolithic phải sử dụng chung công nghệ nên khó thay đổi hay áp dụng công nghệ mới.
Những tính chất giới hạn trên của kiến trúc nguyên khối dẫn tới sự phát triển của kiến trúc dịch vụ nhỏ (Microservices Architecture).
Kiến trúc dịch vụ nhỏ (Microservices Architecture)
Mục tiêu nền tảng của kiến trúc microservices là xây dựng một ứng dụng mà ứng dụng này là tổng hợp của nhiều services nhỏ và độc lập có thể chạy riêng biệt, phát triển và triển khai độc lập.
Một số khái niệm về microservices nói về quá trình chia tách ứng dụng monolithic thành nhóm các services độc lập. Tuy nhiên, theo quan điểm của tôi, microservices không chỉ về chia tách các servcies sẵn có trong monolithic.
Ý tưởng quan trọng chính là nhìn vào các tính năng trong một ứng dụng monolithic, ta có thể nhận biết, xác định các yêu cầu và khả năng cần thiết để đáp ứng một nghiệp vụ. Sau đó từng năng lực nghiệp vụ này sẽ được xây dựng thành những service nhỏ, độc lập. Những services này có thể sử dụng các nền tảng công nghệ khác nhau và phục vụ một mục đích cụ thể và có giới hạn.
Theo đó, ví dụ về hệ thống trong hình 1 có thể được chia theo microservices như trong hình 2. Đây có thể là một ứng dụng phần mềm bán hàng, với kiến trúc microservices, mỗi chức năng kinh doanh hay trong doanh nghiệp được tách thành một microservices. Trong kiến trúc microservices, một service mới được tạo ra từ những services gốc trong kiến trúc monolithic.
Hình 2: Microservices Architecture
Tiếp theo, chúng ta sẽ nói về các nguyên tắc chính của kiến trúc microservices và quan trọng hơn chính là cách chúng được sử dụng trong thực tế.
Thiết kế Microservices: kích cỡ, phạm vi và tính năng
Bạn có thể xây dựng ứng dụng mới với microservices hoặc chuyển đổi ứng dụng sẵn có sang microservices. Với cách nào thì việc quyết định kích cỡ, phạm vi và tính năng của microservices rất quan trọng. Có thể đây chính là phần khó nhất bạn gặp phải khi phát triển hệ thống microservices trong thực tế.
Dưới đây chúng ta sẽ xem xét một số vấn đề thực tế và những hiểu sai về kích cỡ, phạm vi và chức năng của microservices.
Số dòng code/ kích cỡ của một đội lập trình là chỉ số không chính xác: có vài cuộc bàn luận về kích thước của một service dựa vào số lượng dòng code hay kích thước của đội phát triển service đó (ví dụ two-pizza team). Tuy nhiên, những cách đo đếm này không thực tiễn và không chính xác, vì ta có thể phát triển services với ít dòng code hoặc với một đội nhỏ nhưng hoàn toàn đảm bảo được các nguyên lý trong kiến trúc microservices.
“Micro” là một từ khóa dễ gây nhầm lẫn. Một số lập trình viên nghĩ rằng họ nên tạo ra services nhỏ hết mức. Điều này là một cách hiểu sai.
Trong SOA, services thường trở thành các cục monolithic với nhiều hàm, chức năng khác hỗ trợ. Vì vậy, chỉ phát triển services kiểu SOA rồi dán nhãn microservices hoàn toàn lạc hướng và không mang lại bất kì lợi ích nào của kiến trúc microservices.
Do đó, câu hỏi là chúng ta nên thiết kế services trong kiến trúc microservices như thế nào thì phù hợp và đúng mực?
Một Số Chỉ Dẫn Khi Thiết Kế Microservices
Single Responsibility Principle (SRP): một service với phạm vi và chức năng giới hạn, tập trung vào một nhiệm vụ giúp quá trình phát triển và triển khai dịch vụ trở nên nhanh chóng hơn.
Trong quá trình thiết kế, ta nên xác định và giới hạn các services theo chức năng nghiệp vụ thực tế (theo Domain-Driven-Design).
Đảm bảo microservices có thể phát triển và triển khai độc lập.
Mục tiêu của thiết kế là phạm vi của microservices phục vụ một nghiệp vụ chứ không chỉ đơn giản làm các dịch vụ nhỏ hơn. Kích thước hợp lý của một service là kích thước đủ để đáp ứng yêu cầu của một chức năng trong hệ thống.
Khác với services trong SOA, một microservice không nên có quá nhiều hàm hay chức năng hỗ trợ xung quanh và định dạng thông báo/ gửi tin (messaging) phải đơn giản.
Một cách tốt là có thể bắt đầu với services to có phạm vi rộng rồi chia nhỏ dần (dựa theo nghiệp vụ thực tế của hệ thống).
Trong ví dụ về hệ thống bán hàng, bạn có thể thấy ứng dụng monolithic được tách thành bốn microservices là “inventory”, “accounting”, “shipping” và “store”. Chúng giải quyết một yêu cầu giới hạn nhất định nhưng tập trung vào chức năng đó. Theo đó, mỗi service tách biệt hoàn toàn khỏi nhau và đảm bảo tính linh hoạt và độc lập.
Ồ, nếu tách các services ra độc lập, vậy làm sao liên lạc và trao đổi thông tin/dữ liệu giữa các services với nhau?
Liên lạc giữa Microservices
Trong ứng dụng monolithic, các chức năng khác nhau nằm trong các component khác nhau được kết nối bằng cách gọi hàm hay phương thức. Trong SOA, việc này được chuyển sang một chế độ tách rời hơn với kiểu nhắn tin qua các dịch vụ web (web service messaging), phần lớn dùng SOAP trên nền giao thức HTTP, JMS. Những webservices này khá phức tạp. Như đã nói ở trên, microservices yêu cầu là phải có một cơ chế truyền tin đơn giản và nhẹ.
Vậy đó là những cơ chế nào?
Gửi Tin Đồng Bộ – REST, Thrift
Với truyền tin đồng bộ (người gửi – client sẽ chờ một khoảng thời gian để nhận kết quả từ service), REST là sự lựa chọn hàng đầu vì nó cung cấp hệ thống truyền tin đơn giản qua giao thức HTTP dạng request – response. Do đó, nhiều microservices sử dụng HTTP với API. Mỗi chức năng sẽ xuất ra (expose) API.
Hình 3: Dùng REST API để hiển thị microservices
Ngoài REST, Thrift cũng được sử dụng để truyền tin đồng bộ.
Gửi Tin Bất Đồng Bộ – AMQP, STOMP, MQTT
Trong một số kịch bản, truyền tin bất đồng bộ là cần thiết (client không mong đợi response ngay lập tức, hoặc không cần response). Các giao thức truyền tin bất đồng bộ như AMQP, STOMP hay MQTT được sử dụng rộng rãi.
Như vậy là chúng ta có gửi tin nhắn đồng bộ hoặc bất đồng bộ. Nhưng nên định dạng cho tin nhắn thế nào đây?
Các Định Dạng Tin Nhắn – JSON, XML, Thrift, ProtoBuf, Avro
Quyết định định dạng tin nhắn phù hợp cho microservices cũng là một yếu tố quan trọng. Với phần lớn các ứng dụng microservices, họ sử dụng những kiểu tin nhắn dạng chữ như JSON và XML trên nền giao thức HTTP với API. Trong trường hợp cần truyền tin dạng nhị phân, microservices có thể dùng dạng Thrift, Proto hay Avro.
Service Contracts – Định Nghĩa Service Interfaces – Swagger, RAML
Khi bạn có một nghiệp vụ được xây dựng như một dịch vụ, bạn cần định nghĩa và thông báo hợp đồng dịch vụ (service contract thể hiện giao kèo của service).
Bởi vì chúng ta xây dựng microservices trên kiểu kiến trúc REST, ta có thể sử dụng cùng kiểu REST API để định nghĩa hợp đồng của microservices. Do đó, microservices sử dụng các ngôn ngữ định nghĩa REST API tiêu chuẩn như Swagger, RAML để định nghĩa hợp đồng dịch vụ.
Đối với trường hợp microservices không được triển khai dựa trên HTTP/REST (cụ thể là dùng Thrift), chúng ta có thể dùng mức độ giao thức ‘Interface Definition Languages’ (ví dụ: Thrift IDL)
Kết Nối Microservices (Giao Tiếp Giữa Các Services)
Trong kiến trúc microservices, ứng dụng phần mềm được cấu thành từ các dịch vụ độc lập. Để hoàn thành một tác vụ của người dùng trên phần mềm, kết nối và giao tiếp giữa các microservices là cần thiết vì tác vụ gồm nhiều tác động khác nhau lên các services. Vì vậy, giao tiếp giữa các microservices là một vấn đề cực kì quan trọng.
Khi áp dụng SOA, giao tiếp giữa các services được tiến hành bởi một Enterprise Service Bus (ESB) và phần lớn logic nằm trong tầng trung gian này (định tuyến cho tin nhắn, chuyển đổi và điều phối tin nhắn). Tuy nhiên, kiến trúc microservices thúc đẩy việc loại trừ một tầng giao tiếp trung gian tập trung/ ESB và chuyển phần ‘smart-ness’ hay business logic sang các services (nó được gọi là ‘Smart Endpoints’).
Bởi vì microservices sử dụng giao thức tiêu chuẩn như HTTP/REST, JSON, …, Cho nên các giao tiếp giữa các microservices được cố gắng thống nhất về giao thức và hạn chế tối đa việc tích hợp với một giao thức khác. Một lựa chọn khác cho giao tiếp giữa microservices là sử dụng một message bus nhẹ hay gateway với khả năng định tuyến tối thiểu hoạt động như những đường truyền đơn thuần không xử lý business logic gì hết (dump pipe). Dựa vào những phong cách này, có một số kiểu mẫu giao tiếp trong microservices như dưới đây.
Point-to-point – Kết Nối Trực Tiếp Giữa Các Services
Với kiểu kết nối trực tiếp điểm nối điểm, toàn bộ logic của việc định tuyến truyền tin nhắn nằm trong mỗi điểm cuối (endpoint) hay chính là các services. Và services nói chuyện trực tiếp với nhau. Mỗi service mở ra một REST APIs và bất kì service hay khách hàng bên ngoài nào cũng có thể gọi service qua REST API của nó.
Hình 4: Giao tiếp giữa các microservices dùng point-to-point
Rõ ràng là mô hình này đơn giản và hoạt động ổn với ứng dụng microservices tương đối nhỏ nhưng khi số lượng services tăng lên, việc giao tiếp trở nên cực phức tạp. Đây là lý do trong mô hình SOA truyền thống người ta sử dụng Enterprise Service Bus (ESB), chính là để loại bỏ kết nối trực tiếp phức tạp và rối rắm. Sau đây là một số nhược điểm của kiểu giao tiếp trực tiếp (point to point).
Những yêu cầu như xác thực người dùng, điều tiết, giám sát,…phải được thực hiện (implement) ở mọi microservices.
Việc trên dẫn đến các tính năng phổ biến bị trùng lặp, việc thực hiện mỗi microservices có thể trở nên phức tạp.
Không có cách quản lý, kiểm soát giao tiếp giữa các services (chẳng hạn như muốn theo dõi, truy tìm hay lọc các giao hành động giữa các services).
Thường việc kết nối trực tiếp trong microservices được coi là anti-pattern cho việc triển khai các ứng dụng microservice có quy mô lớn.
Vì vậy, với những trường hợp phức tạp hơn, thay vì kết nối trực tiếp hay dùng một ESB trung tâm, chúng ta có thể sử dụng 1 messaging bus trung tâm gọn nhẹ. Nó cung cấp một lớp trừu tượng hóa các microservices (an abstraction layer). Cách này được gọi là API Gateway.
API-Gateway
Ý tưởng chính của API Gateway là sử dụng một cổng truyền tin gọn nhẹ như một điểm vào chính cho tất cả khách hàng/ người dùng và triển khai những chức năng chung mà không liên quan đến nghiệp vụ đặc thù ở cấp Gateway này.
Nhìn chung, một API Gateway cho phép bạn sử dụng một API được quản lý qua HTTP/REST. Vì thế, chúng ta có thể cung cấp tất cả các chức năng nghiệp vụ được phát triển thành microservices qua API Gateway như một APIs tập trung được quản lý.
Hình 5: Tất cả các microservices được giao tiếp thông qua API Gateway
Trong ví dụ bán hàng của chúng ta, theo Hình 5 tất cả microservices đều được xuất ra thông qua API Gateway và đây là một chốt đầu vào duy nhất cho người dùng. Nếu một microservice muốn giao tiếp với một microservice khác thì cần đi qua API Gateway.
API Gateway cung cấp các lợi thế dưới đây:
Cung cấp một lớp trừu tượng hóa các microservices. Ví dụ thay vì cung cấp một API cho tất cả khách hàng, API gateway có thể xuất ra hay hiển thị API khác nhau cho mỗi khách hàng.
Định tuyến và chuyển đổi tin nhắn gọn nhẹ ở cấp gateway.
Một điểm tập trung cho các chức năng chung không mang tính nghiệp vụ kinh doanh như bảo mật, giám sát và điều tiết.
Với API Gateway, microservices trở nên càng gọn nhẹ vì các chức năng chung không mang tính nghiệp vụ đều chuyển sang Gateway.
API Gateway có thể là kiểu mẫu được sử dụng rộng rãi nhất trong triển khai microservices.
Message Broker – Người truyền tin trung gian
Microservices có thể được kết nối qua truyền tin bất đồng bộ như yêu cầu một chiều (requests) hay thông báo/ đăng kí nhận thông báo (publish/ subscribe) qua queues hay topics. Với publish/ subscribe, một service có thể tạo tin nhắn và gửi bất đồng bộ đến một hàng chờ (queue hay topic). Sau đó service khác có thể nhận tin này từ queue hay topic. Phong cách này tách biệt người gửi và người nhận, và người truyền tin trung gian sẽ lưu tin nhắn đến khi người nhận có thể xử lý. Người gửi hoàn toàn không biết gì về người nhận.
Hình 6: Tích hợp gửi tin nhắn bất đồng bộ dùng pub-sub
Giao tiếp giữa người gửi/ người nhận được tạo ra bởi message broker qua các tiêu chuẩn truyền tin bất đồng bộ như AMQP, MQTT,…
Quản Lý Cơ Sở Dữ Liệu Phân Tán
Trong cấu trúc monolithic, ứng dụng lưu dữ liệu vào một cơ sở dữ liệu (CSDL) tập trung duy nhất.
Hình 7: Ứng dụng Monolithic dùng cơ sở dữ liệu tập trung cho tất cả các tính năng của nó
Trong microservices, các chức năng được tách thành nhiều microservices và nếu sử dụng cùng một CSDL trung tâm thì microservices không còn độc lập. Thay đổi dữ liệu của một service có thể làm hỏng các services khác. Do đó, mỗi microservice phải có CSDL riêng.
Hình 8: Microservices có database riêng và chúng không thể truy cập trực tiếp đến database của microservices khác
Dưới đây là vài đặc điểm chính khi phát triển việc quản lý dữ liệu phân tán trong kiến trúc microservices.
Mỗi service có thể có một CSDL riêng biệt để lưu trữ thông tin cần thiết cho nghiệp vụ của service đó.
Một microservice chỉ có thể truy xuất vào CSDL riêng của nó mà không có quyền truy xuất vào CSDL của microservices khác.
Trong một số hoàn cảnh, để hoàn thành một tác vụ bạn cần phải cập nhật nhiều CSDL. Khi đó CSDL của microservices khác chỉ nên được cập nhật qua API của những dịch vụ này (không trực tiếp thay đổi CSDL).
Việc phân tách quản lý dữ liệu cho phép bạn hoàn toàn phân tách các microservices và có thể chọn các công nghệ quản lý dữ liệu khác nhau (SQL hay NoSQL,…nhiều CSDL khác nhau cho các microservices). Tuy nhiên, với các giao dịch phức tạp liên quan đến nhiều microservices, giao dịch phải được thực hiện qua API.
Quản Trị Phân Tán
Kiến trúc microservices ủng hộ quản trị phân tán.
Nhìn chung, quản trị nghĩa là thiết lập và thực thi phương thức mà con người và các giải pháp làm việc cùng nhau để đạt được mục tiêu. Trong ngữ cảnh SOA, quản trị SOA (SOA governance) hướng dẫn việc phát triển các services có thể tái sử dụng, thiết lập cách services được thiết kế, phát triển và cách chúng thay đổi theo thời gian. Nó thiết lập một giao kèo giữa người cung cấp services và người sử dụng services, thông báo cho người sử dụng những thứ họ có thể nhận được và người sử dụng những thứ họ phải cung cấp. Trong quản trị SOA, có hai kiểu quản trị phổ biến:
Quản trị khi thiết kế – định nghĩa và kiểm soát việc tạo services, thiết kế và thực thi các chính sách của services.
Quản trị khi triển khai/ chạy – khả năng đảm bảo các chính sách của services trong quá trình hoạt động.
Vậy trong microservices thì quản trị là gì?
Microservices được xây dựng động lập và phân tán với nền tảng công nghệ khác nhau. Do đó, việc thiết lập một tiêu chuẩn thiết kế và phát triển chung là không cần thiết. Chúng ta có thể kết luận về khả năng quản trị phân tán trong kiến trúc microservices như sau:
Không cần phải có một hệ quản trị tập trung khi thiết kế.
Microservices có thể tự quyết định thiết kế và phát triển của nó.
Kiến trúc ủng hộ và hỗ trợ việc chia sẻ các services chung hay có thể tái sử dụng.
Một số mặt của quản trị trong quá trình hoạt động như SLAs, điều phối, giám sát, bảo mật hay tìm kiếm dịch vụ (service discovery) có thể được phát triển ở cấp API Gateway.
Service Registry & Service Discorvery (Truy Tìm Dịch Vụ).
Trong microservices, số lượng services mà bạn cần xử lý khá lớn. Và địa điểm của chúng có thể thay đổi nhanh và thường xuyên vì tính chất của việc phát triển microservices là nhanh. Nên bạn cần phải xác định được vị trí của một service trong quá trình chạy. Giải pháp cho vấn đề này là Service Registry.
Service Registry
Service Registry giữ các thực thể microservices và địa chỉ của chúng. Thực thể microservices được đăng kí với service registery khi bắt đầu chạy và hủy đăng kí khi tắt. Người dùng có thể tìm các services đang tồn tại và địa chỉ của chúng qua service registry.
Service Discovery
Để tìm các microservices đang tồn tại và địa điểm của chúng, chúng ta cần một quy trình truy tìm dịch vụ. Có hai mô hình là Client-side Discovery và Server-side Discovery. Hãy cùng xem xét hai mô hình này.
Client-side Discovery – Với mô hình này, client hay API Gateway lấy thông tin địa điểm của một thực thể service bằng cách truy vấn Service Registry.
Hình 9: Client-side discovery
Client hay API Gateway phải thực hiện logic tìm kiếm service bằng cách gọi vào Service Registry.
Server-side Discovery – Với cách này, client hay API Gateway gửi yêu cầu lên một component (có thể là một Load Balancer). Component này sẽ gọi Service Registry và quyết định địa điểm của các microservices.
Hình 10: Server-side discovery
Một số giải pháp triển khai microservices như Kubernetes cung cấp mô hình server-side discovery.
Deployment – Triển Khai
Việc triển khai các dịch vụ có một trò trọng yếu và gồm các yêu cầu sau:
Khả năng triển khai/ gỡ xuống độc lập mà không ảnh hưởng đến dịch vụ khác.
Có thể mở rộng theo cấp microservices, chỉ mở rộng microservices cần thiết.
Phát triển và triển khai microservices nhanh chóng.
Một microservice ngắt kết nối hay sập thì không ảnh hưởng các dịch vụ khác.
Docker (một công cụ mã nguồn mở cho phép lập trình viên và quản trị viên hệ thống triển khai các ứng dụng thành các containers trên môi trường Linux) cung cấp một công cụ tuyệt vời để triển khai microservices đáp ứng đủ các yêu cầu trên. Các bước chính gồm:
Đóng gói mỗi microservice thành một ảnh Docker (docker image).
Triển khai mỗi thực thể của service là một Docker container.
Mở rộng dựa vào số lượng thực thể.
Phát triển, triển khai và khởi động microservices trở nên nhanh hơn với Docker (nhanh hơn nhiều các máy ảo thông thường – VM).
Kubernetes mở rộng khả năng của Docker bằng cách quản lý một cụm các Linux container như một hệ thống duy nhất, quản lý và chạy các Docker containers trên nhiều hosts, cung cấp service discovery và kiểm soát việc nhân rộng. Như bạn có thể thấy, những tính năng này cần thiết cho kiến trúc microservices. Vì vậy sử dụng Kurbernetes (trên nền Docker) để triển khai microservices đang trở thành một phương pháp cực kì hữu dụng, đặc biệt với ứng dụng lớn.
Hình 11: Xây dựng và triển khai microservices như các containers
Hình 11 thể hiện tổng quát việc triển khai các microservices. Mỗi thực thể của microservices được triển khai thành một container và có hai containers trên mỗi host. Bạn có thể thay đổi số lượng containers chạy trên một host theo ý mình.
Security – Bảo Mật
Bảo mật microservcies là một yêu cầu phổ biến trong thực tế. Trước khi nói đến bảo mật microservices, hãy nhìn lại cách chúng ta thường thực hiện bảo mật của ứng dụng monolithic.
Bảo mật của một ứng dụng monolithic thường là về xác định xem “Ai là người gọi đến”, “Người này có quyền hạn gì” và “Ứng dụng thông báo về những thông tin này thế nào”.
Một component phụ trách bảo mật chung thường nằm ở đầu chuỗi xử lý yêu cầu và component sẽ trả về thông tin cần thiết.
Vậy chúng ta có thể chuyển đổi trực tiếp mô hình này sang kiến trúc microservices không?
Có nhưng điều này yêu cầu phát triển bảo mật ở từng microservices và kết nối với một cơ sở trung tâm về người dùng để lấy thông tin cần thiết. Đây là một cách khá rối rắm. Thay vào đó, chúng ta có thể tận dụng các API bảo mật tiêu chuẩn như OAuth2 và OpenID Connect để tìm một giải pháp tốt hơn cho vấn đề bảo mật. Trước khi nói sâu hơn, chúng ta sẽ tóm tắt mục tiêu của mỗi tiêu chuẩn và cách sử dụng chúng.
OAuth2 – một phương thức chứng thực kiểu ủy quyền. Client xác thực với server cấp quyền (authorization server) và nhận một token gọi là “Access token”. Access token không chứa bất kì thông tin gì về client. Nó chỉ là một tấm vé tham chiếu đến thông tin người dùng mà server cấp quyền có thể truy xuất đến. Do đó, đây cũng được gọi là token kiểu tham chiếu “by-reference token” và an toàn để sử dụng trên mạng lưới mở và internet.
OpenIDConnect hoạt động tương tự OAuth nhưng ngoài Access Token, server cấp quyền còn phát một ID token chứa thông tin người dùng. Token này thường dạng JWT (JSON Web Token) và được kí bởi server cấp quyền. JWT token do đó được coi là token kiểu tham trị “by-value token” bởi vì nó chứa thông tin về người dùng và có thể trở nên không an toàn.
Bây giờ, hãy xem xét những tiêu chuẩn này có thể bảo mật microservices trong ví dụ bán hàng của chúng ta như thế nào.
Hình 12: Bảo mật microservices với OAuth2 và OpenID Connect
Như hình trên, các bước chính để thực hiện bảo mật microservices gồm:
Chuyển việc xác thực cho server dạng OAuth và OpenID Connect (Authorization server).
Sử dụng API Gateway để có một điểm đầu vào duy nhất cho yêu cầu từ clients.
Client kết nối với server cấp quyền và nhận Access token. Sau đó gửi token này đến API Gateway cùng với yêu cầu.
Dịch token tại Gateway – API Gateway lấy ra access token và gửi đến server cấp quyền để lấy JWT.
Gateway truyền JWT cùng với yêu cầu đến microservices.
JWT chứa thông tin người dùng cần thiết để lưu user sessions,….
Ở mỗi lớp microservice, bạn có thể có một component xử lý JWT, việc này khác đơn giản.
Transactions – Các giao dịch
Các transactions (giao dịch) trong microservices được hỗ trợ thế nào?
Trên thực tế, hỗ trợ các giao dịch phân tán trên nhiều microservices là một nhiệm vụ đặc biệt phức tạp. Kiến trúc microservice tự khuyến khích sự phối hợp không có giao dịch giữa các dịch vụ.
Ý tưởng là một dịch vụ nhất định hoàn toàn khép kín và dựa trên nguyên lý Single Responsibility Principle.
Việc cần phải có các giao dịch phân tán trên nhiều microservice thường là một triệu chứng của lỗ hổng thiết kế trong kiến trúc microservice và thường có thể được sắp xếp bằng cách tái cấu trúc phạm vi của microservice.
Tuy nhiên, nếu có một yêu cầu bắt buộc là phải có các giao dịch phân tán trên nhiều dịch vụ, thì các kịch bản như vậy có thể được thực hiện với ‘compensating operations’ (các hoạt động bù ) ở cấp độ mỗi dịch vụ.
Ý tưởng chính là, một microservice cụ thể dựa trên nguyên lý Single Responsibility Principle và nếu một microservice nào đó không thực hiện được nhiệm vụ đã giao, chúng ta có thể coi đó là một thất bại của toàn bộ microservice đó. Sau đó, tất cả các hoạt động khác
(các hoạt động ở cấp trên) phải được hoàn tác bằng cách gọi hoạt động bù tương ứng của các dịch vụ siêu nhỏ đó.
Design for Failures – Thiết Kế Cho Các Thất Bại
Kiến trúc microservices tăng khả năng xảy ra thất bại tại microservices. Một microservice có thể sập do một vấn đề mạng, nguồn tài nguyên bị thiếu hụt hoặc không sẵn sàng,… Một microservice không đáp ứng lại thì không nên dẫn đến toàn bộ ứng dụng microservices sập. Do đó, mỗi microservices nên có khả năng chịu lỗi và hồi phục khi có thể. Người dùng phải có trải nghiệm tốt, nhẹ nhàng và không nhận ra lỗi bên trong hệ thống.
Thêm nữa, vì các dịch vụ có thể gặp lỗi bất cứ lúc nào, việc phát hiện (giám sát thời gian thực) lỗi nhanh chóng và nếu có thể tự động phục hồi dịch vụ là cực kì quan trọng.
Có một vài kiểu mẫu xử lý lỗi trong microservices phổ biến.
Circuit Breaker
Khi có lời gọi từ bên ngoài đến một microservice, bạn có thể cấu hình một component giám sát lỗi với mỗi lời gọi. Component này đếm số yêu cầu thành công và thất bại, khi lỗi đạt một giới hạn nhất định thì component này sẽ dừng hoạt động của service (ngắt giao mạch).
Cách này hữu dụng để tránh tiêu tốn tài nguyên không cần thiết, yêu cầu bị chậm vì timeouts, cách này cũng giúp giám sát hệ thống.
Bulkhead
Vì một ứng dụng kiến trúc microservices bao gồm nhiều microservices, một service dừng hoạt động không nên ảnh hưởng đến phần còn lại. Kiểu mẫu bulkhead tách biệt các phần của ứng dụng để khi có lỗi tại một nơi nào đó thì không ảnh hưởng hệ thống.
Timeout
Kiểu mẫu timeout là một quy trình cho phép dừng một yêu cầu khi thời gian chờ đợi vượt quá hạn mức. Bạn có thể cấu hình khung thời gian tùy ý.
Vậy khi nào chúng ta sử dụng những kiểu mẫu này?
Trong phần lớn trường hợp, những kiểu mẫu này được áp dụng ở lớp Gateway. Khi microservices không đáp lại hay không sẵn sàng, ở cấp Gateway chúng ta có thể quyết định có nên gửi yêu cầu đến microservices sử dụng circuit breakers hay timeout. Hơn nữa, sử dụng bulkhead ở Gateway khá quan trọng vì đây là một điểm đầu vào cho tất cả yêu cầu từ clients, nên nếu lỗi một service cũng không ảnh hưởng đến việc gửi yêu cầu đến các services khác.
Thêm vào đó, Gateway có thể được sử dụng như một điểm trung tâm ta có thể lấy thông tin về trạng thái và theo dõi các microservices hoạt động.
Microservices, Tích Hợp Cho Doanh Nghiệp, Quản Lý API và hơn thế nữa
Chúng ta đã trao đổi các đặc tính của kiến trúc Microservices và cách bạn có thể thực hiện chúng. Tuy nhiên, bạn nên lưu ý rằng Microservices không phải toa thuốc chữa bách bệnh. Việc áp dụng mù quáng những khái niệm đang nổi sẽ không xử lý vấn đề thực tế của bạn. Nếu bạn đã đọc toàn bộ bài này thì bạn sẽ thấy Microservices có nhiều lợi ích và chúng ta nên tận dụng. Tuy nhiên, bạn cần hiểu rằng mong chờ microservices giải quyết tất cả các vấn đề là không thực tiễn.
Chốt bài
Qua bài này chúng ta có thể hiểu được Microservices là gì, microservices giúp bạn được những gì, cách để chia nhỏ các microservices, cách để tích hợp và tương tác giữa các microservices với nhau, cách để bảo mật khi triển khai ứng dụng với microservices, những công cụ hỗ trợ để giúp bạn triển khai ứng dụng microservices dễ hơn.
Mong rằng các bạn đã có một cái nhìn rõ hơn về Microservices.
Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh
Đối tượng String, được định nghĩa trong package java.lang, là một đối tượng cơ bản trong Java. Các bạn sẽ sử dụng nó thường xuyên và là một đối tượng không thể thiếu đối với tất cả chúng ta khi lập trình với Java. Trong bài viết này, mình sẽ trình bày với các bạn sâu hơn về đối tượng String này để các bạn hiểu rõ thêm về nó các bạn nhé!
Khởi tạo đối tượng String
Chúng ta có nhiều cách để khởi tạo một đối tượng String, đó là:
– Sử dụng toán tử new
Ví dụ:
String a = new String("Khanh");
– Sử dụng toán tử gán (“=”)
Ví dụ:
String b = "Khanh";
– Khai báo trong dấu nháy kép
Ví dụ:
System.out.println("Khanh");
Sự khác nhau giữa các cách khai báo trên, đó là:
Nếu các bạn khai báo đối tượng String sử dụng toán tử new thì Java sẽ tạo ra những đối tượng Java riêng biệt, lưu trữ ở những vị trí khác nhau trong bộ nhớ.
Do đó, khi các bạn so sánh những đối tượng này sử dụng toán tử quan hệ (“==”) thì kết quả sẽ là false. Hãy xem ví dụ sau nhé các bạn:
package com.huongdanjava.javaexample;
public class Example {
public static void main(String[] args) {
String a = new String("Khanh");
String b = new String("Khanh");
System.out.println(a == b);
}
}
Kết quả:
Nếu các bạn khởi tạo đối tượng String bằng cách sử dụng toán tử gán (“=”) thì khi so sánh những đối tượng này sử dụng toán tử quan hệ (“==”) thì kết quả sẽ là true.
Hãy xem xét ví dụ sau nhé các bạn:
package com.huongdanjava.javaexample;
public class Example {
public static void main(String[] args) {
String a = "Khanh";
String b = "Khanh";
System.out.println(a == b);
}
}
Kết quả:
Nguyên nhân là do đâu các bạn? Đó là bởi vì khi bạn khởi tạo biến String a với nội dung là “Khanh” sử dụng toán tử gán (“=”) thì Java sẽ tạo một chuỗi “Khanh” được lưu trữ ở một vị trí xác định trong bộ nhớ gọi là String pool. Khi các bạn tạo các biến String khác cũng cùng nội dung là “Khanh”, thì Java sẽ trả về chuỗi ký tự “Khanh” đã được tạo ra trước đó trong String pool. Và do đó, khi các bạn so sánh những đối tượng như thế này, kết quả sẽ luôn là true.
Đối với trường hợp thứ ba thì cũng giống như trường hợp thứ hai, khi so sánh những String được khai báo trong dấu ngoặc kép bằng toán tử quan hệ (“==”) kết quả sẽ luôn luôn true.
Hãy xem xét ví dụ sau nhé:
package com.huongdanjava.javaexample;
public class Example {
public static void main(String[] args) {
System.out.println("Khanh" == "Khanh");
}
}
Kết quả:
Khái niệm Immutable trong String
Làm việc với String, các bạn sẽ gặp khái niệm Immutable. Vậy Immutable là gì? Mình sẽ nói ngay: Immutable là khái niệm để chỉ những đối tượng mà nội dung hay trạng thái của nó không thể bị thay đổi bởi bất cứ đối tượng nào khác.
String là một đối tượng Immutable như thế!
Vậy làm thế nào String có thể là một đối tượng Immutable, mình xin trình bày như sau:
– String lưu trữ giá trị của nó trong một biến mảng với kiểu dữ liệu char. Biến mảng này được định nghĩa với access modifier là private.
– Biến mảng này được khai báo với từ khóa final. Như các bạn đã biết, nếu một biến được định nghĩa với từ khóa final thì nó chỉ được khởi tạo một lần duy nhất.
– Không một phương thức nào trong đối tượng String thao tác với biến mảng này.
Khi trình duyệt nhận một dữ liệu HTML, nó sẽ parse qua DOM node
2 – External Resource
Khi gặp các file CSS, JS nó sẽ chạy đi lấy dữ liệu đó, quá trình parse vẫn tiếp tục, nhưng sẽ chặn việc render trên trình duyệt (CSS được sếp vào loại resource block render)
JS hơi khác, mặc định nó sẽ chặn quá trình parse HTML (block parse). Tuy nhiên với việc truyền thêm attribute defer hoặc async, việc parse js sẽ chạy ngầm, và không chặn parse HTML
Với defer, file sẽ được execute sau khi parse document xong, nếu nhiều file được thêm thuộc tính defer, nó sẽ được execute theo thứ tự trong HTML
Với async, file sẽ execute ngay khi load, nghĩa là có thể trong lúc parse hoặc sau lúc parse, vì vậy thứ tự đặt file không quan trọng, không đảm bảo file execute theo đúng thứ tự.
Với các trình duyệt sau này, nó sẽ hỗ trợ thêm việc preload, lấy về những resource chưa thật sự cần ở thời điểm hiện tại, nhưng trong tương lai có thể cần đến, việc này cũng tùy thuộc vào từng trình duyệt mà cách xử lý có khác nhau
<link href="style.css"rel="preload"as="style"/>
3 – Parse CSS
Sau khi đã có được source file css “trong tay”, trình duyệt làm tiếp 2 thao tác, parse CSS và build CSSOM
4 – Execute JS
Các trình duyệt khác nhau, quá trình parse-compile-execute sẽ khác nhau, cũng cần nhớ thêm việc parse JS rất tốn kém tài nguyên của máy.
Ngay sau khi JS đã load xong và DOM đã parse xong, sự kiện document.DOMContentLoaded sẽ được emit
Sau khi các async JS, image load xong, sự kiện window.load sẽ được emit
window.addEventListener('load',(event)=>{});
5 – Merge DOM và CSSOM để tạo render tree
Hợp thể giữa DOM và CSSOM sẽ cho ra render tree, là toàn bộ những gì sẽ hiển thị trên trình duyệt
6 – Calculate layout và paint
Sau khi đã nhận được render tree, trình duyệt đã có đủ thông tin để tính toán những phần tử nào, đặt ở đâu, kích thước ra làm sao, qua trình đó gọi là calculate layout, kết thúc quá trình tính toán này, trình duyệt sẽ bắt đầu quá trình paint, là những gì user sẽ thấy trên trình duyệt, đây cũng là bước cuối cùng.
Tuyen dung IT thông qua Omni-channel đang dần chiếm lấy vị trí dẫn đầu – khắc phục điểm yếu của multi-channel bằng việc cung cấp sự nhất quán; tập trung vào trải nghiệm của ứng viên. Từ đó giúp việc tuyen dung it trở nên đơn giản và tiết kiệm thời gian hơn. Cùng TopDev tìm hiểu về những điều thú vị xoay quanh Omni-channel trong tuyen dung it.
Omni-channel trong tuyen dung it là gì?
Thuật ngữ Omni-channel có vẻ đã quá quen thuộc trong ngành bán lẻ.
Nó được hiểu là mô hình đặt khách hàng làm trọng tâm trong quá trình mua hàng bằng việc tối đa hóa bán hàng từ kênh offline đến online trên hệ thống quản lý duy nhất; hướng đến sự “nhất quán hóa” trải nghiệm cho họ.
Omni-channel là gì?
Chiến lược này cũng áp dụng cho tuyen dung it. Omni-channel trong tuyen dung it đặt trọng tâm trong quá trình thu hút nhân tài dựa trên:
Tối đa hóa tỉ lệ ứng tuyển (trên cơ sở vận dụng đa kênh; đảm bảo sự tương tác liền mạch). Mục tiêu quan trọng: tạo ra trải nghiệm tuyệt vời cho ứng viên.
Ví dụ của Omni-channel trong tuyen dung freelancer it:
Chạy quảng cáo trên Facebook dẫn về Website của doanh nghiệp. Cùng lúc đó, ứng viên truy cập vào website doanh nghiệp và nhận được lời mời “chat” trong chức năng chat tự động. Các tính năng đa dạng từ đa kênh này chính là Omni-channel.
Tại sao Omni-channel giúp tuyen dung it hiệu quả hơn?
Tiết kiệm thời gian tuyển dụng
Lấy ví dụ là bài toán lớp 5 cơ bản: người thứ nhất làm xong việc trong 4 giờ; người thứ 2 hoàn thành trong 5 giờ; và khi 2 người làm chung, thời gian chỉ rút ngắn còn 2,22 giờ mà thôi.
Omni-channel cũng thế. Nếu như bạn chỉ dùng một kênh duy nhất thì thời gian tuyển được nhân tài vô cùng lâu (có khi tính theo tháng). Tuy nhiên nếu phối hợp khéo léo tất cả các kênh mà ứng viên có mặt thì, bạn biết rồi đấy, CV IT Developer về sau vài ngày không phải là chuyện lạ!
Thông tin doanh nghiệp đáng tin hơn
Khi ứng viên IT thấy doanh nghiệp bạn xuất hiện trên tất cả (hoặc hầu hết) những kênh mà họ truy cập thường ngày, họ sẽ cảm nhận rằng doanh nghiệp bạn biết kết nối và đầu tư vào tìm kiếm nhân tài. Dù freelancer IT hay Developer IT thì những thông tin luôn được cập nhật và chính xác hơn.
Nắm trong tay insights của các ứng viên
Có thể nói mức độ đa dạng của kênh tuyển dụng tỉ lệ thuận với lượng thông tin thu thập về ứng viên
Bạn sẽ có cơ hội tiếp cận nhiều hơn về hành vi; tâm lý ứng viên từ lúc bắt đầu tiếp cận doanh nghiệp đến khi quyết định ứng tuyển vào.
Và dĩ nhiên, những hành vi này là khác nhau với từng kênh tuyển dụng. Việc thu thập đủ thông tin sẽ giúp bạn biết nên đẩy mạnh kênh nào tương ứng với nội dung gì. Từ đó chuẩn bị tốt cho kế hoạch tuyển dụng cạnh tranh hơn. đơn xin nghỉ việc
Làm thế nào để tối ưu hóa vai trò Omni-channel trong tuyển dụng IT?
Tận dụng các dữ liệu hiện có
Ông bà ta có câu “Biết người biết ta trăm trận trăm thắng”. Điều đó không hề sai trong việc sử dụng Omni-channel trong tuyen dung it.
“Biết người” ở đây là thấu hiểu ứng viên IT. Bạn cần nắm rõ chân dung ứng viên IT, các đặc điểm về nhân khẩu học, hành vi, tâm lí,.. một cách sâu sắc nhất.
Ứng viên hay hỏi về doanh nghiệp qua phương tiện nào?… và kết hợp với các đặc điểm chung của thế hệ Milennial và Gen Z – hai thế hệ chiếm tỉ trọng lớn trong lượng ứng viên IT hiện nay. Họ mong đợi ở doanh nghiệp những gì? Liệu các freelancer IT giữa 2 thế hệ có gì khác nhau? Mức độ gắn kết thế nào?…
Tuyen dung it đối với các thế hệ khác nhau là một thách thức lớn
“Biết ta” là hiểu về mình – ở đây là hiểu những cách thức mà mình áp dụng để chiêu mộ nhân tài.
Hiện tại mình sử dụng bao nhiêu kênh? Lượng ứng viên IT sử dụng các kênh này có đông đảo không? Số lượng ứng tuyển từ mỗi kênh là bao nhiêu? Liệu các kênh này đang cho thấy vị trí ngày một quan trọng hay dần ít quan trọng đi?…
Lựa chọn các kênh phù hợp
Sau khi tổng hợp các dữ liệu và rút ra insights quan trọng từ bước 1, bạn có thể tham khảo các kênh tuyển dụng sau:
– Hội chợ việc làm (Job fair)
– Mạng xã hội thông dụng: LinkedIn, Facebook, Snapchat, Instagram, Twitter, Pinterest, Viadeo,.. (theo WeareSocial và Hootsuite, năm 2019, top 5 mạng xã hội được người Việt Nam sử dụng nhiều nhất: Youtube, Facebook, Instagram, Twitter và LinkedIn)
– Các nền tảng khác: TikTok, Houseparty, Lasso, Caffeine,…
– Sự kiện, hội nghị về công nghệCác phần mềm như Google AdWords, Facebook Ads,..
– Blogging, diễn đàn về công nghệ nơi ứng viên IT có thể thảo luận về chủ đề nào đó
– Employee Referral
– Trực tiếp gọi ứng viên
Sai lầm cần lưu ý
Có một sai lầm rằng thấy kênh nào “trendy” thì dùng kênh đó mà quên rằng mình đăng tin để tuyển nhân tài, nghĩa rằng mọi thứ phải đặt mục tiêu là ứng viên, hướng về ứng viên. TopDev sẽ cho bạn một số gợi ý để bạn có thể tự trả lời cho câu hỏi “Liệu mình có nên sử dụng kênh này để tuyển IT không?”
Số người tham gia hiện tại là bao nhiêu?
Có phương tiện truyền thông hay những người nổi tiếng trong lĩnh vực từng nói về nói chưa?
Những nền tảng cũ hơn có tính năng nào na ná không?
Nếu mình sử dụng kênh này cho tuyển dụng, ứng viên có thấy dễ dàng truy cập/sử dụng/tham gia không?
Liệu các ứng viên IT có hứng thú với những kênh mình sắp sử dụng không?
Loại nội dung nào là phù hợp với kênh đó?
Tuyển Dụng Nhân Tài IT Cùng TopDev Đăng ký nhận ưu đãi & tư vấn về các giải pháp Tuyển dụng IT & Xây dựng Thương hiệu tuyển dụng ngay!
Hotline: 028.6273.3496 – Email: contact@topdev.vn
Dịch vụ: https://topdev.vn/page/products
Bài viết được sự cho phép của tác giả Nguyễn Hữu Đồng
function_score
Khi search trong elasticsearch, đôi khi chúng ta mong muốn sẽ chấm điểm dựa trên những điều kiện đã đặt ra để lấy ra một danh kết quả chính xác.
Ví dụ khi bạn search những người có tên có chứa cụm từ “ste” và mong muốn nếu first_name tên đó là “steph ” thì + thêm 3 điểm hoặc nếu first_name của tên đó là “stephen” thì + 5 điểm, …vv, lúc này bạn chắc hẳn sẽ dùng đến function-score để custom hàm chấm điểm.
Như hình trên mỗi function-score là một kiểu “query”, chỉ là nó hơi đặc biệt, trong function-score, field “query” quy định điều kiện để mỗi index được chấm điểm như đoạn code trên.
"query": { "match_all": {} }
Điều này có nghĩa là mọi index sẽ được chấm điểm dựa, hoặc nếu như đoạn code đưới thì nếu index đáp ứng điều kiện là first_name hoặc last_name là “do” thì index sẽ được chấm điểm. Function-Score sẽ kết hợp điểm của query và điểm của function.
score_mode : định nghĩa các kết quả điểm được tạo ra bằng query và điểm tạo ra trong function (function trong function-scrore) sẽ được kết hợp như thế nào, có 6 kiểu nhân, cộng , trung bình cộng, max và min, hoặc là lấy điểm của function đầu tiên có filter match với index.
boost_mode : định nghĩa cách tính điểm khi mà có các điểm mới được tạo ra bằng function score, có 6 kiểu, nhân, cộng, trung bình cộng, thay thế, min, max
boost : điểm để tăng dùng để tính điểm cho các kết quả truy vấn bằng query ( query trong function_score)
functions : tập hợp các function để tính thêm với các index đã được chọn và tính điểm bằng “query”
Function trong Functions của Function-score là nơi chấm điểm cho các kết quả đã được trả về từ query, mỗi index được chấm điểm nếu nó match vs filter của function.
Như đoạn code trên nếu mỗi index sau khi chọn mà thoả mã filter trên thì sẽ được weight = 5 điểm trả về từ function. 5 Điểm này sẽ kết hợp với điểm của các function khác qua giá trị của “score-mode” ví dụ cộng lại điểm của các function hay lấy trung bình cộng, hoặc lên min,max … để trả về kết quả của “functions”.
Ngoài cách dùng functions tính điểm ta còn có thể dùng “script-score” để chấm điểm.
Nhìn sơ qua thì script score sẽ chạy một đoạn code với Index, dùng những tham số đã được truyền qua từ bên ngoài để trả về điểm.
Code demo, sau đây mình sẽ viết một query để chấm điểm cho những kết quả trả về khi mình search những user mà first_name hoặc last_name có chứa chữ “shar”, trả về 1 điểm và nếu first_name hoặc last_name là “sharland” thì mình sẽ cộng thêm 5 điểm.
Ở trên câu query trên, mình chỉ ra rằng, đầu tiền cần tìm ra những index có first_name hoặc last_name có chứa cụm từ “shar” và nếu có thì trả về 1 điểm cho những index này, sau đó tiếp tục tính điểm tiếp với function có filter, nếu index thoả mãn filter thì sẽ trả về 5 điểm.
Do mình setup “boost_mode = replace “ nghĩa là điểm của function score sẽ thay thế điểm của query trên, “score_mode = sum “, nhưng do chỉ có một function nên tổng điểm của functions = điểm của function.
Như các bạn thấy đó, function rất hữu dụng khi bạn muốn custom score trả về theo mong muốn, để tìm hiểu về function-score bạn có thể ghé thăm tại đây.
Cá nhân mình cũng mới tìm hiểu và không tránh khỏi nhiều sai sót, trong tương lai nếu có cơ hội mình sẽ chia sẻ tiếp về những điều thú vị của elasticsearch. Mình xin dừng bút tại đây, cảm ơn các bạn đã đọc bài ^_^
Đây là bài cuối trong loạt các bài về kiểm thử tự động. Bài này sẽ tổng hợp lại một số cách làm tốt nhất và các chiến lược để làm kiểm thử tự động.
Mặc dù những bài trước đã có đề cập đến vài cách làm hay (và vài điều sẽ được nhắc lại ở đây), bài này chỉ liệt kê vài điều, nhưng quan trọng nhất, để làm kiểm thử tự động.
Những chiến lược này không chỉ là từ kinh nghiệm bản thân mà còn từ những chuyên gia kiểm thử như Micheal Bolton, James Back và Cem Kaner. Những cách làm việc này nên được áp dụng trong mọi dự án kiểm thử tự động.
Thuê một đội ngũ hay kỹ sư kiểm thử chuyên trách
Đây là một điều cơ bản. Đừng đòi hỏi kỹ sư kiểm thử thủ công trong dự án tham gia vào kiểm thử tự động. Nếu chúng ta muốn họ phải làm được kiểm thử tự động, hãy giải phóng họ khỏi các công việc kiểm thử thủ công. Kiểm thử tự động là một công việc toàn thời gian. Để đạt được điều đó, chúng ta cần những nhân sự chuyên trách.
Một công cụ kiểm thử tự động là quan trọng, nhưng nó không phải là giải pháp cho tất cả
Chúng ta đã nói về cách lựa chọn một công cụ kiểm thử. Nhưng lựa chọn được một công cụ đúng chỉ là bước khởi đầu. Vài người quản lý có hiểu lầm rằng, nếu có một công cụ đúng, mọi chuyện về kiểm thử tự động sẽ dễ dàng. Hãy cẩn thận, công cụ kiểm thử tự động không cho chúng ta mọi thứ. Chúng chỉ làm cho quá trình tự động hóa dễ dàng hơn. Và chúng ta cần những nhân sự có kỹ năng để hoàn thành quá trình đó.
Thông thường, những công cụ kiểm thử tự động cũng có lỗi của nó và chúng gặp vấn đề khi xác định những đối tượng UI phức tạp của ứng dụng. Nhân sự mà chúng ta có, nếu họ có kỹ năng, sẽ đưa ra những giải pháp để đẩy nhanh quá trình làm việc. Ngược lại, nếu nhân sự không tốt, chỉ với công cụ không thể đảm bảo cho một dự án kiểm thử tự động thành công.
Lựa chọn công cụ kiểm thử quen thuộc với nhân sự đang có
Nếu nhân sự của chúng ta quen thuộc với C# và ứng dụng cần kiểm thử cũng phát triển bằng C#, vậy thì không có lý do nào để chúng ta lựa chọn một công cụ kiểm thử không hỗ trợ viết mã bằng C#.
Học ngôn ngữ lập trình là một quá trình tốn kém thời gian. Bỏ qua được bước này bằng cách sử dụng một công cụ hợp lý sẽ tối thiểu hóa thời gian làm quen với công cụ.
Hiểu biết về ứng dụng cần kiểm thử
Lựa chọn công cụ kiểm thử tự động phụ thuộc vào độ nặng của công nghệ được dùng trong ứng dụng. Hiểu biết về ứng dụng từ trong ra ngoài trước khi bắt đầu việc kiểm thử tự động.
Nếu là một ứng dụng web, biết về những trình duyệt mà nó sẽ hỗ trợ. Biết về những công nghệ được sử dụng trong nó. Nếu là một ứng dụng Desktop, biết về ngôn ngữ để xây dựng nó. Những đối tượng của bên thứ ba được dùng trong ứng dụng. Những điều này sẽ giúp chúng ta lựa chọn công cụ chính xác và kiểm thử tự động trong tương lai sẽ dễ dàng hơn.
Kiểm thử tự động tốt nghĩa là các kịch bản kiểm thử thủ công tốt
Những kịch bản kiểm thử thủ công tốt sẽ tiết kiệm công sức tự động hóa những kịch bản dễ được làm tự động nhưng không đủ mạnh để tìm lỗi.
Kết quả của việc tự động hóa mà không dựa vào thiết kế kiểm thử tốt là có quá nhiều việc để làm nhưng giá trị mang đến lại chẳng bao nhiêu.
Luôn luôn nên viết kịch bản kiểm thử ở định dạng dành cho kiểm thử thủ công. Xác định tất cả các điều kiện quyết định và dữ liệu kiểm thử. Viết các bước rõ ràng và viết các kết quả mong muốn cho các bước. Mục tiêu của từng kịch bản nên rõ ràng và nó nên độc lập với những kịch bản kiểm thử khác. Kỹ sư kiểm thử tự động nên thực thi kịch bản kiểm thử một cách thủ công, ít nhất một lần, để quyết định các đối tượng nào cần xác định và luồng làm việc. Nên tham khảo thêm từ những kỹ sư kiểm thử thủ công.
Hoạt động này, đôi khi, giúp xác định lỗi ngay cả trước khi bắt đầu viết mã kiểm thử. Những chuyên gia cho rằng, đa số các lỗi được xác định trong giai đoạn phát triển mã kiểm thử hơn là giai đoạn thực thi các mã đó.
Xác định mọi cơ hội với tự động hóa
Nếu chúng ta được giao kịch bản kiểm thử để tự động hóa, đừng chỉ tự động hóa bản thân kịch bản đó. Thay vào đó, hãy tìm kiếm những cơ hội trong việc tự động hóa đó, mở rộng giới hạn của kịch bản kiểm thử đó.
Ví dụ, nếu kịch bản kiểm thử yêu cầu chúng ta đăng nhập vào một hệ thống. Chúng ta có thể mở rộng kịch bản này bằng cách sử dụng hướng-dữ-liệu. Liệt kê toàn bộ nhựng kịch bản khả thi của việc đăng nhập như mật khẩu không hợp lệ, mật khẩu rỗng, tên đăng nhập rỗng, tên đăng nhập không hợp lệ, v.v… liệt kê nhưng kịch bản khả thi này vào trong một tập tin Excel và xem tập tin đó như một nguồn dữ liệu cho kịch bản kiểm thử. Và giờ, với một kịch bản kiểm thử ban đầu, với tự động hóa, chúng ta có thể kiểm thử toàn bộ kịch bản khả thi với một lần thực thi.
Luôn luôn tìm kiếm những cơ hội có thể làm với tự động hóa, những việc khó làm với cách làm thủ công. Như kịch bản kiểm thử sức tải, kiểm thử hiệu suất, cùng một kịch bản trên nhiều môi trường khác nhau, cấu hình khác nhau, v.v… đó là những kịch bản khó có thể làm với kiểm thử thủ công.
Chúng ta không thể tự động hóa mọi thứ
Kiểm thử tự động chỉ thực thi những kịch bản nào mà yêu cầu phài thực thi thường xuyên. Chúng ta bắt đầu với bộ kịch bản Smoke trước. Sau đó, đến bộ kịch bản cho kiểm thử chấp nhận. Rồi đến những kịch bản phải sử dụng thường xuyên, và những kịch bản mà tốn nhiều thời gian. Nhưng phải đảm bảo rằng mỗi kịch bản mà chúng ta đã tự động hóa, nó phải tiết kiệm thời gian cho kỹ sư kiểm thử thủ công để tập trung vào những thứ quan trọng khác.
Tự động hóa ở đây không phải để thay thế kỹ sư kiểm thử thủ công. Nó không thể. Tự động hóa có mặt để làm những công việc lặp đi lặp lại thay cho kỹ sư kiểm thử thủ công để họ dành sự tập trung và sức lực cho việc tìm kiếm những kịch bản kiểm thử mới và lỗi mới.
Tự động hóa những kịch bản giá trị và tiết kiệm thời gian hay khó để làm với kiểm thử thủ công. Nếu chúng ta làm được điều đó, công việc của kiểm thử tự động đã hoàn thành.
Bỏ qua kiểm thử tự động GUI khi có những giải pháp thay thế
Kiểm thử tự động GUI luôn là phần khó khăn hơn những kiểu kiểm thử tự động khác. Vậy nên, nếu có những tình huống mà chúng ta có thể đạt được mục tiêu mà không cần đụng đến GUI, bằng cách dùng các phương pháp khác như câu lệnh, thì chiến lược chính xác là bỏ qua phần kiểm thử tự động trên GUI.
Ví dụ, chúng ta cần kiểm thử sự cài đặt của một ứng dụng. Mục tiêu là kiểm tra ứng dụng có được cài đặt hay không trên một môi trường cụ thể. Một cách tiếp cận là khởi động chương trình cài đặt và nhấn vào “Next” liên tục thông qua công cụ kiểm thử tự động. Cách này khá khó để áp dụng, tốn kém thời gian và nó là một vấn đề khi bảo trì khi mà UI thay đổi. Một cách tiếp cận khác là khởi động quá trình cài đặt bằng câu lệnh với một tham số “silent”. Ứng dụng sẽ được cài đặt mà không có một GUI nào. Mục tiêu của kiểm thử sẽ đạt được với thời gian ít hơn và đáng tin cậy hơn.
Tự động hóa
Dùng tự động hóa cho những mục đích hữu ích khác
là một thứ tuyệt với. Chúng ta có thể đạt được nhiều thứ từ nó mà có thể chúng ta chưa từng nghĩ đến. Tự động hóa không chỉ là viết mã cho một kịch bản kiểm thử thủ công. Hơn thế, chúng ta có thể dùng tự động hóa để làm nhanh những hoạt động khác trong dự án.
Ví dụ, chúng ta có thể dùng tự động hóa để tạo những dữ liệu chính và thiết lập cấu hình môi trường một cách tự động cho kỹ sư kiểm thử thủ công. Sau đó, họ có thể bắt đầu việc kiểm thử của họ sớm nhất có thể.
Tôi có thể đưa cho các bạn một ví dụ từ công ty của tôi. Chúng tôi muốn thay đổi công cụ quản lý kiểm thử. Chúng ta đã dùng “Test Director” (HP ALM) và muốn chuyển sang dùng TFS (Team Foundation Server). Chúng ta có khoảng 4000 kịch bản kiểm thử và báo cáo lỗi trong Test Director. Chuyển toàn bộ dự liệu này sang TFS có thể mất cả tháng nếu làm thủ công. Do đó, quản lý của tôi yêu cầu tôi thử vài cách tự động hóa.
Tôi tìm hiểu vài công cụ và thấy rằng, Test Director sử dụng SQL Server làm cơ sở dữ liệu. Với TFS, tôi tìm ra một công cụ cho phép đọc kịch bản kiểm thử và báo cáo lỗi từ tập tin Excel, nếu nó có một định dạng cụ thể, và có thể ghi vào TFS. Phần còn lại của câu chuyện thật đơn giản. Tôi viết một đoạn SQL để lấy toàn bộ kịch bản kiểm thử và báo cáo lỗi, và ghi nó ra một tập tin Excel với một định dạng xác định. Sau đó, tôi dùng công cụ để đọc những dữ liệu này và ghi vào TFS. Toàn bộ quá trình chỉ mất khoảng 3 giờ. Quản lý của tôi rất hài lòng. Tôi hy vọng bạn thấy được vấn đề tôi đang nói ở đây.
Kiểm thử tự động là phát triển phần mềm
Nếu chúng ta phát triển một ứng dụng chất lượng, nó cần những bài thực hành tốt. Nó cần xem xét mã nguồn để viết mã có chất lượng. Nó cần một khuôn khổ để đi theo. Nó cần bảo trì liên tục.
Kiểm thử tự động về cơ bản là việc phát triển phần mềm. Do đó, những bài thực hành tốt nhất mà chúng ta đi theo khi phát triển ứng dụng cũng nên được áp dụng khi làm kiểm thử tự động. Khuôn khổ kiểm thử tự động nên có. Xem xét mã nên được tiến hành. Lỗi của kiểm thử tự động nên được báo cáo trong kho lỗi. Mã nguồn của kiểm thử tự động nên được để trong một hệ quản lý mã nguồn, v.v… chúng ta càng xem việc kiểm thử tự động giống phát triển ứng dụng, kiểm thử tự động càng thành công.
Kết luận
Đây là kết thúc bài này cũng như toàn chuỗi bài về kiểm thử tự động. Tôi đã học được nhiều thứ khi viết chuỗi bài này và tôi hy vọng bạn cũng học được khi đọc chúng. Kiểm thử tự động là một sự nghiệp đầy hứng khởi và xứng đáng. Làm nó đúng không chỉ mang lại lợi ích cho chúng mà còn cả cho công ty/dự án.
Mỗi ngày làm việc với kiểm thử tự động và những kỹ thuật của nó, tôi tìm thấy nhiều thách thức mới và hấp dẫn cần giải quyết. Chuỗi bài này chỉ đánh dấu vài thứ trên con đường kiểm thử tự động. Tôi hy vọng tôi chuyển tải nó đến các bạn một cách chính xác và rõ ràng.
Cơ bản là dạo này nhiều việc linh tinh lớn chiếm nhiều thời gian quá, thành ra không còn nguồn lực dành cho viết bài được, vẫn là tranh thủ thời gian chờ thang máy đọc mấy cái linh tinh thì mới lại nhớ ra mấy trò hay ho này nên tổng hợp thành một bài, danh sách có nhiều thứ và ở nhiều chủ đề khác nhau cơ, nhưng cơ bản là lười với lại vẫn là không sắp xếp được thời gian nên là chỉ có nhiêu đây thôi :))
Ngoi lên chút để thấy là mình vẫn không quên cái trang blog này, đã bao lâu rồi, đã bao nhiêu món nợ chưa trả được… ây za.. nhưng mà yên tâm, mình sắp trở lại rồi đây!!!!!
1. Sinh tự động chuỗi ký tự trong Word và Excel
Chắc hẳn là trong chúng ta đã từng rơi vào trường hợp kiểu như là muốn ghi nháp một vài từ nào đó mà tự dưng ko biết ghi cái gì đành gõ bừa bàn phím một cách loạn xạ và nhanh nhất có thể. Từ nay khi biết đến sự tồn tại của hàm này bạn sẽ có thể nhanh chóng tạo ra được một đoạn ký tự mẫu đẹp mắt và chuyên nghiệp hơn.
Trong MS Word, chỉ cần gõ: =rand() sau đó nhấn enter, lúc này Microsoft Word sẽ tự động sinh ra một đoạn ký tự ngẫu nhiêu mà bạn không cần phải gõ thêm tí nào nữa.
Với hàm trên, ta cũng có thể thêm các đối số cho nó ví dụ như =rand(2,3), lúc này đoạn ký tự được sinh ra sẽ có 2 đoạn, mỗi đoạn sẽ có 3 câu.
Bên cạnh =rand(), MS cũng cung cấp một số hàm khác mà bạn có thể sử dụng với tính năng tự như:
=lorem() và =rand.old()
Còn với MS Excel, hàm =rand() sẽ giúp bạn sinh một số thập phân ngẫu nghiên nằm trong khoảng từ 0 đến 1. :D. Hoặc có thể sinh một số ngẫu nhiên trong một khoảng số nào đó thì có thể dùng hàm =randbetween(lớn hơn số này, nhỏ hơn số này), ví dụ: =randbetween(45;80) – thì có nghĩa là sinh ngẫu nhiên 1 số nằm trong khoảng từ 45 đến 80, ta có thể kéo công thức này cho các ô phía dưới hoặc bên cạnh như hình minh họa phía dưới.
2. Tìm kiếm linh hoạt và chủ động hơn với Google
Đơn giản như bạn muốn tìm nhanh thông tin hoặc tài liệu theo định dạng file cụ thể nào đó, thì chỉ cần gõ từ khóa tìm kiếm đó vào ô tìm kiếm của Google với cú pháp sau:
Filetype:file_format
Ví dụ gõ: ISTQB filetype:pdf > nhấn Enter => Kết quả tìm kiếm sẽ hiển thị tương tự như hình phía dưới đây.
Tương tự đối với các loại định dạng file khác nhau, có thể là doc, pttx, xlsx… bất kỳ định dạng nào mà bạn muốn tìm kiếm đều có thể sử dụng cách tìm kiếm này để tối ưu hơn.
Bên cạnh tips nhỏ phía trên, ta còn có thể sử dụng trực tiếp công cụ tìm kiếm nâng cao của Google bằng cách nhấn nào link Cài đặt > Tìm kiếm nâng cao. (https://www.google.com/advanced_search)
Ở tìm kiếm nâng cao, chúng ta có thể tùy chọn việc tìm kiếm còn linh hoạt hơn nữa, với các tiêu chí cụ thể hơn. Các bạn tham khảo hình, và thử tìm kiếm vài thứ xem sao nhé!
3. Hẹn giờ tắt máy
Có khá là nhiều cách để tắt máy tính sau khi làm việc, thường thi sau khi làm việc xong thì chỉ cần nhấn nút nguồn là máy tắt, chọn Start > Shutdown là xong. Còn không thì cứ để máy ngâm đó, sau khoảng thời gian máy sẽ tự sleep…
Trò này thì có thể không phải chị em nào cũng biết, vậy thì hôm nay mình giới thiệu thêm cho các bạn một trò tắt máy khác là dùng run, gõ lệnh shutdown –s
Có cái này còn hay hơn là hẹn giờ để tắt máy, nghĩa là mình muốn sau khi mình đi khỏi chỗ 30 phút thì mới thực hiện tắt máy, vẫn dùng run, gõ lệnh “shutdown -s -t 1800″ (Sau 30 phút = 1800 giây)
Hihi, chắc hẳn cái này không có gì là mới, nhưng cũng có thể là không nhiều người biết, cứ chia sẻ thôi nha
4. Một vài phím tắt hay ho có thể dùng trong các trình duyệt
Alt+D → Address bar – Bôi đen nhanh địa chỉ web tại tab đang mở
Ctrl+N → New Window – Mở nhanh của sổ trình duyệt mới
Ctrl+Shift + N → New Incognito Window – Mở cửa sổ trình duyệt ẩn danh mới
Ctrl+T → Open New Tab – Mở một tab mới tại trình duyệt đang mở
Ctrl+Tab → Toggle between Tabs – Chuyển qua lại giữa các tab đang mở trong cửa sổ trình duyệt
Ctrl+Number → Switch to the numbered tab (Ex: Ctrl+2 → Switch to 2nd tab) – Chuyển sang trình duyệt ở số thứ tự tương ứng, ví dụ nhấn Ctrl +2 thì trình duyệt sẽ nhảy sang tab thứ 2 trong cửa sổ trình duyệt đó.
Ctrl+F4/Ctrl+W→ Close current tab – Đóng tab hiện tại
Ctrl+Shift+T → Reopen recently closed tab – Mở lại tab vừa đóng. – Hữu ích khi mà nhỡ tay đóng mất tab không muốn đóng.
Ctrl+Left_Click → Open link in a New Tab – Nhấn để mở link trong tab mới
Ctrl+H → History – Hiển thị lịch sử duyện web
F11 → Full Screen Browsing – Hiển thị trình duyệt toàn màn hình
Ctrl+Enter → Adds “www.” at start and “.com” at the end of the word you type in address bar – Sau khi nhập vào một chuỗi ký tự, nhấn tổ hợp phím này thì thanh địa chỉ trình duyệt sẽ add thêm “www.” vào đầu và “.com” vào cuối chuỗi ký tự mình nhập vào trước đó.
Ví dụ: khi gõ chữ “pinterest” sau đó nhấn tổ hợp phím “Ctrl+Enter” thì trình duyệt sẽ tự thêm và duyệt đến địa chỉ web là www.pinterest.com
Nói chung thì có khá là nhiều trò hay ho nhưng mà để tổng hợp dần dần, bản thân mình thấy các phím tắt sử dụng với trình duyệt kia không phải là ít người biết đến, với cũng thường dùng chuột quen rồi, tuy nhiên nếu hạn chế chuột thì mình thấy sử dụng phím sẽ nhanh và tiện hơn rất nhiều.
Hầu hết trong bài viết này là những cái mà mình đã từng và có cái là sử dụng liên tục, có thể nói là hàng ngày (trừ thứ 7, chủ nhật) vậy nên cũng rất vui nếu giúp ích ai đó trong việc làm cho công việc thường ngày đỡ nhàm chán đôi khi mang đi thể hiện với những người không chuyên còn thấy rất ngầu nữa =)) Haha
Việc tạo, thật ra sử dụng những thư viện có sẵn (jsonwebtoken nếu bạn đang dùng Node.js), bạn chỉ cần quan tâm những giá trị đã hoặc muốn nhét thêm trong JSON
Một trường tối quan trong trong JSON là expiresIn, cho phép token sẽ expire sau bao lâu.
Việc validate, thì dùng thư viện nào tạo token, nó sẽ có luôn phương thức để kiểm tra token đó có hợp lệ không.
Phía client dùng SPA
So sánh định danh bằng Session và Token
Giống nhau
Chức năng như nhau, để định danh
Sau khi định danh ở Backend, nó trả về token cho client
Gửi kèm token trên khi muốn dùng một service ở phía backend
Khác nhau
Session thì dữ liệu và trạng thái đăng nhập của user được lưu ở bộ nhớ phía server. Không phù hợp với RESTful APIs, mỗi service đều phải stateless, anh là ai, anh từ đâu tới đều phải đưa chứng minh nhân dân chứ chúng tôi không ai rảnh đầu ngồi nhớ mặt hết những ai ra vào service.
Session sẽ lưu thông tin về user ở cookie của trình duyệt, vấn đề là các service có thể khác domain, trình duyệt không biết và sẽ không đưa thông tin cookie cho các domain khác
Vấn đề với XSS và CSRF khi dùng JWT
Hết sức thận trọng khi xử lý JWT trong code, token là mồi ngon cho XSS và CSRF
Tuyệt đối không dùng local storage để lưu JWT trên phía frontend. Localstorage có thể được truy xuất bằng JS cùng domain, attacker có thể dùng điểm này để inject thêm mã để lấy local storage. (XSS)
Vì cookie được gửi trên tất cả request, attacker có thể lợi dụng điểm này để gửi một link yêu cầu đổi password (CSRF)
Nếu không còn lựa chọn nào khác, lưu trong bộ nhớ, lưu ý sẽ mất khi user refresh.
Cookie thật ra không phải là không dùng được, nhưng dùng thì phải kiểm tra
Dùng httpOnly để cookie không thể được truy cập thông qua JS
Dùng SameSite để hạn chế cấp phát cookie đi các domain chỉ định. Nếu phải đưa qua nhiều domain khác nhau, dùng Lax, nó cho phép gọi truyền cookie khác domain nếu là GET
Nếu muốn 100% an toàn tuyệt đối, một số cái giá phải trả, như tắt cross-domain request.
Nếu sử dụng axios, và backend tạo cookie đúng chuẩn, để axios lo phần đó cho an toàn, không cần lo việc xử lý token, cookie một cách thủ công, thiếu chuyên nghiệp.
HTTPS có đảm bảo an toàn tuyệt đối cho site, là yêu cầu bắt buộc khi sử dụng JWT?
100% bảo mật là con số chưa ai giám nhận, hay nói tẹc ra là không thể. Sẽ luôn có đâu đó một con người tài giỏi, thông minh hơn bạn, họ sẽ tìm được cách tấn công phù hợp. May mắn thay những người xuất chúng như vậy họ cũng có đạo đức cao và không rảnh để làm những việc quá tầm thường. Đừng có lên mạng mà “Anh đố chú hack được site anh!”
HTTPS là cơ chế encrypt thông tin đi-về giữa client và server, đảm bảo không có người ngoài nào có thể dòm ngó và đọc được bạn đang gửi gì, nhưng nếu nó đã chui được vào nhà bạn rồi thì thành thật mà nói HTTPS cũng không phải là cánh cửa chỉ có bạn mở được.
Khi nào không nên dùng JWT
Nếu bạn đang muốn sử dụng một stateful backend, JWT là thừa thãi không cần thiết.
Đúng như tên gọi, hệ thống này giúp bạn follow rất nhiều chiến dịch của các thương hiệu lớn cũng như timeline triển khai dự án và analytics của từng chiến dịch.
Dựa vào những campaign này, và những số liệu thực tế, bạn hoàn toàn có thể có những chiến dịch Email Marekting phù hợp
Website cung cấp template viết bằng CSS và HTML5 miễn phí nhưng cực kì chất lượng Hiện website có khoảng 845 template, tất cả đều được thiết kế theo phong cách hiện đại.
Những template này đều hỗ trợ giao diện responsive, được thiết kế và code bởi Cherry + AJ và được xuất bản theo giấy phép Creative Commons. Bạn có thể sử dụng miễn phí những template này cho nhu cầu cá nhân hoặc thương mại.
5. EMOTIFY – EMOTIONAL INTELLIGENCE FOR YOUR WEBSITE
Bạn thấy các tương tác cảm xúc của Facebook rồi chứ? Hệ thống này cũng tương tự, nó sẽ giúp bàn chèn những icon cảm xúc và người dùng sau khi đọc xong hoặc sử dụng xong sản phẩm của bạn, họ có thể phản hồi về những điều họ cảm thấy.
Vì hệ thống này free, nên bạn hãy cứ thử nghiệm đi nhé 😉
Đây là một công cụ kiểm tra hiệu suất website từ Google. Công cụ này sẽ hiển thị trạng thái, hiệu suất hoạt động của blog/website và hướng dẫn cho bạn cách để cải thiện nó.
Bài viết được sự cho phép của tác giả Trần Duy Thanh
Mấy ngày này cái tên Kotlin đã tạo nên một cơn địa chấn làm rung chuyển giới công nghệ, bạn đã xem phim “Đường Sơn Đại Địa Chấn” chưa? nếu bộ phim vô cùng hay này đã cướp đi không biết bao nhiêu nước mắt của khán giả thì Kotlin làm điều ngược lại, nó lan tỏa không biết bao nhiêu nụ cười cho giới lập trình viên bởi nhiều tiện ích mà nó đem lại. Đặc biệt ngày 17/05/2017 vừa rồi Google đã công bố Kotlin trở thành ngôn ngữ lập trình Android chính thống giáo, từ phiên bản Android Studio 3.0 các lập trình viên có thể tha hồ tung hoành!
Và Tui dự đoán rằng: Trong tương lai sẽ có làn sóng mạnh mẽ về tuyển dụng lập trình viên Android bằng ngôn ngữ Kotlin, các công ty sẽ rất khát nhân lực, các bạn cần nhanh chóng nghiên cứu Kotlin để đi đầu về công nghệ.
Nếu bạn còn bảo lưu quan điểm Chậm Mà Chắc, thì Tui nghĩ nó không còn đúng nữa. Thời đại này khác xưa rồi, các bạn phải Nhanh Mà Chắc mới hơn người ta được, đừng chờ cho tới khi Kotlin quá phổ biến thì lúc đó bạn là người đến sau. Hãy chiến đấu ngay từ bây giờ để đi đầu về công nghệ!
Hi hi hi, nghe tới đây bạn Đã Ghiền Kotlin chưa? Ngày xưa Tui học Văn là dốt nhất lớp, toàn bị 4.5 điểm, nên cố gắng lắm mới viết được một chút ít giới thiệu về Kotlin
ha ha – nhìn hình này có vẻ Toptal nói Java già cỗi
Kotlin có nhiều ưu điểm, ở đây Tui liệt kê một số để các bạn tham khảo (dĩ nhiên các bạn có thể tìm hiểu thêm):
Ngắn gọn như thế nào?
Ta có thể dễ dàng viết các POJO (Plain Old Java Object) trên một dòng :
Và còn nhiều cách viết ngắn gọn khác nữa, các bạn có thể tham khảo thêm trên http://kotlinlang.org/
An toàn như thế nào?
Kotlin tự động kiểm tra lỗi biễn dịch Null pointer exception, các hành vi trên tập dữ liệu null, tự động ép kiểu đúng một cách chính xác cho ta, ví dụ so sánh:
Đa năng như thế nào?
Phải nói Kotlin có thể làm các multiplatform applications. Có thể build Kotlin cho Server-side , cho Android, cho Javascript, Native….
Khả năng tương tác như thế nào?
Kotlin có thể sử dụng được 100% các thư viện từ JVM, có thể dễ dàng từ Kotlin triệu gọi Java và từ Java triệu gọi Kotlin. Giúp các Lập trình viên không lo lắng về việc chuyển đổi coding, tăng khả năng tương tác mạnh mẽ trong hệ thống.
Ngoài ra Kotlin còn có thể dễ dàng lập trình trên nhiều công cụ khác nhau: Website, Eclipse, Netbeans, Android Studio, JetBrains… Tài liệu lập trình phong phú, cộng đồng hỗ trợ Kotlin ngày càng không ngừng phát triển.
Các cuốn sách Lập trình viên có thể nghiên cứu:
1.Kotlin in Action
Cuốn sách có 11 chương, giúp bạn hiểu rõ về Kotlin từ cơ bản tới nâng
2.Kotlin for Android Developers
Sách dành cho những ai đã rành về Kotlin, tiếp tục phát triển Kotlin bên Android (phần đầu vẫn dạy về Kotlin), được xé nhỏ thành 26 chương giúp ta dễ dàng học
3.Modern Web Development with Kotlin
Cuốn sách dạy về Web với Kotin, đặc biệt EcmaScript 6 chuẩn mới nhất, Json….Các bạn quan tâm có thể học, khoảng 115 trang.
4.Programming Kotlin
Cuốn này cũng tương tự, giúp ta có thể học tốt Kotlin. Bố trí thành 13 chương (420 pages ) các bạn có thể bám theo cuốn này để học
5.Fundamental Kotlin
Cuốn sách này khá hay, bạn có thể tham khảo.
Chúc các bạn nhanh chóng học tốt Kotlin, hẹn gặp các bạn ở những bài sau
Low coupling và high cohesion là 2 thuộc tính đi cùng với nhau như là mục tiêu cần đạt được trong thiết kế, trong bài viết này, cùng tìm hiểu xem chúng là gì, làm sao để đạt được và tránh các lỗi liên quan đến coupling và cohesion khi thiết kế phần mềm.
COUPLING
Low coupling, loose coupling hay high coupling và tight coupling, ắt hẳn ai trong chúng ta khi học về các nguyên lý lập trình căn bản đều biết về khái niệm coupling này. Coupling đề cập đến vấn đề phụ thuộc lẫn nhau giữa các component. Low coupling, loose coupling có nghĩa là các component ít phụ thuộc vào nhau, sự thay đổi trong component này ít khi, hoặc không ảnh hưởng đến component kia. Ngược lại, high coupling và tight coupling cho thấy các component phụ thuộc nhiều vào nhau, khi thay đổi 1 component thì các component kia đều bị ảnh hưởng và có khả năng phải thay đổi theo. Tất nhiên, low coupling là mục tiêu chúng ta cần hướng đến để đảm bảo cho hệ thống ít bị ảnh hưởng khi có thay đổi và do đó, tăng tốc độ thực hiện công việc và bảo trì.
Trong câu hỏi trên StackOverflow có một câu trả lời cho thấy một mô tả hài hước nhưng khá chính xác và rõ ràng về những gì 1: 1 coupling là:
iPod là một ví dụ tốt về tight coupling: một khi pin chết bạn cũng có thể mua một chiếc iPod mới vì pin được hàn cố định và sẽ không bị lỏng, do đó thay thế rất tốn kém. Một cái máy có tính loosely coupled sẽ cho phép thay đổi pin dễ dàng.
iPods are a good example of tight coupling: once the battery dies you might as well buy a new iPod because the battery is soldered fixed and won’t come loose, thus making replacing very expensive. A loosely coupled player would allow effortlessly changing the battery.
Tương tự, 1: 1, trong phát triển phần mềm.
Chúng ta sẽ xem xét diagram dưới đây:
Nếu chúng ta nhìn vào hình trên, nó cho chúng ta thấy một mối liên hệ giữa hai class được gọi là tight coupling. Class1 ở trên tạo ra các đối tượng của Class2 trực tiếp, và thậm chí là đi đến các biến thành viên và truy cập vào. Điều này làm cho nó rất phụ thuộc vào Class2. Điều gì sẽ xảy ra nếu chúng ta quyết định rằng chúng ta muốn thêm tham số thêm vào trong constructor của Class2 và đặt mặc định là private? Sau đó, chúng ta phải thay đổi mọi cách sử dụng Class2 ở mọi nơi. Không đẹp lắm, heh? Có thể là một cơn đau đầu rất lớn và là một trong những vấn đề đầu tiên trong thiết kế.
Dưới đây là ví dụ bằng code:
public class ClassA {
private boolean attributeA;
public int methodA() {
if(attributeA) {
return new ClassB().attributeB;
}
return -1;
}
public String getValue() {
return new ClassB().getValue();
}
}
public class ClassB {
public int attributeB;
public String getValue() {
return "Heh?!?";
}
}
Ví dụ trong Java, ta sẽ thêm một interface. Đó là cách Class1 sẽ chỉ phụ thuộc vào interface đó, chứ không phải là implementation thực tế của Class2, do đó giảm thiểu sự phụ thuộc trực tiếp giữa 2 class với nhau.
Lợi điểm của Law of Demeter là nó giúp hệ thống của chúng ta đứng vững trước những thay đổi bằng cách giảm coupling hay còn gọi là cách design loose coupling, mọi sự thay đổi sẽ là nhỏ nhất nếu có thể.
COHESION
Còn high cohesion (trái ngược với nó là low cohesion) là gì? Khi nói đến cohesion chúng ta nghĩ đến nhiệm vụ của từng module. Nhiệm vụ của từng module càng rõ ràng và tách biệt thì cohesion càng cao (high cohesion), và đó là mục tiêu cần đạt tới khi thiết kế. Giải thích bằng code có lẽ sẽ không rõ ràng, hãy xem xét câu dưới đây:
Tại kỳ họp Quốc hội thứ năm, khi thảo luận về quản lý chất lượng vệ sinh an toàn thực phẩm có vị đại biểu Quốc hội đã ví việc có tới 5 bộ chịu trách nhiệm chính như vậy cũng giống như “nhiều sãi không ai đóng cửa chùa”.Bởi thế, làm rõ trách nhiệm của từng cơ quan quản lý Nhà nước về an toàn thực phẩm là một yêu cầu được nhấn mạnh khi xây dựng Dự Luật An toàn thực phẩm.
Nếu xem Dự Luật An toàn thực phẩm là một feature thì rõ ràng nó đã không đạt được tính high cohesion trong thiết kế vì nó phải dàn trải và phụ thuộc vào rất nhiều module (5 bộ, phòng ban) khác nhau. Do đó, khi cần chỉnh sửa bổ sung dự luật sẽ rất khó khăn vì phải sửa 1 lúc 5 module, mà bạn thấy đó, điều đó rõ ràng là rất khó. Nếu quy trách nhiệm xây dựng bộ luật này cho một bộ ban duy nhất thì sẽ giảm tính phức tạp và do đó, tăng tính cohesion. High cohesion thường đạt được nếu ta tuân thủ theo nguyên tắc đơn nhiệm (Single responsibility principle), mỗi module, khi đó chỉ đảm nhiệm một nhiệm vụ duy nhất, không hơn không kém, và không có chuyện 2 module cùng làm một nhiệm vụ, một tính năng.
Đến đây chắc ai cũng hiểu được rồi đúng không? Ít nhất là về mặt lý thuyết, hãy xem xét bảng sau trước khi mình đi vào các dẫn giải tiếp theo.
Bài viết được sự cho phép của tác giả Nguyễn Trần Chung
Laravel 8 bổ sung một phương thức hoàn toàn mới để giúp việc thay đổi giá trị auto increment trở nên dễ dàng và đây là thông báo chính thức được đưa ra trên Twitter của Taylor Otwell:
Sneaking this into Laravel 8.x today… 👨🔬 pic.twitter.com/Bg24S7iX4j
— Taylor Otwell 🛸 (@taylorotwell) September 6, 2020
Việc thay đổi auto-increment thông qua các nền tảng cơ sở dữ liệu (database platforms) khác nhau luôn có thể thực hiện được, nhưng bạn cần thực hiện điều đó thông qua một lệnh thô (raw command). Với việc bổ sung phương thức startValue, điều này cho phép bạn thiết lập số đầu tiên để tăng tự động sẽ bắt đầu.
Đối với hầu hết các ứng dụng, bạn có thể sẽ không cần điều này nhưng trong những trường hợp bạn không muốn người dùng biết rằng ứng dụng của bạn chỉ có 10 người dùng, thì đây là một tùy chọn rất hữu ích phải k nào.
Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh
Khái niệm transaction trong database là một khái niệm quan trọng mà tất cả các lập trình viên nên biết bởi vì chúng ta sẽ làm việc rất nhiều với khái niệm này. Trong bài viết này, mình xin trình bày với các bạn về khái niệm này!
Để dễ hình dung, mình xin lấy một ví dụ như sau: chúng ta đang làm việc với một ứng dụng bên ngân hàng, ứng dụng này có một tính năng đó là chuyển tiền giữa các tài khoản ngân hàng với nhau, ví dụ chuyển tiền cho tài khoản A sang tài khoản B. Đây là một tính năng mà quá trình xử lý sẽ gồm 2 bước:
Rõ ràng, như các bạn thấy, đây là một quá trình nếu gọi là thành công thì bắt buộc 2 bước trên phải thành công, hoặc nếu thất bại thì bắt buộc 2 bước trên cũng phải thất bại luôn. Nếu chỉ một trong 2 bước trên thành công hoặc thất bại thì chúng ta sẽ gặp vấn đề ngay. Và chúng ta khi xây dựng ứng dụng cũng phải đảm bảo 2 điều kiện trên.
Đây chính là ý tưởng chính của khái niệm transaction trong database. Trong database, một transaction là một tập hợp các thao tác mà ở đó hoặc là các thao tác đó được thực hiện thành công, hoặc là không một thao tác nào được thực hiện thành công cả. Khi các bạn suy nghĩ về transaction trong database, các bạn hãy hình dung nó là “hoặc là tất cả hoặc là không gì hết”.
Ở đây, chúng ta có một chữ viết tắt ACID (Atomicity, Consistency, Isolation, Durability) định nghĩa các tính chất của một transaction trong database.
Trong đó:
Atomicity: tính chất này thể hiện khái niệm “hoặc là tất cả hoặc là không gì hết”. Toàn bộ các bước được thực hiện trong một transaction nếu thành công thì phải thành công tất cả, nếu thất bại thì tất cả cũng phải thất bại. Nếu một transaction thành công thì tất cả những thay đổi phải được lưu vào database. Nếu thất bại thì tất cả những thay đổi trong transaction đó phải được rollback về trạng thái ban đầu.
Trong ví dụ của mình, rõ ràng khi đã trừ tiền trong tài khoản A thì bắt buộc việc cộng tiền vào tài khoản B phải xảy ra. Còn không thì không có gì xảy ra hết, đã không trừ tiền trong tài khoản A thì chắc chắn rồi, việc cộng tiền vào tài khoản B cũng không xảy ra.
Consistency: dữ liệu từ thời điểm start transaction với lúc kết thúc phải nhất quán.
Trong ví dụ của mình thì, nếu đã trừ 10$ trong tài khoản A thì trong tài khoản B phải được cộng 10$.
Isolation: nếu chúng ta có nhiều transaction cùng một lúc thì phải đảm bảo là các transaction này xảy ra độc lập, không tác động lẫn nhau trên dữ liệu.
Trong ví dụ của mình, giả sử cùng môt lúc xảy ra 2 transaction như trên thì rõ ràng chúng ta không xác định được trạng thái của tài khoản A và tài khoản B sau khi thực hiện cùng 1 lúc. Mà điều này thì rất nguy hiểm.
Durability: điều này có nghĩa dữ liệu sau khi thực hiện transaction sẽ không thay đổi nếu chúng ta gặp vấn đề gì đó liên quan đến database.
Ví dụ sau khi chuyển tiền vào tài khoản B thành công thì dù database có gặp bất cứ vấn đề gì thì tài khoản B vẫn đảm bảo đã nhận đủ 10$.
Nói về cơ sở dữ liệu thì chắc ai cũng nghĩ ngay đến hệ quản trị cơ sở dữ liệu quan hệ như Mysql, PostgreSQL, hay NoSQL như MongoDB, DynamoDB, Cassandra…
Và theo mình nghĩ đa số anh em ở đây cũng đang sử dụng chủ yếu là MySQL. Mình cũng vậy, từ lúc đi làm đến giờ toàn phang MySQL, chưa có cơ hội làm việc với NoSQL (tự tìm hiểu thì có còn dùng trong dự án thật thì chưa)
Kể cả các công ty to như Pinterest hay Instagram cũng vậy, họ vẫn đang dùng MySQL.
Còn NoSQL thì hiện nay thấy rất nhiều công ty đã dùng vào hệ thống chính của họ. Ví dụ như Netflix, Discord, Spotify …
Nên hôm nay quyết định viết bài này để tìm hiểu xem thật sự thằng Cassandra này nó có ưu điểm, nhược điểm gì, dễ scale hay không …
Khái quát qua về Cassandra
Cassandra là NoSQL, được phát triển bởi Facebook vào năm 2007. Sau đó nó được tặng cho quỹ Apache vào 2/2010 và nâng cấp lên thành dự án hàng đầu của Apache.
Cassandra là hệ cơ sở dữ liệu phân tán, kết hợp những gì tinh tuý nhất của Google Bigtable và Amazon DynamoDB. Ngôn ngữ phát triển Cassandra là Java.
Cassandra được thiết kế có thể chạy trong phần cứng giá rẻ, và cung cấp write throughput khá là cao (latency tầm 0.5ms), trong khi read throughput thì thấp hơn (latency tầm 2.5ms).
Nếu nói đến NoSQL thì chắc ai cũng đều có chút liên tưởng nó hoạt động thế nào rồi. Cassandra cũng vậy, dữ liệu được lưu vào table, sau đó dùng 1 ngôn ngữ query như SQL để thực hiện thao tác với dữ liệu.
Cassandra là hệ cơ sở dữ liệu phân tán, dữ liệu được lưu trữ trên nhiều node của nhiều máy khác nhau, theo cơ chế P2P. Hiệu năng xử lý của hệ thống cũng tăng theo số node (nếu càng nhiều node thì càng xử lý được nhiều request).
Điều đó sẽ giúp cho Cassandra dễ dàng scale theo chiều ngang.
Về hiệu năng thì Netflix cũng đã thực hiện đo benchmark, kết quả ngoài mong đợi. Với 288 nodes, Casandra đã đạt được throughput lên đến 1 triệu write/s. Khá kinh khủng.
Cassandra là 1 hệ cơ sở dữ liệu không quan hệ, và thường được sử dụng trong nhiều loại ứng dụng khác nhau. Dưới đây là 1 số use cases mà Cassandra thường hay được sử dụng.
Messaging
Cassandra rất thích hợp trong những ứng dụng hay service làm về chat. Hiện nay có 1 số công ty đang dùng như Facebook, Discord.
Internet of things
Cassandra cũng rất thích hợp cho những dòng ứng dụng mà có tốc độ dữ liệu gửi đến cực khủng từ nhiều thiết bị khác.
Social Media Analytics and recommendation engine
Cassandra cũng rất thích hợp cho những chức năng về recommendation hay 1 vài chức năng liên quan đến analytics.
Điểm mạnh của Cassandra
Hệ thống phân tán
Do Cassandra được kế thừa từ Amazon DynamoDB nên tính mở rộng của nó là khá lớn. Khi tốc độ xử lý của hệ thống không đủ thì ta chỉ cần thêm node mới vào là được.
Partitioning
Là kiến trúc phân phối dữ liệu trên nhiều node bên trong cluster.
Dựa theo thuật toán Consistent Hashing thì mỗi node sẽ được cấp phát 1 token, và dựa vào token này sẽ phân phối dữ liệu đến từng node.
Dữ liệu được tạo ra nhờ replication sẽ tự động phân chia đến từng node.
Gossip Protocol
Là giao thức truyền thông giữa các node trong cluster. Cơ bản là truyền thông P2P.
Cơ chế lưu dữ liệu
Cassandra thực hiện việc lưu dữ liệu thông qua 2 chỗ:
Không gian bộ nhớ (được gọi là memtable)
Không gian đĩa (được gọi là SSTable)
Khi write dữ liệu thì đầu tiên sẽ lưu trên memtable. Sau khi dữ liệu trên memtable full thì khi đó sẽ thực hiện ghi toàn bộ dữ liệu trên memtable xuống SSTable.
Khi read dữ liệu thì đầu tiên sẽ tìm trong memtable trước. Nếu không có thì lại tìm xuống SSTable để lấy.
→ Chính vì dữ liệu được lưu trên memory nên việc việc lấy dữ liệu trên Cassandra trở lên khá là nhanh.
Khi xoá dữ liệu thì thực tế dữ liệu không được xoá, mà nó được gán 1 cái cờ gọi là tombstone. Sau 1 khoảng thời gian nào đó sẽ có 1 con batch chạy đi scan và thực hiện xoá.
Tính nhất quán dữ liệu trong cluster
Khi nhận được request đọc ghi đến DB của Cassandra, khi đó cái node nhận được request này sẽ đảm nhiệm 1 chức vụ được gọi là coordinator, và tiến hành xử lí request đọc ghi đến những node liên quan.
Dựa vào cấp độ của tính nhất quán (Consistency Level) mà việc kết nối đến từng node sẽ khác nhau.
Cấp độ của tính nhất quán sẽ được set trên mỗi câu truy vấn đọc ghi. Do đó giúp nhà phát triển ứng dụng sẽ dễ dàng điều chỉnh Consistency Level cho phù hợp với yêu cầu của họ: muốn kết quả trả về nhanh hay muốn dữ liệu trả về chính xác.
Nếu Consistency Level được set là 1 thì khi đó coordinator chỉ cần kết nối trực tiếp đến 1 node -> kết quả trả về nhanh
Nếu Consistency Level đươc set là ALL thì khi đó coordinator phải kết nối đến toàn bộ node và thực hiện xử lý dữ liệu. -> dữ liệu trả về chính xác
Tính dư thừa
Các node trong cluster có vai trò như nhau, không có node nào làm node chính cả. Hơn nữa dữ liệu không chỉ được lưu trên 1 node mà nó được lưu trên toàn bộ các node, do đó độ chịu lỗi của nó là khá cao.
Cho dù có 1 node bị lỗi đi chăng nữa thì khi truy vấn kết quả, nó sẽ được điều hướng sang các node khác để lấy.
Trong trường hợp mà chúng ta phục hồi dữ liệu từ 1 node bị lỗi thì nó sẽ xử lý như thế nào?
Giả sử như trong khi đang phục hồi thì có dữ liệu mới đến, khi đó dựa vào cơ chế Hinted Handoff thì cái node nhận được dữ liệu mới này sẽ thực hiện việc lưu tạm thời dữ liệu lại. Và cái node bị lỗi sau khi phục hồi dữ liệu xong thì sẽ tiến hành update dữ liệu dựa vào cái thông tin đã lưu lúc trước.
Ngoài ra dựa vào cơ chế Read Repair, khi chúng ta query dữ liệu. Chẳng may cái dữ liệu nhận được nó cũ hơn dữ liệu đang có ở các node khác. Khi đó nó sẽ tự động tiến hành update dữ liệu.
Cấu trúc dữ liệu
Dữ liệu được lưu trữ trong DB của Cassandra thuộc dạng Key value store (KVS).
Có thể tạo được nhiều table trong database nhưng mà giữa các table sẽ không có mỗi quan hệ nào. Nhiều table được tổng hợp lại thành keyspace.
Thông thường database trong NoSQL thì không cần thiết phải tạo schema ngay lúc đầu. Thế nhưng Cassandra thì lại khác. Trước khi insert dữ liệu thì cần phải tạo keyspace và schema của table.
Có thể thực hiện được 1 số câu query như select, update, insert, delete, drop.
Tổng kết
Mình tổng hợp lại 1 số đặc tính của Cassandra như sau:
Là NoSQL
Dữ liệu được phân tán trên nhiều node khác nhau.
Node càng nhiều thì throughput của nó càng tăng.
Write throughput luôn luôn cao hơn read throughput.
Tính chịu lỗi khá cao, cho dù node bị chết đi chăng nữa thì khi truy vấn sẽ được chuyển hướng đến node khác.
Backup, restore dữ liệu 1 cách đơn giản.
Tốc độ truy vấn cao
Đọc đến đây chắc hẳn các bạn cũng biết Cassandra nó làm việc thế nào rồi phải không.
Bài sau mình sẽ đi đào sâu vào 1 số hệ thống lớn xem họ đang áp dụng nó thế nào.
Câu khai báo trên có thể diễn giải là với route “/” (tương đương với trang chủ), thì gọi render component Home
2 component <Router> và <Route> là những component React không render trong DOM, nếu path khớp với uri, nó render ra component chúng ta truyền vào cho nó (qua props component), chúng ta sẽ gặp lại khái niệm này thường xuyên: Một component bản thân không render trong DOM, mà render một component khác
Khi user truy cập đường dẫn /users, React Router sẽ render component <UserList /> bên trong component <SearchLayout/>, cả 2 component này lại đặt trong component <MainLayout/>
Nếu muốn trang chủ cũng render <MainLayout/> cùng với component <Home/>
<Router> muốn hoạt động được, phải khai báo với ReactRouter.browserHistory
var browserHistory =ReactRouter.browserHistory;ReactDOM.render((<Routerhistory={browserHistory}></Router>),document.getElementById('root'));
Những version trước đây của React Router, attribute history có giá trị mặc định là hashHistory giống như router của Backbone.js, các version sau này, attribute history sẽ không có giá trị mặc định và bắt buộc phải khai báo khi sử dụng
Component UserProfile sẽ được render trong các trường hợp: users/1, users/145, users/abc, React Router sẽ truyền vào giá trị userId vào UserProfile như một props, access đến giá trị này bằng this.props.params.userId
Dễ nhất là viết về 1 cái mà ai cũng biết, và khó nhất cũng là viết về 1 cái mà ai cũng đang xài, vì nó không còn gì mới mẻ, không còn gì hay ho để người ta có thể khám phá.
Mình dùng Google Keep đến nay đã sang năm thứ 5, mỗi tháng mình checked khoảng 500 checklists, toàn bộ công việc cá nhân, công ty, và gia đình thú thực mình đều quản lý trên Google Keep, vô cùng đơn giản, hiệu quả, và tiết kiệm thời gian.
Đầu tiên chúng ta vẫn cứ phải nhắc lại Google Keep là gì đã nhé…
Google Keep là dịch vụ ghi chú được phát triển bởi Google. Ra mắt vào ngày 20 tháng 3 năm 2013, Google Keep có sẵn trên web và có các ứng dụng di động cho hệ điều hành di động Android và iOS. Keep cung cấp nhiều công cụ để ghi chú, bao gồm văn bản, danh sách, hình ảnh và âm thanh.
_ Trích Wikipedia
Google có giới thiệu về công cụ Google Keep của mình như thế này: [bg_collapse view=”button-blue” color=”#fff” expand_text=”Click để xem thêm thông tin” collapse_text=”Rút gọn lại” ]
Ghi lại nội dung quan trọng và làm được nhiều việc hơn.
Sắp xếp. Ghi lại cảm hứng và việc cần làm một cách dễ dàng. Cộng tác trên ghi chú với các thành viên trong nhóm và đặt nhắc nhở để luôn theo kịp tiến độ. Mọi thứ đều đồng bộ hóa trên các thiết bị của bạn nên nội dung quan trọng luôn trong tầm tay.
Cùng nhau làm được nhiều việc hơn.
Với Keep, bạn có thể dễ dàng cộng tác với đồng nghiệp trên các ghi chú, danh sách, ảnh, âm thanh và bản vẽ. Ghi lại các ý tưởng đột phá một cách nhanh chóng, giữ trong tầm tay khi bạn làm việc và xem những việc cần làm được đánh dấu hoàn thành trong thời gian thực.
Cập nhật ghi chú mọi lúc, mọi nơi.
Truy cập, tạo và chỉnh sửa ghi chú ở bất cứ đâu — từ máy tính, điện thoại hay máy tính bảng — ngay cả khi không có kết nối. Mọi chỉnh sửa bạn thực hiện sẽ được lưu và cập nhật tự động trên tất cả các thiết bị.
Tìm nhanh nội dung bạn cần.
Keep giúp bạn dễ dàng sắp xếp ghi chú và tìm thấy nội dung mình đang tìm kiếm nhanh hơn nữa. Lọc nhanh ghi chú theo màu, nhãn hoặc thuộc tính như danh sách có hình ảnh, ghi chú âm thanh có nhắc nhở hoặc ghi chú được chia sẻ. Hoặc ghim các ghi chú quan trọng vào đầu danh sách của bạn.
Không bao giờ bị lỡ thời hạn.
Nhắc nhở trong Keep giúp bạn hoàn tất công việc mọi lúc, mọi nơi bạn cần. Bạn có dự thảo thuyết trình phải hoàn thành lúc 3 giờ chiều? Hãy đặt nhắc nhở theo thời gian. Bạn cần mua đồ ăn nhanh cho chuyến dã ngoại của nhóm? Hãy thêm nhắc nhở theo vị trí để thông báo cho bạn khi bạn đi qua cửa hàng tạp phẩm.
Làm cho ý tưởng trở nên sống động.
Nhanh chóng ghi lại các ghi chú và ý tưởng trong Keep, sau đó dễ dàng tham chiếu để lấy cảm hứng khi bạn cộng tác với các thành viên nhóm trong Tài liệu. Chỉ cần truy cập giấy ghi chú Keep qua menu Công cụ của Tài liệu và bạn sẽ thấy tất cả ghi chú Keep trong một bảng điều khiển bên.
[/bg_collapse]
Vậy tại sao 1 phần mềm ghi chú lại hữu dụng, được nhiều người tin tưởng sử dụng đến vậy?
2. Ai có thể sử dụng Google Keep?
Bất cứ ai nếu có nhu cầu quản lý công việc và các ghi chú cá nhân hiệu quả hơn, ngoài ra:
Bạn muốn miễn phí
Bạn muốn đồng bộ giữa nhiều thiết bị để có thể ghi chú cũng như theo dõi ở bất cứ đâu
Muốn làm việc nhóm, lên ghi chú và mục tiêu với team của mình
Bạn có xu hướng và mong muốn quản lý và giao tiếp công việc theo mục tiêu (OKRs) để có thể linh hoạt và sáng tạo, thay vì bó hẹp theo đừng đầu mục chi tiết có trước.
Bạn muốn tối ưu thời gian và không bao giờ quên việc!!!
3. Tại sao lại là Google Keep?
Đương nhiên bạn sẽ hỏi câu hỏi này, vì có rất nhiều công cụ ghi chú khác như Evernote, OneNote, hay thậm chí Sticky Note trên Windows 10, Ghi chú trên IPhone… [bg_collapse view=”button-blue” color=”#fff” expand_text=”Click để xem so sánh Google Keep vs Evernote vs One Note” collapse_text=”Rút gọn nội dung” ]
OneNote
Evernote
Keep
Developer
Microsoft
Evernote
Google
Delivery
Web, Mobile, Desktop
Web, Mobile, Desktop
Web, Mobile
Windows
Yes
Yes
Online Only
Mac OS X
Yes
Yes
Online Only
Android
Yes
Yes
Yes
iOS
Yes
Yes
Online Only
Windows Phone
Yes
Yes
Online Only
Blackberry
Online Only
Yes
Online Only
# of Devices Per License
Unlimited
Unlimited
Unlimited
Packages and Cost in USD
Free
Free or Premium Available ($5 to 10 USD/user/month) Education or Business version also available (varied)
Nhìn vào bảng trên chắc bạn sẽ thắc mắc: “ủa thế google keep hơn onenote hay evernote ở điểm nào?”, thì câu trả lời cho câu hỏi này có lẽ sẽ không bao giờ có thể thuyết phục được tất cả người dùng! Chúng ta chỉ là đang đi tìm câu trả lời cho câu hỏi: “Công cụ nào phù hợp với mình nhất?” mà thôi!
Bảng trên giúp bạn xem các tính năng hiện có của Google Keep, và xem xét trên nhu cầu của bản thân để xem có phù hợp không, không quan trọng nhiều hay ít tính năng, quan trọng có đủ dùng không!!! Có 2 lợi thế không có trong bảng so sánh, đó là:
Google Keep nhẹ hơn 2 công cụ kia
Google Keep thuộc hệ sinh thái của Google nên nếu bạn quen sử dụng các công cụ của Google rồi thì thực sự rất rất tiện.
4. Sử dụng Google Keep như thế nào?
Như lúc đầu mình có viết, Google Keep thực sự rất dễ dùng, bạn chỉ cần truy cập: https://keep.google.com và đăng nhập tài khoản Google mà mình muốn sử dụng.
Có một số tính năng quan trọng mà bạn cần phải lưu ý, vì nếu ứng dụng đủ sâu, Google Keep sẽ mang lại những hiệu quả cực lớn cho cách bạn quản lý và sắp xếp công việc:
Ghim ghi chú: Hiểu đơn giản là bạn đánh dấu ghi chú nào là quan trọng, ưu tiên hiển thị lên đầu tiên.
Tiêu đề ghi chú: Tên chủ đề của mỗi ghi chú / công việc để bạn có thể phân loại và làm việc tập trung hơn.
Ghi chú: Bạn sẽ có 2 lựa chọn tạo Ghi chú mới hoặc Danh sách mới (Checklist), thường là những cái cần note nhanh hoặc lưu tạm.
Danh sách mới: Hầu hết mọi người đều ưu tiên sử dụng tính năng này, tạo một danh sách các đầu việc cần đánh dấu hoàn thành, đây là một tính năng đơn giản nhưng cực hữu dụng.
Lời nhắc: Nhắc bạn lưu ý hoặc hoàn thành các ghi chú/danh sách trong thời gian phù hợp, có thể chọn ngày giờ và địa điểm (liên kết đến Google Calendar)
Cộng tác viên: Thêm người cùng theo dõi các ghi chú, cùng sửa đổi, cùng hoàn thành.
Thay đổi màu: Nghe là hiểu rồi nhỉ 😀
Thêm hình ảnh: Thêm hình ảnh vào Ghi chú để có thể tiện theo dõi, thảo luận, trao đổi, tương tác hơn.
Lưu trữ: Khi một ghi chú hoàn thành, bạn có thể ấn Lưu trữ để tối ưu số lượng Ghi chú có trên Google Keep của bạn, nhiều sẽ loạn, sau này tìm vẫn ra!
Thêm nhãn: Đánh dấu các ghi chú theo mức độ liên quan đến chủ đề, một dạng danh mục ghi chú, rất tiện nếu bạn muốn xem tập trung vào mục nhãn (danh mục) cụ thể
Thêm bản vẽ: Thêm bản vẽ tay trên ghi chú để tương tác và thảo luận trên đó.
Hướng dẫn sử dụng Google Keep hiệu quả
5. Case Study sử dụng Google Keep
Cách sử dụng
Áp dụng nguyên tắc đánh giá công việc, tạo các keep với mức độ quan trọng [PIN] và không quan trọng
Để phân loại hiệu quả: Tên Keep / màu săc / tag
Share cho người khác để cùng tương tác
TIPS
Liên tục note việc mới và checked việc đã hoàn thiện
Review mỗi sáng và mỗi tối trong ngày
Khi đã note việc lên: cần phải biết rõ lúc nào hoàn thành thì hợp lý, hoàn thành như
thế nào, và chất lượng hoàn thành ra sao.
Tạo 1 keep có title: “Việc trong ngày” – mọi việc trong ngày (only today) hãy note
Việc quan trọng là việc có ảnh hưởng trực tiếp tới công việc, đời sống cá nhân, gia đình, các mối quan hệ xã hội, và quyền lợi của bạn.
Việc gấp là việc cần phản hồi sớm trong tối đa 1 ngày, tùy vào yêu cầu phản hồi.
Ví dụ:
Đi làm, có khách tiềm năng mới, luật của công ty là phải liên hệ không quá 3h đồng hồ kể từ khi khách liên hệ, đây là việc gấp.
30p nữa bạn có lịch đi pitching 1 dự án lớn vài tỷ đồng – đây là việc quan trọng, tuy nhiên gia đình bạn lại đang xảy ra 1 sự cố và rất cần bạn có mặt – đây là việc gấp và quan trọng.
Có 1 email từ 1 ai đó gửi cho bạn để hẹn cafe – đây là việc không gấp và không quan trọng.
2. Hãy nhớ nguyên tắc ưu tiên công việc
“Sức khỏe có thể không phải là tất cả, nhưng nếu thiếu sức khỏe thì tất cả không có ý nghĩa gì!”
Sức khỏe
…
…
…
…
(kaka phần này là quan điểm cá nhân thôi, anh chị em tùy biến thứ gì là quan trọng nhất với mình nhé, sức khỏe có thể cho xuống cuối cũng được :D)
CASE STUDY
1. Làm sau để follow tất tần tật việc trên Google Keep?
a. Hãy tạo Các nhãn theo chủ đề:
Việc cá nhân
Việc gia đình
Việc công ty (trong này có thể lại chia nhỏ ra nhiều nhanh nữa)
Ví dụ nhãn của mình…
b. Hãy lưu ý chỉ Ghim (PIN) những ghi chú quan trọng
c. Những công việc trong ngày, hãy tạo riêng 1 ghi chú là Việc trong ngày:
Mỗi đầu ngày hãy note tất cả việc cần làm vào đây
Mỗi cuối ngày hãy checked hết tất cả việc đã làm xong, chưa làm xong cần tính toán phân bổ về các ghi chú khác phù hợp hơn hoặc cam kết ngày hôm sau phải hoàn thành.
d. Tất cả các công việc không quan trọng, hãy cứ note ra nhưng đừng bao giờ ghim, cũng đừng bao giờ bỏ, vì đó là cơ hội.
Tôi có một yêu cầu triển khai dự án với mục tiêu như thế này, anh tự bóc tách đầu việc, tự xác định thời gian, rồi anh hoặc người của anh tự làm. Luôn luôn nhớ rằng phải đảm bảo đúng deadline.
Nghe có vẻ quan liêu vl, nhưng thực sự OKR đã giúp các doanh nghiệp tiết kiệm vô cùng nhiều thời gian cũng như tăng khả năng sáng tạo lên max level. Tại sao vậy:
Vì OKR tập trung vào tính cam kết và những nỗ lực về thời gian cũng như hiệu suất
Vì OKR chỉ hiệu quả với người thực sự hiểu việc và biết phải bắt đầu từ đâu (thường chỉ work với ban lãnh đạo cấp cao của 1 doanh nghiệp ở VN)
VÌ OKR hướng đến một mục tiêu chung và tất cả cùng tự giác triển khai công việc của mình.
…
Vậy ứng dụng vào Google Keep như thế nào?
Khi bạn Start 1 dự án, hãy tạo 1 Keep (ghi chú) mới và invite (mời) tất cả người liên quan vào Keep đó.
Tạo checklist các đầu việc và để tên người triển khai ở trước mỗi checklist, ví dụ: [DucNT] Hoàn thành Landing Page launching 1-11/2019
Ai hoàn hoàn checklist nào thì check done vào đó.
Mục tiêu cuối cùng là không còn checklist nào nữa -> ấn lưu trữ -> hoàn thành
3. Mua sắm hiệu quả hơn?
Chúng ta thường mua sắm vô tội vạ và trong nhất thời vì thích một món đồ theo cảm xúc mà chi tiêu không hợp lý. Google Keep giúp bạn được việc đó, hãy thử theo cách này:
Tạo 1 Keep mới với tên Shopping Whistlist
Hãy nhớ đừng bao giờ cho Keep này vào mục cần phải ghim
Cứ khi nào bạn cần mua 1 món đồ gì hãy note nó ra + cả giá + link mua nhé -> note để đấy thôi
Ít nhất 24h sau vào xem lại, nghĩ kỹ xem có thực sự cần mua không? -> Nếu cần hãy mua và check done, nếu không hãy cứ check done…
Rồi để xem, sau 3 tháng bạn tiết kiệm được bao tiền 😀
Thực ra, còn cả trăm ngàn ví dụ nữa cơ, nhưng do mình ngại viết quá, không ngờ rằng bài viết này cũng ngốn hơn 2h đồng hồ của mình!!! Hy vọng nó đáng và hữu ích với anh chị em bạn bè!!!
Nếu các bạn cần viết thêm case study, hãy comment nhé, mình sẽ update trong thời gian sớm nhất. Chúc một ngày thật nhiều niềm vui ^^!
Đón đầu xu hướng công nghệ, Stratavo là công ty start up đang ngày càng khẳng định vị thế của bản thân trên thị trường với các sản phẩm phần mềm và dịch vụ Công nghệ cao cấp, trở thành “điểm đến” lý tưởng cho các lập trình viên phát triển tiềm năng. Cùng với sự ra đời của trung tâm công nghệ tại Thành phố Hồ Chí Minh và Đà Nẵng, Stratavo hứa hẹn là nơi thắp lên ngọn lửa nhiệt huyết cho các tài năng công nghệ tỏa sáng sự nghiệp.
Góp mặt vào đường đua công nghệ, Stratavo không ngừng tăng tốc giành lấy ngôi vị dẫn đầu
Stratavo là startup trẻ đến từ xứ sở “Sương mù” (Vương quốc Anh), chuyên cung cấp các dịch vụ tư vấn công nghệ mới với các phần mềm và dịch vụ Cloud chất lượng, hướng đến việc kiến tạo một cuộc sống dễ dàng và tiện nghi hơn.
Sở hữu đội ngũ nhân viên đến từ nhiều quốc gia trên thế giới, yếu tố cốt lõi giúp gắn kết con người tại Stratavo chính là mục tiêu tạo ra những sản phẩm và dịch vụ tuyệt vời. Đối với mỗi thành viên tại Stratavo, đam mê chính là bí quyết giúp làm việc hăng say, không ngừng học hỏi và sẵn sàng vươn mình tỏa sáng.
Xây dựng một nền văn hóa đề cao sự tôn trọng và quyền tự chủ của mỗi nhân viên, Stratavo mang đến cho các “phần tử” tài năng của mình cơ hội bứt phá tài năng, vững bước trên con đường xây dựng sự nghiệp rực rỡ của bản thân.
Giờ đây, với sự phát triển không ngừng, Stratavo mở rộng thị trường và đồng thời trao cơ hội cho các tài năng công nghệ, những người với cùng niềm đam mê và lòng nhiệt huyết phát triển sự nghiệp rực rỡ tại trung tâm nghiên cứu của Stratavo.
Stratavo đang rộng cửa chào đón nhân tài công nghệ cùng phát triển và “chạm đích” thành công
Và nếu bạn đã sẵn sàng để trở thành một phần quan trọng của Stratavo, chớ nên bỏ qua những vị trí hấp dẫn mà “ngôi nhà” Stratavo đang tìm kiếm:
Bạn tự tin với kỹ năng sáng tạo và giải quyết vấn đề xuất sắc cùng với khả năng quản lý con người? Các vị trí sau đây sẽ là sự lựa chọn tuyệt vời cho bạn tại bứt phá năng lực và đạt đến những giới hạn mới:
Bạn mong muốn tạo ra các thiết kế UX/ UI có tầm ảnh hưởng và mang lại trải nghiệm tuyệt hảo cho người dùng? Đừng ngại phát triển tài năng của mình với vị trí Senior English Speaking UX/UI Designer tại Stratavo để cùng nhau tạo nên những sản phẩm đỉnh cao.
Bạn vững vàng với 5 năm kinh nghiệm áp dụng công nghệ để giải quyết bài toán kinh doanh của khách hàng? Hãy để tài năng của bạn được đồng hành với sự phát triển của công ty, vị trí Senior English Speaking Solution Architect vẫn rộng mở cơ hội cho bạn.
Bạn tìm kiếm cơ hội tỏa sáng tài năng với những kiến thức và kinh nghiệm về OpenStack? Stratavo có ngay vị trí OpenStack Developer với nhiều dự án hấp dẫn, hứa hẹn là bệ phóng cho tài năng của bạn vươn tầm cao mới.
Bạn mong muốn phát triển các sản phẩm web nổi bật và sáng tạo? Cơ hội phát triển sự nghiệp tại vị trí Senior English Speaking Web & Graphic Designer đang rộng mở chào đón sự góp mặt của bạn.
Bạn có khả năng phân tách số liệu với lối tư duy logic? Vị trí Senior English Speaking Business Analyst tại Stratavo hứa hẹn là nơi giúp sự nghiệp bạn thăng hoa. Tài năng của bạn chính là yếu tố quan trọng góp phần cho những sản phẩm chất lượng của công ty.
Chỉ cần bạn dám chấp nhận cùng Stratavo đương đầu với những thách thức sắp tới, những điều bạn sẽ nhận được tại đây là vô cùng xứng đáng.
Đến với Stratavo, bạn được thỏa sức thể hiện tài năng, bởi mỗi đóng góp của bạn chính là chiếc chìa khóa để Stratavo ngày càng phát triển.
Trải nghiệm cuộc sống hiện đại với các công cụ, thiết bị mới nhất. Bạn sẽ sẽ luôn được cập nhật các xu hướng hiện đại, tiên tiến về công nghệ.
Cơ hội làm việc cùng những người đồng đội thân thiện, trẻ trung, làm việc hết mình, ăn chơi hết mức và không quên hỗ trợ nhau cùng phát triển tốt hơn. Đội ngũ công nghệ hàng đầu với đội ngũ nhân viên giàu kinh nghiệm để hỗ trợ ứng viên mới Vận hành văn hóa học hỏi và cải tiến liên tục để cho phép …
Bên cạnh đó, những đãi ngộ cực tốt tại Stratavo sẽ giúp kích hoạt động lực trong bạn:
Về tay mức lương xứng đáng với năng lực lên đến $4,000 + lương tháng 13 hấp dẫn;
Trải nghiệm văn phòng đầy tiện ích với khu vực thư giãn, cà phê và trà miễn phí cùng hồ bơi tuyệt đẹp;
Phát triển sự nghiệp với nhiều cơ hội làm việc với các đối tác nước ngoài;
Và nhiều phúc lợi, đặc quyền hấp dẫn chờ bạn tại gia đình “Stratavo”.
“Lên dây cót” cho sự nghiệp mới và chiến ngay chờ chi!
Tháng 11 – 12 được xem là thời gian “vàng” để thiết lập kế hoạch tuyển dụng nhân sự. Dù freelancer it hay bất kỳ một vị trí chuyên về tuyen dung it nào cũng cần đảm bảo một quy trình khoa học. Vậy đâu là một kế hoạch nhân sự chuyên nghiệp? Cùng TopDev tìm hiểu bài viết sau đây!
Nắm rõ thị trường và nhu cầu nguồn nhân lực
Tìm hiểu về nhu cầu nguồn nhân lực rất quan trọng.
Thị trường tuyen dung it luôn biến động. Ví dụ như việc các freelancer it ngày càng nhiều tạo ra sức ép cạnh tranh lớn. Freelancer it không chỉ cạnh tranh với các đối thủ thuộc cùng lĩnh vực freelancer it. Họ còn có những đối thủ là những ứng viên it với nhiều chuyên môn khác nhau.
Ngoài ra, nhu cầu nguồn nhân lực lại rất quan trọng. Tăng – giảm, những biến động đều thể hiện nguồn nhân lực thay đổi ra sao. Vì thế, phòng kế hoạch nhân sự cần lập các kế hoạch tuyển dụng nhân sự.
Rà soát và tổng hợp nguồn dữ liệu liên quan: khối lượng công việc, mô tả công việc, chế độ lương thưởng,… Phân tích rõ về môi trường làm việc, các yêu cầu – chính sách liên quan đến hợp đồng lao động, phúc lợi,… Tổng hợp nhu cầu tuyển dụng nhân sự từ các trưởng bộ phận/ phòng ban.
Để thiết lập một kế hoạch tuyển dụng nhân sự hoàn hảo, định hướng phát triển thật sự quan trọng. Do vậy, nên đặt nhu cầu nguồn nhân lực gắn liền với định hướng hoạt động. Từ cơ sở đó, xác định rõ các số lượng chi tiết về nhu cầu: số lượng nhân sự mới cần tuyển, chất lượng chuyên môn và các kỹ năng cần có; thời gian phù hợp để tuyen dung it.
Đánh giá “trình” tuyển dụng tại doanh nghiệp
Đây được xem là bước quan trọng của quy trình thiết lập kế hoạch nhân sự hiệu quả.
Liệu bạn có đánh giá chính xác Level tuyển dụng tại doanh nghiệp?
Ban nhân sự cần đánh giá lại tình hình chung cùa doanh nghiệp: Hệ thống nhân sự, cơ cấu doanh nghiệp gồm những ai? Liệu những nhân sự đều thật sự phù hợp với vị trí đó? Họ có sự thay đổi gì về sự thể hiện của bản thân?
Giải đáp những thắc mắc đó giúp bộ phận nhìn lại tổng quan đến chi tiết mỗi nhân viên trong tổ chức. Đồng thời, đó cũng là cách thức phù hợp giúp thiết lập một hệ thống tổ chức hoàn chỉnh hơn. Một điều lưu tâm là nhân sự nên xem xét vấn đề này trong cùng một khía cạnh về chế độ đãi ngộ, chính sách quản lý,...
Thách thức đặt ra – Bài toán tăng hay giảm nhân sự?
Từ những phân tích trên, các nguồn cứ liệu quan trọng đã được tập hợp. Bộ phận nhân sự bắt đầu xác định liệu nhân lực. Từ cơ sở đó, thực trạng thiếu hay thừa dựa trên hiệu suất của công việc.
Vấn đề tăng hay gia giảm nhân sự là câu chuyện riêng của từng doanh nghiệp.
Các phán đoán, đề xuất và việc quyết định chính thức bổ sung hay cắt giảm đều dựa trên nguồn dự liệu thu thập. Ví dụ như tuyển dụng Data Scientist hay freelancer it.
Nhân sự cần đặt ta các cơ sở liệu có nên tuyển thêm họ không nếu có sự bất ổn định trong việc thực hiện các nhiệm vụ.
Triển khai kế hoạch thực hiện chiến lược
Một chiến lược phát triển kế hoạch tuyen dung it sẽ gồm các trình tự như sau:
– Đưa ra bản kế hoạch chi tiết tuyển dụng nhân viên:
+ Về số lượng, vị trí và các yêu cầu
+ Mô tả từng nhiệm vụ
+ Mức lương phù hợp, thời gian và hình thức tuyen dung it
+ Dự trù kinh phí
Ví dụ: một dự án đó cần bao nhiêu freelancer it, Senior Developer,…
– Phương án tái cơ cấu nhân sự: Phân bổ, sắp xếp lại nhân sự thuộc các phòng ban phù hợp với năng lực, kinh nghiệm, trách nhiệm.
– Kế hoạch, chỉ tiêu thăng tiến phù hợp với năng lực
– Vấn đề cắt giảm nhân sự: Đưa ra những cơ sở rõ ràng, có cơ sở pháp lý, tránh tranh chấp nảy sinh.
Đây là một kế hoạch dài hạn. Do vậy, nó cần đảm bảo tính khả thi. Bộ phận nhân sự cần thảo luận để đưa ra những đánh giá bổ sung. Mặt khác, nên có những back-up phù hợp để tối ưu hóa hiệu quả thực hiện dự án. Điều này có ý nghĩa rất quan trọng. Vì tổ chức cần theo dõi và tìm ra các rủi ro tiềm ẩn có thể xảy ra. Đồng thời, lên kế hoạch thiết lập các giải pháp hoàn thiện nhất trong các trường hợp thực tế không lý tưởng.
Tuyển Dụng Nhân Tài IT Cùng TopDev Đăng ký nhận ưu đãi & tư vấn về các giải pháp Tuyển dụng IT & Xây dựng Thương hiệu tuyển dụng ngay!
Hotline: 028.6273.3496 – Email: contact@topdev.vn
Dịch vụ: https://topdev.vn/page/products
ha ha – nhìn hình này có vẻ Toptal nói Java già cỗi
Ngắn gọn như thế nào?
Đa năng như thế nào?
Cuốn sách có 11 chương, giúp bạn hiểu rõ về Kotlin từ cơ bản tới nâng
Sách dành cho những ai đã rành về Kotlin, tiếp tục phát triển Kotlin bên Android (phần đầu vẫn dạy về Kotlin), được xé nhỏ thành 26 chương giúp ta dễ dàng học
Cuốn sách dạy về Web với Kotin, đặc biệt EcmaScript 6 chuẩn mới nhất, Json….Các bạn quan tâm có thể học, khoảng 115 trang.
Cuốn này cũng tương tự, giúp ta có thể học tốt Kotlin. Bố trí thành 13 chương (420 pages ) các bạn có thể bám theo cuốn này để học
Cuốn sách này khá hay, bạn có thể tham khảo.
