Bài viết được sự cho phép của tác giả Nguyễn Việt Hưng
Không ít học sinh phổ thông từng thắc mắc học môn lập trình để làm gì? Có phải vì mức lương 4000 USD của sinh viên mới ra trường mà nhiều người hay nhắc đến khi nói về lập trình viên.
Hôm nay mình đọc một bài trên Facebook nói về lí do Tại sao bạn học lập trình?, trong đó có 1 lí do được nhắc đi nhắc lại rất nhiều đó là có một tương lai tươi sáng với mức lương khởi điểm khi ra trường 4000 USD. Bài này nói lên quan điểm của mình về việc học lập trình để làm gì.
Mình cũng giống các bạn trong clip trên, đều là học sinh cấp 3, đều có không ít thì nhiều kiến thức về lập trình nhưng mình thấy các bạn đang có phần ảo tưởng về ngành lập trình. Mình tiếp xúc với không ít lập trình viên chuyên nghiệp, nên không còn lạ gì những nỗi khổ của ngành này: trĩ lòi, mắt mờ, đau lưng, cột sống, stress, deadline, đau dạ dày, trầm cảm… Những người ngoài chỉ nhìn vào họ những lúc họ khoe lương nhưng đâu có nhìn thấy lúc họ làm việc. Trên các loại báo xàm ke của Việt Nam và các bà hàng xóm, nghề lập trình thường xuyên được nhắc đến trong các chủ đề như: “những công việc lương cao nhất”, “những công việc không sợ thiếu việc làm lương cao trong 5 năm tới”, blabla … ; nhưng sự thực có phải vậy không ? Công việc lập trình cũng chỉ giống bao nhiêu ngành nghề khác là bán sức lao động và giá trị của bản thân cho công ty và xã hội thôi.
Bố mình từng nói “Không có ngành nghề dễ kiếm việc hơn hay lương cao hơn ngành nghề nào. Tất cả công việc mày được trả lương là người ta trả cho giá trị và khả năng của mày mang lại chứ không phải trả cho cái ngành nghề của mày hay cái trường mày học.”
Lương 4000 USD/tháng với lập trình không phải là không có nhưng những nguời như thế thuộc loại hiếm và thường có kinh nghiệm 5–7 năm đi làm. Còn về lương một cử nhân Bách Khoa ra trường thì “4000 USD/năm tương đương khoảng 7.5 triệu đồng/tháng thì hợp lý, và cũng là cao hơn mặt bằng xã hội”, “xạo chó”, “ra trường 4k có cái củ cải” … là những câu trả lời mình nhận được khi gửi bức ảnh trên và hỏi những người trong nghề và có có cả những người với mức lương >= 4000 USD.
Quay về vấn đề chính thôi, mình học lập trình để làm gì? Đơn giản thôi, mình học để hiểu về cách của mọi thứ trên Internet đang hoại động và để nó là công cụ cho mình để thực hiện được những gì mình muốn: Làm một trang web, vẽ bản đồ trà sữa, viết một con chatbot, blabla … Với mình, ngôn ngữ trong lập trình cũng giống như Tiếng Anh nó giúp bạn giao tiếp với các lập trình viên khác và thế giới.
Trong cuộc sống, chúng ta không khó để thấy những sự thật về những con người thành công trong nhiều lĩnh vực nhưng những lĩnh vực đó không hề hot hay được truyền thống tung hô ví dụ: nuôi lợn, trồng rau, … vì đơn giản họ tìm thấy được đam mê của mình với nghề và tiềm năng của nghề. Do đó chúng ta thấy được sự thành công đến từ bản thân bạn chứ không phải ngành nghề của bạn
Kiểu dữ liệu float là viết tắt của “real floating-point number” – kiểu “số thực dấu chấm động”.
float là một cách BIỂU DIỄN XẤP XỈ cho một số thực (real number) bằng cách đánh đổi độ chính xác (precision).
Các quy tắc / chuẩn để biểu diễn float được mô tả trong tiêu chuẩn quốc tế IEEE 754
Số thực
là tập số gồm:
các số hữu tỷ (số biểu diễn được ở dạng phân số: VD: 2, 1/3)
và các số vô tỷ (số không biểu diễn được ở dạng phân số: VD: căn bậc 2 của 2)
Số vô tỷ
Bản chất của các số vô tỷ là bạn không thể biểu diễn chính xác chúng ở dạng số (A.BCDEF) hay phân số. Vậy nên khi biểu diễn các số vô tỷ bằng kiểu float, ta chỉ biểu diễn một giá trị gần đúng với giá trị thật, trong một phạm vi sai số ta chấp nhận.
In [14]: import math
In [15]: math.sqrt(2)
Out[15]: 1.4142135623730951
Ở các trường đại học có dạy môn giải tích số / phương pháp tính, đưa ra các cách tính để tính ra các số phần thập phân của căn bậc 2 của 2 trong phạm vi sai số cho phép. Có thể kể tới phép lặp Newton.
Số hữu tỷ
Đối với các số hữu tỷ, ta luôn có thể biểu diễn chúng ở dạng phân số thập phân (decimal fractions). Nhưng nếu không sử dụng ký hiệu phân số để biểu diễn, giá trị số thực thu được không bằng giá trị thật của phân số. Ví dụ với 1/3, khi biểu diễn trên máy tính bằng kiểu float, 1/3 sẽ chỉ được biểu diễn bằng giá trị xấp xỉ của nó:
In [1]: 1/3
Out[1]: 0.3333333333333333
In [2]: len(str(1/3))
Out[2]: 18
Dù đã biểu diễn bằng 17 con số (16 số sau dấu thập phân .) thì giá trị mà ta nhìn thấy vẫn không phải là giá trị chính xác mà ta cần biểu diễn, dù có thêm bao nhiêu số sau dấu phẩy đi nữa.
Một lý do mà số hữy tỷ không được biểu diễn chính xác trên máy tính nữa là do: máy tính biểu diễn các giá trị phân số thập phân (hệ 10) bằng các phân số nhị phân (các phân số có mẫu là lũy thừa của 2 – binary fractions).
Ví dụ: 0.125 là biểu diễn thập phân của giá trị 1/10 + 2/100 + 5/1000 sau khi rút gọn ta có phân số tối giản là 1/8. Máy tính biểu diễn giá trị này ở hệ nhị phân: 0.001 – có giá trị là 0/2 + 0/4 + 1/8 = 1/8. Vấn đề dẫn đến sai số khi dùng float biểu diễn các số hữu tỷ là bởi hầu hết các phân số hệ thập phân không có biểu diễn ở hệ nhị phân. Điều này dẫn đến mỗi số float người dùng nhập vào sẽ được máy tính lưu trữ tương ứng một giá trị nhị phân gần bằng với nó. Ví dụ với biểu diễn 0.1 hay giá trị ở hệ thập phân là 1/10. Khi đưa vào máy tính biểu diễn ở dạng phân số nhị phân, ta có phân số sau đây:
In [1]: 3602879701896397 / 2 ** 55
Out[1]: 0.1
In [2]: format(3602879701896397 / 2 ** 55, '.17f')
Out[2]: '0.10000000000000001'
Giá trị máy tính thực sự lưu trữ kiểu float khi người dùng gõ 0.1 là giá trị sinh bởi phân số nói trên. Và nó không bằng 0.1.
Khi ta cộng 3 giá trị 0.1 với nhau sẽ có:
In [1]: 0.1
Out[1]: 0.1
In [2]: 0.1 + .1 # .1 là kiểu viết tắt cho 0.1
Out[2]: 0.2
In [3]: 0.1 + .1 + .1
Out[3]: 0.30000000000000004
In [4]: 0.1 + .1 + .1 == 0.3
Out[4]: False
Vậy nên, khi nhìn thấy số kiểu float, thì khả năng lớn nó không phải là một giá trị chính xác, mà chỉ là giá trị xấp xỉ – mặc dù việc xấp xỉ (làm tròn) này không đáng kể – nhưng khi dồn lại nhiều sẽ dẫn đến một sai số lớn. Điều này khiến các ứng dụng liên quan đến tài chính không bao giờ dùng kiểu float. Đặc biệt không so sánh các số kiểu float với nhau vì sẽ gặp những kết quả bất ngờ như ví dụ trên. Để so sánh float, dùng function math.isclose
In [1]: import math
In [2]: math.isclose(10**60, 1e60)
Out[2]: True
In [3]: 10**60 == 1e60
Out[3]: False
In [4]: type(1e60)
Out[4]: float
Khi cần tính toán chính xác, hãy sử dụng các thư viện có sẵn của Python như decimal, fraction để tính toán chính xác:
In [5]: from decimal import Decimal as D
In [6]: D('0.1') + D('0.1') + D('0.1') == D('0.3')
Out[6]: True
Cách tìm ra phân số nhị phân được dùng để xấp xỉ giá trị 0.1
In [4]: n = 0.1
In [5]: n.as_integer_ratio()
Out[5]: (3602879701896397, 36028797018963968)
In [6]: t, m = (0.1).as_integer_ratio()
In [7]: import math
In [8]: math.log2(m)
Out[8]: 55.0
In [9]: 2 ** 55
Out[9]: 36028797018963968
In [12]: from fractions import Fraction as F
In [13]: F.from_float(0.1)
Out[13]: Fraction(3602879701896397, 36028797018963968)
Với dạng biểu diễn phân số nằm dưới giá trị float 0.1, ta lấy tử số nhân với 10 rồi so sánh với mẫu số xem lệch bao nhiêu (nếu không lệch thì tử * 10 – mẫu == 0).
Bài viết được sự cho phép của tác giả Kien Dang Chung
Cùng với sự phát triển của các Framework Javascript và CSS, các website ngày càng sử dụng nhiều hơn mã Javascript, CSS giúp nâng cao trải nghiệm người dùng. Với các Framework Javascript mạnh mẽ như Vue.js, React, Angular… việc xây dựng website có tính tương tác cao, tải nhanh chóng, sử dụng mô hình ứng dụng đơn trang trở lên đơn giản. Cũng chính vì lẽ đó, số lượng các thư viện, các module sử dụng trong ứng dụng trở lên không kiểm soát nổi khi hệ thống website phình ra. Khi đó, mã nguồn cần được thiết kế sao cho quản lý được tốt là một vấn đề. Có rất nhiều các hệ thống quản lý module nổi tiếng như Browserify, RequireJS… tuy nhiên Webpack làm tốt hơn cả với nhiều tính năng nổi trội. Khi tìm hiểu Laravel 5.4, có phần Laravel Mix là công cụ để tập hợp và biên dịch mã javascript và css chúng ta thấy rằng Laravel Mix dựa trên Webpack để bundle (đóng gói các thư viện khác nhau lại) các module.
Về ý tưởng Webpack là một công cụ đóng gói các module và các thư viện phụ thuộc thành các file tĩnh, mục tiêu Webpack muốn đạt được là:
Chia nhỏ toàn bộ tài nguyên các thư viện và các tài nguyên phụ thuộc thành các “chunk” và chỉ tải các thành phần nhỏ này khi cần thiết.
Giúp quá trình tải các tài nguyên nhanh.
Mọi file tĩnh sau quá trình đóng gói sẽ ở dạng module.
Cho phép tích hợp các thư viên bên thứ ba ở dạng module.
Cho phép cá nhân hóa mọi thành phần của công cụ đóng gói module.
Thích hợp cho cả những dự án cực lớn.
Cài đặt Webpack
Webpack có thể cài đặt thông qua các công cụ quản lý thư viện lập trình Javascript như npm hoặc yarn, chúng ta cần cài đặt gói webpack toàn cục để có thể dùng được với CLI (Command Line Interface).
npm install webpack -g
yarn global add webpack
Sau khi cài đặt xong chúng ta có thể kiểm tra xem webpack được cài đặt ok chưa bằng câu lệnh webpack -v:
c:\xampp\htdocs>yarn global add webpack
yarn global v0.23.4
warning No license field
[1/4] Resolving packages...[2/4] Fetching packages...
warning fsevents@1.1.1: The platform "win32" is incompatible with this module.
info "fsevents@1.1.1" is an optional dependency and failed compatibility check.
Excluding it from installation.[3/4] Linking dependencies...[4/4] Building fresh packages...
success Installed "webpack@2.5.0" with binaries:- webpack
warning No license field
Done in 5.42s.
c:\xampp\htdocs>webpack -v
2.5.0
Ok, như vậy chúng ta đã cài đặt xong Webpack. Tiếp theo chúng ta cùng nhau bắt đầu một ví dụ trước khi đi vào tìm hiểu các khái niệm trong Webpack.
Ví dụ đầu tiên sử dụng Webpack
Trong ví dụ đầu tiên về Webpack chúng ta sẽ tạo ra một thư mục webpack-demo bằng câu lệnh:
C:\>mkdir webpack-demo && cd webpack-demo
C:\webpack-demo>
Tiếp đó, thực hiện tạo ra file package.json mẫu bằng lệnh npm init –yes hoặc npm init -y.
C:\webpack-demo>npm init -y
Wrote to C:\webpack-demo\package.json:{"name":"webpack-demo","version":"1.0.0","description":"","main":"index.js","scripts":{"test":"echo \"Error: no test specified\" && exit 1"},"keywords":[],"author":"","license":"ISC"}
Bước tiếp theo, chúng ta thực hiện cài đặt webpack cục bộ thông qua npm và chèn một entry vào devDependencies với câu lệnh:
Mở package.json ra trong thuộc tính devDependencies chúng ta đã thấy có webpack:
"devDependencies":{"webpack":"^2.5.1"}
Với cách cài đặt cục bộ này, webpack không thể sử dụng trong các CLI (Xem thêm cách cài đặt cục bộ và cài đặt toàn cục gói phần mềm thông qua Npm). Tiếp theo, tạo một thư mục app trong thư mục webpack_demo với một file index.js nằm trong đó. Nội dung file index.js như sau:
function component (){var element = document.createElement('div');/* lodash is required for the next line to work */
element.innerHTML = _.join(['Hello','webpack'],' ');return element;}
document.body.appendChild(component());
Để chạy đoạn code này, chúng ta tiếp tục tạo ra file index.html nằm trong thư mục gốc dự án là thư mục webpack_demo với nội dung:
Ok, khi chạy index.html chúng ta thấy dòng chữ Hello webpack, để ý rằng trong index.js đã sử dụng gói lodash với hàm join để gắn kết hai từ Hello và webpack. Do đó, trong file HTML chúng ta cần chèn mã nguồn gói lodash vào. Các file HTML và Javascript này hết sức bình thường với cách làm thông thường trước đây, tuy nhiên chúng ta thấy trong file HTML có tới hai thẻ <script> để chèn vào mã nguồn hai file Javascript, tiếp theo chúng ta sẽ sử dụng Webpack để bundle (đóng gói) chúng lại thành một file duy nhất. Để đóng gói, đầu tiên chúng ta cần cài đặt cục bộ gói lodash và tạo một entry vào dependencies trong package.json với câu lệnh npm install –save lodash
Sau đó, chúng ta điều chỉnh nội dung file app/index.js:
import _ from 'lodash';function component (){var element = document.createElement('div');/* lodash is required for the next line to work */
element.innerHTML = _.join(['Hello','webpack'],' ');return element;}
document.body.appendChild(component());
Thêm dòng import _ from ‘lodash’; để tải lodash và sử dụng. Trong file HTML index.html thay vì hai thẻ <script> chúng ta thay bằng một thẻ và trỏ đến file bundle.js là file Webpack đóng gói từ hai nguồn index.js và gói lodash được cài đặt ở trên.
Ở đây, chúng ta sử dụng gói webpack được cài đặt cục bộ trong dự án webpack_demo để thực hiện đóng gói tài nguyên. Mở file dist/bundle.js chúng ta thấy sẽ có mã nguồn gói lodash, mã wrapper của webpack và mã nguồn file index.js đã được chuyển dạng. Thực hiện chạy file index.html chúng ta thấy kết quả vẫn như cũ nhưng việc chèn file Javasript chỉ còn lại một file dist/bundle.js. Thử tưởng tượng nếu dự án của bạn sử dụng hàng trăm các gói phần mềm Javascript khác nhau, chưa kể các file Javascript do bạn tự phát triển, khi đó webpack sẽ đóng gói tất cả chúng vào một file duy nhất và bạn chỉ cần insert file này vào file HTML là chạy được. File bundle.js ở trên ở dạng đọc được, tuy nhiên khi triển khai lên máy chủ web, chúng ta cần “minify” chúng đi nhằm giảm dung lượng file bundle.js giúp SEO tốt hơn. Để thực hiện minify các file đầu ra chỉ cần thêm cờ -p (ngắn gọn của –optimize-minimize) trong khi thực hiện lệnh webpack.
OK, giờ mở file bundle.js bạn sẽ thấy code trong file này đã được minify.
Các khái niệm cơ bản trong Webpack
Ví dụ trên đây giúp bạn hiểu webpack dùng để làm gì một cách dễ dàng. File bundle.js được tạo ra thông qua việc sử dụng các câu lệnh, tuy nhiên khi việc đóng gói trở lên phức tạp với nhiều đầu vào và các thiết lập chúng ta cần định nghĩa file cấu hình cho Webpack. Chúng ta tạo ra một file webpack.config.js nằm trong thư mục gốc của dự án webpack_demo với nội dung:
var path =require('path');
module.exports ={
entry:'./app/index.js',
output:{
filename:'bundle.js',
path: path.resolve(__dirname,'dist')}};
Khi đó bạn chỉ cần thực hiện lệnh webpack là cho ra kết quả tương tự mà không cần đưa các tham số vào cho lệnh webpack.
Watch mode – đóng gói ngay khi thay đổi
Để ý là trong quá trình viết code, mỗi lần khi thực hiện thay đổi code các file Javascript, CSS chúng ta lại phải chạy lại lệnh webpack để thực hiện đóng gói, như vậy quả là phiền phức trong quá trình phát triển ứng dụng khi mà việc thay đổi code xảy ra thường xuyên. Watch mode sẽ giải quyết vấn đề này, khi bạn thực hiện lệnh webpack với cờ -w (ngắn gọn của –watch) thì mỗi khi code thay đổi webpack sẽ tự động đóng gói mà chúng ta không cần làm gì khác. Chú ý, bạn không được tắt màn hình console bởi watch mode sẽ chạy liên tục để kiểm tra xem mã nguồn của bạn có thay đổi không thông qua các mã băm.
Ok, tiếp theo bạn thử thay đổi file index.js thêm dòng alert(‘Webpack watch mode’); vào cuối file index.js như sau:
import _ from 'lodash';function component (){var element = document.createElement('div');/* lodash is required for the next line to work */
element.innerHTML = _.join(['Hello','webpack'],' ');return element;}
document.body.appendChild(component());alert('Webpack Watch mode');
Ngay lập tức, trên màn hình console bạn sẽ thấy Webpack phản ứng ngay:
Bạn mở thử file index.html thì thấy kết quả là đoạn code vừa thêm vào đã có tác dụng ngay. Chúng ta cũng có thể cấu hình watch mode trong file webpack.config.js với thuộc tính watch như sau:
var path =require('path');
module.exports ={
entry:'./app/index.js',
output:{
filename:'bundle.js',
path: path.resolve(__dirname,'dist')},<strong>watch:true</strong>};
Tiếp theo chúng ta cùng tìm hiểu các khái niệm cơ bản khác của Webpack như Entry, Ouput, Loader, Plugin
Entry
Trong file webpack.config.js chúng ta thấy có thuộc tính entry, đây chính là điểm bắt đầu khi ứng dụng chạy và cũng chính là điểm bắt đầu để Webpack đọc và phân tích các gói thư viện liên quan, các file liên quan cho việc đóng gói.
Khi webpack đóng gói tất cả các module liên quan, bạn cần thiết lập cho webpack nơi file kết quả được tạo ra sau khi đóng gói. Webpack sử dụng thuộc tính output trong đối tượng cấu hình:
Trong ví dụ trên, chúng ta sử dụng các thuộc tính output.filename và output.path để nói cho webpack là tên file đầu ra và đường dẫn nơi đặt file đầu ra này.
Loader
Loader cho phép bạn tiền xử lý một file khi bạn sử dụng câu lệnh require() để tải nó, các loader chuyển đổi file từ các ngôn ngữ khác nhau như TypeScript, CoffeeScript… sang Javascript, nó thậm chí cho phép bạn require() file CSS trong Javascript. Webpack xử lý các file (.css, .html, .scss, .jpg…) như những module, tuy nhiên webpack chỉ hiểu Javascript do đó nó cần các loader. Hiện nay, đã có rất nhiều các thư viện mã nguồn Javascript được viết ở chuẩn ES6 (ECMAScript 2015), tuy nhiên các trình duyệt vẫn chưa hỗ trợ cho tiêu chuẩn này, do đó khi sử dụng các đoạn mã ES6 sẽ không thể chạy được trên trình duyệt, tuy nhiên với loader babel nó sẽ giúp tiền xử lý ES6 thành ES5 và từ đó Webpack có thể tiếp tục công việc của mình. Để sử dụng các gói phần mềm loader này chúng ta cần cài đặt thông qua npm hoặc yarn:
Chú ý, do babel-loader phụ thuộc gói babel-core và chúng ta cũng muốn chuyển đổi mã nguồn từ ES2015 hay ES6 về dạng ES5 để trình duyệt có thể xử lý được nên chúng ta cần cấu hình cho babel-loader sử dụng preset do đó gói babel-preset-es2015 là cần thiết. Do đó chúng ta cần cài đặt cả ba gói phần mềm trên để cấu hình cho loader.
Loader chỉ được sử dụng để thực hiện các chuyển dạng cho các file cần xử lý, plugin thì khác, nó thực hiện các hành động hoặc các chức năng của người dùng trên các compilation hoặc chunk. Để sử dụng các plugin, bạn cần sử dụng require() và sau đó đưa chúng vào mảng plugins của đối tượng cấu hình.
Webpack là một công cụ module bundler xuất sắc, đặc biệt khi bạn require cả mã HTML và CSS trong Javascript, Webpack thực hiện nó rất tốt, nó hữu dụng trong những tình huống như bạn muốn tải file CSS trong mã Javascript. Chúng tôi sẽ còn quay lại với công cụ Webpack trong các bài viết tiếp theo.
Kỹ năng đàm phán trong tuyển dụng được xem là một kỹ năng quan trọng đối với công việc tuyển dụng. Đàm phán giúp tạo ra cầu nối chặt chẽ hơn giữa ứng viên và nhà tuyển dụng. Từ đó, giúp cả hai bên định hình; làm rõ và thống nhất hơn về các nhiệm vụ cần thực hiện trong thời gian tới. Cùng TopDev tìm hiểu bài viết sau đây để nắm rõ những kỹ năng đàm phán cùng nhà tuyển dụng!
Thế nào là kỹ năng đàm phán trong tuyển dụng?
Khi một cá nhân đã và đang làm việc tại một tổ chức/doanh nghiệp nào đó, việc xảy ra tranh chấp, bất đồng nảy sinh là điều khó tránh khỏi.
Đây có thể được xem là hệ quả của việc chưa có sự tìm hiểu, bàn bạc, thảo luận và thống nhất về cac quy chế, nhiệm vụ công việc, các yếu tố cần lưu ý đối với môi trường – văn hóa doanh nghiệp,…. Chính việc bạn chưa có kỹ năng đàm phán trong tuyển dụng đã tạo ra các mâu thuẫn về ý kiến; những ảnh hưởng về quyền lợi, phát ngôn, các điều khoản hợp đồng tuyển dụng,…
kỹ năng đàm phán trong tuyển dụng
Để giải quyết vấn đề này, không còn cách nào khác chính là trao đổi kỹ lưỡng và đánh giá thống nhất giữa các thể chế giúp xây dựng định hướng/lộ trình thực thi phù hợp. Do vậy, chúng ta có thể nhận thấy kỹ năng đảm phán cùng nhà tuyển dụng là rất quan trọng. Hãy cùng TopDev khái quát thế nào là đàm phán trong tuyển dụng nhé!
Đàm phán trong tuyển dụng là gì?
Nói một cách dễ hiểu, đàm phán trong tuyển dụng được dùng phạm vi hoạt động của lĩnh vực nhân sự. Đồng thời, mô tả quá trình thảo luận để đi đến một sự nhất trí trên cơ sở đồng thuận; thỏa hiệp giữa các bên về nhiệm vụ công việc; cách thức giải quyết các vấn đề liên quan đến quyền lợi của hai bên và các bên liên quan (nếu có).
Những cuộc thương lượng mang đậm ấn về kỹ năng đàm phán trong tuyển dụng là điều vẫn đang diễn ra. Cùng điểm qua top các chiến lược đàm phán hiệu quả dành cho bạn. Hãy lưu tâm để áp dụng; cải thiện kỹ năng đàm phán trong tuyển dụng một cách tốt nhất.
Bỏ túi các tip giúp phát huy kỹ năng đàm phán trong tuyển dụng
1. Nên biết về giới hạn của sự thương lượng
Đây là điều quan trọng mà hầu như nhiều cá nhân bỏ qua. Đừng thương lượng quá nhiều với nhà tuyển dụng. Đặc biệt, đó lại là lần gặp gỡ đầu tiên.
Hãy đặt bản thân trong tư tưởng/suy nghĩ của các nhà tuyển dụng, bạn cần biết họ cần thấy điều gì ở bạn và phát huy nó. Đừng cố tỏ ra mình đắt giá khi họ chưa có những thách thức để thử mức độ “giá trị” của bạn. Không thương lương quá nhiều!
Việc luôn đưa ra nhiều mong muốn với nhà tuyển dụng sẽ khiến họ trở nên “ngộp”. Họ sẽ nghĩ bạn chỉ đang làm mọi cách để có lợi cho bản thân. Điều này hoàn toàn không tốt khi chính bạn sẽ có những bất đồng với doanh nghiệp trong các khía cạnh khác nhau sau này: ngân sách, cách thức tổ chức, phương thức tiếp cận – đánh giá, các giải pháp,… Vì vậy, điều đầu tiên là phải biết lắng nghe để hiểu họ. Đừng thương lượng quá nhiều với họ ngay từ đầu.
2. Đàm phán thông minh – Không nên đánh giá quá thấp bản thân
Mỗi cá nhân đều có những thế mạnh của riêng mình. Đúng là việc nếu phô bày quá nhiều về bản thân; lấy đó là cơ sở để tạo ra sự thương lượng thì không điều khó hoàn toàn không nên; có thể gây ra tác dụng ngược. Tuy vậy, ứng viên cũng đừng quá tự ti, e ngại về năng lực của mình mà không dám thể hiện. Cơ hội không đến nhiều lần. Và bạn cần phải nắm bắt tốt chúng. Nếu bạn còn không tự tin với chính mình thì sao nhà tuyển dụng có thể tin tưởng bạn.
3. Xem xét và cân nhắc trước mọi lời mời thương lượng
Hãy ghi nhớ điều này để không phải chịu thiệt thòi của “ván cờ tuyển dụng”. Thường bên phía tuyển dụng dễ dàng đưa ra các lời mời họ. Họ sẽ làm mọi cách để khiến bạn chấp nhận lời thương lượng đó.
kỹ năng đàm phán trong tuyển dụng
Nếu thiếu sự tỉ mỉ và nhanh nhạy, bạn khó có thể bắt kịp ý đồ của họ. Vô tình, bạn trở thành một con cờ trong chính suy nghĩ cảm tính họ phía tuyển dụng. Và một điều dễ nhận thấy, lời thương lượng đầu từ họ đều chỉ có lợi cho họ mà thôi. Đừng để những phát ngôn của họ dẫn dắt.
Hãy tỉnh táo và luôn xem xét mọi lời mời thương lượng trước khi đi đến quyết định cuối cùng.
4. Hãy lắng nghe nhiều hơn
Sự lắng nghe và giao tiếp hiệu quả chính là hai yếu tố quan trọng giúp hoàn tiện kỹ năng đàm phán trong tuyển dụng. Bạn cần có một sự điều tiết tốt trong lời nói. Khi tham gia đàm phán, việc lắng nghe giúp bạn ghi nhận những thông tin một cách chuẩn xác. Từ đó, bạn có sự phân tích; kết nối thông tin để đưa ra những lời đối đáp phù hợp nhất.
Nói ít đi và không nên vội vàng trong phát ngôn. Hãy đảm bảo bạn thật sự là một cá nhân trong hội thoại đàm phán. Việc bạn cân bằng giữa lắng nghe và suy nghĩ giúp phát ngôn tương tác của bạn có chiều sâu hơn, đúng trọng tâm và do vậy, quá trình thương lượng cũng diễn ra một cách tốt hơn.
5. Khéo léo thương lượng
Khi đàm phán với nhà tuyển dụng, bạn sẽ phải đưa ra những tiêu chí riêng. Đó có thể là một mức lương phù hợp với năng lực; một lời gợi mở về các định hướng lâu dài từ công ty; một mức lương dao động. Chính từ những cơ sở nội dung đó, nhà tuyển dụng sẽ xem xét dựa trên năng lực, cá tính, sự hòa hợp môi trường văn hía doanh nghiệp. Ví dụ thực tế trong việc đề xuất về mức lương mong muôn.
kỹ năng đàm phán trong tuyển dụng
Thường khi bạn tự đưa ra những con số mà bạn cho là phù hợp với năng lực của mình. Tất nhiên, nhà tuyển dụng sẽ chọn cho bạn một mức lương thấp nhất trong khoảng bạn vừa đề xuất đến. Vậy tại sao trong trường hợp này không giành lấy cơ hội để có một mức lượng cao hơn.
Đừng lo sợ mà hãy tin tưởng bản thân! Để rồi vững tin để có thề hoàn toàn yêu cầu một mức lương ổn định nhất. Đây cũng là biểu hiện, bạn thật sự biết rõ mình ai, bạn đến đây làm gì và mong muốn tạo ra gì khác biệt.
6. Đảm bảo thống nhất quyền lợi bình đẳng
Một điều cực quan trọng trong kỹ năng đàm phán cùng nhà tuyển dụng chính lả yếu tố thống nhất về tính quyền lợi. Thực tế, bạn cần hiểu mọi cuộc đàm phán cần có sự thuân thủ nguyên tắc “có qua có lại”. Nếu việc thương lượng giữa hai bên không có sự thống nhất về quyền lợi; hoặc chênh về quyền lợi sẽ tạo ra sự tranh chấp lớn. Ứng viên với nhà tuyển dụng khi tham gia đàm phán tức là bước vào giai đoạn của sự hợp tác. Vì thế, cần phải đảm bảo thống nhất về quyền lợi bình đẳng để giảm thiểu; loại bỏ các vấn đề mâu thuẫn phát sinh trong quá trình tiếp nhận và thực hiện công việc.
Một số lỗi cần tránh khi phỏng vấn tuyển dụng – Bí quyết nâng cao kỹ năng đàm phán trong tuyển dụng
Phỏng vấn tuyển dụng có mối tương quan lớn với việc thương lượng. Việc nắm bắt tốt một số lỗi cần tránh khi phỏng vấn tuyển dụng có một ý nghĩa quan trong để rèn luyện kỹ năng đàm phán trong tuyển dụng.
1. Tuyệt đối không được vội vàng
Những cuộc đàm phán nhanh chóng đến rồi cũng sẽ sớm kết thúc. Kết quả đọng lại là những lời phát ngôn thiếu tính khả thi do quá trình thống nhất vẫn chưa được diễn ra. Do vậy, để thương lượng – phỏng vấn hiệu quả, bạn cần có sự nhẫn nại, lắng nghe cùng óc phân tích các vấn đề được đề cập xuyên xuốt. Nhờ việc theo dõi kỹ lưỡng đối phương, không vội vàng, bạn sẽ dễ dàng nhận ra được nhiều mấu chốt của vấn đề. Thậm chí, bạn còn biết được đâu là phần người nói muốn nhấn mạnh. Vì vậy, hãy thật sự lưu tâm bí quyết này nhé!
Những cuộc thương lượng kết thúc nhanh chóng bao giờ cũng không tốt. Mỗi cuộc Vì vậy, nếu như bạn nhận ra sự thay đổi khác thường nào đó thì có thể họ đang lợi dụng sự bất cẩn của bạn. Bạn cần phải thật bình tĩnh, suy nghĩ thấu đáo và tự hỏi 3 câu đã nêu ở điều 8 để những điều bất lợi không xảy ra với mình.
2. Tôn trọng và dè chừng đối thủ
Quá trình phỏng vấn – thương lượng không dễ dàng. Và chắc chắn bạn sẽ luôn gặp phải các thách thức tuyển dụng nhân sự. Một trong số đó là những câu hỏi khó khăn từ phía nhà tuyển dụng. Dù nhận được một câu hỏi nào liên quan đến các ứng viên khác. Bạn cần thể hiện mình là người tôn trọng đối thủ. Tất nhiên bạn nên có tự tin nhưng nó vẫn trong một giới hạn nhất định.
Tuyệt đối không được nói về những hạn chế của các ứng viên khác. Hoặc đơn giản, ứng viên sẽ thể hiện sự thất vọng thay vì thể hiện khao khát vị trí. Họ bắt đầu “bài tập làm văn” về những viễn cảnh có thể xảy ra nếu không may mắn trượt vị trí công việc này.
Tôn trong và dè chừng đối thủ được xem là một cách thể hiện thiện chí nhất, phù hợp nhất. Đồng thời, nó cũng được xem là cách trả lời các thách thức khó nhằn nhất đến từ nhà tuyển dụng.
Lời kết
Kỹ năng đàm phán là một kỹ năng rất quan trọng trong tuyển dụng. Không đơn thuần là nghệ thuật giao tiếp, đàm phán – thương lượng là kỹ năng giúp ứng viên/nhân viên bộc lộ khả năng phân tích; lắng nghe và tương tác hiệu quả với nhà tuyển dụng. TopDev hi vọng, bài viết trên có thể giúp bạn đọc hiểu được thế nào là kỹ năng đàm phán. Đồng thời nắm được bí quyết rèn luyện kỹ năng đàm phán cùng nhà tuyển dụng. Hãy áp dụng chúng vào thực tiễn cuộc sống để thiết lập hoàn chỉnh hơn bộ kỹ năng phát triển năng lực hơn từng ngày.
Giá tôi có thể biết những điều này trước khi bắt đầu viết code!
Tác giả: Nick Bull
Giới thiệu
Giống như rất nhiều lập trình viên khác, kể từ khi xác định được con đường sự nghiệp của mình tôi chỉ tập trung vào việc code mà thôi. Đối với tôi, code là một thứ ma thuật mà khi bạn gõ một thứ gì đó trên bàn phím, máy tính sẽ hiển thị ngay kết quả công việc của bạn trên màn hình. Nhưng đến gần đây khi đang làm việc với vai trò là một Full-stack developer, tôi mới nhận ra có rất nhiều điểm khác biệt, có những mặt tốt, mặt xấu khác nhau mà giá như tôi được biết trước.
Coding hiệu quả chịu ảnh hưởng nhiều của những yếu tố liên quan
Những kỹ năng viết code gì dev nên ghi nhớ?
1. Không chỉ đơn thuần là coding
Bạn nghĩ lập trình là gì? Là viết code? Là viết code chạy thành công?
Đó mới chỉ là một phần của vấn đề mà thôi! Lập trình không chỉ đơn thuần là viết code mà là giải quyết các vấn đề có thể xảy ra với code.
Khách hàng không quan tâm bạn sử dụng công nghệ, ngôn ngữ nào. Họ chỉ quan tâm đến một điều: sản phẩm của bạn có giải quyết được vấn đề của họ hay không.
Đó là lý do tại sao tương đối ít người quan tâm đến công nghệ mà Google tìm kiếm sử dụng. Miễn là mọi người có thể tìm thấy thông tin liên quan với nó, họ sẽ sử dụng nó. Đây cũng chính là điều số một tôi ước mình biết ngay từ khi bắt đầu lập trình.
Tôi sẽ dành ít thời gian hơn để viết ra những code tốt nhất và nhiều thời gian hơn để giải quyết các vấn đề của khách hàng theo cách nhanh nhất và hiệu quả nhất mà tôi có thể.
Đừng chỉ viết code một cách đơn thuần. Hãy viết code để giải quyết vấn đề của khách hàng!
2. Kỹ năng giao tiếp quan trọng không kém kỹ năng viết code
Khi tôi mới bắt đầu sự nghiệp của mình với tư cách là một lập trình viên, việc thiếu kỹ năng mềm không phải là vấn đề chính của tôi. Nhưng khi tôi thăng tiến dần lên những vị trí cao hơn, việc thiếu sót của kỹ năng mềm đã bộc lộ rõ ràng trong tôi.
Khi bạn làm việc trên một sản phẩm với một nhóm người khác nhau (kỹ sư, nhà thiết kế, nhà quản lý), giao tiếp là điều duy nhất khiến bạn có thể hòa nhập được với họ và giúp bạn phát triển sản phẩm một cách hiệu quả. Thiếu kỹ năng giao tiếp sẽ khiến mọi chuyện trở nên khó khăn, thậm chí là tồi tệ hơn hẳn. Nó làm tăng thời gian phát triển sản phẩm của bạn và giảm năng suất tổng thể.
Vì vậy, hãy cải thiện các kỹ năng mềm, kiến thức xã hội bên cạnh việc trau dồi kỹ năng viết code của mình. Vì tầm quan trọng của chúng là như nhau.
Và hãy nhớ một sự thật đơn giản: Con người làm việc với con người, chứ không phải máy móc.
3. Việc lập trình sẽ trở nên đơn giản hơn nếu bạn biết cách nắm bắt
Khi tôi bắt đầu làm quen với ngôn ngữ JavaScript, tôi thật sự thấy nó quá khó, đơn giản vì tôi bắt đầu sai cách. Tôi đọc rất nhiều lý thuyết mà không có thực hành, không có thói quen, và cũng không hề đặt ra mục tiêu cuối cùng là mình phải đạt được cái gì.
Tôi đã nghĩ rằng đây là chuyện hoàn toàn bình thường cho đến khi tôi phát hiện ra phương pháp học tập có chủ đích ảnh hưởng lớn như thế nào đến kết quả tôi sẽ đạt được.
Đó là một kiểu làm việc và học tập có mục đích, có hệ thống.
Sự khác biệt giữa luyện tập bình thường và luyện tập có chủ đích nằm ở sự tập trung. Và bạn phải có mục tiêu cụ thể là trở nên tốt hơn và cải thiện hiệu suất của mình.
Coding luôn đòi hỏi sự tập trung cao độ
Sau khi áp dụng một phương pháp thực hành có chủ ý, tôi bắt đầu nhận thấy mình tiến bộ nhanh như thế nào khi học JavaScript. Kiến thức của tôi bắt đầu gắn bó lâu dài, không chỉ trong 5 phút sau khi hướng dẫn. Tôi đã tạo ra mục tiêu cuối cùng của mình, trình bày rõ lý do tại sao tôi học JavaScript và hiểu những gì tôi cần học và những gì tôi không.
Vậy bạn cần làm gì để luyện tập thói quen đặt ra mục tiêu cho mình?
Tìm giáo viên: cung cấp các hoạt động thực hành được thiết kế để giúp bạn cải thiện hiệu suất.
Cố gắng thực hiện với nỗ lực tối đa: liên tục bị đưa ra khỏi vùng an toàn của bạn.
Có các mục tiêu cụ thể và được xác định rõ ràng: không chỉ là “cải tiến tổng thể”.
Đảm bảo rằng bạn tập trung: tập trung toàn bộ, không bị phân tâm.
Hoàn thành các hành động có chủ đích: lập ra những kế hoạch cụ thể.
Trả lời phản hồi ngay lập tức và sửa đổi chiến lược của bạn.
Khi bạn bắt đầu học một ngôn ngữ, công nghệ, khuôn khổ mới hoặc bất cứ thứ gì, hãy tuân thủ các quy tắc này để đạt được kết quả lớn nhanh nhất có thể.
Khi bắt đầu sự nghiệp của mình, tôi nghĩ rằng một lập trình viên giỏi là một người biết rất nhiều ngôn ngữ lập trình, nhiều cách làm, nhiều framework khác nhau.
Nhưng tôi nhận ra mình đã sai.
Tư duy như vậy chỉ sinh ra hội chứng “kẻ giả mạo”. Nó sẽ khiến bạn nghĩ rằng mình không xứng đáng với vị trí hiện tại, với mức lương hiện có, và rằng mình chỉ như một kẻ lừa đảo mà thôi.
Vì vậy, tôi bắt đầu theo dõi các dev nổi tiếng trên Twitter, đọc mọi ấn phẩm về công nghệ và xem hàng nghìn blog của họ chỉ để thuyết phục bản thân rằng tôi xứng đáng với những gì tôi có và để cảm thấy gần hơn với danh hiệu một developer giỏi nhất.
Nhưng sự thật thì đây không phải là việc làm hiệu quả trong việc cải thiện kỹ năng viết code.
Tôi phát hiện ra rằng rất nhiều người mà tôi theo dõi – những người mà tôi nghĩ rằng họ là lập trình viên siêu giỏi không thật sự hoàn hảo như tôi tưởng. Họ có thể đã biết cách thực hiện một số công việc phức tạp đòi hỏi kiến thức sâu rộng trong một vài lĩnh vực, nhưng điều đó không nghĩa với việc họ đã hiểu hết những kiến thức cơ bản khác. Họ có thể đã biết cách thiết kế kiến trúc cơ sở dữ liệu có khả năng mở rộng cao, nhưng lại không biết cách căn chỉnh theo chiều dọc một phần tử với CSS.
Không có ai là hoàn hảo nhưng nếu biết trước những điều này chắc chắn sẽ khiến bạn biết cách tự đánh giá và nhìn nhận lại giá trị của bản thân một cách chính xác nhất. Hãy học hỏi nhiều hơn, đọc nhiều hơn để tự nâng cao giá trị của bản thân.
Trước khi bắt đầu kiểm thử ứng dụng trên các thiết bị di động (gọi tắt là kiểm thử di động) như công cụ trò chuyện, mạng xã hội, trò chơi, ứng dụng kinh doanh…có một số điều mà một Tester kiểm thử di động cần phải biết để kiểm thử được hiệu quả.
Phân tích các ứng dụng tương tự: Hãy thử phân tích một số ứng dụng khác tương tự như ứng dụng của bạn. Ví dụ, nếu bạn phải kiểm thử ứng dụng chia sẻ tệp tin trên điện thoại di động, hãy tìm kiếm một số ứng dụng tương tự khác và quan sát tính năng của nó.
Giữ cho các trình giả lập (emulator) luôn sẵn sàng: đôi khi, chúng ta mất rất nhiều thời gian để mượn hoặc yêu cầu thiết bị di động cho việc kiểm thử. Trong trường hợp này, để tận dụng thời gian bạn có lẽ sẽ muốn kiểm thử một vài trường hợp trên trình giả lập.
Phân tích các vấn đề liên quan đến thiết bị: Một khi các thiết bị mục tiêu đã được xác định, bạn hãy tìm hiểu các vấn đề liên quan đến thiết bị đó. Điều này sẽ giúp bạn hiểu rõ vấn đề bạn đang và sẽ gặp phải liên quan đến thiết bị hay ứng dụng.
Sử dụng trình giả lập nhưng không hoàn toàn tin tưởng nó: Bạn có thể cần đến các trình giả lập trong khi kiểm thử, tuy nhiên hay ghi nhớ rằng không được thực hiện 100% test case trên emulator. Thêm vào đó, thời gian đáp ứng ở emulator rất khác với thiết bị thực, cho nên bạn có thể sẽ bỏ qua một số lỗi và những lỗi này chính là điểm yếu của các thiết bị thật.
Xác định các tiêu chuẩn về hiệu suất (performance): đối với bất kỳ ứng dụng di động nào, hiệu suất chính là điều lo lắng lớn nhất. Hãy đảm bảo là bạn có những tham số hoặc yêu cầu kiểm thử về hiệu suất để bạn có thể dựa vào chúng trong quá trình kiểm thử. Bộ nhớ cũng là 1 trong những yếu điểm của các thiết bị di động, và ứng xử của ứng dụng lệ thuộc vào những điều kiện này. Hãy dành cho nó một sự quan tâm phù hợp
Gradle là 1 trong những công cụ tự động hóa quá trình build và quản lý các thư viện, nhằm tối ưu hóa công đoạn biên dịch, đóng gói, thuận tiện hơn cho việc phát triển phần mềm.
Năm 2000, Apache Ant ra đời như là một trong những tool đóng gói hiện đại và nhanh chóng được sử dụng trong các dự án sử dụng ngôn ngữ Java. Ant cho phép nhà phát triển mô tả meta-data của dự án cũng như các hoạt động trong quá trình build thông qua bộ cú pháp XML. Tuy nhiên những đoạn mã viết theo tiêu chuẩn của Ant quá dài và phức tạp.
Năm 2004, Apache Maven ra đời và đưa ra các cải thiện so với Ant. Bằng việc đưa ra một cấu trúc dự án tiêu chuẩn, Maven cho phép nhà phát triển sử dụng một trong các plugin của mình thay vì phải viết toàn bộ các dòng code mô tả quá trình đóng gói. Ngoài ra Maven còn cho phép tải về các thư viện phụ thuộc thông qua internet, điều này giúp cho việc chia sẻ cũng như quản lý phiên bản trở nên dễ dàng hơn. Đổi lại, nhà phát triển sẽ mất khá nhiều công sức để tùy chỉnh nếu cấu trúc dự án hiện tại không tuân theo Maven Standard Directory Layout. Và việc vẫn sử dụng XML làm cho file POM (Project Object Model) trở nên dài dòng và phức tạp để nắm bắt logic.
Năm 2012, Gradle release version 1.0 kết hợp các ưu điểm của Ant và Maven đồng thời thêm vào các cải thiện mới và sử dụng Groovy trong việc giải quyết bài toán đóng gói.
1. Các ưu điểm của Gradle
1.1 Build cho nhiều ngôn ngữ
Gradle hỗ trợ build cho 60 ngôn ngữ lập trình khác nhau bao gồm Java, Scala, Python, C/C++, Android, iOS.
Java + JVM languages
Được thiết kế để chạy trên JVM, Gradle hỗ trợ mạnh mẽ cho các dự án viết bằng Java và các ngôn ngữ JVM khác như Scala, Groovy,… với việc hỗ trợ nhiều loại ứng dụng và công cụ phát triển thiết yếu như test frameworks (JUnit, TestNG, Spock), application frameworks (Java EE, Grails, Play!), embedded web servers (Jetty) and code analysis cops (Checkstyle, CodeNarc, FindBugs, JDepend, PMD, JaCoCo, Sonar).
Android’s build system
Tích hợp với Android Studio hỗ trợ quản lý dependency, multi-project. Đồng thời tích hợp các test services phổ biến như AppThwack, TestDroid và Manymo. Ngoài ra, có thể tạo nhiều APK từ 1 module và upload chúng lên Google Play và các app store khác với các phiên bản khác nhau (free, paid,…)
C/C++, Objective-C/C++, Assembly, CUnit
Hỗ trợ compiler, assembler và linker; cho phép phân phối các thư viện, file thực thi với nhiều loại (debug, release), platforms (x86, x86_64), phiên bản (community, enterprise) khác nhau. Tích hợp GCC, CLANG, XCODE, VISUAL C++ …
Từ các IDE (Integrated Development Environment) đến các CI (Continuous Integration) hay các công cụ deploy, Gradle tích hợp với tất cả mọi thứ mà bạn có thể nghĩ đến. Tham khảo danh sách các tool có thể tích hơp: https://gradle.org/why/integrates-with-everything/
Build script viết bằng Gradle ngắn gọn và trực quan dễ đọc hơn
Thời gian build của gradle nhanh hơn
Maven
quá trình build diễn ra lâu do quá trình clean toàn bộ các artifact và sau đó là quá trình đóng gói lại từ đầu.
các đoạn Unit Test cũng tiêu tốn khá nhiều thời gian
Gradle
một task build đều được định nghĩa input và output, nên khi có sự thay đổi nhỏ trong source code, Gradle sẽ chỉ thực hiện build lại một phần cần thiết
Gradle sẽ tự tìm kiếm các task khác lệ thuộc task này và thực hiện quá trình build lại
Gradle cho phép chạy parallel các đoạn code test nhờ đó rút ngắn thời gian của quá trình build
Ngoài ra Gradle cho phép thực hiện việc phân phối các đoạn code test qua nhiều machine khác nhau để giảm thiểu thời gian chờ đợi
Và khi gặp lỗi, sẽ không phải chờ đợi quá lâu để build và gặp lỗi, sửa lỗi và build lại
Maven
dừng quá trình build ngay khi gặp lỗi
Gradle
thực thi hết tất cả các task có thể
tổng hợp toàn bộ các lỗi gặp phải trong một lần đóng gói
Gradle tương thích với Ant, Maven
Cho phép nhà phát triển phần mềm không tốn quá nhiều công sức khi không phải chuyển đổi toàn bộ để sử dụng Gradle.
Cộng đồng phát triển sử dụng gradle tăng một cách mạnh mẽ trong những năm gần đây đã đóng góp đáng kể trong việc giúp Gradle liên tục có thêm các cải thiện mới.
3. Tạo Build Script cơ bản
Dưới đây là build script đơn giản giúp tạo file jar và upload lên server test.
configurations {
sshAntTask
}
dependencies {
sshAntTask 'org.apache.ant:ant-jsch:1.9.2'
}
# Task Tạo file jar
jar {
baseName 'xxx' # Tên file
doFirst {
zip64 = true # Zip type
}
exclude 'META-INF/*.RSA', 'META-INF/*SF', 'META-INF/*.DSA'
# Main class
manifest {
attributes 'Main-Class' : xxx
}
# Tập hợp các dependency phụ thuộc
from configuration.compile.collect {
it.isDirectory() ? it : zipTree(it)
}
}
ant.taskdef {
name:'scp'classname:'org.apache.tools.ant.taskdefs.optional.ssh.Scp',
classpath: configurations.sshAntTask.asPath
}
# Task copy file jar tới server test
# Bằng cách sử dụng ssh scp
task scpJar() {
doLast {
file: file("xxx"), # Path file cần copy
trust: true,
todir:'user@server_ip:/home/' # @:/Path thư mục đíchpassword:'xxx' # Mật khẩu
}
}
Kết hợp với IDE, ví dụ với IntelliJ > Run > Edit Configurations để có thể nhanh chóng thực hiện các task trên với 1 vài phím tắt.
Theo định nghĩa của RESTful, server không lưu trữ bất kỳ thông tin gì về client state, nguyên tắc này gọi là Stateless. Phía client gửi thông tin cần thiết trên mỗi request
Stateless có gì hay?
Scale khả năng đáp ứng của API lên cho hàng triệu concurrent user bằng cách deploy lên nhiều server khác nhau. Bất kỳ server nào cũng có thể handle một request từ client vì tất cả thông tin cần thiết điều được gửi từ phía client.
Đơn giản hóa API nhờ vào việc gở bỏ việc đồng bộ logic của state
Dễ cache hơn. Phía server có thể quyết định cache hay không một kết quả HTTP request dựa vào thông tin của một request, những request trước đó không ảnh hưởng đến khả năng cache của request hiện tại.
Vài cái status code phổ biến?
201 created
204 No content
400 Bad request
403 Forbidden
404 Not found
405 Method not allowed
409 Conflict
500 internal server error
Cái gì cache được, cái gì không?
GET cache được
POST mặc định là không, nhưng có thể dùng expires header hoặc cache-control header nếu muốn bật cache
PUT/DELETE không
Khác nhau giữa AJAX và REST?
AJAX là một kỹ thuật thực hiện phía client để cập nhập giao diện, trong khi REST là một kiểu kiến trúc để truyền và xử lý HTTP Request.
Keep-Alive là gì và lợi ích của nó?
Mặc định một HTTP connection sẽ tự đống sau khi request đã complete, nghĩa là phía server sẽ close TCP connection sau khi đã gửi đi response. Để giữ connection này cho nhiều request, dùng thuộc tính keep-alive trên header
Bài viết được sự cho phép của tác giả Nguyễn Hữu Đồng
Khi làm việc với một ngôn ngữ, do giới hạn của các thư viện có sẵn, chúng ta chắc hẳn đều viết ra một thư viện riêng hoặc ít nhất là dùng thư viện của người khác viết.
Do mỗi người đều có một phong cách viết hay cách tiếp cậnkhác nhau nên sinh ra chuyện rất khó để mọi người có thể dùng các thư viện của nhau, và thậm chí trong mỗi phiên bản của một cá nhân đều có như thay đổi khiến cho việc sử dụng của người khác bị ảnh hưởng.
Và để giải quyết vấn đề này, cộng đồng sẽ quy định ra một tiêu chuẩn chung cho một thư viện được viết ra tuân thủ theo trình quản lí thư viện của cộng đồng đó, vị dụ bạn viết Nodejs Package thì bạn phải tuân thủ theo nguyên tắc của npm, hay nếu bạn viết một thư viện trong golang thì bạn phải tuân thủ theo tiêu chuẩn của go module.
Ví dụ, là tiêu chuẩn về phiên bản, mỗi phiên bản thường có dạng version@x.y.z trong đó x là phiên bản chính, y là phiên bản phụ và z là phiên bản bản vá, đơn cử nếu có 3 phiên bản là 1.1.3, 1.1.9, và 2.0.0 hai phiên bản đầu dường như không có gì khác nhau chỉ có điều khác là phiên bản 1.1.9 được release cùng những bản vá lỗi của 1.1.3 , còn 2.0.0 thì đây là một phiên bản hoàn toàn mới so với 1.1.3
Trong GoLang có hai khái niệm liên quan đến quản lí gói là Go Package và Go Module. Mỗi Go Package là tập hợp các file trong cùng một thư mục, hướng tới xử lí một tập hợp các vấn đề có liên quan đến thứ mà Package đó hướng tới, ví dụ, trong thư mục user của mình mình có 3 file .go cùng xử lí các vấn đề liên quan đối với user thì mình sẽ đặt tên package là user, việc này giúp năng cao khả năng tái sử dụng code cho những project sau này. Còn Go Module là tập hợp của các Go Package, mỗi project là một module và các package được sử dụng trong module đều được go quản lí bằng go.mod file.
Để tạo một module chạy lệnh. Và go.mod sẽ được tạo ra.
go mod init <module name>.
ví dụ : go mod init github.com/dongnguyenltqb/go-simple
go mod init go-simple
Trong mỗi file go.mod thì có ba phần chính. Phần đâu khai báo tên module, thông thường tên module giống với một url chỉ tới git responstory của module đó và phiên bản go đang sử dụng. Phần thứ 2 là phần tuỳ chỉnh URL của package, đa số là rút gọn , mỗi khi bạn import một package thay vì phải viết dài như “import “github.com/dongnguyenltqb/demo/untils” giờ nếu bạn thay thế phần “github.com/dongnguyenltqb/demo” bằng “demo/utils” thì sẽ đỡ tốn công . Thực hiện bằng cách thêm dòng chữ sau vào, phần thứ 2 trên “require”. Và khi build go sẽ get các package đó bằng url gốc.
replace demo=> github.com/dongnguyenltqb/demo
Phần thứ 3 đây là phân quan trọng nhất, chỉ định rõ những Package mà bạn dùng trong module, bao gồm phiên bản, chú thích // indirect chỉ ra rằng module của bạn không dùng trực tiếp Package này mà một trong số những package bạn đang sử dụng dùng package đó, chú thích +incompatible chỉ ra việc Go đã bỏ qua những quy định về quản lí phiên bản theo tiêu chuẩn Semver
Thông thường khi cài đặt một package bằng cách sử dụng “go get” thì mặc định go sẽ tải xuống phiên bản mới nhất của package, để tránh điều này bạn có thể chỉ định rõ version, thậm chí là cả commit và branch của package.
$ go get <path-to-repo>@<branch>
$ go get <path-to-repo>@<commit>
$ go get <path-to-repo>@<version>
Ngoài go.mod còn có thêm go.sum, file này giúp go xác định chính xác version bạn đang sử dụng bằng mã checksum với những version khác đã được cache qua các lần go get trước. Nếu có nhiều người cùng làm việc chung một project, khi họ clone code về nếu trong project có tồn tại file go.sum thì khi download các dependency package, sẽ có những cảnh báo được đưa ra nếu checksum của phiên bản khác với, checksum trong go.sum file, điều này gíup ta cẩn trọng hơn với những gì được đưa vào project.
Và Module trong go có thể là Private, điều này dễ đến go không thể checksum cho package đó, nhưng điều này hoàn toàn có thể bypass dễ bằng bằng cách bỏ qua việc checksum nó, Go cung cấp ba cách để thực hiện, một là khai bao danh sách Private repository hai là thêm responstory vào danh sách bỏ qua checksum hoặc tắt hẳn luôn việc checksum 😀
Để khai báo danh sách các Private repository, set lại giá trị của GOPRIVATE, GOPRIVATE là một biến môt trường của go, thay vì set bằng tay kiểu
go env -w KEY=VALUE
thì bạn có thể Edit thẳng và tự động edit mỗi lần khi mở Terminal bằng cách chỉnh sửa file ~/.bash_profile như hình dưới
sudo vi ~/.bash_profile
Cách hai là khai báo danh sách cách responstorykhông cần thực hiện checksum cũng tương tự cách trên chỉ khác tên biến môi trường là GONOSUMDB
export GONOSUMDB="gitlab.com/dongnguyenltqb"
Lưu ý bạn không cần chỉ định rõ hoàn toàn url của responstory, nếu set “gitlab.com/dongnguyenltqb” thì mặc đinhj nõ sẽ có hiệu lực “gitlab.com/dongnguyenltqb/go-demo” hay “gitlab.com/dongnguyenltqb/go-medo”.
Hoặc cách củ chuối hơn là tắt luôn Go Check Sum bằng cách set biến GOSUMDB = off
go env -w GOSUMDB=off
Và sau này, nếu chúng ta hoặc các package không dùng package phụ nào nữa thì ta có thể nhờ Go check và remove các package không cần thiết bằng lệnh.
go mod tidy
Tổng kết, với sự ra đời của Go Module, chúng ta sẽ ko cần phải đặt tất cả các project vào trong Go Path, ta có thể copy project ra nhiều nơi và có thể tự do edit code mà không ảnh hưởng đến project còn lại. Việc này giúp ta quản lí được linh động hơn.
Đến đây là hết rồi, cảm ơn các bạn đã đọc bài. 😀 Nếu có gì sai mong các bạn comment để mình xem lại và sửa chữa. Bye bye các bạn ^_^
Bài viết được sự cho phép của tác giả Tô Thị Vân Anh
Bài mở đầu khi học Selenium – không tính mấy bài lý thuyết thì chắc chắn bạn sẽ được biết đến dòng lệnh driver.close() hay driver.quit() để đóng trình duyệt sau khi đã làm xong một vài tác vụ tự động như đăng nhập vào một trang web nào đó hay chỉ đơn giản là sau khi mở được một số trang web nào đó với Selenium.
Thế bạn có tự hỏi là hai cái này khác nhau như thế nào chưa? Nó đều có mục đích là để đóng trình duyệt, dùng cái nào chả như nhau, vậy thì tại sao lại cần tách ra là close() và quit() để làm gì? Có bí ẩn gì đằng sau hai lệnh này hay không?
Bạn đã từng tra cứu Google để tìm ra câu trả lời chưa? :)) Nếu đã tra cứu rồi thế câu trả lời của họ đã làm bạn thỏa mãn chưa? :v Nếu chưa hi vọng bài này của mình sẽ giúp bạn thỏa mãn được chút nào đó! kaka
Câu trả lời cũng chẳng có gì cao siêu đâu, cơ bản là ghi chú lại cho nhớ, với cả nhỡ đâu vẫn có bạn nào đi tìm câu trả lời cho vấn đề này thì sao, biết đâu đấy lại tìm trúng bài này :v
close()
close() là một command của Webdriver để thực hiện đóng trình duyệt mà bạn đang trực tiếp sử dụng, hay đang tương tác lên nó. Có nghĩ là nếu như có nhiều hơn một trình duyệt đang được mở bởi Selenium, khi bạn sử dụng command close() này thì nó sẽ chỉ đóng cái trình duyệt mà tại thời điểm gọi command, bạn đang focus vào mà thôi, những trình duyệt còn lại khác thì sẽ không được đóng nhé!
quit()
Trong khi đó, bên cạnh command close(), có một Webdriver command khác là quit(), quit() sẽ thực hiện tắt toàn bộ Webdriver hiện thời. Có nghĩa là toàn bộ các trình duyệt ( số lượng các trình duyệt này có thể nhiều hơn 1) đang sử dụng được bật bởi Selenium sẽ được đóng lại ngay sau khi lệnh quit() được gọi.
Cả close() và quit() đều sẽ thực hiện công việc đóng trình duyệt giống nhau nếu như Selenium chỉ đang bật và sử dụng một trình duyệt duy nhất. Sự khác nhau sẽ thể hiện rõ ràng nếu như có hai trình duyệt được mở đồng thời trở lên bởi Selenium.
Tùy tình huống và yêu cầu sử dụng các bạn có thể lựa chọn command cho phù hợp nhé.
Các bạn có thể tham khảo thêm bản tiếng anh đầy đủ ở dưới đây:D
Các thiết bị di động hiện nay là một trong những thị trường lớn cho các phần mềm. Bài viết này đề cấp đến 4 thách thức chính của kiểm thử phần mềm trên các thiết bị di động: sự đa dạng của các thiết bị cũng như hệ điều hành di động; hiệu năng của các mạng di động; giao diện người dùng và sự giới hạn của các công cụ kiểm thử di động.
Những sự tiến bộ của các phần mềm hiện tại đã thực sự giải phóng khả năng tiềm tàng của các thiết bị di động. Theo ABI Research, thị trường ứng dụng di động đã tăng trưởng lên đến 27 tỉ đô la trong năm 2013 – dự kiến con số này sẽ tăng hơn nữa trong những năm tới. Một sự gia tăng nhanh chóng như thế chắc chắn sẽ tạo ra những vấn đề cho các lập trình viên, đặt họ dưới áp lực làm sao có thể sản xuất ra những phần mềm một cách nhanh chóng cho các thiết bị khác nhau.
Nhiều bộ phận như QA cũng trong tình cảnh tương tự – họ phải cố gắng kiểm thử các ứng dụng một cách đầy đủ trước khi sản phẩm được đưa ra thị trường. Bốn thách thức then chốt đặc biệt phân biệt quá trình/quy trình kiểm thử ứng dụng trên các thiết bị di động. Dev & QA phải học cách làm thế nào để vượt qua được những thách thức này để đảm bảo sự thành công của dự án.
Sự phân tán: ứng dụng di động chạy trên nhiều loại thiết bị, phiên bản hệ điều hành, nhà sản xuất và giao diện người sử dụng khác nhau.
Mạng đi động: hiệu năng của các mạng đi động là khác nhau và nó ảnh hưởng đến trải nghiệm người dùng 1 cách mạnh mẽ.
Tính tiện dụng: một thiết kế giao diện người dùng thông minh là cần thiết trong việc tạo ra các ứng dụng để mọi người có thể sử dụng một cách trực quan hơn.
Công cụ: các công cụ kiểm thử trên thiết bị di động rất hạn chế so với công cụ kiểm thử trên các ứng dụng truyền thống.
Phát triển một chiến lược kiểm thử phù hợp & thực tế.
Để vượt qua những thách thức này, cần phải có một chiến lược kiểm thử tối ưu hóa mức độ bao phủ (test coverage) – kết hợp giữa các thiết bị thật, trình giả lập, các thiết bị có thể truy cập từ xa (remote-access devices) thông qua điện toán đám mây (cloud). Đồng thời cần trả lời cho 2 câu hỏi sau:
Sự khác biệt về địa điểm và sự biến động trong kết nối ảnh hưởng đến ứng dụng như thế nào?
Ứng dụng xử lý sự gián đoạn như các cuộc gọi tới, tin nhắn và các thông báo từ các mạng xã hội như thế nào?
Chiến lược kiểm thử nên bao gồm 4 mảng chính: chức năng, hiệu xuất, bảo mật và tính tiện dụng. Tự động hóa các quá trình đóng vai trò là nhân tố chính trong việc quản lý dự án tốt hơn. Biết rõ nên tập trung nhân lực của dự án vào đâu cũng là một điều kiện tiên quyết trong việc tận dụng thế mạnh của đội ngũ nhân viên.
Các bạn đều biết rằng kiểm thử tất cả các trường hợp là không thể, do đó chúng ta cần xem xét sản phẩm và mục đích sử dụng của nó, cũng như những thiết bị mục tiêu quan trọng.
Thêm vào đó, cần chú ý đến sự khác biệt về kích thước màn hình, các thiết bị cũng như các phiên bản hệ điều hành phổ biến.
Linh động trong việc xử lý với các yêu cầu mới và sự thay đổi yêu cầu.
Thật là phi thực tế khi bạn nghĩ rằng mình có thể tạo ra một kế hoạch kiểm thử hoàn thiện và mong đợi sử dụng nó cho các thiệt bị thật cho đến khi ứng dụng được phân phối trên thị trường. Bởi vì các yêu cầu mới hoặc bổ sung được thêm vào, bạn cần lên kế hoạch trong từng giai đoạn. Bắt đầu bằng việc sử dụng trình giả lập để tìm lỗi và những vấn đề về chức năng. Sau đó bạn có thể kiểm thử trên các thiết bị thật và các thiết bị di động truy cập từ xa (remote-access devices) khi kiểm thử với điều kiện thức tế của người dùng cuối, cũng như khi xem xét ảnh hưởng của bảo mật và mạng di động.
Tính hợp lệ của các yêu cầu cũng như chất lượng của sản phẩm chủ yếu được xác định dựa trên kiểm thử chức năng và kiếm thử tính tiện dụng – tuy nhiên hãy nhớ rằng những tính năng mới có thể được thêm vào trong quá trình sản phẩm đang được phát triển.
Khi bạn đóng vai trò là người dùng cuối, sẽ là tốt nhất nếu bạn có thể kiểm tra các trường hợp sử dụng trong môi trường không hoàn hảo. Kiểm tra hiệu suất của ứng dụng dưới tác động của các nhân tố mà người dùng có thể gặp phải:
Tín hiệu mạng yếu, mạng 3G và 4G, các tốc độ đường truyền wifi khác nhau.
Rớt mạng khi chuyển từ 3G sang wifi và ngược lại
Các ràng buộc được tao ra bởi chipsets cụ thể
Ảnh hưởng không mong muốn lên bộ nhớ tạm
Pin yếu
Những tính năng khác của các thiết bị di động
Ngoài ra, chúng ta cũng nên nghĩ về việc sử dụng tài nguyên ở mức độ thấp, các vấn đề của bộ đệm, dữ liệu rác. Cân nhắc an ninh bao gồm mã hóa dữ liệu và nhiều người sử dụng xử lý hỗ trợ.
Hy vọng bài viết này cung cấp cho bạn một số điều cần xem xét trong việc thiết lập một kế hoạch kiểm thử di động cho công ty của bạn.
FirewallD là giải pháp tường lửa mạnh mẽ tương tự Firewall CSF, được cài đặt mặc định trên RHEL 7 và CentOS 7, nhằm thay thế Iptables với những khác biệt cơ bản:
FirewallD sử dụng “zones” và “services” thay vì “chain” và “rules” trong Iptables.
FirewallD quản lý các quy tắc được thiết lập tự động, có tác dụng ngay lập tức mà không làm mất đi các kết nối và session hiện có.
Trước khi thực sự dùng đến FirewallD cần hiểu khái niệm về Zone và thời gian hiệu lực của quy tắc.
1.1. Zone
Trong FirewallD, zone là một nhóm các quy tắc nhằm chỉ ra những luồng dữ liệu được cho phép, dựa trên mức độ tin tưởng của điểm xuất phát luồng dữ liệu đó trong hệ thống mạng.
Các zone được xác định trước theo mức độ tin cậy, theo thứ tự từ “ít-tin-cậy-nhất” đến “đáng-tin-cậy-nhất”:
drop: ít tin cậy nhất – toàn bộ các kết nối đến sẽ bị từ chối mà không phản hồi, chỉ cho phép duy nhất kết nối đi ra.
block: tương tự như drop nhưng các kết nối đến bị từ chối và phản hồi bằng tin nhắn từ icmp-host-prohibited (hoặc icmp6-adm-prohibited).
public: đại diện cho mạng công cộng, không đáng tin cậy. Các máy tính/services khác không được tin tưởng trong hệ thống nhưng vẫn cho phép các kết nối đến trên cơ sở chọn từng trường hợp cụ thể.
external: hệ thống mạng bên ngoài trong trường hợp bạn sử dụng tường lửa làm gateway, được cấu hình giả lập NAT để giữ bảo mật mạng nội bộ mà vẫn có thể truy cập.
internal: đối lập với external zone, sử dụng cho phần nội bộ của gateway. Các máy tính/services thuộc zone này thì khá đáng tin cậy.
dmz: sử dụng cho các máy tính/service trong khu vực DMZ(Demilitarized) – cách ly không cho phép truy cập vào phần còn lại của hệ thống mạng, chỉ cho phép một số kết nối đến nhất định.
work: sử dụng trong công việc, tin tưởng hầu hết các máy tính và một vài services được cho phép hoạt động.
home: môi trường gia đình – tin tưởng hầu hết các máy tính khác và thêm một vài services được cho phép hoạt động.
trusted: đáng tin cậy nhất – tin tưởng toàn bộ thiết bị trong hệ thống.
1.2. Quy tắc Runtime/Permanent
Trong FirewallD, các quy tắc được cấu hình thời gian hiệu lực Runtime hoặc Permanent.
Runtime(mặc định): có tác dụng ngay lập tức, mất hiệu lực khi reboot hệ thống.
Permanent: không áp dụng cho hệ thống đang chạy, cần reload mới có hiệu lực, tác dụng vĩnh viễn cả khi reboot hệ thống.
Ví dụ, thêm quy tắc cho cả thiết lập Runtime và Permanent:
Việc Restart/Reload sẽ hủy bộ các thiết lập Runtime đồng thời áp dụng thiết lập Permanent mà không hề phá vỡ các kết nối và session hiện tại. Điều này giúp kiểm tra hoạt động của các quy tắc trên tường lửa và dễ dàng khởi động lại nếu có vấn đề xảy ra.
Lưu ý: Các ví dụ thiết lập trong bài sử dụng cả Runtime và Permanent.
2. Cài đặt FirewallD
– FirewallD được cài đặt mặc định trên CentOS 7. Cài đặt nếu chưa có:
# yum install firewalld
– Khởi động FirewallD:
# systemctl start firewalld
– Kiểm tra tình trạng hoạt động
# systemctl status firewalld
– Thiết lập FirewallD khởi động cùng hệ thống
# systemctl enable firewalld
Kiểm tra lại :
# systemctl is-enabled firewalld
Ban đầu, bạn không nên cho phép FirewallD khởi động cùng hệ thống cũng như thiết lập Permanent, tránh bị khóa khỏi hệ thống nếu thiết lập sai. Chỉ thiết lập như vậy khi bạn đã hoàn thành các quy tắc tường lửa cũng như test cẩn thận.
– Khởi động lại
– Kiểm tra zone active (được sử dụng bởi giao diện mạng)
Vì FirewallD chưa được thiết lập bất kỳ quy tắc nào nên zone mặc định cũng đồng thời là zone duy nhất được kích hoạt, điều khiển mọi luồng dữ liệu.
# firewall-cmd --get-active-zones
– Thay đổi zone mặc định, ví dụ thành home:
# firewall-cmd --set-default-zone=home
3.2. Các lệnh liệt kê
Liệt kê toàn bộ các quy tắc của các zones:
# firewall-cmd --list-all-zones
Liệt kê toàn bộ các quy tắc trong zone mặc định và zone active
# firewall-cmd --list-all
Liệt kê toàn bộ các quy tắc trong một zone cụ thể, ví dụ home
# firewall-cmd --zone=home --list-all
Liệt kê danh sách services/port được cho phép trong zone cụ thể:
# firewall-cmd --zone=public --list-services
# firewall-cmd --zone=public --list-ports
3.3 Thiết lập cho Service
Đây chính là điểm khác biệt của FirewallD so với Iptables – quản lý thông qua các services. Việc thiết lập tường lửa đã trở nên dễ dàng hơn bao giờ hết – chỉ việc thêm các services vào zone đang sử dụng.
Đầu tiên, xác định các services trên hệ thống:
# firewall-cmd --get-services
Lưu ý: Biết thêm thông tin về service qua thông tin lưu tại /usr/lib/firewalld/services/.
Hệ thống thông thường cần cho phép các services sau: ssh(22/TCP), http(80/TCP), https(443/TCP), smtp(25/TCP), smtps(465/TCP) và smtp-submission(587/TCP)
– Thiết lập cho phép services trên FirewallD, sử dụng –add-service:
Việc sử dụng tường lửa FirewallD trên CentOS 7 không khó khi đã biết các lệnh trên trong nhu cầu sử dụng thông thường. Ngoài tường lửa FirewallD còn có tường lửa CSF khá phổ biến.
Loader dùng để pre-processing, plugin phức tạp hơn và nó can thiệp nhiều vào quá trình compile.
🐸 Làm sao để tách một số data ra khỏi bundle thành một file riêng biệt, ví dụ như file css
Sử dụng ExtractTextWebpackPlugin. Tất cả css sẽ không còn nằm inline trong file JS bundle, nó sẽ là một file riêng (style.css chẳng hạn)
🐸 Hot module replacement là gì?
Tính năng cho phép cập nhập module mà không cần reload
🐸 parallel-webpack là gì và nó ảnh hưởng thế nào đến quá trình build
parallel-webpack sẽ giúp config với nhiều entry point, cho phép webpack build parallel, nâng cao tốc độ build
🐸 Mô tả một cách ngắn gọn long-term caching và làm sao sử dụng nó trong webpack?
Browser sẽ cache static file bên dưới local để cải thiện tốc độ load, để đảm bảo nếu có bản build mới, trình duyệt biết và download file mới, tên file thường được đặt như sau
app.js?build=1
app.js?build=2
// hoặc
app.js.2a6c1fee4b5b0d2c9285.js
app.js.70b594fe8b07bcedaa98.js
Để làm việc này, trong webpack chúng ta đặt config
[hash] tạo ra một id ngẫu nhiên cho từng lần build và sử dụng cho tất cả chunk. Nếu thay [hash] bằng [chunkhash] nó sẽ tạo ra mỗi chunk một id ngẫu nhiên.
🐸 Mô tả CommonsChunk Plugin?
Là một tính năng có sẵn của webpack, cho phép tạo file riêng (gọi là chunk) cho những module dùng chung. Hỗ trợ caching và nâng cao tốc độ load
Hệ thống quản lý chất lượng dữ liệu: Tại sao và như thế nào?
Một ngày của Data team ở Amanotes bắt đầu bằng việc xử lý rất nhiều tin nhắn được gửi cho data team, ví dụ như sự chênh lệch của chỉ số, tại sao trendline có vẻ thay đổi,… Những câu hỏi về các vấn đề liên quan đến data nhân lên rất nhiều lần cho các metrics trên rất nhiều dashboard của công ty.
Điều này khiến data team suy nghĩ đến việc nên làm sao để mọi người không phàn nàn về những vấn đề liên quan đến data nữa. Và nhờ vậy chúng tôi quyết định build một hệ thống quản lý chất lượng data. Đó cũng là lý giải cho việc tại Amanotes quyết định build hệ thống này và team đã build nó như thế nào?
Nhiều quyết định quan trọng được đưa ra dựa vào data
Tại sao việc build hệ thống này lại quan trọng với data quality cũng như data team của một công ty?
Mỗi ngày, business stakeholders sẽ có những quyết định quan trọng và tất cả những quyết định đó đều dựa trên data. Và điều quan trọng nhất là mọi người phải tin vào data mà họ nhìn thấy, chỉ có như vậy mới tối ưu hóa được lợi ích mà data mang lại cho user cũng như giúp cho business stakeholders tốn ít thời gian hơn trong việc double check data, complain data và tự tin hơn trong quyết định của họ.
Về sự phân cấp giá trị mà data đem lại, bắt đầu từ data bằng việc processing và khai thác những thông tin quan trọng từ nó chúng ta mới bắt đầu có information. Dựa vào information, stakeholders sẽ có knowledge, từ đó build up thành wisdom – sự thông thái và hiểu biết về những gì đang diễn ra trong business của mình. Vậy nên data chính là nền tảng của tất cả những hiểu biết, những thế mạnh của một doanh nghiệp. Và data quality chính là bước đầu tiên để kiểm soát nguồn thông tin, dữ liệu và sự hiểu biết trong doanh nghiệp.
Vậy data team đã copy lại cách user complain về data như thế nào?
User complain flow
User complain flow – những gì thực chất diễn ra bằng con người và Data Quality Control System.
Cũng giống như data team hằng ngày bắt đầu làm việc bằng việc check dashboard, sẽ có 2 cách để check xem data ngày hôm nay có bất thường hay không hoặc có bug gì xảy ra với data hay không.
Có thể check bằng mắt, xem trendline của ngày hôm đó so với các ngày trước có thay đổi hay không, có quá cao hay quá thấp hay không. Nếu như nhìn ở góc độ data quality control system thì đó chính là thuật toán Anomaly Detection. Sau khi đã xem qua các metrics rồi thì bản thân các business stakeholders sẽ có những kiến thức về mặt business để xét xem những con số này có chính xác hay không. Nếu có 2 metrics liên quan đến nhau trên cùng một dashboard thì liệu 2 metrics này có đi cùng một trend hay không… Điều này tương tự với những Rule-based Auto-Tests được đưa vào trong Data Quality Control System.
Và dĩ nhiên là cả Anomaly Detection Algorithm và Rule-based Auto-Tests đều apply trên cùng một data source mà chính những data source đó được sử dụng để visualize lên những dashboard đang có. Dựa vào thông tin của Eye-check và Business Intuition thì bản thân các business stakeholders sẽ quyết định xem những bất thường này có nghiêm trọng hay không. Nếu nó thật sự nghiêm trọng và ảnh hưởng đến quá trình ra quyết định thì họ sẽ liên lạc với data team.
Data team dựa vào các câu hỏi của stakeholders sẽ đào ngược lại vào trong data source, test, investigate, explore lại xem lỗi này xảy ra như thế nào. Để mimic (mô phỏng/bắt chước) lại quá trình đó thì trong Data Quality Control System sẽ có thêm Data Quality Scoring. Data Quality Scoring là hệ thống check tất cả những input từ Run-based Auto-Tests và các thuật toán để detect anomal, scoring nó để đánh giá data quality của ngày hôm nay có tốt hơn ngày hôm qua hay không. Đưa ra một con số để tất cả user nhìn vào con số của ngày hôm nay biết được tình trạng data quality của toàn bộ pipeline đó như thế nào.
Song song với Data Quality Scoring thì có thêm Severity Rating là tất cả các text và out layer sẽ trả về một list kết quả test là fail hay pass. Mình sẽ có những logic khác nhau dựa trên các chuẩn mực riêng biệt để đánh giá xem lỗi fail test có nghiêm trọng hay không. Nếu nghiêm trọng mình sẽ đưa vào Alerting System và data team sẽ giải quyết vấn đề này trước khi một stakeholders nào check nó trên dashboard.
Tại sao lại cần có Severity Rating để đánh giá data quality?
Có thể hiểu là ở bước Rule-based Auto-Tests và Anomaly Detection nó sẽ trả về rất nhiều loại fail hay pass test. Thậm chí lượng fail test có thể chiếm 10 – 15% của tất cả những test mà mình từng viết nếu như ngày hôm đó không được may mắn cho lắm. Nếu coi tất cả những test đó như nhau và cho nó vào Alerting System thì một ngày data team sẽ nhận được rất nhiều alert!
Và đương nhiên là, nếu liên tục nhận được những signal, những alert không thật sự nghiêm trọng thì dần dần đối tượng của Alerting System sẽ không tin vào lỗi được báo nữa nên mục đích của Severity Rating ở đây là source lists và filter data. Chỉ những tests nào fail thật sự nghiêm trọng và trigger khiến data team phải can thiệp lại việc fail test đó thì mới đưa vào alerting system. Đó là một bước để tối ưu hóa hiệu quả của hệ thống và giúp data team hoạt động hiệu quả hơn trong việc build các bugs và kiểm soát được chất lượng của hệ thống dữ liệu.
Framework bên dưới để quá trình này diễn ra hoạt động như thế nào?
Analytics Engineering Flow mà hiện tại Amanotes sử dụng có 3 loại technology. Đầu tiên là Google BigQuery như Data Warehouse, đây cũng là technology rất phổ biến dạo gần đây. Thứ hai là Airflow được sử dụng Airflow như công cụ để điều phối các tasks liên quan đến data cũng là một công cụ rất nổi tiếng. Công cụ tiếp theo mới được sử dụng gần đây là dbt. Đây là một công cụ mới cho phép các data engineers và các bạn analytic engineers có thể apply một template cho auto develop và auto test framework với các best practices trong software engineering trên Sql để apply cho BigQuery.
Framework hỗ trợ đắc lực cho quá trình làm xử lý data
Framework sẽ hoạt động từ Data loader đưa vào trong Raw data. Từ Raw data sẽ đi qua các bước Snapshot, Transform, Test, Deploy và Document. Ngôn ngữ chính đang sử dụng ở đây là BigQuery Sql và dbt. Bình thường khi nhắc đến Sql mọi người sẽ không đánh giá cao nó như một ngôn ngữ mang các best practices của Software Engineering và thiếu đi rất nhiều công cụ để test code đã được viết hoặc để deploy hay document nó.
Nhưng dbt xuất hiện trong framework cho phép thực hiện tất cả những điều này với Sql bao gồm cả version control và test. Đồng thời trong dbt nó cũng automate toàn bộ documentation liên quan đến pipeline gồm các components và các metrics được tạo ra như thế nào. Cùng với version control, Amanotes cũng đang build Alerting và Logging. Alerting và Logging là sự kết hợp của rất nhiều công cụ đang sử dụng trong stack này bao gồm logging từ Airflow và dbt. Amanotes cũng có 1 product inhouse để combine nó lại và đưa vào trong Alerting System. Sau khi raw data đã đi qua tất cả các bước transforming này thì sẽ được show lên BI tool cùng với Metabase.
3 components chính trong hệ thống quản lý chất lượng data
3 components này gồm Rule-based Auto-Tests, Anomaly Detection và Data Quality Scoring. Alerting là output cuối cùng nhận tất cả các kết quả ở 3 hệ thống vừa được đề cập.
1. Rule-based Automated Tests
Mục đích của testing là để validate lại những assumptions của data team nên test được thiết kế tốt là test có thể bắt được những assumption sai về data mà mình đang có. Assumption cụ thể ở đây là khi viết Query, ta assume là kết quả trả ra sẽ như vậy và nếu bộ data đủ phức tạp thì một developer sẽ không thể bao quát hết tất cả những corner case liên quan đến nó. Do đó việc apply test là để check lại kết quả của các query dựa trên một số assumption mà dev biết.
Nếu là fail assumption thì đây sẽ là trigger để cho biết data đang có vấn đề gì và assumption cho thấy data đang không chính xác. Ở đây mình chia tất cả các test thành rất nhiều components khác nhau: comment issues mà data users hay đưa lên cho data team, team biến nó trở thành những automatic tests. Tất cả những issues này sẽ thuộc về những nhóm khác nhau. Ví dụ như revenue đưa xuống ở country level quá lớn thì nó thuộc group Source of Truth vì bên cạnh những dashboard internal mình cũng có những dashboard partners external.
Một trong những cách đơn giản nhất để viết automatic test này là compare cùng một thông tin từ 2 nguồn data khác nhau để đối chứng với nhau. Có những thông tin liên quan đến data không fresh ví dụ như việc đếm số new users data trong một ngày, như hôm nay là ngày 10 nhưng trong data không có ngày 10 thì lúc này team sẽ biết là data đang không đúng và có vấn đề trong data pipeline của mình.
Tiếp theo là có thể theo dõi inconsistent data hoặc historical trend bằng việc xem LTV trendline của nó qua mỗi ngày có consistent hay không, hay đột nhiên có vấn đề lệch ra khỏi quỹ đạo thông thường. Tất cả các tasks này sẽ được viết bằng Sql để kết quả trả ra là yes hay no và dbt chính là sản phẩm cho phép chúng ta làm được chuyện đó bằng Sql trong BigQuery trong framework. Khi team sử dụng version control để kiểm soát toàn bộ những code mà bọn mình từng viết trong data pipeline này, nếu đã full request thì dbt sẽ tự động chạy. Hoạt động này cũng giống như dbt tự động chạy mỗi ngày trong pipeline để check lại tất cả các bảng data cũng như các metrics quan trọng. Để xem đi qua hết list object này, trải rộng suốt một pipeline thì tất cả các task của mình có pass hay không. Nếu tất cả các test đều pass hết thì sẽ có một report được gửi về cho data team và đảm bảo ngày hôm nay không có vấn đề gì xảy ra.
Data Profiling cũng mô phỏng lại một hành vi của user. Cách thức để tìm ra một vấn đề xảy ra trong chart đó là nhìn vào những điểm data bất thường dựa vào những điểm data xung quanh nó. Đây cũng là điểm cốt lõi của Data Profiling và Outlier Detection. Có những quan sát sẽ đi chệch ra nhiều hơn so với những quan sát khác đứng phía trước và sau nó, thường sẽ là đằng sau vì phía trước là dữ liệu trong tương lai mình không thể quan sát được. Và những thứ đi chệch ra này sẽ khiến users hoặc người làm data đưa ra những nghi vấn rằng mọi thứ có đang diễn ra bình thường hay không hay đang có vấn đề bất thường.
Với Anomaly Detection, cần phân biệt được data discrepancy, sự khác biệt của metrics so với một điểm data nào đó. Ở đây mình so với 3 tiêu chí khác nhau:
Một là một điểm data với Business Normal Range, tức là khoảng bình thường theo rule của business. Tiêu chí thứ 2 là so với giá trị trung bình của 7 ngày trước đó. Thứ 3 là so với giá trị trung bình của 4 ngày cùng thứ của 4 tuần trước đó. Tiêu chí thứ 3 này là tiêu chí cần phải có vì ví dụ như với Amanotes là một công ty về mobile app thì vào cuối tuần, behaviours và lượng thông tin sẽ rất khác so với các ngày trong tuần nên thông tin sẽ không công bằng và không capture được outlier thực tế của nó. Trong đó Outliers có 2 dạng: thứ nhất là có lỗi xảy ra và thứ hai là không có lỗi nào cả, chỉ đơn giản là bản chất của data mà thôi.
Ngoài ra, còn có các solution khác nhau để identify một outlier dựa vào 3 tiêu chí của data discrepancy. Đầu tiên là dựa vào statistics distribution based ví dụ như so sánh stability index của distribution. Thứ 2 là distance based, thứ 3 là density based và thứ 4 là deviation based. Đây là 4 phương pháp kết hợp và tạo ra outlier. Hiện tại data team mình sử dụng là high bridge của nhiều solution khác nhau và combine output từ những thứ khác nhau như vậy để đi đến quyết định cuối cùng là một data bond có phải là outlier hay không.
3. Data Quality Scoring
2 components trên sau khi hoạt động sẽ trả ra kết quả là pass or fail, bản thân Abnormal Detection cũng sẽ output ra kết quả pass or fail. Ví dụ như một data bond được nhận diện là outlier thì sẽ trả về kết quả là fail và mình coi outlier detection đó cũng là test như Rule based Tests nhưng Abnormal Detection là một database, machine learning base test được apply lên data. Một chuỗi kết quả fail and pass này sẽ được đưa vào Data Quality Scoring. Mục đích của nó là tạo được một metrics, score về data quality của pipeline trên tất cả những metrics trong dashboard ngày hôm đó.
Scoring giúp đánh giá chính xác chất lượng dữ liệu
3.1. Data Quality
Data Quality là một metrics để measure rất nhiều criteria khác nhau.
Đầu tiên là tính chính xác của data. Tính chính xác này đến từ rule based, automatic tests hoặc so sánh nó với source of truth hoặc outlier thì sẽ compare với historical data.
Thứ 2 là tính toàn vẹn của data. Data có thể hiện hết những value mà mình đang quan tâm hay không. Có những metrics rất quan trọng nhưng 70 – 80% của nó là missing value.
Thứ 3 là relevance. Ở đây sẽ có những điểm data, vậy liệu những điểm data liên quan tới nhau có đang thể hiện một mối tương quan giống trong quá khứ hay không.
Thứ 4 là timeliness. Nó thể hiện được data có fresh hay không, có đến vào đúng thời điểm mà mình cần hay không. Vì thật ra tất cả các data source không đến cùng một thời điểm, có rất nhiều nguồn data được control internally thì timeliness và độ trẻ của nó sẽ ít hơn nhưng cũng có nhiều data mình kéo bằng API, từ nhiều nguồn ở ngoài sẽ có độ trẻ lâu hơn. Thường timeliness sẽ compare data availability với hiểu biết mà mình đã có về độ trẻ của data.
Thứ 5 là clarity, nghĩa là tất cả những data, những metrics có thỏa mãn về mặt syntax và grammar rules hay không. Thật ra mảng này hiện không được cover trong Data Quality Scoring hiện tại của mình.
Thuộc tính cuối cùng là Accessibility – data có thân thiện, hiệu quả và access được với tất cả mọi người hay không.
Ở đây sẽ có những metrics quan trọng hơn các metrics khác như completeness, relevant và timeliness là những tiêu chí rất dễ hình dung để đưa ngay vào trong data quality control system của mình. Accuracy ngược lại hơi mang tính chủ quan hơn vì thực chất có rất nhiều bộ data đang có chỉ mang tính tương đối và cũng không biết được đâu là source of truth để compare data mình đang có với nó. Clarity và Accessibility cũng mang tính chất khách quan nhiều hơn và hiện nay với version hiện tại của Data Quality Control System ở Amanotes không cover 2 metrics này.
3.2. Cách để measure data quality
Đầu tiên là Accuracy – tất cả những rule based auto tests bị fail. Thứ 2 là abnormal detection. Thứ 3 là tính toàn vẹn của data, tức NULL rate trong dữ liệu của mình. Cuối cùng là usability mà cụ thể là Zero rate của một metrics nào đó.
Vậy sự khác nhau giữa NULL rate và Zero rate là gì?
Zero rate không mixing, data này thật sự có giá trị là 0 nhưng nó ảnh hưởng đến usability vì nếu một metrics có đến 70 – 80% nhận cùng giá trị 0 thì đó không phải là một metrics có ý nghĩa và không add được nhiều value cho business của mình. 4 criteria này sẽ được đưa vào một Ranking/Weighting Algorithm.
Weighting Algorithm đến từ việc mình đang có nhiều criteria khác nhau và mỗi criteria này có references khác nhau mà mình collect input này từ phía stakeholders. Ví dụ như trong số những criteria này thì Accuracy là criteria quan trọng nhất và Usability là criteria ít quan trọng nhất. Nó được chấm dựa trên thang điểm từ 1 đến 5. Weighting Algorithm sẽ kết hợp tất cả những criteria đã được weighting và cho ra một kết quả có ý nghĩa, làm sao để tiêu chí được đánh giá, được cho điểm cao nhất và nó không dominate score cuối cùng của mình cũng như làm sao để tiêu chí được cho điểm thấp nhất vẫn có tầm quan trọng nhất định.
Framework chính để Anomates thiết kế Algorithm là dựa trên decision making framework trong management science và sử dụng ranking trên một decision. Sau khi đưa input từ accuracy, abnormal detection, completeness và usability vào Ranking/Weighting Algorithm thì kết quả trả về là score có giá trị từ 0 đến 1. Đề xuất cho data user là nếu bạn đang cân nhắc sử dụng một nguồn data nào đó mà đang có nhiều lựa chọn, nhiều data sources thì hãy lựa chọn data sources có data quality scoring cao hơn.
Data quality control system sẽ trả ra hàng loạt test và những test này sẽ được đánh giá về mức độ usability dựa trên nhiều yếu tố. Đầu tiên là metrics này có quan trọng hay không và độ lệch của nó có nghiêm trọng hay không. Nhìn vào dashboard, data team sẽ biết nên ưu tiên sửa vấn đề nào trước và nên làm gì với những vấn đề đó.
Cuối cùng là phải tối ưu hóa data quality alerting system. Mục đích của việc này là để giảm đi lượng false positive và có thể tăng productivity của data team lên rất cao, giảm các công việc liên quan đến việc tìm bug, thông báo và communicate với end-user.
Vậy việc tối ưu sẽ diễn ra như thế nào?
Hiện nay interface để entrust với data alerting system mà data team đang sử dụng là thông qua notification của Slack và những thông số trên Metabase giống như rất nhiều dashboard trước đó. Có rất nhiều states khác nhau có thể apply để tối ưu, thứ nhất là smart grouping, kết hợp những alert có liên quan tới nhau và những alert lặp đi lặp lại. Thứ 2 là exception list, có những test lặp đi lặp lại và đây là lỗi mà team không thể sửa được hoặc lỗi này nằm bên ngoài system nhưng không ảnh hưởng quá lớn đến data pipeline và quyết định của mình thì cũng có thể đưa vào exception list.
Theo dõi các vấn đề có thể xảy ra với data giúp kiểm soát chất lượng data tốt hơn
Thứ 3 là automatic synchronization giữa các platforms để đảm bảo tất cả mọi thứ hoạt động trơn tru và không bị spam quá nhiều cho các thành viên của datateam. Bên cạnh đó thì việc optimize anomaly detection, data quality scoring và severity levels cũng giúp optimize data alerting system.
Nhưng sự thật thì sẽ không thể nào dự đoán được chuyện gì sẽ xảy ra với data, luôn có rất nhiều corner cases trong khi data là những gì đã xảy ra trong quá khứ. Chúng ta sẽ không bao giờ đoán trước được việc data ngày mai sẽ diễn ra như thế nào, nó có thay đổi hay không và bug nào sẽ xảy ra tiếp theo. Do đó quá trình build data quality control system sẽ là một nỗ lực liên tục, teamwork cùng nhau, làm việc cùng các stakeholders để nâng cao chất lượng của data và có thể đưa data vào ứng dụng hơn nữa nhằm tạo ra benefit cho business của mình.
Bài viết được trích dẫn từ phần trình bày của chị Đặng Huỳnh Mai Anh tại sự kiện Vietnam Web Summit 2020 LIVE do TopDev tổ chức
Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
CHECKED VÀ UNCHECKED EXCEPTION TRONG JAVA
CƠ BẢN
Trong Java có 2 loại exception: checked và unchecked. Tất cả các checked exception được kế thừa từ lớp Exception ngoại trừ lớp RuntimeException. RuntimeException là lớp cơ sở của tất cả các lớp unchecked exception. Đó cũng là dấu hiệu để nhận biết đâu là checked exception và đâu là unchecked exception. Cùng xem qua hierarchy của tất cả các lớp exception:
KHÁC NHAU GIỮA CHECKED VÀ UNCHECKED EXCEPTION
Điểm khác biệt giữa các lớp checked và unchecked expcetion chính là thời điểm xác định được expcetion có thể xảy ra. Đối với checked exception, việc kiểm tra được thực hiện ngay thời điểm compile time, một số IDE sẽ giúp chúng ta bằng cách hiển thị lỗi cú pháp nếu ta gọi một method throw ra bất kỳ checked exception nào mà không được catch. Một số checked exception tiêu biểu như: IOException, InterruptedException, XMLParseException.. Còn đối với unchecked exception, việc xác định có exception xảy ra hay không chỉ có thể thực hiện ở thời điểm runtime, và các IDE sẽ không giúp chúng ta xác định được chuyện đó. Một số unchecked exception tiêu biểu là: NullPointerException, IndexOutOfBoundsException, ClassCastException… Hãy xem các ví dụ để hiểu rõ hơn.
Ở đoạn trên, nếu ta remove phần try-catch thì IDE sẽ báo lỗi:
Unhandled exception type FileNotFoundException đối với method: FileReader(…)
Unhandled exception type IOException đối với method: readLine()
Bây giờ hãy viết riêng một method để test
public class MainCheckedAndUncheckedException {
public static void main(String[] args) {
try {
doParseXML();
} catch (XMLParseException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
private static void doParseXML() throws XMLParseException, IOException {
doOpenXML();
// Do parse XML. This method may be thrown a checked exception
}
private static void doOpenXML() throws IOException {
// Do open XML. This method may be thrown a checked exception
}
}
Method doOpenXML được dánh dấu là sẽ throw ra IOException, do vậy, bất cứ method nào gọi doOpenXML đều phải catch nó hoặc đánh dấu là sẽ throw ra exception của method nó gọi. Trong trường hợp này doParseXML gọi doOpenXML và quyết định throw ra IOException của doOpenXML. Đồng thời nó cũng throw thêm 1 exception là XMLParseException. Và method main gọi doParseXML chọn cách catch các exception của doParseXML có thể throw.
Ứng tuyển các vị trí việc làm Java lương cao trên TopDev
UNCHECKED EXCEPTION:
public class MainCheckedAndUncheckedException {
public static void main(String[] args) {
printArray();
}
private static void printArray() {
int[] array = new int[1];
System.out.println(array[1]);
}
}
Với đoạn code trên sẽ có 1 exception được throw ra mà không hề báo trước:
Exception in thread “main” java.lang.ArrayIndexOutOfBoundsException: 1
at com.edward.tutorial.corejava.exception.MainCheckedAndUncheckedException.printArray(MainCheckedAndUncheckedException.java:12)
at com.edward.tutorial.corejava.exception.MainCheckedAndUncheckedException.main(MainCheckedAndUncheckedException.java:7)
Dù cho ta có đánh dấu method printArray sẽ throw ra ArrayIndexOutOfBoundsException thì IDE vẫn không báo lỗi khi hàm main gọi đến hàm printArray bởi vì ArrayIndexOutOfBoundsException là 1 unchecked exception
public class MainCheckedAndUncheckedException {
public static void main(String[] args) {
printArray();
}
private static void printArray() throws ArrayIndexOutOfBoundsException {
int[] array = new int[1];
System.out.println(array[1]);
}
}
CHECKED VÀ UNCHECKED EXCEPTION USE CASES
Vậy một câu hỏi đặt ra khi design API là khi nào một method sẽ throw checked exception, và khi nào sẽ throw unchecked exception.
Throw unchecked exception trong trường hợp chương trình bị sai về logic, không thể làm gì tiếp theo nếu gặp những lỗi đó, ví dụ như có 1 biến null hoặc không hợp lệ khiến toàn bộ đoạn chương trình phía sau không thể làm tiếp, ta sẽ throw NullPointerException hoặc IllegalArgumentException. Còn trong trường hợp những lỗi vẫn còn có thể handle được thì throw checked exception. Ví dụ như method open file có thể throw FileNotFoundException nhằm mục đích cảnh báo khi client gọi đến method này, cần phải handle trường hợp không tìm thấy file lúc đọc file. Đó không phải là lỗi logic chương trình mà là 1 ngoại lệ khác với kết quả mong muốn từ việc đọc file.
Nói về chủ đề này thì đã có quá nhiều bài viết trên mạng, thế nhưng mục đích mình bài này là để cho những đứa em của mình cũng đang theo con đường lập trình có một nơi để tham khảo. Rất hy vọng được các bạn góp ý để kiến thức mình chia sẽ được tốt hơn.
Thật ra thì với các bạn sinh viên mới ra trường đi làm (con đang là Internship hay Fresher) thì câu hỏi này là top những câu hỏi gặp phải khi phỏng vấn đó nha.
Bên cạnh đó, hiểu rõ sự khác nhau giữa Interface và Abstract Class sẽ giúp chúng ta có thể thiết kế được các ứng dụng mà nó có các kết nối lỏng lẽo (loosely coupled) và dễ dàng mở rộng. Vấn đề này bạn sẽ hiểu rõ hơn trong bài viết nói về Dependency Injection Principle. Một điều quan trọng là bạn không thể chọn dùng Interface hay Abstract Class nếu chỉ biết chúng khác nhau thế nào.
Interface trong C#
Có thể hiểu đơn giản Interface là một bản thiết kế cho bất kì class muốn thực hiện nó. Nghĩa là nó chỉ có phần khai báo các phương thức/sự kiện và thuộc tính. Các class muốn thực hiện Interface này sẽ viết code implement cho tất cả các khai báo của Interface này.
Các tính chất của Interface
Interface không cung cấp việc kế thừa như Class hay Abstract Class mà nó chỉ khai báo phương thức/sự kiện để các lớp khác thực hiện nó.
Nó không được khởi tạo nhưng nó có thể được tham chiếu bởi đối tượng của lớp thực hiện nó. ví dụ:
IUserRepository user = new UserRepository();
Không có interface lồng nhau (nested interface)
Không có constructor, destructor, constants, static và variable.
Một interface có thể kế thừa từ một hoặc nhiều interface khác.
public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable
Một interface có thể mở rộng một interface khác.
Một class có thể implement một hoặc nhiều interfaces.
Mọi phương thức, property đều mặc định là public.
Abstract Class trong C#
Lớp trừu tượng (Abstract Class) là một loại lớp đặc biệt không thể khởi tạo được và nó hoạt động như một lớp cơ sở cho các lớp khác.
Mục đích của Abstract Class là cung cấp các chức năng cơ bản mặc định hoặc các chức năng chung chung mà các lớp dẫn suất có thể thực hiện và ghi đè. Nghĩa là, bạn có thể viết định nghĩa cho phương thức trong Abstract Class, các phương thức trong Abstract Class có thể vừa trừu tượng vừa cụ thể.
Các tính chất của Abstract Class
Một Abstract Class không thể được khởi tạo.
Abstract Class có thể chứa các phương thức trừu tượng và cụ thể (abstract method – virtual method).
Một Abstract Class không thể là một Sealed Class. Vì Sealed Class không cho phép kế thừa.
Không thể kế thừa từ một Class hay Interface.
Lớp dẫn xuất từ Abstract Class phải implement tất cả các abstract methods của Abstract Class đó.
Trong Abstract Class thì các abstract method chỉ có khai báo. Còn virtual method thì có thể được định nghĩa.
Abstract Class có thể dùng các access modifiers như: private, protected, internal. Nhưng các abstract/virtual methods thì không thể dùng private.
Abstract Class có thể có contructor, destructor, constants, fields
Không hỗ trợ đa kế thừa.
using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
SampleClass sc = new SampleClass();
//AbsSimpleClass absSimpleClass = new AbsSimpleClass(); // Error here
sc.Paint();
Console.ReadKey();
//Output:
//--> AbsSimpleClass constructor here
//--> Paint method here
}
public abstract class AbsSimpleClass
{
public AbsSimpleClass()
{
Console.WriteLine("AbsSimpleClass constructor here");
}
public abstract void DoSomething();
public virtual void Paint()
{
Console.WriteLine("Paint method here");
}
}
public class SampleClass : AbsSimpleClass
{
public override void DoSomething()
{
Console.WriteLine("Do something here");
}
}
}
}
Những điểm khác nhau giữa Interface và Abstract Class
Interface
Abstract Class
Constructors, Fields and Constants
Không
Có
Multiple inheritance
Một class có thể hiện thực nhiều interface.(tạm coi là thừa kế)
Không hỗ trợ đa thừa kế
Default implementation
Không thể định nghĩa code xử lý, chỉ có thể khai báo.
Có thể định nghĩa thân phương thức, property.
Access Modifiers
Mọi phương thức, property đều mặc định là public.
Có thể xác định modifier.
Adding functionality
Mọi phương thức, property của interface cần được hiện thực trong class.
Không cần thiết.
Khi nào nên dùng Interface
Cần cung cấp các chức năng chung cho các lớp không liên quan.
Cần nhóm các đối tượng dựa trên các hành vi phổ biến.
Cần sử dụng đa hình vì một lớp có thể thực hiện nhiều interfaces.
Cần tạo các thành phần (components) được ghép lỏng lẻo, dễ bảo trì và dùng như 1 plugin vì việc implement cho interface được tách biệt với nó.
Khi nào nên dùng Abstract Class
Cần sử dụng kế thừa.
Cần cung cấp các phương thức mặc định cũng như các phương thức phổ biến mà nhiều lớp dẫn xuất có thể thực thi và ghi đè.
Cần tạo nhiều phiên bản cho các thành phần (components). Bạn có thể thêm các thuộc tính và phương thức vào Abstract Class mà không vi phạm mã và tất cả các lớp kế thừa được tự động cập nhật với thay đổi.
Một vấn đề khác là các Interfaces có thể được implement ngầm hoặc rõ ràng (implemented implicitly or explicitly).
À, còn một vấn đề nữa. Như các bạn thấy một Class có thể implement một hoặc nhiều interfaces. Vậy nếu một class implement 2 interfaces mà trong đó có cùng 1 phương thức (method) thì sẽ thế nào?
Thử mở Visual Studio và chạy console app sau xem như thế nào nhé:
using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
SampleClass sc = new SampleClass();
IControl ctrl = new SampleClass();
ISurface srfc = new SampleClass();
sc.Paint();
ctrl.Paint();
srfc.Paint();
}
interface IControl
{
void Paint();
}
interface ISurface
{
void Paint();
}
class SampleClass : IControl, ISurface
{
public void Paint()
{
Console.WriteLine("Paint method in SampleClass");
Console.ReadKey();
}
void IControl.Paint()
{
Console.WriteLine("Paint method in IControl");
Console.ReadKey();
}
void ISurface.Paint()
{
Console.WriteLine("Paint method in ISurface");
Console.ReadKey();
}
}
}
}
Hy vọng bài viết này sẽ giúp bạn hiểu rõ hơn về Interface và Abstract Class. Từ đó giúp bạn xây dựng ứng dụng tốt hơn.
Mình cũng rất mong được các bạn góp ý để bổ sung và hoàn chỉnh kiến thức này.
Bài viết được sự cho phép của tác giả Nguyễn Trần Chung
Trước khi Composer ra đời, chúng ta thường khó chịu với hàng tá các thư viện của bên thứ ba cần phải quản lý, rất khó khăn để cập nhật và còn lại các khâu cài đặt lằng quằng. Đó là quá khứ thôi, sự ra đời của Composer đã làm thay đổi hoàn toàn mọi thứ rồi. Trong bài viết này chúng ta sẽ tìm hiểu về Composer thực chất nó là gì.
Composer là gì ?
Composer là một công cụ quản lý sự phụ thuộc trong PHP. Nó cho phép bạn khai báo các thư viện mà dự án của bạn phụ thuộc vào và nó sẽ quản lý (cài đặt / cập nhật) các thư viện cho bạn.
Composer là một mã nguồn mở (OpenSource) nên được cộng đồng hỗ trợ rất nhiều, bạn có thể tham gia phát triển, phát triển lại từ trang Github chính thức của Composer.
Như mình đã nói ở trên Composer ra đời để giải quyết các vấn đề khó khăn như dung lượng project sẽ lơn hơn, việc cập nhật cũng như chèn vào project rất phức tạp và phiền phức. Với composer, bạn sẽ cần khai báo tên và version của các thư viện mà bạn có sử dụng mà không cần phải tự tay chép code của nó vào project, composer sẽ tự động tìm và tải thư viện mà bạn cần trên Server, nếu trong thư viện đó có dùng các thư viện khác thì nó cũng sẽ tải các thư viện khác về, nó đệ quy cho đến khi tải đủ các thư viện, thật tuyệt vời phải không nào.
Khi bạn sử dụng VCS, bạn sẽ chỉ cần commit tên version, tên thư viện ở file cấu hình composer.json mà không cần phải commit những thay đổi trong code của các thư viện như trước. Mặt khác, khi trong project của bạn có các thư viện mà các thư viện ấy lại dùng thư viện khác và khi đó chỉ cần một trong những cái đó có update thì composer sẽ tự động update giùm bạn luôn.
Các framework PHP hiện giờ đều sử dụng composer để quản lý thư viện cần thiết.
Để cài được composer vào máy bạn cần phải cài đặt sẵn PHP 5.3.2+, và nên cài sẵn Git để hỗ trợ tốt hơn với các gói thư viện. Composer hỗ trợ tốt trên ba nền tảng OS X, Windows và cả Linux.
Composer Trên Linux / Unix / OSX
bạn mở Terminal lên và nhập lần lượt từng dòng lệnh sau:
Hoặc bạn có thể download composer.phar từ https://getcomposer.org/ (ở cuối trang) sau đó duy chuyển nó vào trong thư mục bin bằng lệnh
sudo mv composer.phar /usr/local/bin/composer
Composer Trên Windows
Dùng bộ cài tự động
Đây là cách cài dễ dàng nhất, bạn chỉ việc tải về Composer-Setup.exe sau đó cài như một phần mềm bình thường (nhớ trỏ đến php.exe đã cài sẵn trên máy tính đúng chỗ). Composer Installer sẽ tự động cài và thêm vào PATH sẵn cho bạn để bạn có thể dùng lệnh composer trên CMD.
Cài Thủ Công
Như ở trên, bạn tải về composer.phar từ https://getcomposer.org/ (ở cuối trang) sau đó duy chuyển nó vào trong thư mục bất kỳ bạn muốn, ở đây tớ ví dụ là C:\bin nhé.
Bạn tạo tập tin có tên là composer.bat với nội dung như sau:
echo @php "%~dp0composer.phar" %*>composer.bat
Để dùng được lệnh composer trên CMD bạn cần phải thêm thư mục Composer vào PATH environment variable. Bạn có thể xem cách thực hiện dưới đây hoặc bằng Google
Vào File Exploder, chọn chuột phải vào This PC ⇒ Properties ⇒ Advanced System Settings, ở cửa sổ Pop-up chọn Envaironment Variables…
Sau đó ở mục System Variables chọn vào mục Path và bấm vào nút Edit
Bấm vào New sau đó thêm vào C:\bin (thư mục cài composer như trên) sau đó bấm OK thế là hoàn tất và bây giờ bạn có thể mở CMD và đánh vào câu lệnh sau để kiểm tra: composer -v
Có hai phần riêng biệt để quản lý dependencies bằng Composer. Đầu tiên là command line tool của Composer cho việc nắm giữ và quản lý các dependencies. Thứ hai là Packagist – Đây là nơi lưu trữ các package mà bạn muốn sử dụng.
Khi sử dụng Composer trong thư mục gốc chúng ta có một tập tin JSON là composer.json có nội dung:
{"name":"dinhquochan/my_project","description":"My New Project","authors":[{"name":"Dinh Quoc Han","email":"admin@dinhquochan.com"}],"require":{"monolog/monolog":"1.12.0"}}
Trong tập tên trên có các phần như sau:
name tên dự án có dạng vendor_name/package_name.
description mô tả gói của bạn.
authors tác giả của dự án.
require đây chính là danh sách các package thư viện cần thiết, nó sẽ lấy từ server về. sẽ có 2 phần là tên vendor/ tên gói cùng với chỉ định version hay không.
Trong trường hợp trên mình đã yêu cầu Monolog, một framework phổ biến dùng để logging. Chỉ vì tôi có một file JSON với thông tin này không có nghĩa là chúng ta sử dụng được có thể sử dụng Monolog. Chúng ta phải vào Terminal tại thư mục hiện tại với câu lệnh:
composer install
Nó sẽ đưa tất cả dependencies của dự án vào thư mục mang tên vendor và thực hiện các công việc cần thiết khác. Cùng lúc đó nó sẽ tạo ra file composer.lock để biết là composer đã được thiết lặp tại thư mục mình sẽ nói cái này ở dưới. và các bạn hãy kiểm tra thử thư mục vendor xem ắt hẳn các thư viện đã được tải về và một file autoload.php.
Ngay lúc này, để sử dụng được các thư viện đó bạn chỉ viện chèn autoload.php vào file cần thiết:
require"vendor/autoload.php";
Sau đó làm theo hướng dẫn sử dụng của Package đó là xong, ở đây tớ ví dụ monolog nhé:
<?phprequire"vendor/autoload.php";useMonolog\Logger;useMonolog\Handler\StreamHandler;// create a log channel$log=newLogger('name');$log->pushHandler(newStreamHandler('path/to/your.log', Logger::WARNING));// add records to the log$log->addWarning('Foo');$log->addError('Bar');
Chỉ định version cho các Package trong Composer
Trong composer.json trên chúng ta thấy ta đang sử dụng version 1.12.0 nhưng nếu muốn dùng phiên bản khác thì sao? Có 6 cách để xác định version mà bạn muốn, hãy tìm hiểu xem:
Version Range
Bằng cách sử dụng các toán tử so sánh bạn có thể lấy version cao hơn, thấp hơn hoặc tuân theo một số các nguyên tắc thậm chí phức tạp hơn như sử dụng AND và OR. Các toán tử có thể là >, <,> =, <= và !=. AND được biểu diễn bằng một dấu cách hoặc dấu phẩy, OR được biểu diễn bằng hai dấu gạch dọc: ||.
Ví dụ >2.7 nghĩa là bất kỳ version nào trên 2.7. >2.7 <=3.5 bao gồm các version từ 2.7 trở lên tới 3.5 (bao gồm cả 3.5).
Bằng cách sử dụng một ký tự đại diện, bạn có thể xác định một pattern. x.x.* sẽ bao gồm tất cả các version x.x.0 trở lên và trở xuống (tất nhiên cả x.x, nhưng không bao gồm x.y.0.
Ví dụ 2.3.* sẽ bao gồm từ 2.3.0 trở lên và trừ 2.4 Nó tương đương với >=2.3.0 <2.4
Hyphen Ranges
Hyphen Ranges cho phép bạn xác định range dễ dàng hơn, mặc dù bạn sẽ cảm thấy bối rối hơn một chút vì cách nó xử lý các partial version. Full version gồm ba số trong trường hợp hyphen ranges thực hiện đầy đủ ý nghĩa của nó
2.0.0 – 3.0.0 nghĩa là tất cả các version bao gồm 2.0.0 trở lên và bao gồm 3.0.0 trở xuống.
2.0 – 3.0 bao gồm bất kỳ version nào kể cả 2.0 trở lên nhưng không bao gồm version 3.1
Lý do cho hành động tưởng chừng như kỳ lạ này là phần bên trái dấu gạch ngang nghĩa là bao gồm, còn phần bên phải hoàn toàn chỉ là một ký tự đại diện. Biểu thức trên sẽ tương đương với >=2.1 <3.1.0
Tiddle Range
Tiddle Range rất tuyệt vời để đáp ứng các yêu cầu nhỏ nhất cho việc xác định version và chấp nhận bất kỳ version nào trở lên, nhưng không bao gồm chính nó. Nếu chỉ rõ là ~3.6 thì bạn chấp nhận các version từ 3.6 trở lên nhưng không bao gồm 4.0.
Method này tương đương với >-3.6 <4.0
Caret Range
Caret Range có nghĩa là chấp nhận tất cả các phiên bản hiện tại tính từ nó nhưng không bao gồm phiên bản lớn hơn. Ví dụ ^3.3.5 bạn chấp nhận bất kỳ version nào trở lên, nhưng không bao gồm4.0
Dev-Master
Với dev-master bạn đang giữ version mới nhất được phát triển nhưng không được tag với một version number cụ thể. Điều này có thể tốt trong khi phát triển nhưng bạn cần nhận thức được sự tiềm tàng về bugs là cao hơn so với các version kia.
Ứng tuyển ngay các vị trí PHP tuyển dụng mới nhất trên TopDev
Locking trong Composer
Locking là một trong những tính năng hữu ích nhất của Composer. Trước tiên ta sẽ nói đến composer.lock. Công việc của nó là khóa lại các versions của các components đã sử dụng. Lock file có thể chắc chắn rằng mọi người làm việc với các versions giống nhau của các files.
Khi lần đầu tiên sử dụng Composer để lấy một dependency nó sẽ ghi chính xác version vào file Composer.lock. Ví dụ như nếu bạn chỉ rõ 2.3.* và 2.3.5 là version mới nhất thì version được cài đặt sẽ là 2.3.5 và nó sẽ được đưa vào trong lock file.
Giả sử sau 1 tuần có một developer gia nhập team của bạn. Trong thời gian này dependency đã được update lên 2.3.6. Nếu anh ta sử dụng câu lệnh (composer install) thì sẽ nhận được2.3.5 vì nó đã được ghi trong file lock.
Tất nhiên bạn có thể quyết định việc update các dependencies của mình. Trong trường hợp đó, bạn sẽ thực hiện lệnh :
composer update
Nó sẽ lấy các version mới nhất và ghi chúng vào file lock.
Chú ý: Không bao giờ chạy lệnh composer update trong môi trường thực tế (production) mà hãy kiểm tra trên máy để tránh tình trạng không tương thích.
Require-dev
Composer cho phép bạn xác định các dependency cho môi trường dev. Điều này được thực hiện bằng cách xác định các dependency của bạn trong mảng require-dev thay vì mảng require.
{"name":"dinhquochan/my_project","description":"My New Project","authors":[{"name":"Dinh Quoc Han","email":"admin@dinhquochan.com"}],"require":{"monolog/monolog":"1.12.0"},"require-dev":{"fzaninotto/faker","dev-master"}}
Faker là một thư viện tạo ra các dữ liệu mẫu. Điều này là rất tốt trong khi bạn đang dev để test thử nhưng khi đã public sản phẩm thì nó lại không thực sự cần thiết. Nếu muốn loại trừ các yêu cầu phát triển, bạn cần thực hiện lệnh install hoặc update với tùy chọn –no-dev
composer install --no-dev
Lời Kết
Composer giúp lập trình viên giảm bớt suy nghĩ về các thư viện và chỉ tập trung vào ứng dụng chính của mình. Tiết kiệm khá nhiều thời gian để làm những việc khác. Hiện tại, hầu hết các Framework đều hỗ trợ Composer, như: CodeIgniter, Symfony2, Laravel, FuelPHP…
Composer đúng là một công cụ tuyệt vời dành cho PHP.
Không rõ vì lý do cá nhân gì, mà CSS chỉ áp dụng cái luật margin collapse này cho giá trị top và bottom, nếu giá trị margin là left hoặc right, thì nó lại bình thường
Bài viết được sự cho phép của tác giả Nguyễn Chí Thức
Lập trình Scratch từ lâu đã là ngôn ngữ lập trình phổ biến cho học sinh, sinh viên và các em nhỏ. Với Scratch, việc lập trình từ ban đầu được gán cho cái mác khó nhằn, khó hiểu, đơn điệu và tẻ nhạt bỗng trở thành ngôn ngữ lập trình được các em nhỏ không cần cha mẹ nói cũng vào học.
Vậy điều gì làm nên sức hút của Scratch. Giải đáp Scratch là gì? Tạo scproject với scratch như thế nào? trong bài viết này.
Scratch là gì?
Ngôn ngữ lập trình Scratch là gì?
Scratch là một ngôn ngữ lập trình trực quan và môi trường phát triển tích hợp được thiết kế đặc biệt cho trẻ em và người mới bắt đầu. Được phát triển bởi Lifelong Kindergarten Group tại MIT Media Lab, Scratch cho phép người dùng tạo ra các câu chuyện tương tác, trò chơi, và hoạt hình thông qua việc kéo và thả các khối mã màu sắc. Mục tiêu chính của Scratch là giúp người học tiếp cận dễ dàng với lập trình và phát triển các kỹ năng tư duy sáng tạo, giải quyết vấn đề và làm việc nhóm.
Mục đích của phần mềm Scratch
Trẻ em cũng có thể học lập trình là một ý tưởng rất có ý nghĩa thực tiễn, tuy nhiên để sáng tạo ra một phương pháp lập trình phù hợp với trình độ và tâm lý lứa tuổi trẻ em thì lại vô cùng khó khăn. Không phải nhà khoa học máy tính nào cũng có thể làm được. Những khái niệm khoa học kỹ thuật khó hiểu, những quy tắc luật lệ chằng chịt, những suy nghĩ liên miên mệt mỏi trong những ngôn ngữ lập trình kiểu dòng lệnh phổ biến như Pascal, C, C++, Java, PHP, …chính là rào cản đối với sự tiếp cận lập trình cho trẻ em.
Tuy nhiên, đối với Scratch thì khác! Ngôn ngữ lập trình Scratch phát triển theo hướng tương tác trực quan, đồ họa sống động, sản phẩm liền tay mà vẫn đảm bảo tính khoa học, tính liên thông tri thức sau này.
Mục đích của phần mềm Scratch
Khi sử dụng Scratch, thay vì phải viết những dòng lệnh logic dễ gặp lỗi thì ở đây bạn chỉ cần nắm và kéo các khối lệnh đầy màu sắc có sẵn để lắp ghép thành một kịch bản điều khiển các đối tượng trên sân khấu biểu diễn.
Đối với những người mới bắt đầu học các ngôn ngữ lập trình như Pascal, C, PHP,…sẽ rất khó hiểu với việc sử dụng Biến, Hàm, Thủ tục, Danh sách và các Điều kiện, Vòng lặp,…nhưng khi sử dụng Scratch thì những khái niệm đó trở nên trực quan, dễ hiểu và dễ vận dụng trong các tình huống cụ thể.
Với đặc điểm dễ học, dễ sử dụng và hiệu quả như vậy, Scratch được xem như là một ngôn ngữ nền tảng trước khi học các ngôn ngữ khác. Và vì thế, đến nay đã có hàng triệu dự án được chia sẻ trên trang chủ của nhà thiết kế. Rất nhiều trường học trên khắp thế giới, từ trường Tiểu học đến Đại học đã sử dụng Scratch như một môn học chính thức.
Đặc điểm của ngôn ngữ lập trình Scratch
Scratch là một ngôn ngữ lập trình trực quan được thiết kế để giúp trẻ em và người mới bắt đầu học lập trình một cách dễ dàng và thú vị. Dưới đây là những đặc điểm chính của ngôn ngữ lập trình Scratch:
Giao diện trực quan và thân thiện
Scratch sử dụng giao diện kéo và thả, giúp người dùng dễ dàng thao tác mà không cần phải viết mã phức tạp. Các khối lệnh được tổ chức theo màu sắc và hình dạng khác nhau, giúp người dùng nhận biết chức năng của từng khối và sắp xếp chúng một cách dễ dàng. Điều này làm cho quá trình lập trình trở nên trực quan và thân thiện với người dùng, đặc biệt là trẻ em.
Khối lệnh màu sắc
Các khối lệnh trong Scratch được phân loại theo màu sắc dựa trên chức năng của chúng. Ví dụ, các khối điều khiển (control) có màu vàng, các khối chuyển động (motion) có màu xanh lam, và các khối âm thanh (sound) có màu tím. Sự phân loại này giúp người dùng dễ dàng tìm kiếm và sử dụng các khối lệnh phù hợp cho dự án của mình.
Tính năng kéo và thả
Scratch cho phép người dùng tạo ra các chương trình bằng cách kéo và thả các khối lệnh vào khu vực làm việc. Điều này giúp loại bỏ sự phức tạp của việc viết mã bằng văn bản và giúp người dùng tập trung vào việc xây dựng logic và ý tưởng cho chương trình. Tính năng kéo và thả làm cho quá trình lập trình trở nên thú vị và ít căng thẳng hơn.
Component-Based Architecture
Scratch sử dụng kiến trúc dựa trên component, nơi mà mỗi thành phần (sprite) có thể được lập trình độc lập. Mỗi sprite có thể có các kịch bản (scripts), trang phục (costumes) và âm thanh riêng, giúp người dùng dễ dàng quản lý và phát triển các thành phần của dự án một cách linh hoạt. Điều này giúp tạo ra các dự án phức tạp một cách dễ dàng và hiệu quả.
Khả năng tương tác
Scratch cho phép người dùng tạo ra các chương trình tương tác thông qua việc sử dụng các sự kiện (events) và cảm biến (sensors). Người dùng có thể lập trình các sprite để phản hồi lại các sự kiện như nhấn chuột, nhấn phím hoặc chạm vào màn hình. Khả năng tương tác này giúp tạo ra các trò chơi và hoạt hình hấp dẫn và sinh động.
Hỗ trợ đa nền tảng
Scratch có thể chạy trên nhiều nền tảng khác nhau bao gồm máy tính để bàn, laptop và máy tính bảng thông qua trình duyệt web hoặc ứng dụng Scratch dành cho thiết bị di động. Điều này giúp người dùng dễ dàng tiếp cận và sử dụng Scratch ở bất kỳ đâu và bất kỳ lúc nào, tạo điều kiện thuận lợi cho việc học và sáng tạo.
Tính năng tích hợp với phần cứng
Scratch có thể tích hợp với nhiều loại phần cứng như robot, bộ điều khiển và các thiết bị IoT. Điều này mở rộng khả năng sáng tạo của người dùng, cho phép họ xây dựng các dự án phức tạp và thực tế hơn, đồng thời áp dụng kiến thức lập trình vào các lĩnh vực khác nhau. Khả năng tích hợp này giúp Scratch trở thành một công cụ mạnh mẽ cho các dự án STEM (khoa học, công nghệ, kỹ thuật và toán học).
Theo chính tác giả Scratch, ông giáo sư Mitchel Resnick đã chia sẻ như sau:
“Khi học lập trình Scratch, trẻ em học được những nguyên lý cơ bản của việc thiết kế, học được cách thử nghiệm ý tưởng mới, học được cách phân chia ý tưởng phức tạp thành những phần việc đơn giản, học được cách hợp tác với người khác để thực hiện dự án, học được cách tìm và sửa lỗi khi kết quả không được như ý, tập được tính kiên trì khi đối mặt với khó khăn. Ngày nay, đó không chỉ là những kỹ năng cần thiết cho việc lập trình, mà còn cần thiết cho nhiều hoạt động khác.”
Từng bước với lập trình Scratch
Cài đặt và đăng kí sử dụng Scratch
Để bắt đầu với lập trình scratch, truy cập trang chủ và ấn vào start creating. Các bạn cũng có thể signup (tạo tài khoản để lưu trữ các project của cá nhân mình).
Truy cập trang chủ và ấn vào Start Creating
Scratch sẽ chuyển hướng ta tới trang bắt đầu để lập trình với Scratch.
Giao diện sau khi đã khởi tạo project tại Scratch
Trước khi bắt đầu, các bạn nên xem qua video hướng dẫn một số thao tác cơ bản và thành phần của scratch.
Video hướng dẫn cụ thể và rõ ràngLập trình scratch chú trọng tới các đối tượng và lập trình animations cho các đối tượng. Đối tượng ban đầu và mặc định là chú mèo scratch. Để thêm các đối tượng khác. Ấn vào góc bên dưới bên phải màn hình.
Góc dưới bên phải cho phép thêm nhiều hơn các đối tượng.
Sau khi đã có các đối tượng, bước tiếp theo là các thao tác, âm thanh được tuỳ chọn để lập trình. Việc lựa chọn đúng các thao tác giúp đối tượng trở nên sinh động hơn.
Scratch hiện tại hỗ trợ code (trực quan không code), costumes (tuỳ chỉnh cao hơn) và Sounds (phần âm thanh cho các đối tượng)
Các đối tượng trong Scratch
Về mặt code, hiện tại scratch hỗ trợ danh sách sau:
Motion (di chuyển 10 bước, xoay ngang dọc, di chuyển tới vị trí có toạ độ x và y)
Looks (xin chào, thay đổi kích thước, ẩn (hide), hiện (show), …
Sounds (âm thanh bắt đầu tới lúc kết thúc, thay đổi volume tăng hoặc giảm, …)
Events (khi ấn vào thì sao?, khi nhận được tin nhắn, …)
Control (kiểm soát, các câu lệnh cơ bản của lập trình, nếu a thì b, nếu như thế này thì thế kia, …)
Sensing (các sự kiện của chuột, các sự kiện chờ cho câu hỏi, câu trả lời, …)
Operators (các phép cộng trừ, so sánh, tính toán độ dài, …)
Variables (các biến tuỳ chỉnh, thiết lập dữ liệu, thay đổi các biến, …)
Các đối tượng được hỗ trợ trong khối Variables
Tuỳ biến, tuỳ chỉnh cao hơn với lập trình Scratch
Sau khi đã hiểu rõ và thực hành một số thành phần code được hỗ trợ bởi Scratch. Nếu các animations và lập trình cần tới tuỳ chỉnh các đối tượng. Việc tuỳ chỉnh đối tượng cho phép làm ra các đoạn code sinh động hơn, phù hợp hơn với yêu cầu.
Mục consumes dành cho các đối tượng tuỳ chỉnh. Cho phép chỉnh sửa màu sắc, hình dạng, kích thước các đối tượng.
Thay đổi màu sắc quần của đối tượng sang màu tím.
Một thành phần khác giúp cho các video animations được lập trình trở nên tuyệt vời hơn là âm thanh. Âm thanh cũng có thể tuỳ chỉnh ở mục Sounds.
Nếu hình ảnh trong bộ sưu tập có sẵn của Scratch không phù hợp hoặc chưa đáp ứng được nhu cầu của bạn. Các bạn có thể tự tải lên các hình ảnh riêng của mình bằng nút nhấn phía bên dưới phải màn hình.
Tải lên các hình ảnh cá nhân hoặc tự xây dựng là hoàn toàn khả thi với scratch
Khả năng lập trình máy tính là một phần quan trọng trong học vấn của xã hội ngày nay. Khi mọi người học cách lập trình bằng Scratch, bản thân họ sẽ học được những chiến thuật quan trọng để giải quyết vấn đề, thiết kế các chương trình và truyền đạt những ý tưởng.
Chính vì vậy, không chỉ riêng tập lớp trẻ em, học sinh là nên tiếp thu với lập trình scratch. Người già, các đối tượng khác trong xã hội nếu có điều kiện cũng có thể thử sức, sáng tạo với lập trình scratch. Có thể bạn quan tâm:
Bài viết được sự cho phép của BQT Kinh nghiệm lập trình
Bài trước mình đã giới thiệu tổng quan về nghề IT BA hiện nay ở nước ta. Bài này mình sẽ giới thiệu chi tiết BA là làm những công việc gì?
BA là viết tắt của từ Business Analyst. Về cơ bản BA là người làm việc với khách hàng để lấy yêu cầu, sau đó chuyển thông tin và thảo luận đưa ra giải pháp với team nội bộ (development, tester,…) và quản lý các loại tài liệu.
Theo BABOK define:
“A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.”
Tuyển business analyst các ngành hấp dẫn nhất
Vai trò của BA trong dự án:
Là người kết nối giữa các stakeholder, giữa stakeholder và nhóm phát triển.
Là người hiểu về cấu trúc, chính sách, cách vận hành của tổ chức.
Đề xuất các giải pháp giúp tổ chức đạt được các mục tiêu.
BA role
Các công việc của một BA
Tài liệu Architecture: Tài liệu mô tả luồng thao tác người dùng, luồng hoạt động của hệ thống, cấu trúc cơ bản của hệ thống, các thành phần trong hệ thống, tương tác giữa các thành phần trong hệ thống.
Tài liệu SRS or basic design: Tài liệu mô tả chi tiết các chức năng, giao diện của từng chức năng
Tài liệu test point: Các testcase cơ bản, đặc thù liên quan đến giao diện từ phía người dùng.
Thiết kế mô tả database: Database hệ thống, mô tả chức năng của các bảng các trường đặc biệt.
Các bước tiếp cận với yêu cầu mới từ khách hàng
Requirement là gì? Yêu cầu được định nghĩa là: Một điều kiện hoặc khả năng cần thiết của một bên liên quan để giải quyết một vấn đề hoặc đạt được một mục tiêu. Một điều kiện hoặc khả năng mà hệ thống phải đáp ứng hoặc sở hữu để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật hoặc tài liệu chính thức khác. Một bản trình bày bằng văn bản của một điều kiện hoặc khả năng như trên.
Các bước để tiếp cận một yêu cầu:
Phân tích tổng quan (Enterprise Analysis)
Sau khi nhận được yêu cầu từ khách hàng thì BA sẽ bắt đầu tìm hiểu, nghiên cứu tính khả thi, đánh giá rủi ro, các tình huống có thể xảy ra. Đôi khi yêu cầu đưa ra ở trạng thái sơ sài, khái quát và là nghiệp vụ mới với BA, nếu gặp phải tình huống này thì tìm hiểu thông tin từ internet hoặc tìm người có hiểu biết để tham khảo thông tin.
Khơi gợi, khám phá (Elicitation)
Sau khi kết thúc bước trên thì BA sẽ có hiểu biết cơ bản về yêu cầu của khách hàng, bước thứ 2 này sẽ trao đổi lại với khách hàng để làm rõ yêu cầu.
Cách khơi gợi yêu cầu từ khách hàng
Phỏng vấn các stakeholder liên quan đến dự án. Tập trung các câu hỏi what, why, when, how (Interviews)
Khảo sát yêu cầu (Survey)
Tổ chức các cuộc họp (Meeting)
Quan sát (Observation)
Tạo các bản mẫu (Prototyping)
Phân tích yêu cầu và làm tài liệu (Requirements Analysis & Documentation)
Mô hình hóa yêu cầu bằng các biểu đồ (Workflow, Use Case, Activity diagram, Sequence diagram…)
Tài liệu mô tả database (ERD)
Documentation: Có 2 loại tài liệu thường được sử dụng: SRS (System Requirements Specifications), BD (Basic design).
Đánh giá và xác thực giải pháp (Solution Assessment & Validation)
Mục consumes dành cho các đối tượng tuỳ chỉnh. Cho phép chỉnh sửa màu sắc, hình dạng, kích thước các đối tượng.
Thay đổi màu sắc quần của đối tượng sang màu tím.
