Bài viết được sự cho phép của tác giả Kien Dang Chung
Trong quá trình làm việc với Git, chúng ta cần phải kiểm tra các trạng thái hiện tại hay các ghi log của kho lưu trữ, Git hỗ trợ các câu lệnh đủ mạnh để đáp ứng tất cả các yêu cầu này.
git status
Câu lệnh git status hiển thị trạng thái working directory và staging area, nó cho phép xem các thay đổi trong staging area, các file nào được track. Git status không hiển thị bất kỳ thông tin nào liên quan đến commit. Câu lệnh này cũng gợi ý các bước làm tiếp theo khi bạn thực hiện, ví dụ như với file untrack nó sẽ gợi ý bạn track bằng lệnh git add hoặc với file đã track có thể chuyển về untrack bằng git rm. Git status bỏ qua các thư mục, file được liệt kê trong .gitignore. Chúng ta cùng xem ví dụ về git status:
Trong ví dụ trên, lần đầu sử dụng git status sẽ thấy thông báo file index.html đã được track và được thay đổi, nó cũng gợi ý có thể sử dụng git add để cập nhật vào staging area, hoặc git checkout — để bỏ qua các thay đổi trong working directory. Sau đó, git add sẽ ghi nhận lại các thay đổi vào staging area và chúng ta xem git status lần thứ hai thì thấy không còn gì cần làm.
git log
Câu lệnh git log sẽ hiển thị các staging area snapshot đã được commit, nó cho bạn thấy danh sách các lịch sử thay đổi của dự án, cho phép lọc hoặc tìm kiếm các thay đổi. Git log và git status khác nhau ở chỗ, git status cho thấy trạng thái của working directory và staging area trong khi đó git log chỉ làm việc với các lần commit.
Câu lệnh git log có rất nhiều các tùy chọn khác nhau:
git log -n : chỉ hiển thị log cho lần commit gần nhất.
git log –online: hiển thị mỗi log commit trên một dòng, sẽ không có thông tin như author và date được hiển thị.
git log –stat: hiển thị log commit chi tiết hơn với các file nào thay đổi và số lần git add, nếu danh sách quá dài, khi thoát cần nhấn tổ hợp Shift + ZZ.
git log -p: hiển thị log commit chi tiết –stat với các dòng thay đổi trong từng file được hiển thị, Shift + ZZ để thoát nếu danh sách quá dài.
git log –author=””: hiển thị các log commit của người thực hiện xác định.
git log –grep=””
git log ..: hiển thị các log commit trong khoảng từ đến , hai tham số này đều là các ID của mỗi lần commit.
git show <commit_id> dùng để xem chi tiết một commit. Câu lệnh git show có thể được sử dụng để xem rất nhiều các dạng đối tượng khác nhau, bạn xem chi tiết git show ở đây. Trong khuôn khổ bài viết chúng ta chỉ tìm hiểu git show ở góc độ xem chi tiết một commit. Trước hết để xem chi tiết, chúng ta cần lấy ID của commit bằng git log –oneline.
git diff
Trong project cần rất nhiều lần thay đổi, làm chủ các thay đổi này giúp bạn quản lý dự án tốt hơn. Các câu lệnh git status, git log chỉ cho bạn thấy được một phần thông tin, với git diff bạn sẽ có được thông tin một cách tường tận nhất. git diff cho phép bạn so sánh các phiên bản khác nhau của một file.
git diff HEAD : So sánh file trong local repository với working directory.
git diff : So sánh file trong staging area với working directory.
git diff –cached : So sánh file trong staging area với local repository.
git diff <commit_id_1>..<commit_id_2>: So sánh file trong hai lần commit khác nhau.
Câu lệnh git diff được sử dụng rất nhiều trong quản lý phiên bản, có lẽ đây là một trong những câu lệnh được sử dụng nhiều nhất. Chúng ta cùng xem ví dụ được thực hiện git diff cùng các tùy chọn.
Lời kết
Với các câu lệnh git status, git log, git show, git diff chúng ta đã kiểm soát được trạng thái và tìm ra sự khác biệt giữa các phiên bản khác nhau. Dựa vào các thông tin này chúng ta hoàn toàn quản lý được phiên bản một cách tốt nhất. Trong các bài viết tiếp theo chúng ta sẽ tìm hiểu về cách thức quay trở lại các phiên bản khác nhau cùng với các vấn đề khác khi làm việc trên Git.
Thư mời phỏng vấn là loại hồ sơ quan trọng được nhà tuyển dụng gửi đến các ứng viên sau quá trình dài chọn lọc CV. Sau khi cân nhắc và xét chọn dựa trên các tiêu chí đề ra, những thư mời phỏng vấn sẽ được thông báo cho các ứng viên tiềm năng nhất. Và không quá để nói rằng thư mời phỏng vấn là một trong những yếu tố đại diện bộ mặt của tổ chức/doanh nghiệp.
Nội dung của thư mời interview luôn là vấn đề được nhiều người quan tâm. Vậy hiểu thế nào là một thư mời phỏng vấn đúng chuẩn? Đâu là những điêm cần lưu ý khi viết thư mời phỏng vấn? Bí quyết nào giúp cho nhà tuyển dụng tạo ra các thư mời thật sự có hiệu quả. Cùng TopDev tìm hiểu thông qua bài viết sau.
Thư mời phỏng vấn là gì?
Thư mời phỏng vấn (hay còn gọi là Interview Invitation Email) là lá thư được gửi đến ứng viên sau vòng xét duyệt hồ sơ CV.
Mục đích chính là thông báo đến các ứng viên được chọn đi tiếp “thứ thách tuyển dụng” để trao đổi; khai thác thêm các vấn đề xoay quanh ứng viên.
Đây là loại thư mời quan trọng và được nhà tuyển dụng chú trọng. Thực tế cho thấy, có nhiều hình thức thông báo như gọi điện trực tiếp. Song, quá trình tuyển dụng cần tối ưu hóa và việc gửi thư mời qua email là cách thức hữu hiệu.
Thư mời phỏng vấn – Interview là gì?
Với loại thư này, ứng viên có thể chấp nhận hoặc không; hoặc có thể linh động chọn khác. Phía nhân sự tuyển dụng bên công ty nếu biết cách thiết lập một email chuyên nghiệp với đầy đủ thông tin; văn phong thu hút sẽ tạo ra ấn tượng mạnh với các ứng viên.
Đó cũng chính là cơ sở giúp các tổ chức/doanh ghi điểm trong việc tạo dấu ấn; khiến tỉ lệ ứng viên apply các vị trí lên một mức đáng kể.
Tại sao thư mời phỏng vấn lại trở nên quan trọng?
Đơn giản vì thư mời phỏng vấn là lá thư mời gọi. Nó có giá trị tạo điểm nhấn và liệu ứng viên có phản hồi hay không cũng phụ thuộc một phần vào thư mời này. Thư mời giúp kết nối ứng viên, thông báo sự tiếp diễn trong một quá trình. Từ đó, dẫn đến vòng phỏng vấn cuối cùng sẽ hiệu quả và thành công hơn.
Để giúp mẫu thư mời interview hiệu qủa, người soạn cần phải quan tâm đến nội dung; các mong muốn cần được truyền tải một cách khoa học nhưng vẫn dễ hiểu. Đặc biệt, mẫu thư mời không quá dài dòng. Nó cần thỏa mãn các tiêu chí về tính ngắn gọn, súc tích.
Bố cục nội dung của một thư mời phỏng vấn chuẩn
Thư mời cần rõ ràng về nội dụng. Trình tự logic rất quan trọng đối với mẫu thư mời phỏng vấn. Hãy đảm bảo rằng checklist dưới đây các bạn đã xem và áp dụng một cách phù hợp:
thư mời phỏng vấn
1. Tiêu đề email trong thư mời phỏng vấn
Đảm bảo tính chính xác, đặc biệt khi bạn sử dụng template email cho sẵn. Mẫu template cần ở định dạng chuẩn. Đừng gửi sai email hoặc gửi nhầm. Đó là sai lầm thể hiện sự thiếu chuyên nghiệp dẫn đến tổ chức sẽ bị mất điểm trong mắt các ứng viên.
Vd: THƯ MỜI PHỎNG VẤN
2. Chia sẻ lời cảm ơn ứng viên
Dù đây được xem là yếu tố formal nhưng nó cần phải có. Và bắt buộc phải có trong mỗi mẫu thư mời interview. Đặc biệt, nó lại là nội dung quan trọng trước khi dẫn đến các nội dung trọng tâm khác.
Hãy dành vài dóng đầu tiên để dành lời cảm ơn đối với ứng viên. Cảm ơn vì họ đã quan tâm đến công ty và dành sự đầu tư tâm sức cho vị trí ứng tuyển trong thời gian dài vừa qua.
Lời chia sẻ có thể kèm thông tin của người tới nhận phỏng vấn bao gồm: họ và tên, địa chỉ email, số điện thoại xác nhận…
3. Thông tin về cách thức phỏng vấn
Nếu phỏng vấn qua điện thoại hoặc Skype, bạn sẽ phải cung cấp trước cho ứng viên số điện thoại hoặc tài khoản Skype cho họ; hoặc phỏng vấn qua Google thì cần có mã,…
4. Thông tin về những người liên hệ và các lưu ý kèm xác nhận của công ty/doanh nghiệp
Đây là những phần nhỏ nhưng sẽ cho thấy sự kỹ lưỡng, tính chuyên nghiệp trong khâu tổ chức, quản lý và kiểm soát quá trình tuyển dụng dành cho ứng viên.
Ứng viên có thể bị lạc đường hoặc nhớ nhầm thời gian, bạn phải có những giải pháp back-up trước cho ứng viên.
5. Thông tin chính thức về công ty
Website, fanpage,… Đây được xem là các kênh giúp tăng mức độ nhận diện. Đồng thời, thông qua nguồn thông tin được chia sẻ, ứng viên có thể tìm hiểu cơ bản về các giá trị mà công ty đang định hướng. Đây cũng là một nước đi tốt giúp ứng viên tự tin hơn trong buổi phỏng vấn sắp tới.
Những lưu ý khi gửi mẫu thư mời phỏng vấn cho ứng viên
Để tạo ra những thuận lợi cho quá trình phỏng vấn, TopDev gửi đên bạn đọc những tips sau đây. Cần thật sự lưu tâm vì đây đều là những lưu ý quan trọng.
– Thời gian cần đảm bảo tính khả thi: Thời gian hiệu quả nhất được tính từ lúc gửi thư mới đến thời điểm diễn ra phỏng vấn là khoảng 5 – 7 ngày. Điều này đảm bảo giải quyết các rủi ro có thể xảy ra. Ví dụ như nhiều ứng viên nhảy việc, họ cần một khoảng thời gian để sắp xếp xin nghỉ và tham gia phỏng vấn.
– Phần trọng tâm nội dung ban đầu cần phải nhắc đến ứng viên. Không đi quá xa vào các khía cạnh khai thác thông tin khác.
– Nên nhắc lại vị trí ứng tuyển. Điều này giúp tạo lại ấn tượng về vị trí ứng tuyển của ứng viên. Vì thực tế, ứng viên có thể đã gửi đơn apply rất nhiều nơi tuyển dụng khác nhau.
– Các thông tin về thời gian, địa điểm, cách thức phỏng vấn đều phải rõ ràng, cụ thể tránh mơ hồ khiến ứng viên thiếu hụt thông tin và dẫn đến hoang mang..
– Kiểm tra lỗi chính tả, văn phong trong email trước khi gửi mẫu thư mời cho ứng viên trước khi gửi.
– Phía tuyển dụng của tổ chức/doanh nghiệp cần gọi điện thoại để thông báo cho ứng viên sau khi gửi thư mời tham dự phỏng vấn. 2-6 giờ sau khi gửi email thông báo, bạn có thể gọi để nhắc các ứng viên lần 1.
Mỗi mẫu thư mời đều phải được xây dựng trên một trình tự nội dung chuẩn. Ngoài ra, hình thức của mỗi thư mời cũng đặc biệt quan trọng. Tương tự như bất kỳ loại văn bản nào: sơ yếu lý lịch cho IT, đơn xin nghỉ việc,… thư mời phỏng vấn cũng được xem xét là loại thư mời cần thiết cho quy trình tuyển dụng.
Nó không đơn thuần là một bản thông báo có hiệu lực ngắn hạn được đính kèm trong email. Nó có ý nghĩa quan trọng đối với quy trình tuyển dụng. Nhờ có thư mời phỏng vấn, ứng viên có thể đánh giá sơ bộ tổ chức/doanh nghiệp của mình như thế nào.
Cùng TopDev điểm qua một số mẫu thư mời chuẩn nhất sau đây:
M1 – thư mờiM2 – thư mờiM3 – thư mời
Lời kết
Thư mời phỏng vấn là một trong những loại văn bản quan trọng. Ít người chú trọng đến nó những khi phân tích kỹ, thư mời interview có lại yếu tố chi phối đến mức độ ứng viên đồng ý tham gia buổi phỏng vấn cuối cùng. TopDev hi vọng với những chia sẻ, mọi người sẽ hiểu được tầm quan trọng của thư mời interview. Đồng thời, biết cách viết thư mời sao cho hiệu quả, hấp dẫn ứng viên; tạo ra sự kết nối tốt nhất đến với những ứng viên tiềm năng nhất.
Tuyển Dụng Nhân Tài IT Cùng TopDev Đăng ký nhận ưu đãi & tư vấn về các giải pháp Tuyển dụng IT & Xây dựng Thương hiệu tuyển dụng ngay!
Hotline: 028.6273.3496 – Email: contact@topdev.vn
Dịch vụ: https://topdev.vn/page/products
Bài viết được sự cho phép của tác giả Trần Thị Thu Hà
Sau vài ba năm chinh chiến trong nghề lập trình, chợt nhìn lại thấy đám bạn học cùng đại học giờ đã lên level Tech Lead rồi Manager, mình thì vẫn đi code dạo kiếm tiền. Cùng một xuất phát điểm, nhưng họ thành công hơn bạn. Thực tế, bạn chỉ đứng cách họ 7 bước chân thôi!
“Làm cách nào để thành công với nghề lập trình?” Một chút hài hước, dường như trong chính câu hỏi của các bạn, đã có câu trả lời. Sẽ chẳng có cách nào dễ dàng có thể biến bạn từ một người không biết gì về code trở thành một lập trình viên tài ba cả. Nếu có, thì chắc nó cũng nằm đâu đó trong “7 bước chân” topITworks sắp chia sẻ dưới đây. Quan trọng là bạn có sẵn sàng bước hay không?
Các bạn phải thừa nhận một điều rằng, trường học chỉ cung cấp các kiến thức cơ bản, họ đào tạo lý thuyết chứ không phải chuyên môn có thể giúp bạn trở thành một lập trình viên giỏi. Và đó là lý do hầu hết các lập trình viên giỏi khi còn trẻ không đốt thời gian bằng cách ngồi trên ghế nhà trường trong thời gian còn đi học. Hãy bước ra ngoài và tham gia một vài dự án product nhỏ để lấy kinh nghiệm thực tế. Sẽ có rất nhiều điều bạn cần phải học đấy.
Thực tế, đa phần các chương trình ở trường đại học đều gặp khó khăn trong việc theo kịp sự thay đổi của công nghệ. Trong 1 đến 3 năm đầu, một tấm bằng mà bạn mua được bằng tiền và thời gian có thể giúp bạn kiếm được một công việc giúp bạn đủ sống nhưng từ sau đó, bằng cấp sẽ chẳng tạo ra sự khác biệt nào cả. Các công ty không phải lúc nào cũng căn cứ vào tấm bằng, nhất là đối với những người đã ra trường được một thời gian.
Thế nên, nếu bạn muốn vứt tiền và thời gian vào những bằng cấp này thì tôi khuyên bạn đừng suy nghĩ nhiều về việc trở thành một coder giỏi!
2. Bắt đầu lại với những ngôn ngữ cơ bản nhất.
Nếu bạn muốn nâng cao khả năng code, hãy bắt đầu với những ngôn ngữ lập trình đơn giản nhất. JavaScript là lựa chọn tuyệt nhất cho những ai muốn hiểu sâu hơn về ngôn ngữ lập trình. Đây gần như là ngôn ngữ tiêu chuẩn của nền tảng web và cũng được sử dụng để viết các ứng dụng di động. Bạn thậm chí còn có thể sử dụng JavaScript để viết các ứng dụng cho robot, máy bay không người lái và trò chơi. Khi bạn đã thành thạo những ngôn ngữ cơ bản, việc nâng cao khả năng với các ngôn ngữ khó hơn chỉ còn là vấn đề thời gian.
3. Cách tốt nhất để học code là hãy code đi!
Ở những ngành khác, người ta chọn đọc nhiều sách để nâng cao trình độ chuyên môn. Điều đó đúng, nhưng không phải ở ngành công nghệ thông tin. Cho dù bạn có đọc 100 cuốn sách về lập trình và các ngôn ngữ đi chăng nữa, mà chẳng đụng tay đến máy tính coding lấy một dòng, thì tôi tin chắc rằng bạn sẽ chẳng bao giờ khá lên.
Điều tôi có thể khuyên bạn là : hãy đọc ít thôi và dành thời gian cho các bài luyện tập thực sự, từ đơn giản đến phức tạp. Thay vì đọc những câu chuyện từ sách vở, viết code sẽ giúp bạn nhớ lâu hơn và ở những lỗi sai, bạn mới thực sự hiểu bạn đang cần học thêm gì để giúp việc coding của mình khá hơn.
4. Học từ những người bạn.
Một trong những cách tuyệt vời nhất để học lập trình là xem cách người khác code và quan sát cách họ tư duy cũng như giải quyết vấn đề.
Tốt nhất là hãy tìm một người giỏi hơn bạn hoặc một người có cùng đam mê như bạn và thử lập trình cặp (pair-programming – hai lập trình viên cùng làm việc chỉ trên một máy tính). Tin tôi đi, một vấn đề dưới góc nhìn của mỗi người sẽ có cách giải quyết khác nhau, code cũng vậy. Bạn sẽ học được khá nhiều điều thú vị từ những người ấy. Chỉ cần một thời gian áp dụng, khả năng code của bạn sẽ tốt lên một cách bất ngờ. Đây cũng là cách mà hầu hết những lập trình viên trẻ trên thế giới áp dụng để nâng cao khả năng của mình trong một khoản thời gian ngắn.
5. Đọc và viết blog công nghệ.
Khi bắt đầu viết blog, tôi chắc chắn rằng, mình không là chuyên gia hàng đầu trong lĩnh vực mà tôi chia sẻ đến bạn đọc. Tôi thậm chí còn không thể chắc chắn rằng mọi thứ tôi viết đều đúng. Tôi mắc phải lỗi và nhận được phản hồi từ những người đọc. Nhưng cũng từ những phản hồi này tôi có thể nâng cao kiến thức và kỹ năng của mình. Chính việc chia sẻ những hiểu biết của mình cho cộng đồng tôi mới nhận ra rằng có những việc, nếu không bao giờ chia sẻ với mọi người, bạn sẽ chẳng biết được mình đã sai ở đâu mà cần thay đổi cả.
Mỗi tuần topITworks Blog của tôi có khoảng 3-5 bài viết mới, mỗi bài viết có trung bình khoảng gần 4,000 lượt quan tâm. Bạn có theo dõi hàng tuần không? Vài thứ hay ho bạn không muốn bỏ lỡ đâu: www.topITworks.com/blogs
6. Học bằng cách dạy người khác.
Nếu bạn đã là một lập trình viên thì tôi dám chắc chắn bạn cũng đã biết điều này: công nghệ thay đổi và những điều bạn biết ngày hôm nay có thể sẽ biến mất sau một tháng. Vì vậy việc cập nhật xu hướng công nghệ mới là điều hết sức cần thiết cho các lập trình viên. Và nếu bạn không phải là một người có trí nhớ siêu phàm thì khả năng bạn quên những thứ mới học được sau 1 vài tháng là điều khó tránh khỏi.
Thay vào đó, cố gắng truyền đạt cho ai đó những gì bạn biết là một cách tuyệt vời giúp bạn nhớ tốt hơn. Khi nói về những hiểu biết của mình bạn cũng sẽ tự mình đặt ra nhiều câu hỏi hơn cho bản thân. Và trong nhiều trường hợp bạn nhận ra được nhiều kiến thức “có vẻ” như bạn đã hoàn toàn hiểu trước đó lại là những thứ bạn cần phải đào sâu hơn.
7. Học nhiều hơn một ngôn ngữ lập trình.
Tôi đề xuất bạn đọc cuốn “Seven Languages in SevenWeeks” (tạm dịch: 7 ngôn ngữ trong 7 tuần). Học các ngôn ngữ với các triết lý khác nhau sẽ giúp bạn biết thêm nhiều hướng khi nghĩ về một vấn đề. Cởi mở tâm trí và mở rộng khả năng sáng tạo.
Tuy nhiên, hãy lên kế hoạch để tập trung vào JavaScript trước khi học thêm các ngôn ngữ khác nhé. Muốn giỏi một cái gì đó, hãy chắc rằng bạn đã hiểu rõ bản chất của nó.
Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
Một trong những công việc cuối cùng trong khâu thiết kế hệ thống sau khi đã hoàn thành khâu logical design là dự toán công suất vật lý của hệ thống để xem cần bao nhiêu máy chủ, (v)CPU, RAM, Disk, network bandwidth là bao nhiêu để hệ thống có thể hoạt động đủ mượt nhưng không quá nhàn rỗi dẫn đến lãng phí tài nguyên. Hiện nay với xu hướng người người, nhà nhà đi lên Cloud để tận dụng khả năng elastic, auto-scaling thì có vẻ là công việc này sẽ nhẹ nhàng hơn, nhưng lại có những challenge khác liên quan đến việc thiết kế ứng dụng để làm sao scale được. Trong phạm vi bài viết này, hãy cùng xem xét về góc cạnh dự toán công suất cho ứng dụng.
Khả năng xác định hoặc dự báo khả năng của một hệ thống hoặc tập hợp các thành phần, thường được gọi là ‘sizing’ của một hệ thống, là một hoạt động quan trọng trong thiết kế hệ thống. Một hệ thống với công suất quá khổ sẽ dẫn đến chi phí vượt trội về tài nguyên phần cứng, trong khi công suất quá thấp có thể dẫn đến giảm hiệu suất và không có khả năng để phục vụ mục đích của nó. Hãy tưởng tượng một nhà cung cấp thương mại điện tử sẽ hết bộ nhớ vào Black Friday hoặc một nhà cung cấp công cụ tìm kiếm phải trả gấp 20 lần chi phí cho công suất tối ưu của họ – cả hai kịch bản rõ ràng những nhà dự toán, kiến trúc sư phải xem xét kỹ hơn.
Lập kế hoạch công suất trong thiết kế hệ thống là nghệ thuật cũng như khoa học. Cùng với các tham số nhất định, nó cũng cần đến kinh nghiệm, kiến thức về lĩnh vực kinh doanh và kiến thức bên trong hệ thống. Trong một số trường hợp, chúng ta còn phải phân tích tâm lý của người của hệ thống, mô hình sử dụng của họ, v.v.
2. CÁC CHỈ SỐ HOẠCH ĐỊNH CÔNG SUẤT
Có nhiều phương pháp để thực hiện dự toán công suất. Bài viết này đề cập đến một số chỉ số tập trung vào cách các yếu tố như tính đồng thời, giao dịch mỗi giây (TPS), công việc được thực hiện trên mỗi giao dịch, v.v. Tất nhiên, nhiều yếu tố khác có thể xác định khả năng của một hệ thống, bao gồm sự phức tạp của các giao dịch, độ trễ và các cuộc gọi service bên ngoài, phân bổ và sử dụng bộ nhớ, v.v.
Cách tốt nhất là kiểm tra hiệu năng của hệ thống của bạn để xem liệu nó có hoạt động với công suất dự kiến hay không khi bạn đã thiết lập hệ thống theo phán đoán kế hoạch công suất, sau đó sẽ có những điều chỉnh kịp thời, lấy đó làm kinh nghiệm cho những lần lập kế hoạch tiếp theo.
Chúng ta hãy xem xét chi tiết một số các chỉ số này dưới đây.
2.1 THÔNG LƯỢNG (THROUGHPUT) VÀ TPS
Thông thường thông lượng được xác định là số lượng transaction được xử lý trong một khoảng thời gian nhất định. Thông lượng là thước đo số lượng hành động trên một đơn vị thời gian, trong đó thời gian có thể tính bằng giây, phút, giờ, v.v. TPS (Transaction Per Second) là số lượng giao dịch trên mỗi giây. Đối với một máy chủ stateless, đây sẽ là đặc điểm chính ảnh hưởng đến dung lượng máy chủ.
Về mặt lý thuyết, nếu người dùng thực hiện 60 giao dịch trong một phút, thì TPS sẽ là 60/60 TPS = 1 TPS. Tất nhiên, vì tất cả người dùng đồng thời đăng nhập vào hệ thống có thể không nhất thiết phải sử dụng hệ thống đó tại thời điểm nhất định, điều này có thể không chính xác. Ngoài ra, thời gian suy nghĩ, trì hoãn (think time) cũng nên được xem xét. Nhưng loại bỏ những điều trên, đây có thể được coi là trung bình 1 TPS khi người dùng truy cập thống nhất hệ thống trong hơn 60 giây.
2.2 CÔNG VIỆC ĐƯỢC THỰC HIỆN TRÊN MỖI GIAO DỊCH
Mỗi ‘giao dịch’ đến máy chủ sẽ có một số mức độ hoạt động để hoàn thành giao dịch đó. Điều này có nghĩa là CPU sẽ được kích hoạt để xử lý transaction bao gồm xử lý ứng dụng cũng như các hoạt động hệ thống như truy cập cơ sở dữ liệu, truy cập hệ thống bên ngoài, v.v. Nếu giao dịch đơn giản, điều đó có nghĩa là yêu cầu xử lý tương đối ít hơn so với giao dịch kích hoạt một tập hợp các hoạt động tiếp theo. Một sơ đồ trình tự của giao dịch sẽ giúp xác định các hoạt động thực tế có liên quan đến giao dịch.
2.3 THỜI GIAN SUY NGHĨ (THINK TIME)
Từ góc độ ứng dụng web, người dùng gửi yêu cầu, sau đó được xử lý ở phía máy chủ trước khi trả lại cho người dùng. Sau đó, người dùng thường chờ phản hồi và ‘xử lý, suy nghĩ’ trước khi gửi yêu cầu tiếp theo. Sự chậm trễ này là thời gian suy nghĩ của người dùng, rơi vào giữa các yêu cầu và có thể được tính đến khi tính toán tải hệ thống tối ưu. Đối với giao tiếp giữa máy với máy, thông số thời gian nghĩ này sẽ tương đối thấp hơn. Đối với lập dự toán công suất, thời gian suy nghĩ trung bình là hữu ích trong việc tính toán thông lượng chính xác.
2.4 NGƯỜI DÙNG TÍCH CỰC (ACTIVE USERS) VÀ ĐỒNG THỜI (CONCURRENT USERS HAY CCU)
Một hệ thống sẽ có tổng số người dùng – điều này có thể không ảnh hưởng trực tiếp đến công suất máy chủ, nhưng là một số liệu quan trọng trong việc định kích thước cho cơ sở dữ liệu. Trong tổng số nhóm người dùng này, một tập hợp con trong số họ sẽ là người dùng hoạt động – người dùng sử dụng hệ thống tại một thời điểm nhất định. Thông thường người dùng hoạt động đăng nhập vào một hệ thống, thực hiện một số thao tác và đăng xuất; hoặc họ chỉ để hệ thống hoạt động, đến lượt nó sẽ logout người dùng ra sau khi phiên hết hạn (thường trong 30 phút hoặc lâu hơn).
Hình 1: Users in Capacity Planning
Người dùng hoạt động đồng thời là số lượng người dùng riêng biệt truy cập đồng thời vào hệ thống tại bất kỳ thời điểm nào. Như trong ví dụ trong hình ở trên, người dùng đồng thời là một tập hợp con của những người dùng đang hoạt động đang sử dụng hệ thống tại một thời điểm nhất định. Nếu 200 người dùng hoạt động được đăng nhập vào hệ thống và có thời gian suy nghĩ 10 giây, thì đó sẽ là khoảng 20 người dùng đồng thời thực sự tấn công hệ thống. Trong dự toán công suất, điều này có một số ý nghĩa. Trong một máy chủ ứng dụng stateful với các session tương ứng cho từng user, số lượng người dùng đồng thời sẽ đóng vai trò lớn hơn việc xử lý stateless. Đối với các hệ thống được thiết kế theo cách như vậy, mỗi người dùng đồng thời tiêu thụ một số mức bộ nhớ cần phải được tính đến.
Thông thường, thông lượng của hệ thống tăng theo số lượng người dùng đồng thời cho đến khi đạt được công suất tối đa như trong Hình 2; từ đó trở đi hệ thống sẽ bị suy giảm hiệu năng. Do đó, điều quan trọng là phải tính toán số lượng user đồng thời tối đa mà một hệ thống có thể xử lý.
Hình 2: Server Performance – Throughput
2.5 KÍCH THƯỚC MESSAGE
Kích thước của message của các request cũng là một yếu tố quan trọng trong việc xác định dung lượng cần thiết của một hệ thống. Mesage với kích thước lớn hơn có nghĩa là yêu cầu năng lượng xử lý nhiều hơn, yêu cầu bộ nhớ nhiều hơn. Là một cơ sở để lập dự toán công suất, các kích thước message như bảng dưới đây nên được xem xét.
Message size range
Message size category
Less than 50 KB
Small
Between 50 KB and 1 MB
Moderate
Between 1 MB and 5 MB
Large
Larger than 5 MB
Extra Large
Hình 3: Message Sizes
2.6 ĐỘ TRỄ (LATENCY)
Độ trễ là thời gian bổ sung của hệ thống để thực hiện các thao tác. Các yêu cầu phi chức năng (Non-functional requirements – NFRs) của một hệ thống thường sẽ chỉ ra thời gian đáp ứng mong muốn của một giao dịch mà sau đó một hệ thống phải cố gắng đáp ứng. Xem xét ví dụ trong Hình 4, nếu một transaction đơn lẻ thực hiện một số lệnh gọi xuống cơ sở dữ liệu hoặc một tập hợp các lệnh gọi web service đồng bộ, transaction phải ‘chờ’ để nhận phản hồi. Điều này sau đó sẽ thêm vào thời gian phản hồi tổng thể của transaction.
Hình 4: Server Performance – Latency
Các kỹ thuật như bộ nhớ đệm có thể được sử dụng để cải thiện thời gian trễ.
Độ trễ thường là từ máy khách và cũng cần tính đến chi phí mạng / băng thông.
2.7 CÁC YÊU CẦU PHI CHỨC NĂNG KHÁC
Các yêu cầu về chất lượng dịch vụ (Quality of service – QoS), cùng với các yêu cầu phi chức năng khác, sẽ có ảnh hưởng đến cách bạn lập dự toán công suất. Ví dụ, nếu việc gửi message được đảm bảo (guaranteed delivery) hoặc việc truyền message an toàn (secure) là một yêu cầu bắt buộc, điều này sẽ ảnh hưởng đến hiệu suất chung của hệ thống và cũng cần phải được tính đến. Tương tự, nếu giải pháp với nhiều hệ thống với nhiều công suất khác nhau, thì cũng cần thực hiện một số điều chỉnh (throttling) giữa các hệ thống đó để tránh tình trạng thắt cổ chai (bottleneck).
Một khía cạnh khác cần được xem xét là tính sẵn sàng hoặc thời gian hoạt động của hệ thống. Về lý thuyết, tính khả dụng được xác định là tỷ lệ phần trăm khả dụng của hệ thống trong một năm. Lưu ý mặc dù tính khả dụng và thời gian hoạt động không đồng nghĩa – hệ thống có thể hoạt động, nhưng có thể không sẵn sàng để chấp nhận các yêu cầu, trong trường hợp đó hệ thống không khả dụng.
Thời gian chết (downtime) hệ thống được chấp nhận là một yêu cầu thực tế, thường được tìm thấy như một phần của các yêu cầu không chức năng. Điều này trực tiếp xác định làm thế nào một hệ thống có tính sẵn sàng cao cần thiết kế. Khi tính toán dung lượng, điều quan trọng là phải tính đến thời gian ngừng hoạt động theo kế hoạch, chẳng hạn như nâng cấp hệ thống và triển khai ứng dụng và thời gian ngừng hoạt động ngoài dự kiến, chẳng hạn như sự cố máy chủ.
Tính khả dụng của một hệ thống được xác định theo phương trình sau, mang lại kết quả tỷ lệ %.
x = (n – y) * 100 / n
trong đó ‘n’ là tổng số phút trong một tháng theo lịch nhất định và ‘y’ là tổng số phút dịch vụ không khả dụng trong một tháng theo lịch nhất định.
Với các khái niệm trên (Hình 5), doanh nghiệp cần quyết định thời gian dự báo là gì. Bạn chỉ tập trung vào năm thứ nhất? Liệu các yêu cầu về năng lực sẽ tăng gấp đôi trong năm thứ hai, và nếu vậy sẽ có một thời gian chết đáng kể vào cuối năm thứ nhất để đáp ứng điều này? Một bảng, chẳng hạn như bảng được đưa ra trong Hình 6, sẽ hữu ích cho việc dự báo và có thể dựa trên các xu hướng trong quá khứ và dự báo kinh doanh trong tương lai.
Bài viết được sự cho phép của tác giả Trần Khôi Nguyên Hoàng
WordPress là một CMS cực kỳ lớn và nổi tiếng. Đã số các blog đều sử dụng WordPress để cho tiện trong việc config và hosting. Bản thân cái blog của mình cũng sử dụng WordPress. Nhưng hôm nay thì mình đã chuyển toàn bộ nền tảng blog qua một CMS khác là Ghost. Và mình vừa chuyển qua nên mình làm cái review cho vui nhé.
Ủa? Nếu mà ít tinh năng hơn thì sao không xài WordPress đi, còn bày đặt chuyên platform làm chi vậy?
Tại mình thích
Thích là lý do chính mình chọn Ghost. Khi mỗi lần có ai đó muốn làm một blog cá nhân thì đa số mọi người đều gợi ý nên làm WordPress đi. Mình thì mình thích cái gì đó lạ lạ hơn, cái gì mà ít người làm thì mình làm. Và khi biết là có Platform này thì đã thử chuyển sang đây. Và để mình review một chút về Platform này nhé.
Điểm mạnh
Cài đặt đơn giản.
Nếu như với WordPress thì bạn cần một LAMP stack và source code WordPress thì với Ghost chỉ cần NodeJS là đủ. Ngay cả khi là nếu muốn deploy lên server thì nó vẫn đơn giản hơn WordPress.
Mình thì mình sử dụng 1 Click App của Digital Ocean nên cái nào với mình cũng như nhau. Có SSL các thứ luôn. Xịn xò con bò.
Không cần cài plugin
WordPress đã từng là một Blog Platform. Nhưng hiện tại thì không phải nữa mà nó có thể làm nhiều hơn là Blog. Chính vì vậy mình phải setup một số thứ để viết Blog. Ví dụ như cài Anti Spam, Yoast SEO, hay W3 Total Cache. Với Ghost thì không cần. Nó đã tự làm hết mọi thứ cho việc viết rồi. Mình lười trong chuyện tìm hiểu xem nên cài Plugin nào rồi Config ra làm sao lắm. Tốn thời gian mà không có lợi gì nhiều.
Phù hợp với IT blog
Ghost có một cái editor rất mạnh, gần giống như của Medium vậy. Nó cực kỳ phù hợp cho những bạn viết Blog nói chung và cực kỳ phù hợp cho các bạn viết Blog IT nói riêng. Lý do chính là các IT blogger có thể chèn code vào blog một cách đơn giản và đẹp. Điều mà bên WordPress không có hoặc phải cài thêm Plugin vào để có Syntax Highlighter. Nhưng dù có thì vẫn không thể ngon được bằng thằng Ghost. Bên cạnh đó tình năng chèn ảnh, chèn YouTube video, chèn codepen cũng ngon hơn WordPress rất nhiều.
Nhanh, rất nhanh
NodeJS và PHP so sánh về tốc độ thì khỏi phải bàn nhỉ. Blog mình hồi còn dùng WordPress thì chậm không tả được. Điểm số của Google PageSpeed Insights thì đâu đó được 9 hay 10/100 gì đó. Chả hiểu sao. Sau khi cài thêm mấy cái Plugin để Cache thì lên được 50 – 60/100. Còn với Ghost thì toàn 90 95/100 không à.
Toàn 99 100 thôi
Điểm yếu
Gõ tiếng việt rất sida
Ghost có một bộ editor ngon nhưng việc gõ tiếng việt rất là sida. Mình chưa thử trên Window thì như nào nhưng ở Ubuntu, Ibus Teni và Firefox thì không gõ được. Còn với Chrome thì gõ được nhưng vẫn sida lắm. Phải setup thêm Google Font thì mới tạm tạm gõ được một chút.
Không có Dashboard, Category cũng như khung comment mặc định
Ghost không hề có trang Dashboard dùng để thông kê lượt truy cập hay gì cả. Mình có thể sử dụng Google Analytic để xem nhưng cũng lằng nhằn lắm.
Một điều nữa là nó không có khung comment mặc định. Mình phải tự code thêm tính năng này hoặc dùng của bên thứ ba. Mà mình thì lười lắm. Cơ bản là cũng không có ai vào đọc mà comment ấy chứ :))
Một cái sida nữa là nó không có Category, mà nó quản lý chuyên mục bằng các thẻ Tag. Vì thế nên không có Menu đa cấp mặc đinh. Cũng phải tự code thêm.
Theme ít và rất đắt
Thằng này Theme rất ít, hơn nữa còn lại đắt dã man. Toàn mấy chục đô Trump thôi. Nên mình xài theme mặc định luôn. Thế là OK rồi.
Nhìn kho theme mà chán
Kết luận
Sau một vào giờ setup thằng này thì mình khá là hài lòng. Các bạn nào chưa viết blog thì bật máy và làm một cái blog đi thôi nào.
Chà, căng nhỉ lập trình viên biết test. Đã dev rồi còn test nữa thì nghe khá là căng. Hiển nhiên là mấy bạn mới ra trường hoặc có 1,2 năm kinh nghiệm chắc chắn sẽ từ chối hiểu. LOL
mà phân trần thì cũng có lý chứ không phải là không có lý.
Công ty tuyển tester vào làm gì mà đội dev phải test.
Nhiệm vụ là dev thì cứ dev thôi, test làm gì?
Hiểu, chắc chắn là hiểu cái lý do trình bày này. Nhưng thử phân tích thêm 2,3 cái lý do dưới đây. Nếu nghe xuôi tai thì test cũng còn chưa muộn.
1. Test không hẳn là một công việc nhàm chán
Thực sự thì test là tìm ra lỗi trong sản phẩm. Tiến hành khắc phục, hoặc bịt bug :). Nghĩ thoáng ra một tí thì test làm cho sản phẩm tốt hơn, hoàn hảo hơi.
Bản thân mình tìm thấy bug là một điều may mắn, khách hàng sẽ không bị crash, không gặp bug mà phải cau có mặt mày.
Đôi khi bản thân được gọi là “Software Engineer” – “Kỹ sư phần mềm”. Từ kỹ sư ở đây không khác gì kỹ sư xây dựng, kỹ sư cầu đường. Xây nhà lại để sập, xây cầu để cầu gãy?. Làm gì có chuyện đó đúng không?.
Để cầu không gãy, nhà không sâp thì ta cần ông giám sát công trình. Bên Software thì ta có chị QC, anh QA. Nhưng không cần chị QC, anh QA, bản thân SE cũng có thể test được. Vì vậy phải xác định trước, test là việc nên làm để đảm bảo chất lượng. BUG là niềm vui. Má, nghe nổi da gà.
Đùa chứ mấy anh lập trình viên biết test lại được đánh giá cao. Được tin tưởng giao task khó và bớt thời gian test do trong lúc dev đã test rồi
2. Test giúp nâng skill lập trình
Nhiều ông cứ bảo tôi điêu. Nhưng thử ra ngoài hỏi xem, có ông nào trình cao mà chưa đi fix bug khó không. Fix bug thực sự hữu ích, nâng skill rất nhanh. Nhanh bởi vì sao:
Fix bug đôi khi không phải chỉ hiểu một đoạn code, hiểu cả hệ thống.
Fix bug đôi khi liên quan tới cả business
Fix bug đòi hỏi phải hiểu rõ chức năng hiện tại, vấn đề tương lai
Đấy, fix bug nâng tầm, mà bug thì không phải từ test mà ra sao?. Các ông tìm được bug khi test -> nhớ -> lần sau sẽ chú ý dev kĩ hơn.
Một số trường hợp phát sinh bug. Bản thân Software Engineer có thể biết điều đó, nhưng tester thì không. Theo pattern đôi khi không thể cover hết tất cả các key.
Tôi còn gặp mấy ông code xong thách tester tìm bug, vì bản thân mấy ông đó biết là testcase không thể chạm tới bug đó.
Chính vì vậy, ngay lúc này bản thân Dev cần bắt tay vào test, hoặc ít nhất là nói với tester về khả năng có thể xảy ra case đó trong thực tế. Biết hoặc viết ra sẽ dễ hơn dể tìm và diệt bug.
Nếu cũng nghĩ về chất lượng sản phẩm thì sẽ gạt bỏ được bất đồng (đôi khi thôi)
Đấy, lập trình viên biết test hoặc có kinh nghiệm test cũng được được đánh giá cao hơn trong mắt nhà tuyển dụng.
4. Lập trình viên biết test được đánh giá cao
Trên đây là một số lý do tại sao lập trình viên lại nên test thử cho biết. Rõ ràng mà nói, test hay không test thì bug vẫn là thứ ảnh hưởng tới sản phẩm. Một số bug cơ bản tuy không chết ai. Nhưng nếu viết firmware cho thiết bị y tế có thể đi cả mạng người.
Rèn luyện kỹ năng test giúp Software Engineer có thể thực thụ trở thành một người Senior. Hiểu biết sâu sắc về nghề, tường tận quy trình phát triển phầm mềm. Nên anh em cố mà test nha!
5. Tham khảo
Còn có một trường phái viết test trường khi dev để đảm bảo cover hết case nữa cơ
Năm 2020 vừa qua là một năm thực sự khó khăn với nhiều quốc gia trên thế giới, do ảnh hưởng của dịch covid gây ra, ngành công nghệ thông tin cũng chịu ảnh hưởng không nhỏ, các công ty outsource cho Châu Âu, Nhật Bản đang ít các dự án dần vì dịch, một số công ty đã giảm lương và sa thải nhân viên, nên một số bạn lập trình viên cũng đang gặp khó khăn, tuy nhiên chúng ta đã bước sang năm 2021, thông tin về vắc xin cũng đang được thử nghiệm, chúc các đọc giả năm 2021 này sẽ gặp được nhiều thành công trong công việc cũng như trong cuộc sống.
Trở lại với loạt bài viết chia sẻ về quá trình bước chân vào con đường làm freelancer này, tôi sẽ chia sẻ về quá trình làm freelancer, nhận dự án, báo giá, các kiểu khách hàng gặp phải. Với bài khởi đầu này tôi sẽ nói tổng quan về vì sao tôi chọn làm freelancer, những lợi ích khi làm freelancer và khó khăn gặp phải.
Nếu mọi người đã đọc bài viết về tâm sự lập trình của tôi thì cũng biết ngoài công việc trên công ty thì tôi cũng làm freelancer vào buổi tối và cuối tuần. Lý do tôi chọn freelancer là vì ngoài kiếm tiền ra thì tôi cũng học hỏi được rất nhiều điều thú vị về các dự án, có thể ở công ty bạn chỉ làm những dự án theo kiểu rập khuôn và không đa dạng về nghiệp vụ. Nhưng với freelancer thì bạn sẽ nhận được nhiều yêu cầu mà có thể bạn chưa từng nghe bao giờ.
1. Freelancer là gì?
Nãy giờ nói lan man về freelancer, nhưng có thể có một số bạn chưa hiểu về khái niệm này, freelancer là một người làm công việc tự do, không gò bó bởi công ty, hoàn toàn kiểm soát thời gian làm việc của mình, hoàn toàn có thể chọn nơi làm việc mà mình thích. Freelancer có hai loại. Thứ nhất là làm freelancer toàn thời gian, loại này sẽ không làm ở bất cứ một công ty nào cả, chỉ nhận dự án và làm tự do. Loại thứ hai là làm ở một công ty nào đó, buổi tối và cuối tuần thì sẽ làm freelancer, tôi là loại thứ hai.
2. Lợi ích của làm freelancer là gì?
– Kiếm được tiền : Tiền thì chắc ai cũng cần để trang trải cuộc sống, đối với những người đã có vợ con thì lúc nào cũng sẽ cảm thấy thiếu tiền hoặc đối với những người chưa có nhà cửa ở các thành phố lớn thì cũng cần phải cày cuốc để kiếm tiền mua nhà, mua xe…
– Giúp nâng cao skill bản thân : Từ một thằng có skill kém nhưng từ khi làm freelancer thì đã tăng được nhiều kỹ năng về giải quyết vấn đề, kỹ năng search, kỹ năng phân tích và còn nhiều skill khác nữa. Công việc freelancer là làm việc độc lập, nên việc tự tìm hiểu nhiều thứ là điều tất nhiên, khi bạn tìm hiểu một vấn đề nào đó thì nó sẽ tích lũy dần theo năm tháng.
– Tăng tính tự giác : Việc tự học một ngôn ngữ, kỹ thuật nào đó thì sẽ rất lười biếng tuy nhiên khi đã làm dự án với khách hàng thật, lấy tiền thật thì việc tự giác tìm hiểu, học ngôn ngữ mới hay học thêm nhiều cái khác để đáp ứng nhu cầu công việc thì rất tự giác.
– Quản lý được thời gian công việc : Khi bạn làm freelancer bạn phải tự cân đo đong đếm thời gian làm để hoàn thành dự án và giao hàng. Việc này rất quan trọng vì vừa phải cân bằng được thời gian làm ở công ty vừa cân bằng được thời gian làm freelancer mà không làm hại sức khỏe là một bài toán khó.
3. Nhược điểm của freelancer
Ngoài những lợi ích đem lại thì khi bạn là một freelancer thì sẽ có những nhược điểm không mong muốn.
– Không được đi đâu chơi : Nếu làm freelancer có dự án liên tục thì việc đi chơi với người yêu, đi nhậu nhẹt với bạn bè là điều không thể, vì phần lớn thời gian bạn sẽ chạy dự án, khi đã ngồi vào bàn làm việc rồi thì việc ra ngoài là điều rất khó đối với các bạn lập trình viên.
– Mất ngủ, mệt mỏi, căng thẳng : Việc không quản lý được thời gian làm việc sẽ dẫn đến bạn phải thức đêm thức hôm để làm việc, dẫn đến mệt mỏi căng thẳng, stress, cáu gắt. Sức khỏe lúc này suy giảm.
– Những dự án thúi quắc : Đôi khi nhận dự án, báo giá xong tới khi làm thì mới phát sinh ra nhiều vấn đề, lúc này không thể báo giá lại được nữa và chấp nhận làm chịu lỗ.
– Bị xù tiền, chậm thanh toán : Vì một số lý do nào đó mà khách hàng không thanh toán phần còn lại của dự án hoặc châm thanh toán, có những dự án 5-6 tháng mới thanh toán xong.
Những lợi ích và nhược điểm khi dấn thân vào con đường freelancer ở trên mà tôi đã đúc kết được từ quá trình của mình, các bạn đã sẵn sàng đi vào con đường này hay chưa, bài viết tiếp theo tôi sẽ chia sẻ về dự án freelancer đầu tiên của mình, hãy đón đọc nhé.
Message Queue nôm na là Queue (hàng đợi), chứa Message (Tin nhắn) như hộp thư 😀 Và nó cho phép các thành phần/service trong một hệ thống (hoặc nhiều hệ thống), trao đổi thông tin cho nhau.
Ý nghĩa của queue (hàng đợi) là nó thực hiện việc lấy message theo cơ chế vào trước thì ra trước ( First In First Out ).
Một hệ thống Message Queue thường có những thành phần sau:
Message: Thông tin được gửi (có thể là text, binary hoặc JSON)
Message Queue: Nơi chứa những message này, cho phép producer và consumer có thể trao đổi với nhau
Producer: Service tạo ra thông tin, đưa thông tin vào message queue
Consumer: Service nhận message từ message queue và xử lý
Một service có thể vừa làm producer, vừa làm consumer
Trong các hệ thống dùng kiến trúc microservice, ta sử dụng message queue để giúp các service liên hệ với nhau một cách bất đồng bộ. Service X làm xong việc có thể gửi message queue để service Y kích hoạt xử lý.
Ví dụ: có một trang web cho phép người dùng tải video từ hệ thống thì nó sẽ có các thành phần sau:
API service: Là 1 producer. Nhận thông tin (URL Video) từ phía người dùng và đưa thông tin này vào message queue
Processing Service: Vừa là consumer vừa là producer. Service này đọc URL Video từ message queue, bắt đầu tải file Video về và encode lại, lưu vào server. Sau khi encode xong, nó đưa URL của file đã encode vào message queue
Uploading Service: Khi nhận được message từ processing server, nó sẽ upload video đó lên Amazon S3
Tại sao lại sử dụng Message Queue?
Ưu điểm về Message Queue
Dễ scaling hệ thống: Vào giờ cao điểm, nhiều truy vấn, ta có thể tăng số lượng consumer lên để xử lý được nhiều messege hơn. Khi không cần ta có thể giảm lại.
Phân tán hệ thống: Giúp phân tách hệ thống thành nhiều service nhỏ hơn, mỗi service chỉ xử lý 1 chức năng nhất định theo cấu trúc microservice.
Đảm bảo duration/recovery: Do message đã được lưu trong queue, khi 1 service đang xử lý nhưng bị crash, ta không lo bị mất data vì có thể lấy message từ trong queue ra và retry. Trong 1 hệ thống có nhiều consumer, nếu vài consume crash cũng không làm crash cả hệ thống
Hỗ trợ rate limit, batch process: Trong trường hợp khả năng xử lý của hệ thống có hạn (chỉ có thể xử lý 100 lượt release/s) mà phải xử lý 10000 lượt release. Với message queue, ta có thể lấy từng lượt release chưa xử lý trong queue ra xử lý từ từ, không sợ bị mất.
Điểm cần lưu ý về Message Queue
Làm hệ thống phức tạp hơn: Thêm message queue sẽ tăng tính phức tạp của hệ thống. Ta cần phải biết rõ message nào gửi vào queue nào, ai gửi ai nhận. Lúc debug ở local sẽ khó khăn hơn
Phải có Monitor Queue: Phải có các biện phát theo dõi (monitor), để đảm bảo lượng message queue không quá nhiều, làm đầy queue. Queue tốt nhất là queue luôn rỗng, hoặc số lượng message trong queue không tăng lên nhiều (message gửi vào queue đều bị consume hết trong thời gian ngắn nhất)
Phải có message format: Để gửi/nhận từ 2 phía producer và consumer thống nhất format với nhau. Nếu 1 bên thay đổi sẽ làm bên kia không đọc được dữ liệu.
Khó xử lý đồng bộ: Không phải hệ thống nào cũng cần tới message queue. Nếu như service A gọi service B, theo cơ chế đồng bộ, cần kết quả xử lý ngay, ta nên dùng Rest hoặc gRPC sẽ tốt hơn.
Report bug là công việc thường xuyên và liên tục của một người làm test. Nhưng đã bao giờ bạn nghĩ mình có thể làm gì để một bug report trở nên hoàn chỉnh, ngắn gọn cũng như thể hiện sự chuyên nghiệp và rõ ràng trong từng report được gởi ra cho Dev? Hay nói một cách khác bạn đã bao giờ nghĩ làm sao để viết một bug report tốt.
Miên tả ngắn gọn, thể hiện được lỗi. Tiêu đề tốt còn có thể giúp Dev biết được lỗi mà không cần xem các bước bên trong
Có thể sử dụng cấu trúc dạng: What…When/Where…. Thể hiễn lỗi trước sau đó đến vị trí của lỗi
Không nói chung chung
Ví dụ:
Good Title: Missing the username & password label at Login form
Good Title: [Authentication] The logout button does not clickable at Homepage
Bad Title: The logout button does not work
Bad Title: Something wrong with the register function
Mô tả lỗi (Summary)
Đây là nơi bạn có thể diễn tả rõ hơn về lỗi, không giống như tiêu đề bị gò bó bởi chiều dài, tại summary bạn có thể diễn tả dài hơn.
Tuy nhiên nếu lỗi đơn giản bạn có thể không cần ghì hoặc sao chép lại tiêu đề. Không nhất thiết phải cố gắng diễn tả dài dòng khi lỗi nó chỉ cần chừng đó thông tin là đủ.
Các bước tái tạo (Reproduce / Steps)
Các bước nên đánh thứ tự 1-2-3
Ngắn gọn, diễn tả một hành động, không nên ghi dài
Đảm bảo các bước đúng thứ tự và có thể tái tạo được
Ví dụ:
Enter admin email
Enter admin password
Click on change profile
Upload the photo with GIF format
Check the uploaded photo
Một số trường (field) thường gặp
Actual / Expected (Kết quả thật tế / Kết quả mong muốn)
Ngắn gọn
Thể hiện chính xác mong muốn trong phần expected.
Bad Expected: Change the text color
Good Expected: Change the text color to red (#E52121)
Bad Expected: Add the label to username
Good Expected: Add the label “Username” to the username field.
Một chú ý nhỏ nữa nhưng cũng góp phần quan trọng trong việc tạo cảm giác tốt cho dev là tránh ghi trực tiếp và đề cập đến con người trong đó.
Không nên: You need to fix the bug
Nên: The bug should be fixed
Không nên: Can you change the header text to bold?
Nên: The header text color should be in bold.
Các viết thứ hai sẽ không đề cập đến con người (You need, you must…) mà chỉ tập trung vào vấn đề.
Gợi ý:
Nên đính kèm ảnh, hình ảnh sẽ giúp Dev hiểu rõ vấn đề hơn, đôi khi không cần đọc các bước.
Hạn chế video: khá nặng và tốn nhiều thời gian để xem, chỉ dùng trong các lỗi phức tạp.
Phân biệt và dùng đúng mức độ priority và severity.
Không phải các bug đều được report bằng chữ, bạn có thể report và làm việc trực tiếp với Dev. Có nhiều lỗi bạn cần và cũng nên chia sẻ thông qua giao tiếp & làm việc nhóm.
Kiểm tra kĩ trước khi report, tránh report trùng hoặc không phải là lỗi.
Không nên gộp nhiều lỗi vào 1 report, mỗi report chỉ nên xử lý một vấn đề.
Mình rất muốn nghe chia sẻ thêm từ những kinh nghiệm của các bạn trong việc viết một bug report tốt và hiệu quả, nếu có gì muốn chia sẻ hay bổ sung các bạn để lại comment nhé!
Bài viết được sự cho phép của tác giả Nguyễn Văn Trọng
Nếu bạn đang đọc bài viết này thì chứng tỏ bạn rất quan tâm đến nghề và nghiêm túc trong con đường phát triển bản thân.
OK vậy tốt rồi ! tiếp theo đây mình xin chia sẻ 1 vài kỹ năng cần thiết mà 1 BrSE cần có, nếu bạn đang có thì hãy cố gắng trau dồi, còn nếu chưa … cũng đừng lo, cứ học từ từ sẽ được. Cách đây 5 năm mình cũng ngáo ngơ lắm cứ nhắm mắt làm chứ chả có định hướng gì, h đỡ hơn tí .. hihi. Vậy nên muốn viết ra cụ thể để các bạn xác định trước, sẽ đi đến đích nhanh hơn.
Có 3 kỹ năng chính cần thiết : cứng, mềm và ngoại ngữ.
Khi làm việc với khách hàng, tùy dự án sẽ cần có những nền tảng kỹ thuật khác nhau. Với nghề này các bạn đôi khi không được quyền lựa chọn.
Khách hàng chọn bạn chứ không phải bạn chọn khách hàng
Vậy nên hãy đầu tư cho mình kiến thức rộng về kỹ thuật (ngôn ngữ, framework …), kỹ năng design (basic design, detail design) và khả năng tự học. Vì sao cần có khả năng tự học ? đơn giản thôi, bạn phải nắm bắt thật nhanh hệ thống làm về ngôn ngữ gì, framework gì để lập ra các đối sách cũng như làm việc được ngay, không ai chờ đợi 1 vài tháng để mình học xong mới áp dụng.
1.Kỹ năng design – basic design và detail design
Design Process
Đối với khách hàng Nhật, tài liệu là thứ quan trọng nhất trong dự án. Nếu các bạn đã từng làm dự án với các bác Nhật thì cũng từng trải qua việc nhai tài liệu hàng chục đến hàng sheet excel như nhai cơm trắng trước khi code. Vậy nên trong quá trình này hãy để ý đến cách làm tài liệu, rút ra những ưu nhược điểm đúc kết thành kinh nghiệm để sau này viết ra cái đống ấy.
BASIC DESIGN (hoặc system design)
Hầu hết các dự án đều phải có basic design viết ra với đầu vào tài liệu đặc tả nghiệp vụ, basic design sẽ là tiền đề để tạo Detail Design sau này.
Với những dự án winform hay web ngoài mô tả chức năng xử lý thì cần phải có Prototype. Với những dự án không phải web thì prototype được tạo bằng excel (thông thường) hoặc 1 số tool chuyên dụng – đôi khi code luôn app mô tả thao tác (hardcode), còn dự án web thì ngoài exel để mô tả flow xử lý còn cần có html prototype. Vậy nên các bạn cần chuẩn bị những thứ sau :
Kỹ năng vẽ sơ đồ xử lý hay tạo form bằng excel
Html và css để create html prototype
Kỹ năng giải thích process bằng câu chữ (cái này hơi khó nên cần trau dồi qua kinh nghiệm dự án – đọc design)
Basic design tốt là mô tả đầy đủ - dễ hiểu các chức năng của hệ thống
DETAIL DESIGN
Với đầu vào là basic design, detail design được tạo ra sao cho – Nhìn vào là code được. Vậy nên cần phải trang bị cho mình những kiến thức về design pattern, ngôn ngữ – framework, cấu trúc dữ liệu. Về design pattern, nếu có thời gian tìm hiểu thì quá tốt còn nếu không thì sao ? hãy nắm vững nguyên lý SOLID để cho thiết kế hoàn hảo kẻo mấy anh em cu đơ chửi cho nát mặt “thằng nào design ngu vcd !!!”.
Ngoài ra, vì trong quá trình làm sẽ xảy ra việc làm nhiều cái tương tự nhau, ví dụ như mô tả Item screen – mapping item database. Vậy nên để tăng năng suất thì hãy tự tạo các tool gen tài liệu, mình thấy dùng macro excel là dễ và nhanh nhất – quan trọng là hiệu quả chứ không cần cầu kỳ đâu. Khách hàng sẽ nhìn bạn với con mắt “thán phục” nếu như bạn có 1 vài cái tool apply cho dự án
Tóm cái váy lại những gì cần :
Design pattern hoặc nguyên lý SOLID
Ngôn ngữ, Framework : để chọn cách làm tối ưu
Cơ sở dữ liệu : để biết cách tương tác dữ liệu sao cho hợp lý nhất
Tạo tool nâng cao năng suất – vd : excel macro
Detail design tốt là mô tả đầy đủ - tối ưu - dễ hiểu, nhìn vào code được ngay
2.Kỹ thuật – công nghệ
Tùy dự án sẽ áp dụng ngôn ngữ – framework khác nhau. Vậy nên hãy nắm THẬT CHẮC 1 ngôn ngữ và 1 framework, và nắm TỔNG QUAN 1 vài ngôn ngữ – framework phổ biến, để khi cần có thể rút ngắn thời gian đào sâu nghiên cứu.
Những ngôn ngữ – framework phổ biến (khách hàng Nhật)
Bonus : C++ nếu các bạn thích embedded (nhu cầu C++ để làm lập trình nhúng ở nhật cực kỳ cao), COBOL (ngôn ngữ củ chuối từ xa lắc lơ mà các bác JAV vẫn dùng ầm ầm)
Vì hiện tại có rất nhiều page khác viết về mảng công nghệ kỹ rồi nên mình không nói thêm ở đây nữa.
Kỹ năng mềm
75% thành công được quyết định bởi kỹ năng mềm
Vì sao cần ? thực ra dù làm vị trí nào thì kỹ năng mềm đều cần thiết cả, nhưng với nghề này thì cực kỳ quan trọng vì các bạn phải thường xuyên tiếp khách (tiếp xúc khách hàng – chứ ko phải bán thân :D) cũng như liên lạc thường xuyên với manager để báo cáo, PM để trao đổi tình hình dự án, Dev – giải thích nghiệp vụ, Tester – để bênh dev … giỡn chứ để đàm đạo lúc nghiệm thu sản phẩm. Đôi khi còn nhâm nhi vs cả QA hay BA nữa, nói chung là “quan hệ rộng” (rộng chứ không phải bừa bãi đâu nhé).
Hãy hòa nhã mới mọi người, cương nhu phối hợp nhịp nhàng
Cụ thể là gì ? Có hàng tá kỹ năng mềm các bạn có thể tìm thấy trong sách hay trên internet, ở đây mình chỉ liệt kê những cái thiết thực nhất đúc kết qua kinh nghiệm.
Biết lắng nghe
Nghe khách hàng, nghe phía nhà mình, là việc hằng ngày gặp phải. Nhưng nếu không LẮNG thì không NGHE được 1 cách đầy đủ và thấu hiểu. Nhớ nhé : lắng rồi mới nghe. Người Nhật đa số rất ghét kiểu đang nói mà bị chen ngang, hoặc là nói mà bị lơ.
Thuyết trình
Nói đúng hơn là cách trình bày vấn đề, nếu tiếng nhật không đủ lưu loát thì hãy viết ra những gì muốn nói theo trình tự. Có thể chọn 1 trong 2 cách trình bày :
cách 1 : Nêu bối cảnh hay tiền đề rồi sau đó đến điều cần nói.
cách 2 : Nói cái cần nói trước rồi sau đó là phần giải thích thêm.
Cách nào cũng được chỉ cần mạch lạc.
Làm việc độc lập
Chủ động, chủ động và chủ động. Tự lên kế hoạch công việc, báo cáo 2 bên định kỳ tình hình cho dù không được yêu cầu. Ngoài ra hãy ghi To-do list vào mỗi buổi sáng, và check lại vào cuối ngày xem đã hoàn thành đến đâu.
Giải quyết vấn đề
Mọi việc không phải khi nào cũng suôn sẻ, việc trễ deadline hay gặp khách hàng thay đổi requirement xoành xoạch cũng không hiếm. Vậy nên trong những trường hợp này nếu không có cách nào tốt thì hãy chọn cách đỡ xấu nhất. Năm ngoái mình đã gặp trường hợp dự án trễ liên tục vì design quá tệ hại, cũng may khách hàng hiểu vấn đề từ đầu (design họ làm mà) nên mình báo cáo hằng ngày cho họ biết chi tiết từng module bị trễ và số thời gian để hoàn thành, ban đầu thì khá căng thẳng nhưng cuối cùng cũng xong xuôi – phù phù. Viết đến đây thấy áy náy, nước mắt rưng rưng chảy dài trên gương mặt đập chai … nhớ lại hồi đấy để keep deadline mà bắt anh em trong team OT vs ON thấy bà nội luôn … tội lỗi ! tội lỗi.
Thực ra ngoại ngữ thuộc kỹ năng cứng nhưng mình tách ra thế này để nhằm mục đích nhấn mạnh. Dù bạn ở đâu, đang làm gì, bao nhiêu tuổi … không quan trọng bằng việc bạn có thực sự quyết tâm để hiểu được mấy em gái nhật nói gì, nhầm ! mấy bác khách hàng Nhật nói gì.
9 tháng từ Zero lên N2 ? tại sao lại không ? đã rất nhiều người làm được, nếu bạn không tin thì có thể hỏi bất kỳ 1 nhân viên công ty Fsoft là sẽ biết thực hư. trong 9 tháng này mọi người được học mỗi ngày 10 tiếng, vậy nên nếu học 1 ngày 3- 4 tiếng thì khoảng 2 năm là lên được N2 rồi.
5 phút dành cho quảng cáo :
Hiện tại công ty cũ Fsoft của mình có tuyển sinh kỹ sư cầu nối với chương trình 10K BrSE. Nếu các bạn quan tâm thì có thể đi theo hướng này cũng tốt. Chi phí hơi tốn kém chút nhưng đổi lại tiếng Nhật sẽ lên rất nhanh do được đào tạo bài bản ngay tại Nhật. Nếu muốn sau khi học xong làm được BrSE ngay thì các bạn hãy trau dồi kỹ năng cứng và mềm trước (mình viết ở trên) rồi học tiếng nhật sau thì sẽ có nhiều lựa chọn hơn.
Cảm ơn bạn đã đọc đến đây, bài dài quá trời đất. Nếu có gì sai sót hay cần bổ sung thì hãy comment ở bên dưới nhé.
Sau bao nhiêu bài chém gió linh tinh, bài giới thiệu chung về Postman này mới bắt đầu vào công cụ Postman. Nguyên nhân chính của việc ít bài là do mình bận và mình lười.
Postman là 1 công cụ để test API của cty Postdot Technologies được bắt đầu phát triển từ năm 2012. Hiện tại Postman có 3 phiên bản: Postman, Postman Pro (2016) và Postman Enterprise (2017). Mình mới sử dụng Postman phiên bản free nên mình chỉ giới thiệu phần này.
Ưu điểm:
– Dễ sử dụng, hỗ trợ cả chạy bằng UI và non-UI.
– Hỗ trợ viết code cho assert tự động bằng Javascript.
– Hỗ trợ cả RESTful services và SOAP services.
– Có chức năng tạo API document.
Nhược điểm:
– Những bản tính phí mới hỗ trợ những tính năng advance: Làm việc theo team, support trực tiếp…
2. Cài đặt Postman
Postman cho phép người dùng cài đặt dưới 2 hình thức: tool cài vào máy và Chrome Apps.
Thông tin Account: dùng để Login, logout và sync data.
Settings tùy chỉnh: themes, shortcut, format…
Import data từ ngoài vào
Collections: lưu trữ thông tin của các API theo folder hoặc theo thời gian.
API content: hiển thị nội dung chi tiết API và các phần hỗ trợ giúp thực hiện test API. Đây là phần mà tester phải làm việc nhiều nhất.
Trong phần này gồm có 3 thành phần chính:
Environments: Chứa các thông tin môi trường. Ví dụ: mình làm 1 dự án nhưng có 3 môi trường khác nhau: dev, staging và product. Có phần này, mình có thể nhanh chóng đổi sang môi trường cần test mà không phải mất công đổi URL của từng request. (Cái này sẽ được nói rõ hơn ở những bài sau)
Response: Chứa các thông tin trả về sau khi Send Request.
Phần giới thiệu chung đến đây là kết thúc, bài sau mình sẽ bắt đầu thử với những API đầu tiên.
Bài viết giới thiệu chung về Postman này được đăng lần đâu tiên tại http://giangtester.com/. Bạn có thể download ebook API Testing với Postman của mình ở đường link này.
Bài viết được sự cho phép của BBT Tạp chí lập trình
“Niềm tin sẽ làm nên suy nghĩ của bạn, Suy nghĩ đó sẽ làm nên lời nói của bạn, Lời nói đó sẽ làm nên hành động của bạn, Hành động đó sẽ làm nên thói quen của bạn, Thói quen đó sẽ làm nên giá trị của bạn, Giá trị đó sẽ làm nên số phận của bạn.”
— MAHATMA GANDHI —
Hãy bắt đầu từ thái độ
Chúng ta có thể gặp những người ngoài 60 tuổi vẫn rất chịu khó học hỏi, những cụ 70 vẫn lọ mọ học máy tính để chat với con cháu ở xa. Họ là ví dụ của những người có mô thức phát triển (growth mindset, chữ của nhà tâm lí học Carol Dweck ở đại học Stanford). Những người này không để tuổi tác đè nặng, họ học hỏi không ngừng, thích chinh phục những thử thách, thấy khó tìm cách vượt qua, mỗi cơ hội làm việc được tận dụng để hoàn thiện chính mình, luôn coi các chỉ trích hướng vào mình như là cơ hội học tập, và vui mừng khi thấy sự thành công ở người khác. Đây là mẫu tư duy thường gặp ở những người thành công trong các lĩnh vực học thuật, kinh doanh, hay nghệ thuật.
Ngược lại, lại có những người không thích các thử thách, thấy khó khăn là chùn bước, thấy phê phán là phản ứng tức thì, thấy việc làm là ngại, thấy người khác thành công thì ghen tị. Họ được xếp vào những người có mô thức đông cứng (fixed mindset). Sự khác biệt giữa hai mô thức nằm ở thái độ đối với các mục tiêu trong cuộc sống, trong cách thức phản hồi với thử thách và thất bại, niềm tin về nỗ lực và chiến lược, cũng như thái độ với sự thành công của người khác.
Các nghiên cứu về não bộ gần đây cho thấy tính “mềm dẻo” của não người là rất lớn, và nó có thể thay đổi từ tấm bé cho tới lúc già. Số lượng tế bào thần kinh có thể không tăng, nhưng cơ cấu tổ chức não bộ với những kết nối phức tạp giữa các tế bào đó thì thay đổi luôn luôn. Ngay cả những công nghệ như Internet, Facebook, Google cũng khiến cho hoạt động của não bộ thay đổi đến ngạc nhiên; điều này được Nicolas Carr bàn kĩ trong cuốn “Trí tuệ giả tạo” bán chạy. Từ nghiên cứu về mô thức (Mindset) của Carol Dweck,chúng ta có thể rút ra được kết luận hết sức quan trọng là con người hoàn toàn có thể phát triển trong suốt cuộc đời. Cách phân biệt mô thức đông cứng và mô thức phát triển đặt nền móng khoa học vững chắc cho niềm tin về việc học tập suốt đời và sự làm chủ cuộc đời cho những người làm giáo dục-đào tạo trên toàn thế giới. Nó cũng giúp ta chọn lựa một thái độ tích cực và chủ động đối với các nỗ lực vươn tới thành công và hạnh phúc.
Thói quen hoạt động như thế nào
Có thái độ thôi chưa đủ, chúng ta phải hành động, và còn phải tạo lập các thói quen tốt. Một nghiên cứu ở Đại học Duke cho thấy 40% hoạt động của chúng ta hằng ngày thuần túy là do thói quen chứ không phải do suy nghĩ thấu đáo. Con số đó cho thấy tầm ảnh hưởng rất lớn của những việc lặp đi lặp lại theo kiểu “phản xạ có điều kiện” này.
Khi đã có thói quen, chúng ta lặp lại các phản xạ trước các tính huống của cuộc sống mà không phải suy nghĩ nhiều. Điều đó có nghĩa là nếu thói quen tốt và được rèn luyện tốt, thì trong phần lớn các tình huống lặp đi lặp lại ấy, chúng ta đang sử dụng cách làm tốt, mang lại kết quả tốt, mà không phí sức. Ngược lại, nếu thói quen xấu, nó sẽ vô tình chung ảnh hưởng tới kết quả mà chúng ta cũng không để ý, cho tới khi sự việc đã muộn rồi.
Tác giả Charles Duhlgg của cuốn sách bán chạy “Sức mạnh của thói quen” dẫn các nghiên cứu khoa học cho biết, sở dĩ chúng ta hình thành các thói quen vì não chúng ta muốn được giảm tải. Ví dụ như khi chúng ta mới học lái xe, đầu óc sẽ suy tính rất mệt mỏi, đạp ga thế nào, phanh thế nào, tay giữ vô lăng chặt như thế có được không, v.v. Nhưng qua thời gian luyện tập, chúng ta hầu như không còn phải nghĩ nhiều về những việc này nữa, chúng
ta hoạt động theo thói quen, và não thì rảnh để quan sát đường, và suy nghĩ về những việc khác khi lái xe.
Thói quen được hình thành theo một chu trình ba bước: Bước Kích hoạt có tác dụng khởi động não bộ vào trạng thái tự động và lựa chọn thói quen để sử dụng; bước Hoạt động (có thể là hoạt động thể chất, tinh thần, cảm xúc); và cuối cùng là Phần thưởng cho những hành động vừa trải qua (phần thưởng này có thể là sự khoan khoái, hoặc được ngợi khen, hoặc bằng những vật có giá trị). Não bộ sẽ đánh giá phần thưởng để xem xét khả năng lưu giữ lại hoạt động đó để lặp lại khi có kích hoạt tương tự. Sự liên hệ Kích hoạt với Phần thưởng sẽ giúp não bộ phát triển cảm giác kì vọng, từ đó dẫn đến hình thành thói quen. Khi được lặp đi lặp lại, chu trình “Kích hoạt, Hoạt động, Phần thưởng” sẽ được tự động hóa, và chúng ta có thói quen.
Bạn không thể bỏ thói quen xấu, nhưng có thể tạo thói quen mới. Nguyên tắc vàng để thay đổi thói quen là giữ nguyên phần Kích hoạt và Phần thưởng, chỉ thay đổi phần Hành động. Lặp đi lặp lại, ta sẽ có thói quen mới. Đây là cách thay đổi thói quen phổ biến và rất hữu hiệu.
Cần 66 ngày để có một thói quen mới
Một nghiên cứu gần đây đăng trên Tạp chí Tâm lí học xã hội Châu Âu cho thấy, trung bình bạn cần 66 ngày để hình thành một thói quen. Trong 66 ngày đó bạn sẽ phải làm đi làm lại điều bạn muốn nó trở thành cơ hữu với con người bạn, sẽ thành “phản xạ” ngay cả khi bạn không còn nghĩ gì về nó nữa. Dĩ nhiên 66 là con số trung bình, con số cụ thể sẽ phụ thuộc vào nhiều yếu tố khác như tính chất của thói quen bạn định hình thành, cá tính của bạn, và cả điều kiện mà bạn đang có. Nhưng con số này cho thấy, để tạo lập thói quen, bạn cần một sự kiên trì đáng kể. Đó là lí do vì sao các chuyên gia về thói quen khuyên chúng ta cần tạo lập sự liên kết chặt chẽ giữa phần Kích hoạt với Phần thưởng để liên tục duy trì động lực khi thực hành thay đổi thói quen.
Hình thành thói quen làm việc hiệu quả dựa trên Scrum
Một trong điểm mạnh cơ bản nhất của Scrum, một phương pháp Agile phổ biến nhất, chính là giúp bạn có một thói quen làm việc tốt: tính toán kĩ khi bắt đầu công việc, lập kế hoạch khả thi và linh hoạt, kiểm soát công việc liên tục, đánh giá cẩn thận kết quả đạt được và cải tiến liên tục. Các bước đó được sắp đặt và kết hợp logic với nhau, lặp đi lặp lại để sớm hình thành nếp nghĩ, nếp làm việc một cách khoa học và hiệu quả. Scrum không chỉ giúp bạn sớm nhìn ra hiệu quả công việc, vui sướng ngay trong khi làm việc, mà còn duy trì một thói quen tốt.
Tác giả của Scrum, tiến sĩ Jeff Sutherland đã từng viết trên blog cá nhân và trong cuốn sách “Scrum: Nghệ thuật làm được gấp đôi chỉ trong một nửa thời gian” về những câu chuyện thành công trong sử dụng tư duy Scrum vào mọi mặt của đời sống, từ việc dạy học ở trường phổ thông, đến việc marketing, hay tổ chức công việc hằng ngày ở nhà thờ. Chúng ta gọi thói quen này là Scrumlife, để chỉ việc áp dụng tư duy Scrum vào hình thành thói quen
làm việc hằng ngày cho thật tốt.
Hãy bắt đầu Scrumlife đơn giản như thế này:
Chúng ta sẽ khởi đầu tuần làm việc bằng việc lập kế hoạch, gồm 2 bước: xác định việc cần làm, và cách để hiện thực hóa việc cần làm.
Xong rồi ta cập nhật các công việc đó lên Bảng công việc (kanban board), bắt đầu làm những việc có độưu tiên cao hơn, dần dần cho tới hết. Mỗi ngày ta thực hiện 15 phút DailyScrum để tự theo dõi tiến độvà thích ứng với các tình huống thay đổi.
Cuối tuần ta rà soát lại xem đã làm việc gì, so với dự kiến trong kế hoạch đầu tuần thì hoàn thành được bao nhiêu phần trăm, so với tuần trước thì thế nào?
Cuối cùng, ta suy nghĩ về cách làm việc , có ổn không, cần cải tiến gì không. Hãy cố gắng rút ra ít nhất một điều cải tiến, để tuần sau làm tốt hơn. Lưu ý đây là cải tiến cách làm; ví dụ, nếu tuần rồi ta viết thư điện tử cho sếp mà quên không đính kèm file, dẫn đến sếp bực mình, và đây là lỗi lặp lại lần thứ 3 rồi, thì ta có thể kĩ đến cách thức viết thư mới (ví dụ: đảo ngược quy trình viết thư: Đính kèm đầu tiên, rồi mới viết tiêu đề, rồi viết nội dung, cuối cùng là đọc lại và thêm phần To và gửi cho sếp).
Cách làm này áp dụng cho 1 tuần làm việc hăng say và duy trì sự hiệu quả liên tục. Nhưng bạn cũng có thể áp dụng tư duy ấy cho mỗi ngày làm việc với cấu trúc tương tự.
Trước khi bắt đầu thực hiện thói quen này, hãy nghĩ về mối liên hệ Kích hoạt – Phần thưởng. Phần thưởng cho việc hình thành thói quen này là gì? Bạn hãy nghĩ về những mối bận tâm thường trực khi làm việc: Bạn bắt đầu và kết thúc công việc trong tuần thế nào? Năng suất ra sao? Có hiệu quả không? Có thành tựu không? Có thấy vui sướng khi làm việc không? Và lưu ý, hãy tự thưởng cho mình, hoặc tìm kiếm các phần thưởng từ bên ngoài (từ Sếp, từ gia đình, bạn bè …) khi bạn hoàn thành tốt công việc. Nó không chỉ là cơ chế duy trì động lực tạo thói quen, mà còn là sự tận hưởng cuộc sống.
Nếu bạn thực hành Scrum được 2 ngày và thấy hơi gò bó, thì xin chúc mừng bạn, bạn đang trong quá trình hình thành một thói quen mới. Nhưng hãy nhớ, bạn còn khoảng 64 ngày nữa. Cứ lặp đi lặp lại sẽ hình thành một nhịp làm việc và sinh hoạt đều đặn, dần trở nên tự nhiên và phát huy tác dụng. Hãy thử vài tuần đi, bạn sẽ thấy rất nhiều điều bất ngờ đấy.
Bạn có biết: Scrum từng được đề nghị trao giải Nobel về quản trị?
Đó chính là giải (không có thật) được trao bởi một cây viết quen thuộc trên tạp chí nổi tiếng Forbes, Steve Denning, cho hai ông Ken Schwaber và Jeff Sutherland vì đã có công phát minh ra phương pháp tổ chức công việc nổi tiếng Scrum làm thay đổi thế giới phần mềm trong hơn một thập kỉ qua.
Chuyện giải Nobel là do ông Denning “bịa” cho vui, nhưng để nhấn mạnh sự hiệu quả nổi bật mà Scrum có thể mang lại cho các nhóm làm việc trên khắp thế giới.
Trong một bài viết năm 2011, Denning tóm tắt 10 đặc điểm của Scrum (có thể không giống cách nói của chính các tác giả của Scrum):
Tổ chức công việc theo các chu trình ngắn (gọi là phân đoạn)
Khi nhóm làm việc của họ trong các chu trình ngắn này, cấp quản lí không can thiệp (tức nhóm được trao quyền tối đa)
Nhóm báo cáo trực tiếp cho khách hàng, không phải cho nhà quản lí 4. Nhóm ước tính thời gian để hoàn thành công việc.
Nhóm quyết định khối lượng công việc để làm trong phân đoạn 6. Nhóm quyết định cách hoàn thành công việc trong phân đoạn.
Message Queue nôm na là Queue (hàng đợi), chứa Message (Tin nhắn) như hộp thư. Và nó cho phép các thành phần/service trong một hệ thống (hoặc nhiều hệ thống), trao đổi thông tin cho nhau.
Message queue nhận message từ một application và cung cấp chúng cho một hoặc nhiều application khác theo cơ chế vào trước thì ra trước ( First In First Out ).
Nếu API A cần gửi thông tin cập nhật trạng thái tới các API B và C, thì message queue được thiết lập riêng cho B và C.
A sẽ gửi các message riêng biệt cho mỗi queue và mỗi API nhận sẽ đợi và nhận messgae từ queue được thiết lập riêng, sau khi gửi message thành công thì message sẽ bị khử khỏi queue.
Lúc A gửi message thì cả B và C đều không cần có sẵn để nhận message. Message queue luôn hoạt động, vì vậy nếu một API nhận bị khởi động lại, thì nó sẽ bắt đầu kéo message từ queue riêng của nó khi nó trở lại trực tuyến.
Điều này giúp phá vỡ sự phụ thuộc giữa các hệ thống và cung cấp khả năng mở rộng và khả năng chịu lỗi lớn hơn cho các API.
MESSAGE BUS
Message Bus work flow
Message bus còn được gọi Service Bus.
Message Bus cung cấp phương thức để một hoặc nhiều application giao tiếp message đến một hoặc nhiều application khác.
Message Bus không đảm bảo cho việc vào trước xuất trước. Người nhận (Subscribers) đã đăng ký Message Bus có thể nhận message được publish mà không biết về người gửi (Publisher or Sender).
Một số Message Bus được dùng hiện nay:
Commercial
IBM Integration Bus
IBM WebSphere ESB
InterSystems Ensemble
Information_Builders iWay Service Manager
Microsoft Azure Service Bus
Microsoft BizTalk Server
Mule ESB
Oracle Enterprise Service Bus
Progress Software Sonic ESB (acquired by Trilogy)
SAP Process Integration
TIBCO Software ActiveMatrix BusinessWorks
webMethods enterprise service bus (acquired by Software AG)
Sonic ESB from Aurea
Open source
Apache Camel
Apache ServiceMix
Apache Synapse
Fuse ESB from Red Hat
JBoss ESB
NetKernel
Open ESB
Petals ESB
Spring Integration
UltraESB
WSO2 ESB
Architectural scenarios
Nếu API A truyền thông tin cập nhật trạng thái cho API B thông qua một Bus.
Sau đó, API C cũng có thể hưởng lợi từ những cập nhật này. Ứng dụng C có thể được cấu hình để listen Bus và thực hiện hành động dựa trên các cập nhật này mà không cần bất kỳ yêu cầu cập nhật nào từ API A.
Không giống như Message queue, API gửi message vào queue cho tất cả các API nhận, Message bus sử dụng mô hình Publisher / Subscribers.
Message được API gửi publish lên Bus thì bất kỳ API nhận nào đã subscribe loại tin nhắn nào thì sẽ nhận được message tương ứng.
Cách tiếp cận này cho phép các API tuân theo nguyên tắc Open/Closed, vì chúng trở nên mở đối với các thay đổi trong tương lai trong khi vẫn đóng để sửa đổi bổ sung.
Để giúp các API developer hiểu được nên sử dụng phong cách thiết kế API nào, trong ngữ cảnh nào. Hãy cùng xem xét REST, GraphQL, gRPC và Webhooks, phân tích điểm mạnh và điểm yếu của chúng để ap dụng cho đúng vào từng trường hợp.
Có thể nói nguyên lí REST và cấu trúc dữ liệu RESTful được biết đến rộng rãi trong giới lập trình web nói chung và lập trình ứng dụng nói riêng.
Bản thân REST không phải là một loại công nghệ. Nó là phương thức tạo API với nguyên lý tổ chức nhất định. Những nguyên lý này nhằm hướng dẫn lập trình viên tạo môi trường xử lý API request được toàn diện.
REST (REpresentational State Transfer) là một dạng chuyển đổi cấu trúc dữ liệu, một kiểu kiến trúc để viết API. Nó sử dụng phương thức HTTP đơn giản để tạo cho giao tiếp giữa các máy. Vì vậy, thay vì sử dụng một URL cho việc xử lý một số thông tin người dùng, REST gửi một yêu cầu HTTP như GET, POST, DELETE, vv đến một URL để xử lý dữ liệu.
RESTful API là một tiêu chuẩn dùng trong việc thiết kế các API cho các ứng dụng web để quản lý các resource. RESTful là một trong những kiểu thiết kế API được sử dụng phổ biến ngày nay để cho các ứng dụng (web, mobile…) khác nhau giao tiếp với nhau.
Chức năng quan trọng nhất của REST là quy định cách sử dụng các HTTP method (như GET, POST, PUT, DELETE…) và cách định dạng các URL cho ứng dụng web để quản các resource. RESTful không quy định logic code ứng dụng và không giới hạn bởi ngôn ngữ lập trình ứng dụng, bất kỳ ngôn ngữ hoặc framework nào cũng có thể sử dụng để thiết kế một RESTful API.
Hiện tại với API thì quá phổ biến cho các ứng dụng từ giao tiếp client tới server hay từ instance tới instance. Tuy nhiên ngày nay công nghệ càng ngày càng phát triển với http2 ra đời đã kéo theo 1 loạt những thay đổi để cải thiện performance, gRPC là sự kết hợp của Protocol Buffers và http2, Protocol Buffers được phát triển bởi google nó nhẹ hơn, nhanh hơn và cung cấp hiệu năng tốt hơn so với sử dụng XML hoặc Json
gRPC là một RPC platform được phát triển bởi Google nhằm tối ưu hoá và tăng tốc việc giao tiếp giữa các service với nhau trong kiến trúc microservice. gRPC cũng cho phép định nghĩa cấu trúc của data dưới dạng file protoc và nó tự động generate ra file sử dụng để giao tiếp với ngôn ngữ mà bạn sử dụng. gRPC hiện tại cũng đã hỗ trợ khá đầy đủ các ngôn ngữ như C++, Java, Python, Go, … các bạn có thể tham khảo thêm ở đây https://grpc.io/docs/
gRPC dùng Protocal Buffer giảm kích thước request và response data, RPC để đơn giản hoá trong việc tạo ra các giao tiếp giữa các service với nhau, HTTP/2 để tăng tốc gửi/nhận HTTP request.
RPC
RPC là từ viết tắc của Remote Procedure Call, nó được xây dựng với ý tưởng là đơn giản hoá việc giao tiếp giữa những service với nhau, thay vì những service giao tiếp với nhau theo kiểu RESTful API thì giờ đơn giản là gọi hàm như những object nói chuyện với nhau thôi, còn việc phân tán các service là chuyện của tương lai không dính liếu đến việc code.
PROTOCAL BUFFER
Protocal Buffer là một ngôn ngữ trung lập để serializing structured data sử dụng cho việc giao tiếp giữa các service với nhau. Protocal Buffer được tạo ra với ý tưởng là làm nhỏ kích thước data truyền đi trong giao tiếp và chỉ cần định nghĩa một lần và sử dụng cho các service với các ngôn ngữ lập trình khác nhau.
HTTP/2
HTTP/2 là một phiên bản nâng cấp của HTTP/1.1, HTTP/2 sinh với với mục đích cải thiện tốc độ giao tiếp giữa client/server trên nền tảng Web.
Vậy những ưu điểm rất lớn của RPC, Protocal Buffer, HTTP/2 sẽ gói trong gRPC
GraphQL là một Graph Query Language được dành cho API. GraphQL bắt đầu từ ông lớn Facebook, thế nhưng ngay cả những app đơn giản đôi khi vẫn gặp phải trường hợp “nghẽn cổ chai” do sự hạn chế của REST APIs. Và hiện tại nó được duy trì bởi rất nhiều công ty lớn, và mọi cá nhân trên khắp thế giới. GraphQL từ khi ra đời đã gần như thay thế hoàn toàn REST bởi sự hiệu quả, mạnh mẽ và linh hoạt hơn rất nhiều. Thường được dùng để load data từ một server cho client. GraphQL bao gồm 3 điểm đặc trưng bao gồm cho phép client xác định chính xác những gì dữ liệu họ cần, làm cho việc tổng hợp dữ liệu từ nhiều nguồn dễ dàng hơn và nó sử dụng một type system để mô tả dữ liệu.
Vấn đề mà REST đang gặp phải là nó việc phản hồi dữ liệu của REST trả về quá nhiều hoặc là quá ít. Trong cả 2 trường hợp thì hiệu suất của ứng dụng đều bị ảnh hưởng khá nhiều. Giải pháp mà GraphQL đưa ra là cho phép khai báo dữ liệu nơi mà một client có thể xác định chính xác dữ liệu mà mình cần từ một API.
GraphQL có 1 hệ thống riêng dành cho nó được sử dụng để xác định schema của một api. Tất cả type được liệt kê trong một API thì được viết trong schema thì sử dụng GraphQL Schema Definition Language (SDL). Schema này được dùng như là một bản giao dịch giữa client và server để xác định client có thể truy cập dữ liệu như thế nào. Sau đó team frontend có thể mock data để kiểm tra các component, song song đó team back-end cũng chuẩn bị công việc cần thiết cho phía server.
GraphQL sử dụng việc nạp dữ liệu khác với REST. Nó chí có duy nhất 1 single endpont và hoàn toàn phụ thuộc vào client để xác định những dữ liệu cần thiết. Vì thế client phải chỉ ra các trường cần thiết
Trong GraphQL viêc gửi các queries được gọi là mutations. Các mutation này có 3 loại là CREATE, UPDATE và DELETE. Mutation cũng có cú pháp giống như Fetching Data(Query). Nhưng mutation luôn bắt đầu với một từ khóa.
Một yêu cầu quan trọng khác đối với nhiều ứng dụng đó chính là realtime, để có thể kết nối đến máy chủ để có được thông tin về các event ngay lập tức. Trong trường hợp này, GraphQL cung cấp các khái niệm gọi là subscriptions. Khi 1 client subscriptions một event, nó cũng bắt đầu và giữ các kết nối đến server. Bất cứ khi nào sự kiện đó xảy ra, server sẽ đẩy dữ liệu tương ứng đến client.
Web hook là một cách cực kỳ hữu ích và tương đối dễ dàng, gọn nhẹ trong việc triển khai các phản ứng sự kiện. Các web hook cung cấp một cơ chế trong đó một ứng dụng server-side có thể thông báo cho một ứng dụng phía client-side khi một sự kiện mới (mà ứng dụng client-side có thể quan tâm) đã xảy ra trên máy chủ.
Webhooks đôi khi còn được gọi là “Reverse APIs”. Trong các API, ứng dụng client-side sẽ gọi (tiêu thụ) ứng dụng server-side. Trong khi đó, khi có web hook, phía server-side sẽ gọi web hook (end-point URL được cung cấp bởi ứng dụng client-side), ví dụ: ứng dụng server-side gọi ứng dụng client-side.
Webhooks hoạt động dựa trên khái niệm về phản ứng sự kiện- “event reaction” (đừng gọi cho tôi, tôi sẽ gọi bạn nếu tôi có tin gì mới). Nhờ vậy, ứng dụng client-side sẽ không cần phải liên tục hỏi ứng dụng server-side.
Do đó, thay vì ứng dụng client-side phải liên tục thăm dò ứng dụng server-side để kiểm tra các sự kiện mới, ứng dụng server-side sẽ gọi ứng dụng client-side (bằng cách gọi URL webhook từ client cung cấp) bất cứ khi nào server-side có thông tin gì mới để báo cáo cho client.
SO SÁNH REST, GRAPHQL, WEBHOOKS, AND GRPC
Đối với ứng dụng thì internal bên trong có thể xài gRPC, 1 vài cái integration với hệ thống cũ cùng sử dụng nó nếu được
Public API mình vẫn qua REST vì đa phần nếu các hệ thống bên ngoài và frontend thì Rest vẫn tốt nhất.
Về performance thì theo mấy ngôn ngữ đo được gRPC sẽ tốt hơn khoảng +-20% so với Rest về mặt tốc độ và size payload (message).
Ngoài ra có thể consider dùng Rest + message pack nếu không có nhu cầu chuyển qua gRPC
Restful và gRPC về bản chát là giống nhau, đều là công cụ RPC (remote procedure call).
Chỉ khác nhau cách cài đặt (implement): gRPC sử dụng binary trong đóng gói dữ liệu để truyền thông (protobuf), còn Restf thì tự do, có thể chọn (thường là text-based: xml hoặc json).
Nhờ đó mà gRPC thường có tốc độ cao và độ trễ thấp hơn. Chỉ nên chuyển qua gRPC nếu ứng dụng cần một số yếu tố như tốc độ truyển thông cao và độ trễ thấp, truyển dữ liệu kiểm stream.
Cái giá phải trả là độ phức tạp tăng lên, khó cài đặt (system) và bảo trì hơn nhiều
Còn với GraphQL, hãy xem xét một số tình huống sau:
Ở trường đại học có các sinh viên thuộc về các chuyên ngành khác nhau. Giả sử chúng ta cần lấy chi tiết thông tin sinh viên cùng với chi tiết chuyên ngành. Để làm được điều đó phải gọi nhiều request đến server nếu dùng REST.
Trong một usecase khác khi client muốn hiển chi tiết khoá học của sinh viên theo mục đích sử dụng khi đó cần phải custom REST api endpoint, với GraphQL ko cần phải custom lại endpoint, client chỉ cần định nghĩa model ở dạng graph.
Vậy GraphQL giúp cho ứng dụng Web API sáng sủa hơn, dễ mở rộng và dễ dàng tương thích ngược mà ko cần phải thay đổi Web API có sẵn.
Và với Webhooks, hãy tưởng tượng một ứng dụng server-side thông báo cho ứng dụng client-side bất cứ khi nào một bình luận mới cho một message cụ thể được đăng lên. Trong trường hợp này, bất cứ khi nào một bình luận mới được đăng lên cơ sở dữ liệu phía server-side, ứng dụng server-side sẽ (sau khi đăng bình luận lên cơ sở dữ liệu) gọi URL webhook ở trên, để client biết vừa có một bình luận mới. Do đó, với việc sử dụng webhooks, server-side có thể thông báo cho client-side về một sự kiện có liên quan (hay một bình luận mới đã được đăng).
Bài viết được tổng hợp từ nhiều nguồn trên internet
Kỹ năng giao tiếp là một trong những kỹ năng quan trọng trong xã hội hiện đại. Dù là một sai lầm nhỏ cũng dễ làm bạn bị mất điểm. Đồng thời, khi có sự tương tác tốt sẽ là lợi thế lớn trong việc xây dựng các mối quan hệ. Kỹ năng giao tiếp ngày nay được hầu hết các nhà tuyển dụng đánh giá cao. Vì vậy, bên cạnh kiến thức chuyên môn, kỹ năng giao tiếp đóng một vai trò quan trọng giúp bạn chính phục các nhà tuyển dụng khó tính.
Vậy thế nào là kỹ năng giao tiếp? Nó có những khía cạnh nào nổi bật? Đâu sẽ là những nhân tố trực tiếp cảnh hưởng đến việc phát triển kỹ năng này? Những chia sẻ TopDev dưới bài viết sau đây sẽ giúp bạn cải thiện kỹ năng giao tiếp của mình một cách hiệu quả nhất.
Kỹ năng giao tiếp là gì?
Hiểu một cách đơn giản, kỹ năng giao tiếp là khả năng truyền đạt thông điệp, các tín hiệu có cơ sở, lắng nghe; gửi đi và nhận lại các phản hồi là các thông tin được tri nhận thông qua nền tảng kiến thức riêng của mỗi người.
Quá trình này mô tả sự trao đổi thông tin qua lại giữa chủ thể giao tiếp (người nói) và đối tượng giao tiếp (người nghe) nhằm tạo ra sự liên kết chặt chẽ với định hướng mang lại một mục đích giao tiếp nhất định.
Có rất nhiêu yếu tố ảnh hưởng đến cách thức và hiệu quả giao tiếp. Đó có thể là yếu tố tâm lý, những rối loạn về xúc cảm, sự mất bình tĩnh, ngôn từ, các âm thanh nhiễu xung quanh môi trường giao tiếp,… Do vậy, có thể nói kỹ năng giao tiếp có mối liên hệ mật thiết với năng lực nghe-nói, năng lực tiếp nhận; đánh giá phản hồi và cả các khía cạnh cảm xúc cũa người giao tiếp lẫn người tiếp nhận giao tiếp.
Nếu xét dưới góc độ hình thức giao tiếp thì sẽ rất đa dạng. Ví dụ như giao tiếp thông qua ngôn ngữ – lời nói, giao tiếp qua ngôn ngữ viết, giao tiếp qua ánh mắt hay ngôn ngữ hình thể,… Mỗi hình thức giao tiếp được sử dụng ứng với từng đối tượng giao tiếp phù hợp.
Tầm quan trọng của kỹ năng giao tiếp
Kỹ năng giao tiếp là một kỹ năng mềm cực quan trọng trong thời kỳ phát triển mới
Kỹ năng giao tiếp có vai trò rất quan trọng.
Và có lẽ hiện tại, giao tiếp không gì đơn giản là nói và lắng nghe. Mà nó là cả một nghệ thuật. Bởi lẽ, nó được thiết lập trên nền tảng những quy tắc, nghệ thuật và phong cách ứng xử, cách sự dụng ngôn từ và giọng điệu, cách ứng phó và trình bày kết hợp các quan điểm, ý kiến, góc nhìn,…
Rất nhiều thứ làm nên kỹ năng giao tiếp. Và để phát triển kỹ năng giao tiếp, không còn cách nào khác chính là rèn luyện và trau dồi các kinh nghiệm thông qua trải nghiệm giao tiếp thực tế.
Bạn phải thực sự hiểu rằng giao tiếp là một mắc xích quan trọng giúp xây dựng và nuôi dưỡng các mối quan hệ. Hãy dành thời gian để học hỏi, tăng cường tập luyện để kỹ năng của bạn ngày càng được hoàn thiện. Từ đó, kết quả tương tác và giá trị giao tiếp bạn nhận lại sẽ thật sự có ích.
1. Giao tiếp thúc đẩy hiệu suất công việc và phát triển tiềm năng nhân sự
Môi trường văn hóa công sở nếu thiếu đi kỹ năng giao tiếp sẽ khó có thể phát triển. Sự thăng tiến là điều mà mỗi cá nhân đều mong muốn đạt được. Khi giao tiếp bị giới hạn thì con đường thăng tiến, sự phát triển sẽ gặp những trở ngại. Và đôi khi, bạn sẽ ngã gục trước những khó khăn ấy.
Ngược lại, nếu sở hữu một năng lực tư duy ngôn ngữ tốt, linh hoạt trong giao tiếp sẽ giúp bạn thành công hơn. Cụ thể giao tiếp hiệu quả giúp bạn khai thác thông tin một cách chuyên sâu, nhanh chóng. Những gì bạn truyền đến các đối tác, khách hàng cũng trở nên thuận lợi và suôn sẻ hơn. Đồng thời, hiệu suất công việc cũng được gia tăng.
Hơn thế nữa, giao tiếp giúp bạn kết nối tốt hơn với mọi người. Bạn sẽ trở thành một cá nhân truyền tải quan điểm tốt trong một nhóm. Bạn biết cách giúp đỡ cũng như đẩy cho cuộc thảo luận của hội nhóm đi đến trọng tâm, đảm bảo tính khả thi cho định hướng nhiệm vụ.
Chính giao tiếp giúp bạn có sự tương tác tốt hơn với các đồng đội. Từ đó, nhóm của bạn sẽ ngày một hiểu nhau hơn. Và rất có thể sẽ trở thành một hội nhóm tiểm năng trong việc triển khai thực hiện các kế hoạch của tổ chức/doanh nghiệp. Bởi lẽ, kỹ năng giao tiếp cũng là yếu tố giúp gia tăng tính đoàn kết của mỗi cá nhân trong team. Các bạn sẽ hiểu điểm mạnh, điểm yếu để cùng nhau thảo luận đưa ra các chiến lược thực sự phù hợp.
2. Kỹ năng giao tiếp tạo ra nhiều cơ hội thăng tiến
Để thăng tiến trong sự nghiệp, tất nhiên cần có những chiến lược. Và ngoài các kỹ năng chuyên môn thì kỹ năng giao tiếp là một kỹ năng không thể thiếu. Nếu bạn muốn thăng tiến nhanh, bạn phải là người giao tiếp tốt.
Đơn giản vì bạn là người có tiếng nói. Bạn cần tham gia vào nhiều cuộc trao đổi, các cuộc họp với các đối tác trong và ngoài nước.
kỹ năng giao tiếp
Đặc biệt kỹ năng giao tiếp không chỉ tác động riêng về phía bạn. Nó còn có ảnh hưởng tích cực đến các đồng nghiệp, cấp dưới,… của bạn.
Nhờ có kỹ năng giao tiếp, Leader mới thật sự biết cách khai thác thông tin ở nhân viên. Họ biết nắm bắt tâm lý, tùy cá tính đối tượng nhân viên mà có cách ứng xử phù hợp. Từ cơ sở đó, họ đưa ra các phân tích, suy luận về kế hoạch phát triển riêng cho từng nhân viên. Vì giao tiếp là chiếc chìa khóa giúp họ khai thác các thế mạnh và điều một người lãnh đạo cần làm là hiểu họ. Đồng thời, tạo cơ hội để họ phát triển năng lực của riêng mình thông qua các nhiệm vụ ứng với năng lực thật sự của họ.
Kỹ năng giao tiếp là một trong những kỹ năng quan trọng trong xã hội hiện đại. Dù là một sai lầm nhỏ cũng dễ làm bạn bị mất điểm. Những chia sẻ TopDev dưới bài viết sau đây sẽ giúp bạn cải thiện kỹ năng giao tiếp của mình một cách hiệu quả nhất.
Giao tiếp đúng đối tượng – Bước đi đầu trong việc phát triển kỹ năng giao tiếp
Giao tiếp trong môi trường làm việc chịu ảnh hưởng bởi nhiều rào cản như: ngôn ngữ, tuổi tác, giới tính, kinh nghiệm làm việc, thứ bậc xã hội,…
Mỗi rào cản ứng với từng đối tượng khác nhau. Do đó, buộc chúng ta phải có những cách thức khác nhau.
Đây là điều rất quan trọng . Vì nó giúp xác định những cách ứng xử phù hợp; giúp làm tăng hiệu quả giao tiếp. Hãy nhớ rằng để có một sự phản hồi tốt thì trước hết, bạn phải là một người giao tiếp đúng đối tượng.
Để giúp xác định đối tượng bạn muốn giao tiếp, bạn có thể đặt ra những câu hỏi như sau:
– Người đó là ai? (Là sếp, là nhân viên hay đồng nghiệp của bạn?)
– Người đó đến từ đâu/như thế nào?
– Điều gì mà người đó đang gặp phải?
1. Giao tiếp với cấp trên của bạn
Đối với sếp để tạo cuộc thoại hiệu quả, bạn nên giải thích; trình bày thông tin một cách rõ ràng để nhận được sự đồng ý, chấp nhận về một vấn đề nào đó. Không nên trình bày quá dài dòng. Sếp thường không thích sự dàn trải. Họ sẽ ấn tượng với những nhân viên nói ít mà hiểu nhiều.
Đối với cấp dưới, bản thân họ sẽ cảm thấy ngại và có khoảng cách với bạn. Họ thường ít khi bày tỏ những suy nghĩ của mình. Do tính chất công việc mà bạn cần phải phân công nhiệm vụ cho các thành viên một cách nhanh chóng vì thế tạo ra những ngõ cụt. Thậm chí là đứt đoạn trong giao tiếp.
Họ chỉ dừng lại ở mức thụ động. Họ chỉ nghe theo và làm mà thiếu tính tương tác, đó là nguy cơ tạo ra những sai sót. Vì vậy, đối với cấp dưới thì bạn phải kiên nhẫn, chịu khó giao tiếp với họ. Từng câu chữ cần truyền tải một cách rõ ràng, task cụ thể phù hợp với khả năng.
3. Giao tiếp với đồng nghiệp cùng cấp bậc với bạn
Việc giao tiếp với đồng nghiệp sẽ rất thuận lợi nếu cả hai có sự tương tác và chia sẻ về tương đồng sở thích hoặc cùng lĩnh vực chuyên môn. Ví dụ là đối với một ông senior về code, và một ông senior về BA. Lúc này, giao tiếp sẽ hiệu quả vì cả hai có cùng kiến thức nền nên sẽ dễ dàng thảo luận và đề ra phương án mới cho việc tuyen dung it hay freelancer it. Tuy nhiên xung đột giao tiếp vẫn có thể xảy ra nếu cái tôi của một trong hai quá lớn.
“Bẫy” giao tiếp được hiểu là những tình huống bạn có thể mắc phải do sự giới hạn về kiến thức và nội dung giao tiếp. Hiểu và nhận biết những bẫy giao tiếp sẽ giúp bạn giao tiếp hiệu quả hơn.
kỹ năng giao tiếp
Không với biết: Đây là cách nói được xem là chém gió hay múa rìu qua mắt thợ, nói như kiểu bạn thật sự am hiểu về một vấn đề nào đó quá tinh tường trong khi bạn rỗng tuếch.
Biết với không: Trường hợp này bị lạm dụng khá nhiều. Đây là trường hợp bạn cảm thấy mệt mỏi khi phải giải thích cho người chưa hiểu vấn đề. Vì vậy bạn chọn cách chia sẻ với người đã biết vấn đề đó như mình; hoặc cố tình hiểu sang một vấn đề khác.
Không với không: Đúng thật như kiểu là thầy bói xem voi. Đây cũng là trường hợp đẩy quá trình giao tiếp vào ngõ cụt. Người nói và người nghe đều không biết vấn đề mình đang trao đổi.
Biết với biết: Đây được xem là hình thức giao tiếp hiệu quả nhất vì cả người truyền tải lẫn người tiếp nhận thông điệp đều hiểu vấn đề đang được đề cập đến. Từ đó, họ có thể trao đổi, thỏa hiệp và đi đến những thống nhất chung. Tuy nhiên, tại sao vẫn xếp nó vào “bẫy giao tiếp’. Điều này là điểm hạn chế, Bởi nếu một cá nhân quá phô trương kiến thức của mình, xem mình là ”bác học” để giải lý với người khác thì điều này lại tạo ra tác dụng ngược. Và tất nhiên, dễ khiến hiệu quả giao tiếp bị giảm xuống hoặc thậm chí là mất đi.
Những lưu ý giúp giao tiếp đạt hiệu quả cao
Giao tiếp hiệu quả không hề đơn giản. Và có nhiều người phải thực hiện nhiều phương pháp để thay đổi khả năng giao tiếp của mình. Vậy phải làm gì để giao tiếp hiệu quả?
Cách diễn đạt, trình bày với quá nhiều thuật ngữ chuyên ngành khó hiểu tạo ra sự khó nắm bắt. Bạn nên cố gắng giao tiếp ngắn gọn, trình bày cụ thể, rõ ràng.
Mặc khác, có thể bạn đang gặp vấn khác như là nói quá ít vì thiếu từ ngữ để diễn đạt; hoặc quá lộn xộn, dài dòng do thiếu sự chuẩn bị; hoặc là sử dụng từ ngữ không phù hợp, lạm dụng quá nhiều từ có tính “thô tục” – vì cho rằng nó gây cười hoặc tạo điểm nhấn.
Lời khuyên nào cho vấn đề này:Chuẩn bị trước những gì bạn cần nói; luyện tập ngữ điệu và cách nói sao cho phù hợp. Bạn cần phải nói rõ ràng, chính xác trước khi luyện tập cách giao tiếp hay và chuyên nghiệp.
2. Học cách lắng nghe
Việc lắng nghe đôi rất khó nắm bắt, lắng nghe không dừng lại ở việc nghe đơn thuần. Mà nó đi kèm với sự tri nhận về thông tin và bắt đầu phân tích nó. Và việc lắng nghe một ai đó lại càng trở nên khó khăn hơn. Bởi lẽ, nhiều đồng nghiệp, thậm chí sếp của chúng ta đôi khi lúc diễn đạt vấn đề không rõ ràng, dẫn đến chúng ta hiểu không đầy đủ, hoặc hiểu sai lệch vấn đề.
Khả năng lắng nghe còn chịu sự chi phối về thời lượng sử dụng. Vì vậy, nếu một trong hai hoặc một vài người trong một nhóm người bị xao nhãng thì hiệu quả giao tiếp bị ảnh hưởng đáng kể và không đạt hiệu quả cao như mong đợi ban đầu.
Vậy làm thế nào để lắng nghe tốt? Đúng là câu hỏi không dễ trả lời. Trước tiên là bạn phải bỏ thời gian tìm hiểu chủ đề, nội dung mình được nghe. Ngoài ra, trong các buổi nói chuyện đông người, hãy chịu khó tập trung. Tránh xa các yếu tố có thể chi phối bạn như: điện thoại, tin nhắn, email, hoặc là nói chuyện riêng với người khác.
3. Khả năng tương tác trực tiếp thông qua sự phản hồi
Điều mấu chốt của một quá trình giao tiếp được đánh giá là hiệu quả tức là khả năng tương tác thông qua các phản hồi trực tiếp. Sự phản hồi có thể là những suy nghĩ, góc nhìn của người nghe về cách người nói trình bày; chia sẻ thông tin hay thậm chí là đánh giá về nội dung thông tin mà người nói đang truyền tải.
Một biểu hiện khác của sự phản hồi chính là việc đặt câu hỏi. Vì nó thể hiện người nghe thật sự lắng nghe và đã theo dõi; tiếp nhận thông điệp và có những phân tích riêng từ đó có những thắc mắc cần được thảo luận, làm rõ.
Hãy nhớ rằng nếu ở vai trò là người nghe, khi bạn không nghe rõ, thì hãy hỏi để làm rõ. Đừng xấu hổ và giả vờ hiểu về một vấn đề nào đó. Còn ngược lại, nếu bạn ở vai trò của người nói, nếu bạn có câu hỏi, chưa trả lời được, thì hãy khéo léo trả lời là: “Tôi sẽ tìm hiểu, và trả lời lại sau, vào ngày nào đó.” Đừng mãi loay hoay, suy đoán và nói lung tung, những điều mà bạn không biết.
Nghệ thuật giao tiếp từ kỹ năng giao tiếp chuyên nghiệp
TopDev sẽ chia sẻ với các bạn về những tips cụ thể giúp bạn thiết lập một nghệ thuật giao tiếp cho riêng mình. Tất nhiên, nghệ thuật giao tiếp sẽ được thiết lập trên nền tảng phát triển kỹ năng giao tiếp chuyên nghiệp.
1. Tính rõ ràng, dễ hiểu
Không một cuộc giao tiếp nào hiệu quả nếu cách diễn đạt lủng củng, không rõ ràng. Nó thể hiện bạn chưa đủ bản lĩnh và tự tin trong cuộc giao tiếp; vừa cho thấy sự non nớt trong cách phát ngôn. Hãy cố gắng luyện tập giao tiếp rõ ràng. Có thể bạn không cần nói quá nhanh, hãy nói từ tốn và chậm rãi.Từng bước nâng trình bằng những từ/ngữ có số lượng ký tự dài hơn kết hợp với việc kết hợp làn hơi và nối chữ.
Hạn chế tối đa các từ ngữ như “à, ừm” vì nó thể hiện sự lúng túng, không nhất quán trong lời nói. Khi thực hiện cuộc giao tiếp, hãy nói dứt khoác, ngắt nhịp hợp lý để kiểm soát tốt ý nghĩa của câu nói; không vội vàng cũng không quá chậm rãi. Có thể, người nghe sẽ thấy thoải mái khi lắng nghe những điều mà bạn chia sẻ.
Ngôn từ, giọng nói khác nhau, tông giọng và cách dẫn dắt câu chuyện giao tiếp sao cho nội dung không bị gò bó mà phải đảm bảo tính mạch lạc, logic và dễ hiểu nhất. Đôi khi, không nên sử dụng các ngôn từ quá khoa học chuyên ngành hay có tính chất quá trang trọng trong các tình huống bình thường. Điều này sẽ khiến giá trị của việc ứng biến giao tiếp bị đánh giá thấp hơn.
Tùy trường hợp mà kỹ năng giao tiếp của bạn được bộc lô. Phân tích mới thấy, cả ngôn ngữ, âm sắc lời nói, ngữ pháp trong câu phát ngôn và cách lựa chọn cảm xúc để truyền tại đã đủ mô tà một nghệ thuật giao tiếp hiệu quả rồi.
2. Không “thùng rỗng kêu to”
Giao tiếp chi phối cuộc thoại và giúp nó duy trì một giới hạn nhất định. Tuy nhiên, bạn không nên dùng giao tiếp để nói khoác cho những kiến thức của mình. Đừng nói quá nhiều. “Thao thao bất tuyệt” không khiến cuộc giao tiếp trở nên sôi nổi hơn. Chính điều đó sẽ khiến cho chất lượng cuộc giao tiếp ngày càng đi xuống.
Nghệ thuật giao tiếp giúp nâng chất lượng cuộc giao tiếp. Và việc của bạn cần làm là kéo dài cuộc giao tiếp. Sự tương tác qua lại giữa 2 người hoặc một cá nhân với nhiều đối tượng. Giao tiếp phát triển ở một mức cao hơn khi những kiến thức được chia sẻ qua lại. Họ cùng có một mối quan tâm chung cần giải quyết. Nếu bạn chỉ mãi “thùng rỗng kêu to” với các phát ngôn của mình, cuộc giao tiếp ấy sẽ sớm đi vào ngõ cụt; thậm chí bạn đang thể hiện mình là người thiếu tinh tế trong vấn đề giao tiếp.
3. Tương đồng về nền tảng kiến thức
Như đã đề cập từ trước, mục đích của cuộc giao tiếp chính là truyền tải thông tin, trao đổi, chia sẻ các tín hiệu về dự liệu trên cơ sở chung một nền tảng kiến thức nền. Sẽ khó khăn biết bao nhiêu nếu như bạn đang giao tiếp với một đối tượng không “match” về thông tin. Do vậy, nếu là một người hiểu về nghệ thuật giao tiếp, bạn hãy chủ động khai thác các yếu tố thông tin tương đồng với người tiếp nhận giao tiếp của bạn.
Nếu bạn tìm được một đối tượng biết lắng nghe, chia sẻ các suy nghĩ chung về giá trị kiến thức, thì đó quả là một sự may mắn. Giao tiếp hiệu quả phải đến từ hai phía, bạn và người đối diện cần có sự lắng nghe và tôn trọng lẫn nhau để cuộc giao tiếp trở nên thú vị.
4. Sự lắng nghe
Ai cũng tranh giành các quyền lợi về phát ngôn, ít ai biết lắng nghe thấu hiểu. Dường như đó trở thành xu hướng chung của nhiều người, đặc biệt là người trẻ. Sự hấp tấp trong giao tiếp, khiến mọi thứ trở nên vội vàng. Họ chỉ quan tâm đến việc phô bày qua lời nói; chứ chưa tôn trọng ý kiến hoặc lắng nghe suy nghĩ, quan điểm của người khác. Họ quên rằng cuộc hội thoại này không thể hiệu quả nếu chỉ mỗi mình họ tự độc thoại nội tâm. Thật sự, việc lắng nghe và chia sẻ là cách bạn đang tôn trong đối phương; tạo cơ hội cho cuộc giao tiếp trở nên lâu dài và hấp dẫn.
Tại sao bạn không dừng lại đôi chút để lắng nghe đối phương họ nói gì. Biết đâu, ở họ có một chút cảm xúc tích cực, lời nói, ngôn từ, giọng điệu; cách họ dẫn dắt câu chuyện là thứ bạn nên học tập.
Giao tiếp không phải cuộc tranh luận mà cứ tranh giành quyền nói. Bạn sẽ nhận ra các bài học, các giá trị hay nếu bạn thật sự quan tâm đến những gì đối phương chia sẻ. Có lắng nghe, bạn mới biết phản hồi phù hợp, đúng chủ đề.
Nếu gặp phải một vấn để nào đó, việc lắng nghe giúp bạn mô hình hóa được quá trình và bạn sẽ biết đâu là điểm mấu chốt. Từ đó, bạn biết cách góp ý và giúp đỡ đối phương thông qua các giải pháp cụ thể. Kỹ năng giao tiếp tuy dễ mà khó. Và nếu không biết lắng nghe, bạn chỉ đang làm tốn thời gian cho việc phát ngôn vô ích mà thôi.
5. Kết hợp ngôn ngữ hình thể
Một điều bạn đáng lưu tâm để đạt hiệu quả nghệ thuật giao tiếp chính là tính trung thực khi giao tiếp.
Hãy nói đúng suy nghĩ của mình, cuộc hội thoại sẽ cởi mở hơn; được duy trì và phát triển xa hơn. Nếu cảm xúc trong bạn đang không ổn, hãy cho đối phương biết điều đó. Nếu không muốn tiếp tục chia sẻ, bạn nên nói với họ để dừng lại cuộc thoại. Không nên duy trì khi trạng thái có sự ảnh hưởng tiêu cực. Vì nó là mấu chốt tạo ra những cuộc tranh luận dữ dội. Và quả thật, điều này thật tệ. Đồng thời, khi chia sẻ điều gì, bạn phải thật khéo léo để không làm phật ý đối phương. Tất cả đều biểu hiện cho nghệ thuật giao tiếp hiệu quả nhất.
Ngoài ra, một nghệ thuật giao tiếp khác bạn cần biết chính là ngôn ngữ cơ thể. Không nhất thiết thông qua lời nói. Những cử chỉ nhỏ qua ánh mắt, dáng đứng, nụ cười,… đều có những ý nghia giao tiếp nhất định. Đôi khi có còn hiệu quả truyền thông điệp cao hơn cả lời nói trong nhiều trường hợp. Âm sắc, tông giọng của bạn có thể thay đổi theo cách bạn cảm nhận về một khía cạnh vấn đề. Tất cả những biểu hiện ấy đều bộc lộ ra các tín hiệu về thông điệp. Ngôn ngữ cơ thể rất đa dạng và nó cho thấy sự thú vị hơn, tương tác đa chiều hơn. Đồng thời, nó cũng giúp cuộc hội thoại giao tiếp của bạn không bị nhàm chán nữa.
Lời kết
Kỹ năng giao tiếp thật sự là một kỹ năng quan trọng. Dù ở trong bất cứ lịnh vực, ngành nghề nào, bạn cũng cần kỹ năng giao tiếp. Hãy rèn luyện và phát triển kỹ năng của bản thân để gia tăng các cơ hội phát triển cao hơn trong nghề nghiệp. TopDev hi vọng với bài viết này, các bạn sẽ biết được những thông tin bổ ích; giúp cho việc cải thiện giao tiếp tốt hơn, tự tin và hiệu quả hơn.
NGINX Error 502 Bad Gateway là một lỗi phổ biến ở người dùng trang web. Nguyên nhân nào khiến website của bạn gặp lỗi 502 Bad Gateway Nginx? Cùng chúng tôi theo dõi bài viết dưới đây để tìm hiểu nguyên nhân và cách fix nhanh lỗi này bạn nhé!
Lỗi 502 Bad Gateway Nginx là gì?
Lỗi 502 Bad Gateway Nginx là thông báo lỗi cho biết máy chủ đang nhận lỗi từ máy chủ khác và không thể kết nối với PHP-FPM hoặc PHP-FPM không phản hồi.
Để đi sâu vào nguyên nhân và cách xử lý lỗi 502 Bad Gateway Nginx, bạn cần hiểu 502 Bad Gateway là gì? Click vào bài viết để tìm hiểu từ A-Z về lỗi phổ biến này nhé!
Nguyên nhân gây lỗi 502 Bad Gateway Nginx
1. PHP-FPM không chạy
Nếu PHP-FPM không chạy, NGINX sẽ trả về lỗi 502 cho bất kỳ yêu cầu nào nhằm truy cập ứng dụng PHP. Nếu bạn nhìn thấy 502s, trước tiên hãy kiểm tra để xác nhận rằng PHP-FPM đang chạy. Ví dụ: trên máy chủ Linux, bạn có thể sử dụng lệnh ps như lệnh này để tìm kiếm các quy trình PHP-FPM đang chạy:
sudo ps aux | grep 'php'
2. PHP-FPM đã hết thời gian chờ
Nếu ứng dụng của bạn mất quá nhiều thời gian để phản hồi, người dùng của bạn sẽ gặp phải lỗi hết thời gian chờ. Nếu thời gian chờ của PHP-FPM — request_termina_timeout của config (và mặc định là 20 giây) – ít hơn thời gian chờ của NGINX (mặc định là 60 giây), NGINX sẽ phản hồi với lỗi 502. Error log của NGINX hiển thị bên dưới chỉ ra rằng upstream process — là PHP-FPM — đã đóng kết nối trước khi gửi phản hồi hợp lệ. Nói cách khác, đây là error logs mà chúng tôi thấy khi PHP-FPM hết thời gian:
2020/02/20 17:17:12 [error] 3059#3059: *29 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/mypool.sock:", host: "localhost"
Bạn có thể tăng cài đặt thời gian chờ của PHP-FPM bằng cách chỉnh sửa tệp cấu hình (file config), nhưng điều này có thể gây ra một vấn đề khác: NGINX có thể hết thời gian trước khi nhận được phản hồi từ PHP-FPM. Thời gian chờ NGINX mặc định là 60 giây; nếu bạn đã tăng thời gian chờ PHP-FPM của mình trên 60 giây, NGINX sẽ trả về lỗi 504 Gateway Timeout nếu ứng dụng PHP của bạn không phản hồi kịp thời. Bạn có thể ngăn chặn điều này bằng cách tăng thời gian chờ NGINX của mình. Trong ví dụ bên dưới, chúng tôi đã tăng giá trị thời gian chờ lên 90 giây bằng cách thêm mục fastcgi_read_timeout vào block http của /etc/nginx/nginx.conf:
Nếu NGINX không thể giao tiếp với PHP-FPM vì bất kỳ lý do nào trong số này, nó sẽ phản hồi với lỗi 502, lưu ý điều này trong nhật ký truy cập của nó (/var/log/nginx/access.log):
NGINX’s access log không giải thích nguyên nhân gây ra lỗi 502, nhưng bạn có thể tham khảo error log của nó (/var/log/nginx/error.log) để tìm hiểu thêm. Ví dụ: đây là một mục nhập tương ứng trong nhật ký lỗi NGINX cho thấy rằng nguyên nhân của lỗi 502 là do socket không tồn tại, có thể do PHP-FPM không chạy.
2020/01/31 18:30:55 [crit] 13617#13617: *557 connect() to unix:/run/php/php7.2-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "localhost"
Cách fix nhanh lỗi 502 Bad Gateway Nginx
Mở file cấu hình Nginx:
nano /etc/nginx/nginx.conf
2. Thêm đoạn cấu hình sau vào trong block http { }
Nếu muốn tìm hiểu chuyên sâu hơn về các cấu hình trên, các bạn có về vào trang docs của Nginx với các thông số của module ngx_http_fastcgi_module rất cụ thể.
3. Khởi động lại nginx, php-fpm:
service nginx restart
service php-fpm restart
Trên đây là hướng dẫn cách khắc phục 502 Bad Gateway Nginx dễ dàng mà ai cũng áp dụng được, hi vọng bài viết của đội ngũ Top Dev đã giúp bạn fix thành công lỗi này. Theo dõi chúng tôi để cập nhật nhiều hơn kiến thức về công nghệ mỗi ngày.
3 tips làm việc với JavaScript giúp bạn tiết kiệm thời gian
Tác giả: Gaël Thomas
Để làm việc hiệu quả hơn cũng như tối ưu được thời gian làm việc cho một task, biết thêm một số tips hay ho sẽ giúp ích rất nhiều cho bạn. Dưới đây tôi sẽ giới thiệu với các dev một số JavaScript tip khi làm việc bằng ngôn ngữ JavaScript để tiết kiệm thời gian và công sức.
JavaScript tip giúp công việc trở nên nhẹ nhàng hơn
1. Cấu trúc đối tượng
Đây là một JavaScript tip phổ biến hiện tại. Destructuring là một tính năng đã được giới thiệu trong ES6. Đó là một trong những tính năng bạn sẽ sử dụng hàng ngày khi bạn biết cách. Nó giúp bạn giải quyết ba vấn đề chính:
Lặp lại: Mỗi khi bạn muốn trích xuất một thuộc tính đối tượng và tạo một biến mới, bạn sẽ tạo một dòng mới.
const user ={
firstName:"John",
lastName:"Doe",
password:"123",};// Wow... should we display// John's password like that?const firstName = user.firstName;const lastName = user.lastName;const password = user.password;
Accessibility – Khả năng tiếp cận: Mỗi lần bạn muốn truy cập một thuộc tính đối tượng, bạn nên viết đường dẫn đến nó (ví dụ: user.firstName, user.family.sister)
Destructuring là quá trình trích xuất một thuộc tính từ một đối tượng bằng key của nó. Bằng cách lấy một key hiện có trong đối tượng, sau đó đặt nó giữa hai dấu ngoặc ( { firstName })
Nếu bạn muốn hủy cấu trúc một đối tượng, bạn phải luôn sử dụng một khóa hiện có. Nếu không, nó sẽ không hoạt động.
const user ={
firstName:"John",
lastName:"Doe",
password:"123",
family:{
sister:{
firstName:"Maria",},},};// We access to the nested object `sister`// and we extract the `firstName` propertyconst{ firstName }= user.family.sister;
console.log(firstName);// Output: 'Maria'
Khi làm việc với các đối tượng lồng ghép vào nhau, nó có thể bị lặp lại và lãng phí nhiều thời gian khi truy cập cùng một thuộc tính nhiều lần.
Sử dụng cấu trúc destructuring, chỉ trong một dòng, bạn có thể giảm đường dẫn thuộc tính thành một biến.
Trong lập trình, bạn thường phải giải quyết các vấn đề với cấu trúc dữ liệu. Nhờ toán tử spread được giới thiệu trong ES6, các thao tác đối tượng và mảng đơn giản hơn.
Sử dụng toán tử spread ( ...), chúng ta có thể trích xuất tất cả các thuộc tính của đối tượng này sang đối tượng khác.
const user ={
firstName:"John",
lastName:"Doe",
password:"123",};const myNewUserObject ={...user,// We extract:// - firstName// - lastName// - password// and send them to// a new object `{}`};
Giống như các đối tượng, toán tử spread ( ...) trích xuất tất cả các phần tử từ mảng này sang mảng khác.
const girlNames =["Jessica","Emma","Amandine"];const newNewArray =[...girlNames,// We extract:// - 'Jessica'// - 'Emma'// - 'Amandine'// and send them to// a new array `[]`];
2.2. Cách loại bỏ Array Duplicates
Vì mảng là danh sách nên có thể có nhiều mục cùng giá trị. Nếu bạn muốn loại bỏ các bản sao trong mảng của mình, bạn có thể làm theo một trong các ví dụ dưới đây.
Một trong số đó sẽ chỉ có một dòng nhờ ES6, nhưng tôi để ví dụ “cũ” trong đó để bạn có thể so sánh.
Tìm hiểu thêm các tip JavaScript thông qua bài viết này
Toán tử bậc ba thay thế if và else cho các điều kiện nhỏ.
Lưu ý: Không nên tạo điều kiện phức tạp với toán tử bậc ba vì nó có thể làm giảm khả năng đọc.
Dưới đây là một ví dụ khác sử dụng toán tử bậc ba, nhưng lần này là return trong một hàm.
functionsayHelloToAnne(name){return name ==="Anne"?"Hello, Anne!":"It's not Anne!";}
console.log(sayHelloToAnne("Anne"));// Output: 'Hello, Anne!'
console.log(sayHelloToAnne("Gael"));// Output: "It's not Anne!"
Hi vọng một số tip hay ho trên đây có thể giúp bạn coding hiệu quả hơn với ngôn ngữ JavaScript. Happy Coding!
Để trả lời cho câu hỏi này, chúng ta cùng tìm hiểu qua một số khái niệm về Framework và Library được nhiều người thống nhất ý kiến.
1. Library là gì?
Là một tập hợp các chức năng (functions), các lớp (class) được viết sẳn để có thể tái sử dụng. Mỗi function hoặc class phục vụ cho một công việc cụ thể nào đó.
Ví dụ:
– JQuery là một library, nó cung cấp các chức năng giúp chúng ta thao tác với DOM.
– LinqJS là một library, nó cung cấp các chức năng giúp chúng ta truy vấn (query) dữ liệu dễ dàng, đơn giản và nhanh hơn.
2. Framework là gì?
Là một tập hợp các Library đã được đóng gói để hỗ trợ phát triển ứng dụng dựa trên framework đó. Đồng thời, Framework cung cấp các nguyên tắc, cấu trúc của ứng dụng mà chúng ta phải tuân thủ theo nó.
Ví dụ 1: Angular là một framework. Mục đích Angular framework là giúp cho người dùng xây dựng được các ứng dụng website dạng single page một cách dễ dàng và nhanh chóng. Nó tập trung vào việc phát triển font-end cho ứng dụng web. Angular cung cấp sẵn cho bạn các directives, services, data-biding, filters,… Để sử dụng Angular, chúng ta phải tuân thủ theo mô hình và cách hoạt động của nó. Chẳng hạn, một page sẽ có phần html gọi là template, phần xử lý gọi là controller, các quy định về việc sử dụng $scope, isolate-scope, cách để trao đổi dữ liệu giữa các page như thế nào. Nghĩa là Angular team đã viết sẵn các thư viện ( Libraries ) để bạn sử dụng lại, cùng với một khuôn mẫu (design parttern) mà bạn phải tuân theo nó để có thể xây dựng được ứng dụng.
3. Những điểm khác nhau giữa Framework và Library là gì?
– Framework và Library đều cung cấp các tính năng (functions) được viết sẵn để chúng ta có thể tái sử dụng.
– Framework lớn hơn và phức tạp hơn Library.
– Sử dụng Framework bạn phải thay đổi cấu trúc code của dự án (project’s structure) theo các quy tắc của framework đó để có thể sử dụng được các functions mà framework đó cung cấp.
– Chúng ta có thể sử dụng các functions của Library một cách trực tiếp mà không cần thay đổi cấu trúc code của dự án.
– Framework có thể hiểu là một khung chương trình, người dùng bổ sung code và tuân theo quy tắc để tạo ra ứng dụng. Còn Library chỉ cung cấp các chức năng tiện ích hay các class để sử dụng trong quá trình xây dựng ứng dụng.
– Framework hoạt động chủ động. Nghĩa là nó có thể đưa ra các quyết định gọi hoặc bị gọi bởi các Library hay ứng dụng nào đó.
– Library hoạt động bị động. Nghĩa là nó chỉ được gọi khi nào chúng ta cần dùng nó.
Tới đây, mình nghĩ các bạn đã hiểu được Framework và Library là gì, chúng khác nhau thế nào rồi đúng không. Để giúp các bạn hiểu rõ hơn, mình lấy một ví dụ đời thực để so sanh Framework với Library thế này:
Chúng ta lấy cấu trúc máy tính để làm ví dụ nhe.
Framework: là mô hình để có một cái máy tính hoạt động được. Nghĩa là, một cái máy tính sử dụng được phải bao gồm: màn hình, CPU, bàn phím, chuột, … Và bạn phải lắp đặt các linh kiện này theo tuần tự và quy tắc như: màn hình phải được gắn vào case CPU qua card đồ họa, bàn phím phải được gắn vào case CPU qua cổng COM/USB,… và bản thân case CPU để nó hoạt động phải có đủ các thành phần: chíp CPU, nguồn, dây điện,… và chúng phải được gắn kết với nhau theo quy tắt và vị trí của nó.
Library: có thể xem các cổng COM/USB được chia thành nhiều loại phục vụ cho từng chức năng của nó. Dây điện với các giắc cấm điện (loại 3 đầu, 2 đầu), óc vít dùng để liên kết các thành phần máy tính lại,…
Bài viết được sự cho phép của BBT Tạp chí Lập trình
Các thợ lành nghề trong lĩnh vực phát triển phần mềm chỉ quan tâm nhiều đến những thợ học việc mà có ham muốn thực sự với nghề.
…
Những người thợ học việc là một phần thiết yếu đối với nghề thủ công phần mềm bởi vì họ mang đến lòng nhiệt huyết và định hướng học tập có ảnh hưởng nhiều đến những người xung quanh. —Pete McBreen, Software Craftmanship
Bối cảnh
Bạn đang rất phấn khích và tò mò về việc tạo ra các sản phẩm phần mềm thủ công.
Bạn tự cảm thấy mình đang bị thụt lùi, ý thức được rằng lòng nhiệt huyết của mình cao hơn so với những đồng nghiệp xung quanh.
Giải pháp
Cho dù đang còn thiếu kinh ngiệm, bạn vẫn có những đóng góp nhất định cho nhóm của mình, bao gồm cả việc lan truyền sự nhiệt huyết. Đừng để ai đó làm giảm hứng thú với nghề của mình- đó là một yếu tố rất quý giá và sẽ đẩy nhanh tốc độ học của bạn.
Là một nhà phát triển, bạn sẽ không tránh khỏi việc phải làm theo nhóm. Trong một nhóm, mọi người thường có xu hướng thích nghi với những tiêu chuẩn chung, nhất là với người mới. Phần lớn các nhóm đều không quá đam mê hoặc nhiệt huyết về công nghệ. Ta có thể dễ đoán được là họ thường chỉ tập trung vào việc hoàn thành xong dự án hoặc cải thiện các phương diện trong quá trình phát triển đang gặp phải khó khăn. Vì vậy, những người tập sự nhiệt tình thường sẽ phải cố gắng chịu đựng để không bị soi xét. Họ sẽ cố kìm nén cảm xúc của mình lại, hoặc chỉ biểu hiện ra ngoài trong các công việc hàng ngày của họ. Sẽ có một số rắc rối xảy ra nếu bạn cứ để cảm xúc của mình tuôn trào khi làm việc với một nhóm đã được gây dựng ổn định. Nếu tinh thần xuống thấp hoặc nhóm không chào đón người mới, thì bạn sẽ dễ bị soi xét. Bạn sẽ để lại ấn tượng không tốt với những người hay coi trọng năng lực hơn là khả năng học hỏi, đặc biệt là khi bạn thể hiện sự thiếu hiểu biết của mình. Tương tự như những yếu tố khác, không nên áp dụng phương pháp này một cách mù quáng. Tạo động lực trong nhóm cũng nên được cân nhắc. Nếu bạn thấy mình đang ở trong một nhóm không chấp nhận sự nhiệt tình của bạn, bạn nên tìm cách để nuôi dưỡng đam mê của mình.
Tuy nhiên, trong một nhóm chào đón sự hào hứng và tinh thần đóng góp của một người học việc, bạn nên thể hiện những khả năng đặc biệt mà lập trình viên kinh nghiệm hơn tin vào, chẳng hạn như trí tưởng và sự nhiệt tình. Đây là thời gian có ý nghĩa nhất trong sự nghiệp, cho phép bạn chấp nhận rủi ro và nói lên suy nghĩ của mình. Bạn không có gì nhiều để sợ mất. Những ý tưởng và niềm đam mê của bạn sẽ tăng sự thông minh và tính đa dạng cho nhóm. Trong cuốn The Wisdom of Crowds (Trí khôn của đám đông) của Jam Surowiecki, ông đã nhiều lần chỉ ra rằng sự đa dạng trong suy nghĩ là một thành phần chính của trí tuệ tập thể (collective intelligence – CI).
Một nghiên cứu thú vị về trí tuệ tập thể của các phi hành đoàn máy bay hàng không mẫu hạng cho thấy những người mới đến đóng một vai trò quan trọng trong các hoạt động nhóm phức tạp và đòi hỏi sự phối hợp của nhiều thao tác để vận hành an toàn một cỗ máy lớn với các những chiếc máy bay chiến đấu liên tục đến và đi. Các nhà nghiên cứu nhận thấy một nhóm bao gồm các thành viên có kinh nghiệm ở các trình độ khác nhau góp phần tạo nên một nhóm vững mạnh hơn.
Sự hiểu biết có thể được tăng lên nếu có nhiều người với nhiều trình độ khác nhau kết nối với nhau, như khi những người mới đến, vì những người mới thường không coi điều gì là nghiễm nhiên mà có cả và sẽ thường kết hợp chặt chẽ hơn với những nhân viên kỳ cựu luôn nghĩ rằng họ đã chứng kiến mọi thứ rồi.
-Karl Weick và Karlene Roberts, ” Collective Mind in Organizations “, tr. 366
Cuối cùng, giải phóng lòng nhiệt tình là một trong số khá ít các trách nhiệm của người học việc. Bạn không thể mang lại kiến thức sâu rộng hoặc tăng năng suất, nhưng bạn lại có thể khơi gợi sự hứng thú cho nhóm và đặt câu hỏi về mọi thứ. Bạn đang là người duy nhất (và tạm thời) có một quan điểm mới cho phép mình đưa ra một số gợi ý hữu ích để cải tiến.
Những người thợ lành nghề có thể học hỏi người lại từ những người học việc, ngay cả khi những người đó học hỏi từ họ. Người mới bắt đầu với sự nhiệt tình không chỉ làm mới những người lành nghề mà còn thách thức họ bằng cách đưa những ý tưởng mới từ bên ngoài. Một người học việc được lựa chọn tốt thậm chí có thể làm cho một nghệ nhân làm việc năng suất hơn.
-Pete McBreen, Software Craftsmanship, p. 75
Hành động
Hãy suy nghĩ về lần cuối cùng bạn có ý tưởng nhưng không đề xuất nó. Tìm một người mà đáng lẽ ra bạn đã giới thiệu nó cho họ và mô tả ý tưởng của bạn với người đó. Nếu người đó chỉ ra những sai sót của nó hãy cố gắng thuyết phục người đó giúp bạn cải thiện nó.
Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh
Trong bài viết trước chúng ta đã cùng tìm hiểu thế nào là Dependency Injection rồi, do đó trong bài viết này mình sẽ đi sâu về Inversion of Control (IoC) hơn, và tìm hiểu xem mối liên hệ giữa hai khái niệm này là như thế nào các bạn nhé!
Như mình đã nói, với Dependency Injection thì một đối tượng sẽ không phụ thuộc vào đối tượng khác và đối tượng khác cũng vậy. Khi cần đối tượng này sẽ gọi tới đối tượng kia và ngược lại. Và mình đã hỏi các bạn, các đối tượng sẽ được tạo ra và nằm ở đâu để khi cần chúng có thể gọi lẫn nhau. Câu trả lời là chúng ta phải có một khung chứa, và khung chứa đó chính là một phần của IoC.
IoC có mục đích là cung cấp một cơ chế đơn giản để chứa các đối tượng phụ thuộc và quản lý các đối tượng phụ thuộc đó thông qua chu trình sống của chúng. Một đối tượng bị phụ thuộc sẽ yêu cầu một số lượng nhất định các đối tượng phụ thuộc được quản lý bởi IoC. IoC sẽ cung cấp những cách để các đối tượng bị phụ thuộc có thể truy cập và tương tác được các đối tượng phụ thuộc.
IoC được phân chia thành hai loại khác nhau, đó là:
Dependency Lookup
Dependency Injection
và chúng sẽ có hai kiểu hiện thực khác nhau.
Dependency Lookup sẽ tìm kiếm đối tượng phụ thuộc trong khung chứa IoC và sau đó các bạn có thể dùng code để đưa đối tượng phụ thuộc vào trong đối tượng bị phụ thuộc trong khi đó Dependency Injection sẽ đưa luôn đối tượng phụ thuộc vào đối tượng bị phụ thuộc.
Đến đây chắc các bạn cũng có thể phân biệt được sự khác biệt giữa IoC và Dependency Injection rồi phải không? Bây giờ chúng ta sẽ cùng tìm hiểu thêm về các loại của IoC các bạn nhé!
Dependency Lookup
Dependency Lookup được chia thành hai kiểu khác nhau đó là:
Dependency Pull
Contextualized Dependency Lookup (CDL)
Với Dependency Pull, các đối tượng phụ thuộc sẽ được lấy ra từ một nơi mà các đối tượng phụ thuộc đã được đăng ký chứ không phải lấy trực tiếp từ khung chứa. Nếu các bạn đã làm việc qua với EJB thì các bạn đã làm quen với Dependency Pull vì để lấy các đối tượng phụ thuộc các bạn phải thông qua JNDI API.
Còn Contextualized Dependency Lookup thì việc lấy đối tượng phụ thuộc xảy ra trực tiếp với khung chứa luôn chứ không thông qua nơi mà đối tượng phụ thuộc đã đăng ký.
Dependency Injection
Dependency Injection cho chúng ta hai cách phổ biến để đưa đối tượng phụ thuộc vào đối tượng bị phụ thuộc đó là: Constructor Injection và Setter Injection.
Với Constructor Injection, việc đưa đối tượng phụ thuộc vào đối tượng bị phụ thuộc sẽ thông qua các constructor của đối tượng bị phụ thuộc. Khi đó đối tượng phụ thuộc sẽ là một tham số trong những constructor đó.
