QA là gì? Quality Assurance (viết tắt là QA) là quá trình đảm bảo kiểm tra (development process) sản phẩm để đưa ra quy trình hoạt động phù hợp như mong muốn. Các phương pháp thực tế được sử dụng trong quá trình QA rất đa dạng tùy vào quy mô cũng như tính chất của sản phẩm.
Với mỗi project cá nhân thì chỉ cần nhờ người khác góp ý và phản hồi. Ngược lại với App Banking thì cần phải kiểm tra mọi khía cạnh của từng tính năng để không những hoạt động tố mà còn phải đảm bảo tính an toàn và bảo mật.
Dù quy trình QA có chi tiết hay formal như thế nào thì chung quy lại mục đích của nó là để xác định và giải quyết bugs kịp thời trước khi release product.
Phương pháp agile trong development có thể hiểu nôm na là với mỗi chu kỳ của (‘sprint’) tạo ra một software có thể add vào tổng thể và cải thiện nhiều lần theo vòng lặp, đây là quá trình tương tác và tích hợp miễn sao có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt. Vì thế, testing các thành phần trong software tại mỗi stage của quá trình production sẽ làm giảm rủi ro gặp bug khi release sản phẩm.
Hay còn gọi là Testing hộp đen, là phương pháp được thực hiện không cần biết cấu tạo bên trong của software. Khi test thì các tester sẽ trải nghiệm quan điểm của end-user (người dùng cuối) lên sản phẩm.
Defect
Bất kỳ sai lệch nào so với thông số của application (khiếm khuyết trong thành phần hay hệ thống mà từ đó chức năng không thực hiện đúng như mong đợi) hay còn được gọi là “bug”.
Exploratory Testing
Một cách test khá thú vị khi không được “hẹn trước”, không sử dụng bộ testcase hay một kế hoạch nào cả, mà chỉ dựa trên sự sáng tạo của tester, để tìm ra bugs và xác định regression.
Integration Testing
Test các modules/component độc lập cùng nhau để chắc rằng chúng có kết nối và tương tác với nhau.
Kịch bản testing thử nghiệm được viết ra nhằm hình dung ra được trạng thái lỗi của một tính năng/application, từ đó xác định được những lỗi sẽ cần được xử lý.. Ví dụ về cách test này các bạn có thể thử nhập định dạng số vào field email (trong user account registration) và kiểm tra đảm bảo rằng user sẽ không tiến hành đăng ký được cho đến khi cung cấp địa chỉ email đúng định dạng.
Kiểm thử hồi quy là cách test xem là các chức năng mới khi được add vào sẽ không “phá” các thành phần khác trước đó của application.
Smoke Tests
Quy trình testing tối giản, đảm bảo các chức năng cơ bản hoạt động chính xác trước khi diễn ra các giai đoạn testing sâu hơn.Thường diễn ra ở giai đoạn đầu của quá trình testing.
Test Case
Test case bao gồm những yếu tố như preconditions (điều kiện), steps (bước) và expected results (kết quả mong đợi) được QA tester dựa vào để test tính năng của các task có thực hiện đúng như mong đợi không.
White Box
Trái với Black box thì white box (hay còn gọi là Glass Box, Clear Box hay Transparent Box) là phương pháp testing mà trong đó các thành phần bên trong phần mềm đều có thế “thấy” được. Bước testing này sẽ được thực hiện với level structural trong codebase.
Các thành phần chính:
Unit test: unit (đơn vị) hay component (thành phần) riêng lẻ của software được test xem có làm đúng chức năng không.
Integration test: các unit và component tương tác với nhau đúng cách
Regression test: áp dụng lại các test ở những giai đoạn sau của quá trình development, chắc chắc chúng còn hoạt động
Có ba kỹ thuật chính
Equivalence partitioning (phân vùng tương đương): phân vùng tập điều kiện thành nhiều vùng. mỗi vùng có thuộc tính tương đương nhau. Khi test chỉ cần làm trên giá trị đại diện.
Boundary Value Analysis (phân tích giá trị biên): là phương pháp testing tập trung vào điểm cuối hoặc ranh giới giữa các phân vùng của giá trị input.
Cause-Effect Graphing (đồ thị nhân quả): là kỹ thuật testing black box dựa trên, minh họa mối quan hệ giữa input-output.
Code tốt thường chưa phát huy công dụng khi team còn ít thành viên. Nhưng qua thời gian với sự phát triển về số lượng member và dự án, thì mình càng trân trọng tiêu chuẩn về coding được áp dụng trong team – dù cho chí phí và thời gian bỏ ra là khá nhiều.
Code backend hiệu quả là gồm những gì? Mình sẽ chia sẻ 5 tiêu chuẩn backend mà mình thấy thường bị bỏ qua khi team còn thưa người, team mình có background là backend API và trong môi trường Microservices/mesh architecture.
Khi đi vào hoạt động thì mọi thứ đều có thể xảy ra với app của bạn – hacker xâm nhập hệ thống, hay user gặp lỗi ngoài ý muốn. Bạn sẽ phải triển khai các phương pháp xác thực inputs vào hệ thống, nếu không muốn ảnh hưởng đến hệ thống.
Với backend input thì bạn có thể validate tại 2 level:
API gateway: validate input tại API gateway level qua các policy, hay generic validation như schema, format.
Microservice: cách này thì bao gồm cách kiểm tra sự tồn tại của các entity. Có các thư viện, như Joi validator có thể sử dụng để dễ dàng validate input tùy thuộc vào development stack.
Sau khi xác thực input và tìm ra được lỗi, điều quan trọng tiếp theo là phải xử lý cho hợp lý, đặc biệt với kiến trúc microservice/mesh, khi rất nhiều các services được kết nối ngầm với nhau. Chỉ cần một service có lỗi có thể ảnh huởng đến toàn bộ hệ thống. Mình từng kết hợp 2 phương thức sau để xử lý error sao cho ít ảnh huởng đến hệ thống nhất:
Circuit breaker: ngăn chặn gọi lại các service có khả năng lỗi. Có sẵn các thư viện và ví dụ cho NodeJS, Springcloud, để thực hiện nhanh chóng hơn.
Xử lý exceptions với code lỗi: trả về response mà không ảnh huởng service với business hay HTTP code.
Tham khảo document về các error thường gặp dưới đây:
Với việc validate input thích hợp và xử lý error tại chỗ, service sẽ trở nên linh hoạt hơn giúp giảm nhu cầu khắc phục sự cố thường xuyên.
Chia nhỏ các mối lo backend là gì
Khi chia nhỏ các mối bận tâm hợp lý, bạn sẽ có thể cải thiện code dễ duy trì hơn, từ đó khi các lập trình viên khác tham gia vào dự án cũng dễ dàng và giảm bớt thời gian dư thừa để bắt kịp tốc độ.
Có rất nhiều cách cho cấu trúc code của bạn, ví dụ điển hình là MVC framework. Hãy nhớ mục tiêu chính của việc này là thiết lập tiêu chuẩn phù hợp nhất với team. Bạn cũng có thể research thêm vài ví dụ và đúc kết xem cái gì phù hợp nhất.
Khi triển khai và tuân thủ software architecture trong team sẽ làm giảm rào cản gia nhập cho các lập trình viên khác, từ đó tốc độ và năng suất của team cũng được đẩy mạnh.
Thực hiện health check và logging
Health check (hay còn gọi là kiểm tra sức khỏe định kỳ) theo dõi thời gian hoạt động của service có thể giải quyết vấn đề nhanh chóng, cũng như giảm thiểu tác động trước khi kéo dài. Nếu quá trình health check bị fail và service bị gián đoạn thì cần dựa trên logs dể khắc phục các vấn đề gốc rễ, giải quyết chúng nhanh chóng hơn. Đây là các cách tiếp cận mà mình đã áp dụng (nhưng chỉ với high level):
Health checks (TCP) – health check cơ bản để chắc chắn service đang hoạt động và chạy thông qua ping/TCP. Nhưng không hữu ích lắm vì nó không theo dõi health service-level. Những service như vậy hầu hết chỉ có trên các nền tảng đám mây.
Health check (service-level) – health check nâng cao hơn, lúc này nó sẽ gọi service và xác nhận các output dự kiến để đảm bảo service đang hoạt động đúng hướng.
Logging – ghi lại các actions, như là database queries, requests và response vào bộ lưu trữ log tập trung. Bạn có thể tham khảo logging libraries và công cụ quản lý log.
Lập các phiên bản (version) cho phép triển khai và test bản cập nhật app tiếp theo, cùng lúc với phiên bản hiện tại vẫn hoạt động. Khi ứng dụng ngày càng phát triển thì việc thay đổi cũng trở nên thường xuyên hơn và việc tạo version phù hợp cho phép lập trình viên xử lý hiệu quả hơn. Có hai cách để version:
URL – với ví dụ là “/accounts/v2.1/{id}”
Header – đính kèm header như “X-Version:2.1.”
Team mình thì dùng URL như sau:
Mỗi loại sẽ có ưu khuyết riêng, nên tùy tình hình mà mỗi team nên có lựa chọn phù hợp.
Viết test case và documentation
Kinh nghiệm thực tế của mình cho thấy việc ghi lại các test case trước khi develope giúp cho việc planning và hình dung end product (sản phẩm cuối) rõ ràng hơn trước khi nhảy vào code; giúp giảm thiểu những thay đổi sau đó. Cũng có những trường hợp viết test case cho phép phát hiện các tác động downstream lên codebase – nhất là khi app đang phát triển.
Test-driven development (TDD) là phương pháp phổ biến trong việc viết test case trước khi bắt đầu giai đoạn development. Phương pháp này có những lợi ích nhưng cũng tốn khá nhiều thời gian. Với các service quan trọng thì mình khuyên nên viết test case phức tạp hơn, trên Internet cũng có những testing framework để bạn follow.
Mình không nhận thấy tầm quan trọng của việc document lại quá trình cho đến khi team có nhiều thành viên hơn cũng như số lượng dự án nhiều hơn. Team cũng không có tài liệu hay documentation cụ thể vì đang cung cấp sản phẩm theo tiến độ rất nhanh – hầu như là show của 1 hay 2 dev gì thôi. Sau đó thì công việc phát triển sản phẩm trở nên chậm hơn vì tụi mình phải liên tục trao đổi để làm rõ code khi cộng tác chéo các project. Và việc này tốn rất nhiều thời gian cũng như làm giảm năng suất hẳn.
Sau khi thử nghiệm vài cách dữ liệu hóa API, thì team mình nhận thấy Postman documentions là phù hợp nhất, vì hầu hết tụi mình dùng Postman cho API development.
Tóm lại code backend chuẩn là gì
Có thể các lợi ích của những điểm tiêu chuẩn backend mình liệt kê chưa rõ ràng khi bạn đang bắt đầu team số lượng nhỏ. Mình thì chỉ nhận ra những điều này khi team bắt đầu phát triển và làm nhiều dự án hơn.
Mình cũng khuyên nên bắt đầu tìm hiểu về những phương pháp mình nói trên. vì một trong những thử thách lớn nhất mà mình nhận ra đó chính là coding habit xấu sẽ khó thay đổi hơn ở các giai đoạn tiếp theo của phát triển dự án.
Các chương trình Product Manager tuyển dụng luôn đặt ra yêu cầu cao về trình độ cũng như kỹ năng của các ứng viên. Họ phải là người có được khả năng làm việc tốt, giao tiếp chuyên nghiệp và kết nối được các bên liên quan với nhau để hoàn thành kế hoạch phát hành một sản phẩm. Nhưng làm thế nào để tuyển được những ứng viên xuất sắc như thế? Nhà tuyển dụng phải làm gì để nắm bắt được các tiêu chuẩn cần có này? Bài viết dưới đây sẽ chia sẻ những manh mối để phát hiện được người phù hợp nhất với yêu cầu của công ty.
Cần nắm rõ các kỹ năng để tuyển được Product Manager làm việc tốt nhất
7 tips tuyển dụng Product Manager là gì?
Khả năng giải quyết vấn đề
Đây là khả năng được đánh giá cao nhất của các Product Manager khi làm việc với team của mình. Công việc của Product Manager là gì? Họ luôn phải kết nối với các phòng ban liên quan trong quá trình phát hành sản phẩm, việc đưa một sản phẩm ra thị trường thành công luôn đòi hỏi nhiều giải pháp sáng tạo cho những thách thức bất ngờ. Vì vậy, khi các công ty đang tìm kiếm một Product Manager mới, họ sẽ tìm kiếm ở ứng viên khả năng giải quyết vấn đề một cách thuần thục nhất, vốn thường thể hiện là tư duy sáng tạo.
Đương nhiên là bạn không nên đặt ra những câu hỏi mang tính đánh đố với ứng viên. Hãy cố gắng tạo điều kiện cho họ thể hiện được nhiều nhất về nền tảng kinh nghiệm, sau đó giới thiệu về sản phẩm của công ty và hỏi họ cách để quản lý hoặc cải thiện nó. Từ cuộc thảo luận này, bạn sẽ nhìn nhận được tư duy sáng tạo và năng khiếu giải quyết vấn đề một cách hết sức tự nhiên.
Ngay cả khi ứng viên cho vị trí Product Manager đã thông qua việc kiểm tra tất cả những kỹ năng cần có như: nền tảng quản lý sản phẩm vững chắc, kinh nghiệm làm việc trong ngành, kiến thức kỹ thuật vững chắc. Nhưng nếu có nhiều yếu tố cho thấy ứng viên không thể giao tiếp rõ ràng và hiệu quả với các leader team khác thì họ vẫn chưa đạt yêu cầu cho vị trí này.
Product Manager cần biết cách giao tiếp hiệu quả
Khả năng thấu hiểu của Product Manager là gì?
Khả năng này sẽ giúp Product Manager hiểu được quan điểm và suy nghĩ của khách hàng. Họ có thể thực sự thấu hiểu mọi thứ dựa trên quan điểm của khách hàng và xây dựng sản phẩm phù hợp với nhu cầu, mong muốn, đáp ứng được mọi sự lo sợ của khách hàng và các động lực khác. Trong khi đó nếu là một Product Manager thiếu năng lực sẽ cố gắng ép buộc một giải pháp mà khách hàng không thực sự yêu cầu.
Cách nói chuyện thu hút hay khả năng lãnh đạo, làm việc thuyết phục là yếu tố mang tính chuyên nghiệp cao và cần sự rèn luyện lâu dài mới có được. Product Manager có vai trò quan trọng trong việc điều phối và lãnh đạo một team lớn. Dù họ đảm nhận nhiều vai trò, nhưng thường không có bất kỳ quyền hạn thực sự nào đối với bất kỳ ai trong nhóm đó. Trên thực tế, họ phải làm việc với cả những lãnh đạo lớn hơn trong hệ thống công ty. Vậy làm thế nào để Product Manager phát hành sản phẩm thành công? Đó là nhờ khả năng lãnh đạo.
Một Product Manager giỏi sẽ có khả năng xây dựng các mối quan hệ và tạo ra sự nhiệt tình giữa các team chịu trách nhiệm phát triển sản phẩm đó. Và để thành công khi đối mặt với tất cả những thách thức khi làm việc, Product Manager cũng cần có sức hút, thông qua cách nói chuyện, trao đổi,… để khiến khách hàng và đồng nghiệp cảm thấy tin tưởng vào sự thành công của sản phẩm.
Theo Shivan Bindal, Product Manager tại Procore, “Một Product Manager tò mò sẽ không bao giờ hài lòng chỉ với một câu trả lời”. Quản lý sản phẩm là một vai trò đòi hỏi nhiều sáng kiến và động lực từ bên trong. Họ sẽ chỉ đưa ra những quyết định mang tính chiến lược và tốt nhất sau khi đã nghiên cứu và điều tra một cách nghiêm túc, kỹ lưỡng.
Đây cũng là một trong những đặc điểm quan trọng để đánh giá một Product Manager. Quá trình phát triển sản phẩm là một quá trình dài, thường là vài tháng, thậm chí lên đến vài năm. Đương nhiên trong quá trình đó sẽ kéo theo những thất bại và cả sự thất vọng. Nếu người quản lý sản phẩm chịu trách nhiệm thúc đẩy sự phát triển đầy chông gai và kéo dài đó không đủ đam mê thì toàn bộ nỗ lực có thể “trượt khỏi đường ray” bất cứ lúc nào.
Đam mê giúp các Product Manager vượt qua khó khăn
Thoải mái hơn với thất bại
Những Product Manager thông minh, biết nhìn xa trông rộng sẽ hiểu rằng mọi sản phẩm đơn lẻ nào hoặc những lần ra mắt thị trường cụ thể nào, sản phẩm đều có thể bắt buộc phải giảm giá với bất kỳ lý do nào. Và những Product Manager chuyên nghiệp sẽ không cảm thấy thất vọng với điều đó. Thay vào đó, họ muốn một người quản lý sản phẩm có thể có những phản ứng thích hợp, dành một chút thời gian để buồn bã và sau đó bắt đầu thu thập những kiến thức hữu ích có thể thúc đẩy lần ra mắt tiếp theo thành công.
Kết luận
Rõ ràng vị trí Product Manager là vị trí luôn đòi hỏi những yêu cầu cao với ứng viên do họ là những thành phần đóng vai trò quyết định quan trọng trong sự thành bại của một sản phẩm, thậm chí là cả một công ty. Vậy nên, các nhà tuyển dụng sẽ luôn cân nhắc, lựa chọn người thích hợp nhất dựa trên nhiều tiêu chí khác nhau như thế. Để ứng tuyển thành công, ngay từ bây giờ các ứng viên nên trau dồi kỹ năng cho riêng mình.
Xuất hiện tại thị trường Việt Nam từ năm 2011, AS White Vietnam – Công ty con của tập đoàn As White Global, đã không ngừng phát triển và đứng vững trên thị trường. Đây là môi trường làm việc tuyệt vời với đầy đủ sự chuyên nghiệp, quốc tế, cùng với nền tảng vững chắc và nhiều cơ hội phát triển, xứng đáng là điểm đến lý tưởng cho các nhân tài công nghệ tỏa sáng sự nghiệp.
AS White Vietnam – Mang giá trị “lành nghề” Việt Nam vươn xa đến thị trường Úc
AS White Global là công ty chuyên về các giải pháp nhân sự tích hợp ở nước ngoài với đội ngũ hơn 1000 nhân sự cùng nhiều văn phòng trải khắpSydney, Việt Nam, Philippines và Malaysia. AS White Global đã và đang thực hiện tốt sứ mệnh cung cấp cho các doanh nghiệp tại Úc những “mảnh ghép” tài năng nhất để phát triển đội ngũ toàn cầu của mình.
Là cánh tay đắc lực cho sự phát triển của tập đoàn, AS White Vietnam ra đời với mục đích hỗ trợ công ty mẹ gắn kết nhân tài với các công ty đang có nhu cầu tuyển dụng tại Úc, mang đến các giải pháp tổng hợp nhân sự tối ưu giúp doanh nghiệp tìm kiếm những ứng viên sáng giá và tài năng, phù hợp cho từng vị trí thuộc nhiều lĩnh vực ngành nghề cũng như đáp ứng yêu cầu khắt khe nhất.
Tại Việt Nam, hiện công ty đã và đang làm việc với các khách hàng thuộc hơn 23 lĩnh vực khác nhau, từ Tài chính, Vật liệu xây dựng, Dịch vụ môi trường, CNTT, đến Tư vấn quản lý, Bất động sản, Bán lẻ và Viễn thông.
Với nhiệm vụ cung cấp các giải pháp nguồn nhân lực công nghệ thông tin tích hợp đầu – cuối phù hợp với mô hình của từng khách hàng doanh nghiệp, As White Vietnam đã không ngừng áp dụng các quy trình, công cụ và phần mềm phù hợp với yêu cầu của khách hàng để đảm bảo mọi hoạt động vận hành một cách hoàn hảo và nhanh chóng đem lại hiệu quả kinh doanh. Khách hàng của As White Vietnam sẽ được hỗ trợ mở rộng quy mô kinh doanh thông qua các giải pháp cần thiết và điều kiện cơ sở phù hợp:
Tiếp cận thị trường nhân tài có trình độ cao tại khu vực Đông Nam Á;
Xây dựng đội ngũ nhân lực tài năng toàn cầu;
Tự chủ trong các hoạt động tuyển dụng;
Hỗ trợ khách hàng triển khai các chức năng quản lý nhân sự.
Mang sự độc đáo và chuyên nghiệp trong văn hóa làm việc từ quê hương nước Úc, AS White Vietnam tự hào là đơn vị đáng tin cậy cho các doanh nghiệp nước ngoài mong muốn tìm kiếm nguồn nhân lực cao cấp tại khu vực Đông Nam Á, tạo cơ hội phát triển sự nghiệp cho các tài năng Việt.
Thành công và phát triển bền vững với vốn tài sản lớn nhất mang tên “con người”
Minh bạch, toàn diện và tinh thần đồng đội gắn kết là những giá trị cốt lõi xây dựng nên một tập thể AS White thống nhất. Thừa hưởng những giá trị cốt lõi từ công ty mẹ, AS White Vietnam xem “con người” là tài sản quý giá nhất của mình, đồng thời tạo mọi điều kiện cho sự phát triển tối đa của mỗi thành viên.
Đến với AS White Vietnam, bạn được tự do sáng tạo trong môi trường Agile tiên tiến, thúc đẩy mọi năng lực, sức mạnh tiềm tàng. Tài năng của bạn luôn được phát triển tối đa với các dự án thuộc nhiều lĩnh vực và cơ sở hạ tầng hiện đại.
Không những vậy, AS White Vietnam còn chú trọng đến sự phát triển của từng cá nhân trong tổ chức, xây dựng nền văn hóa doanh nghiệp lành mạnh, tôn trọng lẫn nhau, tạo cơ hội bình đẳng và công bằng cho mỗi cá nhân – “Phần tử” quan trọng cấu tạo nên tập thể AS White Vietnam vững mạnh.
Mở rộng phát triển, tìm kiếm nhân tài hoàn thiện đội ngũ, AS White Vietnam sẵn sàng cùng bạn bứt phá thành công
Cơ hội đặc biệt chạm tay các nhân tài công nghệ khi AS White Vietnam mở ra đợt tuyển dụng với 2 vị trí cùng mức offer hấp dẫn và đãi ngộ tuyệt vời:
Kiểm thử qui hồi, hiểu một cách đơn giản, là phương thức kiểm thử để xem ứng dụng ở phiên bản mới có làm thay đổi hoặc có ảnh hưởng gì đến các chức năng đã có sẵn của ứng dụng hay không. Các lỗi (bug) từng xảy có còn lặp lại hay không. Tuy nhiên, vấn đê hấp dẫn chúng ta cần tìm hiểu ở đây là vì sao chúng ta gọi cách kiểm thử này là “Regression Testing”?
Theo cách nhìn của mình, kiểm thử qui hồi được đặt tên như vậy là vì, khi chúng ta phát hiện một vấn đề của phiên bản mới, chúng ta phải quay về (regress) lại phiên bản trước đó.
Agile ngày càng thay thế mô hình truyền thống Thác Nước (Waterfall) là dựa vào ý tưởng tăng tốc độ quy trình phát triển phần mềm, rút ngắn thời gian đưa sản phẩm đến tay khách hàng, tăng cường lấy phản hồi và chỉnh sửa ứng dụng nhầm đáp ứng nhanh nhất sự thay đổi yêu cầu của khách hàng.
Kiểm thử qui hồi trong môi trường Agile
Với đặc điểm của mô hình Thác Nước, sản phẩm đến tay của kỹ sư kiểm thử không quá liên tục, các kỹ sư kiểm thử có đủ thời gian để thiết kế kịch bản kiểm thử, tiến hành kiểm thử chức năng mới và làm cả kiểm thử qui hồi trong khi đợi các phiên bản cập nhật từ đội ngũ phát triển ứng dụng.
Với mô hình Agile thì ngược lại, tốc độ ra phiên bản mới của ứng dụng có thể tính theo tuần, thậm chí là theo ngày, giờ. Kiểm thử các chức năng mới đồng thời kiểm thử qui hồi các chức năng cũ đã tạo nên một áp lực không nhỏ lên đội ngũ kiểm thử phần mềm.
Một câu chuyện kinh điển
Khi bắt đầu dự án, một đội ngũ phát triển được thiết lập với tỉ lệ 3 dev : 1 tester. Giả thiết rằng chúng ta có 6 kỹ sư phát triển và 2 kỹ sư kiểm thử. Mô hình Agile được thiết lập với mỗi 2 tuần cho một Sprint. Mọi thứ bắt đầu.
Ở Sprint đầu tiên, chúng ta bắt đầu với những chức năng cơ bản (ví dụ khoảng 10 chức năng), kỹ sư kiểm thử bắt đầu thiết kế các kịch bản kiểm thử tiến hành kiểm thử (ví dụ khoàng 100 kịch bản). Mọi chuyện tốt đẹp. Sprint đầu tiên nhận được đánh giá tốt từ khách hàng.
Qua sprint thứ hai, kỹ sư phát triển tiếp tục làm những chức năng mới – cũng khoảng 10 chức năng, và kỹ sư kiểm thử cũng làm những việc như sprint đầu tiên – với thêm 100 kịch bản mới; cộng với 100 kịch bản cũ cần làm kiểm thử qui hồi. À được, chỉ 200 kịch bản thôi, mọi chuyện vẫn còn trong tầm kiểm soát.
Qua sprint tiếp theo, kỹ sư phát triển chỉ cần làm 8 chức năng mới và chỉnh sửa 2 chức năng cũ do nhu cầu khách hàng thay đổi so với ban đầu. Lúc này, 2 kỹ sư kiểm thử không chỉ phải thiết kế kịch bản kiểm thử cho 8 chức năng mới, mà còn phải kiểm tra và cập nhật 200 kịch bản cũ để đáp ứng yêu cầu mới của khách hàng. Cuối cùng, là thực thi toàn bộ khoảng 300 kịch bản. Bạn đã cảm thấy có gì đó “sai sai” chưa?
Qua khoảng vài sprint kế tiếp, 3 kỹ sư phát triển vẫn đáp ứng được số lượng chức năng và yêu cầu thay đổi của khách hàng, nhưng với 2 kỹ sư kiểm thử, số lược kịch bản cần tạo ra và cập nhật, chỉnh sửa càng lúc càng nhiều, số lượng kịch bản cần thực thi của sprint sau nhiều hơn sprint trước.
Một sự mệt mỏi bắt đầu lan tỏa. Sự thiếu thời gian để hoàn thành kiểm thử ứng dụng trước khi đưa đến tay khách hàng càng lúc càng hiện rõ. Nguy cơ bỏ sót lỗi (miss bug) càng lúc càng cao. Yêu cầu thêm nhân sư cho kiểm thử được đưa ra liên tục cho các cấp lãnh đạo, đi kèm với nó là việc tăng chi phí cho đội ngũ phát triển.
Quá nhiều vấn đề phát sinh, phải không?
Kiểm thử tự động
Với những vấn đề ở trên, tự động hóa là câu trả lời all-in-one (giải pháp cho tất cả) cuối cùng mà chúng ta nhận thấy. Vấn đề còn lại là, làm sao để tự động hóa việc kiểm thử một các hiệu quả?
Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
Load balancing giúp hệ thống mở rộng theo chiều ngang bằng cách ngày càng tăng số lượng các máy chủ, nhưng Caching lại là cách để sử dụng tài nguyên (resource) hiệu quả hơn từ đó resource cần cung cấp giảm đi, nhằm tiết kiệm resource và giảm chi phí của hệ thống.
Để làm được điều này, hệ thống sẽ cung cấp một vùng nhớ đệm (cache) để chứa những dữ liệu được request nhiều lần mà không thường xuyên thay đổi vào đó, từ đó hệ thống sẽ lấy dữ liệu từ bộ nhớ cache mà không truy cập vào bộ nhớ chính. Điều này giúp bộ nhớ chính sẽ được giảm tải đi từ đó năng lực của nó tăng lên.
Bộ nhớ cache được sử dụng rất rộng rãi trong mọi thành phần của hệ thống như trong phần cứng (hardware) như RAM/CPU Cache, hệ điều hành (operating systems), trình duyệt web (web browsers), web applications v.v… Bộ nhớ cache giống như một bộ nhớ ngắn hạn (short- term memory) nó có giới hạn về kích cỡ, nhưng thường nhanh hơn rất nhiều lần bộ nhớ chính
Về kiến trúc phần mềm thì Cache có thể tồn tại ở hầu hết các thành phần, nhưng chủ yếu nó tồn tại ở phần thao tác với dữ liệu như Database Layer, giúp trả về dữ liệu nhanh hơn mà không cần tốn chi phí để truy cập vào Database, hay ở phần Front-end để Cache những resource tĩnh như js, css, image file bằng cách dùng CDN.
BỘ ĐỆM TẦNG BACKEND(APPLICATION SERVER CACHE):
Ở tầng backend Cache được áp dụng như một bản sao hoặc một phần của DB/Storage, mỗi lần ứng dụng request dữ liệu từ DB/Storage nó sẽ tìm trong bộ nhớ Cache, nếu có ứng sẽ trả về dữ liệu tức thì mà không tốn tài nguyên để query xuống DB/Storage. Tuy nhiên nó chỉ có tác dụng với những dữ liệu được truy cập nhiều lần nhưng ít được thay đổi, ví dụ thông tin cá nhân của người dùng (tên, quê quán/quốc tịch, ngày tháng năm sinh, địa chỉ, số điện thoại…).
Nếu ta có nhu cầu gia tăng khả năng chịu tải bộ nhớ Cache theo mô hình horizontal scaling, khi đó ta sẽ có thêm nhiều node và mỗi node sẽ chứa các dữ liệu của riêng nó. Tuy nhiên điều này sẽ dẫn đến số lượng “cache miss” tăng cao vì LB sẽ tùy chọn ngẫu nhiên 1 node mỗi request từ đó một request sẽ tới nhiều “cache node” khác nhau. Và để giải quyết điều này ta có hai sự lựa chọn là sử dụng duy nhất một nhớ Cache lớn, hoặc phân chia dữ liệu cache trên cụm server với Consistent Hashing
BỘ ĐỆM TẦNG FRONTEND — CONTENT DISTRIBUTION NETWORK (CDN)
CDN được sử dụng để caching những resource tĩnh trên các website như js, css, images… (static media) mạng lưới CDN sẽ được đặt ở nhiều vùng địa lý khác nhau và dựa theo địa chỉ của từng request mà các static media sẽ được trả về từ trên các máy chủ CDN ở gần nó nhất, nếu không có trên tất cả các máy chủ CDN thì nó sẽ lấy dữ liệu đó từ Back-end Server để trả về và đồng thời cached dữ liệu vừa lấy lên CDN. Nhờ vậy ta có thể tăng tốc khả năng chịu tải cũng như tốc độ của website.
Nếu hệ thống của bạn không đủ lớn để xây dựng một CDN riêng của mình thì bạn cũng có thể sử dụng các dịch vụ CDN sẵn có như như Cloudflare, BootstrapCDN hay Amazon CloudFront v.v…
CACHE INVALIDATION
Về bản chất Cache là một bản sao của bộ nhớ chính có thể là DB hay các dạng Storage khác, ví dụ dữ liệu từ DB được update, thì cache phải được update theo (invalidated cache).Cho nên việc đồng bộ dữ liệu giữa bộ nhớ chính và Cache để giải quyết tính consistency của hệ thống là một vấn đề phải giải quyết.
Ta có 3 chiến thuật để giải quyết vấn đề về cache invalidation là:
1. Write-through cache
Là chiến thuật khi có dữ liệu cần thay đổi, hệ thống sẽ ghi dữ liệu cả và Cache hoặc DB đồng thời. Việc này sẽ đảm bảo được việc dữ liệu sẽ luôn luôn consistency bởi vì process sẽ không thành công và phải thực hiện lại nếu một trong hai thao tác ghi vào Cache hoặc ghi vào DB bị lỗi. Tuy nhiên điểm yếu của chiến thuật này là độ trễ cao trong việc ghi dữ liệu, vì đòi hỏi cả hai thao tác ghi từ DB và Cache phải được hoàn thành.
2. Write-around cache
Chiến thuật này khi có dữ liệu cần thay đổi, sẽ chỉ ghi vào DB mà bỏ qua Cache. Điều này sẽ có thể giảm việc Cache bị tràn ngập các thao tác ghi mà rất có thể các dữ liệu này sẽ không bao giờ được sử dụng. Tuy nhiên việc này sẽ gây ra trường hợp “cache miss” nếu client gửi một request được từ một bản ghi mới được ghi vào, nó sẽ gây độ trễ khi đọc vì lúc này dữ liệu phải đọc từ DB sau đó mới được ghi ngược lại vào Cache và trả về cho Client. Và chiến thuật này chỉ phù hợp với những dữ liệu ít thay đổi và hệ thống chấp nhận độ trễ của dữ liệu, vì dữ liệu có thể không consistency trong lúc Cache chưa hết hạn (expired) mà có dữ liệu mới đã được update.
3. Write-back cache
Là khi có dữ liệu cần thay đổi, sẽ chỉ ghi vào bộ nhớ Cache mà bỏ qua DB, dữ liệu chỉ ghi vào DB sau một khoảng thời gian (interval) hoặc với điều kiện nào đó. Điều này sẽ có lợi ích tạo ra cho hệ thống độ trễ thấp (low latency) và lưu lượng cao (high throughput) với những hệ thống chuyên ghi (write-intensive). Tuy nhiên chiến thuật này có độ rủi ro cao về mất mát dữ liệu, bởi vì trước khi dữ liệu được ghi vào DB thì dữ liệu của chúng ta chỉ nằm ở trong Cache, bất kỳ một sự cố nào về Cache đều có thể gây mất mát dữ liệu.
CACHE EVICTION POLICIES
Ngoài ra ta cũng có các cách chiến thuật xóa dữ liệu không còn cần thiết từ Cache.
1. First In First Out (FIFO): Cách dữ liệu được ghi vào Cache trước thì sẽ được ưu tiên xóa đi trước mà không quan tâm tới tần suất hay số lượng truy cập của nó.
2. Last In First Out (LIFO): Sẽ ưu tiên xóa những dữ liệu được ghi cũ nhất mà không quan tâm tới tần suất hay số lượng truy cập của nó.
3. Least Recently Used (LRU): Sẽ xóa những dữ liệu ít được truy cập gần đây trước tiên.
4. Most Recently Used (MRU): Sẽ xóa những dữ liệu được truy cập thường xuyên gần đây nhất.
5. Least Frequently Used (LFU): Sẽ xóa những dữ liệu ít được truy cập nhất.
6. RR: Sẽ trọn ra một dữ liệu bất kỳ trên Cache để thực hiện thao tác xóa.
Thông thường thì hệ thống sẽ đánh dấu thời điểm hết hạn (expire time) của dữ liệu, nếu quá thời hạn thì Cache sẽ bị xóa đi. Tính toán expire time của Cache cũng là một bài toán khá đau đầu tùy vào logic của hệ thống đang phát triển.
Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh
Hello các bạn! Lại là Xuân Quỳnh đây. Trong bài trước bạn đã biết cách sử dụng cmd để build 1 file C ra file exe. Bạn thấy hay không? Bài này tôi sẽ giới thiệu 1 kiến thức mới hay chả kém. Đó là in ra 1 câu chào ra màn hình Đơn giản vậy thôi.
OK bây giờ tôi nhắc lại file C hôm trước các bạn xài:
voidmain(){printf("Chao em C xinh dep");}
Tôi vừa thêm 1 lệnh viết bằng tiếng Anh là printf, nghĩa là in ra màn hình dòng chữ chào em C xinh đẹp :)) Thấy hay không? Bây giờ tôi build thử bằng dòng lệnh nha.
Bạn cd vào thư mục chứa file C của bạn, tôi thì thế này:
cd /d F:\C_project
Bạn nào đọc xong chả hiểu dòng này vui lòng xem lại 2 bài trước nhé.
Rồi, bây giờ tôi đang trong thư mục chứa code C. Tôi tiến hành build như bài hôm trước tôi làm:
gcc goobyec.c -o goodbyec
Rồi tôi nhận được một cái thông báo như sau:
Bạn chú ý dòng đỏ tôi bôi đó. Bạn thấy nó note gì không? Hãy thêm cái stdio.h hoặc định nghĩa 1 hàm printf để sử dụng hàm này. OK, lý do là hàm printf cần thư viện stdio.h đó nạ Cái này giống như kiểu bạn muốn chạy xe máy thì phải đổ xăng vậy đó, printf thuộc thư viện stdio.h. Muốn dùng thì include vào :))
Rồi bây giờ tôi sửa lại code như sau:
#include <stdio.h>voidmain(){printf("Chao em C xinh dep");}
Rồi tôi build lại. Thì nó hết mấy cái warning :)) Bạn hiểu thế này. Có 1 nhóm người viết ra ngôn ngữ C, bọn nó đặt tên file stdio.h và định nghĩa 1 hàm printf trong đó. Nếu Việt Nam mình mà biết cách thì tạo ra 1 ngôn ngữ C của Việt Nam. Giả sử tôi đặt tên file là vaora.h và trong file này tôi có hàm inra để in các ký tự ra màn hình. Tiếc là nhà mình không đủ tiền và do cái chế độ phong kiến đô hộ lâu quá mà mãi tới năm 97 công nghệ thông tin mới thực sự vào Việt Nam :)) Thôi thì chấp nhận Việt Nam mình nghèo vì lạc hậu. Bạn yên tâm, bài sau tôi sẽ định nghĩa 1 file như thế cho bạn xem, tôi cũng sẽ tạo 1 hàm inra cho bạn xem =)) Cứ nằm im hưởng thụ cái này đã.
Rồi bây giờ tôi muốn chạy chương trình thì làm thế nào. Bạn xem hình này:
Bạn để ý cho tôi dòng 1. Tôi giải thích như sau: Ở window bạn chỉ cần gõ đúng tên file exe của chương trình vừa build là nó in ra màn hình cho bạn. Còn trên linux thì bạn phải gõ như này:
./goodbyec
Bạn biết vì sao lại thế không? bởi vì linux chả giống win. Linux đối xử với mọi thứ là tệp. Mà nó coi file exe là 1 tệp đóng gói, ông muốn chạy nó thì ông thêm ./ trước tên file cho tôi. Tôi cũng khuyên bạn nào muốn học C cho pro thì cũng nên xài linux cho biết. À, đợt này win 10 cũng đã tiến hành tích hợp nhân linux trên window rồi đấy, cho nên anh em cứ ls các kiểu là nó cũng chơi với linux. Linux và window bây giờ yêu nhau rồi đó :))
Dòng 2 là cái kết quả bạn xem đó nạ :3
Hôm nay tôi chỉ giới thiệu từng ấy thôi. Bạn mà thấy ít quá thì để lại comment cho tôi ở dưới bài. Tôi sẽ nâng kiến thức dần dần qua từng bài, để việc tán em C là việc cần thời gian, mưa dầm thấm lâu. Tôi định bài tiếp giới thiệu về makefile, 1 khái niệm mà có lẽ nhiều ông sinh viên học C ra chả biết nó là cái gì Tiếc là chưa có 1 giáo trình C nào cho chuẩn, mà sinh viên mình thì ngại đọc tiếng Anh.
Tầm nhìn lãnh đạo được xem là một yếu tố quan trọng tạo nguồn động lực, truyền cảm hứng mạnh mẽ đến các nhân sự tiềm năng không ngừng phát huy và hoàn thiện bản thân. Cùng TopDev điểm qua 5 câu hỏi sau giúp phát triển tầm nhìn lãnh đạo trong bạn.
Người có ảnh hưởng lớn đến cuộc sống của bạn là ai? Và bạn học được gì từ họ trên cơ sở kỹ năng lãnh đạo nhân sự?
Ai là người ảnh hưởng đến bạn nhất?
Đây là một câu hỏi quan trọng. Và xu hướng chung của các nhà lãnh đạo nhân sự thường nhắc đến người có ảnh hưởng lớn đến họ thường là gia đình, cố vấn chuyên môn, bạn bè,..
Ít khi họ đề cập đến những gương mặt cụ thể là các ông lớn, các lãnh đạo của các bệ phóng tổ chức tiềm năng. Việc tự nhìn nhận lại giúp họ xác định được ai là nguồn động lực thôi thúc họ phát triển; không ngừng vươn tới những đỉnh cao mới.
Đâu là mục đích cuộc sống của bạn? Bạn là ai và bạn muốn đạt được điều gì?
Không một người thành công nào mà không có những hoài bão, mục đích cuộc sống của mình.
Như đơn giản bạn quyết định trở thành một freelancer it hay Senior Developer, bạn sẽ có kế hoạch để thực hiện mục tiêu một cách tốt hơn. Việc xác định mục tiêu giúp bạn thiết lập lộ trình hai phá bản thân và tiến hành các thử thách nhằm hướng đến mục tiêu cuộc sống.
Giá trị cốt lõi của bạn là gì? Yếu tố sẽ giúp định hướng hành vi của bạn trong hành trình sống cuộc sống “có mục đích”?
Hiểu một cách đơn giản, giá trị cốt lõi điều bạn cho là quan trọng nhất đối với bạn. Đồng thời nó cũng bao gồm các giá trị thực mà bạn muốn tạo ra với tự cách là một nhà lãnh đạo nhân sự.
Liệu bạn có thật sự tìm ra giá trị cốt lõi của bản thân?
Sự giàu có, tình cảm,… có thể là thứ quan trọng nhất của bạn. Nếu được, bạn hãy liệt kê chúng ra. Và bắt đầu phân tích mức độ giá trị mà chúng chi phối đến bạn. Sắp xếp chúng theo thứ tự để biết được cái nào bạn cần tập trung phát triển.
Như thế, bạn dễ dàng xác giá trị cốt lõi. Hay nói cách khác là hiểu bản thân mình. Đồng thời, đó là cơ sở quan trọng để một bạn phát huy tố chất lãnh đạo nhân sự một cách tốt hơn.
Từ việc trải nghiệm thực tế, quan điểm lãnh đạo của bạn là gì?
Đối với một nhà lãnh đạo nhân sự tài năng, quá trình hoàn thiện và phát triển rất quan trọng. Chính khoảng thời gian cọ xát với thực tế, họ nhận ra bản thân đang thiếu sót ở đâu. Từ đó đề ra các kế hoạch bồi dưỡng.
Tầm nhìn lãnh đạo được phát triển dựa trên sự hiểu biết không chỉ về kiến thức chuyên môn mà còn nằm ở tư duy. Do vậy, khi có quá trình đúc kết các kinh nghiệm, bạn có thể tự tin đưa ra một quan điểm lãnh đạo riêng của riêng mình.
Quan điểm lãnh đạo có ý nghĩa đặc biệt. Vì nó là dấu ấn riêng của mỗi cá nhân. Nó thấy bạn đã đủ trưởng thành. Đồng thời, tiềm năng về tầm nhìn lãnh đạo của bạn đã được phát huy một cách hiệu quả. Từ cơ sở này, bạn có đủ năng lực để sẵn sàng chinh phục bước tiếp theo – Đào tạo và phát triển thế hệ nhân sự lãnh đạo trẻ.
Nhân sự tiềm năng có thể mong đợi gì từ bạn?
Bạn là lãnh đạo, bạn có quyền lực và có tiếng nói. Tuy nhiên, hãy là người lãnh đạo có quyền lực và tiếng nói thể hiện đúng các giá trị mà bạn theo đuổi.
Điều gì mà giới nhân sự tiềm năng đáng chờ đợi ở bạn?
Bạn phải đặt câu hỏi: Bạn cho họ được điều gì? Họ cần bạn giúp bạn khai phá khía cạnh nào. Hãy sẵn sàng nhấn mạnh ý tưởng lãnh đạo. Vì đó là một quá trình hợp tác giữa người lãnh đạo và nhân viên. Bạn cần xây dựng một chân dung nhà lãnh đạo cho họ trên cơ sở là các tầm nhìn.
Nếu quan sát các chương tuyển dụng của nhiều công ty khác nhau như KMS Technology tuyển dụng, chúng ta sẽ nhận thấy có 5 loại profile khác nhau của các Product Manager. Có sự khác biệt gì giữa các loại này, hãy tìm hiểu với bài viết bên dưới.
5 loại profile của các Product Manager là gì?
Engineering Product Manager
Họ bắt đầu với vai trò của một kỹ sư thiên về kỹ thuật và chuyển sang làm công việc của một quản lý sản phẩm. Rõ ràng những người này sẽ rất giỏi các nhiệm vụ liên quan đến chuyên môn kỹ sư của mình. Do đó họ cũng dễ dàng thấu hiểu và làm việc với team engineering tốt hơn. Họ cũng có thể hiểu rõ các vấn đề về kỹ thuật và tìm ra lỗi sai để khắc phục tốt hơn.
Engineering Product Manager có thế mạnh về các yếu tố kỹ thuật
Tuy nhiên, những người này dễ gặp phải nhiều khó khăn khi chuyển sang vai trò mới. Việc chuyển từ các công việc mang tính cá nhân sang công việc đòi hỏi khả năng teamwork cao hơn cũng yêu cầu họ cần có tư duy rộng hơn, nắm được các yêu cầu hiện tại của thị trường đôi khi sẽ khiến họ gặp nhiều khó khăn.
Đây là những người chuyển từ công việc thiết kế sang làm Product Manager. Vậy công việc Product Manager là gì với họ? Lợi thế của những người này là họ có thể hiểu rõ được những cảm nhận của khách hàng để tạo ra những sản phẩm chất lượng và thú vị cho người dùng. Bên cạnh đó, họ cũng nắm được những vấn đề mà người dùng có thể gặp phải.
Để làm tốt công việc Product Manager, những người chuyển hướng từ công việc design nên có được khả năng quan sát một cách tổng quan về doanh nghiệp cũng như nắm được những vấn đề cần giải quyết cho sản phẩm của mình.
Business Product Manager
Đây là những người đã có kinh nghiệm làm việc trong công việc kinh doanh hoặc đã có bằng cấp, chứng chỉ quản trị kinh doanh,… Những người chuyển hướng từ chuyên môn kinh doanh sang làm Product Manager ngày nay đang trở nên rất phổ biến. Để làm tốt công việc này đòi hỏi họ phải có khả năng quan sát được bức tranh tổng thể của vấn đề, làm thế nào để đưa ra các quyết định phù hợp với mong muốn của các bên liên quan. Bên cạnh đó, khả năng giao tiếp của họ cũng được đánh giá rất cao. Do đó họ có thể làm việc tốt với tất cả các bên liên quan trong lộ trình phát triển sản phẩm.
Một điểm có thể làm khó nhóm ứng viên này là phải có con mắt quan sát tỉ mỉ từng khía cạnh của vấn đề. Sai lầm của họ là nghĩ rằng vai trò quan trọng nhất của Product Manager là phải có khả năng giao tiếp và thúc đẩy mọi người trong team làm việc tốt hơn mà thôi. Hãy nhớ rằng vai trò thật sự của một Product Manager tuyển dụng vào công ty cần được đặt lên hàng đầu chính là khả năng điều khiển mọi người trong team làm việc để đáp ứng yêu cầu sản phẩm của khách hàng.
Business Product Manager là những người có óc phân tích tốt
Data Product Manager là gì
Đây là những người có chuyên môn trong mảng phân tích dữ liệu. Họ thường có nền tảng làm việc với các con số nên có thế mạnh trong việc tiếp cận với các hướng dữ liệu khác nhau, chia nhỏ vấn đề để giải quyết được vấn đề lớn hơn, toàn diện hơn.
Tuy nhiên cũng cần cẩn thận vì họ phải phụ thuộc quá nhiều vào dữ liệu đôi khi lại gây phản tác dụng. Nhưng một Product Manager là gì và nên làm gì khi có xuất phát điểm là một người làm về data? Họ có thể nhìn ra được vấn đề bên trong các dữ liệu bằng trực giác cũng như từ những kiến thức mà họ có để giải quyết vấn đề.
Đây là những người làm trong team tăng trưởng – phát triển của công ty vậy nên thế mạnh của họ cũng tập trung nhiều nhất vào việc đẩy mạnh sự phát triển của dự án. Thế mạnh của những người này là có khả năng đưa ra các quyết định liên quan đến việc sáng tạo giải pháp để gia tăng chỉ số, họ biết cách làm việc để phát triển lộ trình sản phẩm.
Tuy nhiên, họ có quá nhiều giải pháp, thậm chí là nóng vội trong giải quyết vấn đề nên đôi khi nó không đem lại hiệu quả. Một Product Manager cần có tầm nhìn bao quát và thấu hiểu mọi vấn đề khi phát hành dự án. Để có thể nhìn nhận ra các vấn đề có thể xảy ra sau khi phát hành sản phẩm lần đầu tiên và cải thiện cho giai đoạn sắp tới của sản phẩm.
Kết luận
Để có thể làm rõ vấn đề cũng như nắm được kỹ năng của từng ứng viên khi tham gia ứng tuyển, như với chương trình KMS Technology tuyển dụng chẳng hạn, nhà tuyển dụng nên hiểu rõ về điểm mạnh và điểm yếu của từng profile. Từ đó có thể lên kế hoạch training và giúp nhân viên phát huy hết khả năng của mình khi làm việc.
Theo thông báo mới nhất từ Kubernetes thì nền tảng này sẽ loại bỏ Docker làm container runtime sau phiên bản 1.20. Tuy nhiên đừng hoảng hốt bởi vì sự việc chưa đến mức tệ đến thế.
Tóm tắt: Docker, với chức năng runtime cơ bản sẽ không được sử dụng Container Runtime Interface (CRI) đuợc tạo cho Kubernetes. Tuy vậy, Docker image vẫn hoạt động trong cluster với mọi runtime như từ trước đến giờ.
Đối với end-user của Kubernetes thì sẽ không thay đổi nhiều lắm. Thông tin này không đồng nghĩa sẽ khai tử Docker và cũng không có nghĩa bạn không thể, hay không nên dùng Docker làm development tool nữa. Docker vẫn sẽ là tool hữu ích để build container và các image từ việc chạy docker build vẫn có thể chạy trong Kubernetes cluster.
Nếu bạn đang sử dụng các service quản lý bởi Kubernetes như GKE, EKS, hay AKS (ser mặc định là container) thì bạn cần xác định là các node đang sử dụng container runtime được hỗ trợ trước khi Docker bị loại bỏ trong các phiên bản tương lai của Kubernetes. Nếu bạn có node customize thì có thể phải cập nhật dựa trên yêu cầu môi trường và runtime. Vì vậy hãy work với service provider để update việc testing và planning phù hợp.
Nếu bạn dùng cluster riêng thì bạn cần thay đổi để tránh cluster bị sập. Với phiên bản 1.20, sẽ có cảnh báo loại bỏ Docker. Khi Docker runtime support bị xóa trong các bản release tiếp theo của Kubernetes, nó sẽ không được support và lúc đó bạn cần đổi sang các container runtime khác, như containerd hay CRI-O. Hãy đảm bảo chọn runtime sẽ support cấu hình docker daemon bạn đang dùng (ví dụ như logging).
Tại sao đây là tin chấn động?
Chúng ta đang đề cập đến hai môi trường hoàn toàn khác nhau, dẫn đến dễ bị nhầm lẫn. Bên trong Kubernetes cluster, container runtime chịu trách nhiệm đẩy và chạy container image. Thì Docker là lựa chọn phổ biến cho runtime đó (lựa chọn khác là containerd và CRI-O) nhưng Docker không được thiết kế để tương thích với Kubernetes, đây là khi vấn đề nảy sinh.
Cái ta gọi là “Docker” không chỉ làm một việc – nó là toàn bộ tech stack, một phần của nó được gọi là “containerd” bản thân đã là container runtime high-level rồi. Docker rất cool ngầu và hữu dụng bởi vì nó có nhiều cải tiến UX giúp người dùng dễ dàng tương tác khi làm các công việc development nhưng những cải tiến này thật sự không cần thiết đối với Kubernetes, vì đơn giản Kubernetes không phải là “human”.
Kết quả của việc tạo ra lớp thân thiện với người dùng này là Kubernetes cluster phải dùng công cụ khác gọi là Dockershim để tích hợp – containerd. Điều này khá là phiền bởi vì chúng ta có thêm một cái để maintain và tăng khả năng mất kết nối. Thật ra thì Dockershim đã bị loại bỏ khỏi Kubelet từ phiên bản v1.23 cũng như bỏ hỗ trợ cho Docker như là container runtime luôn. Tới đây nhiều người thắc mắc, nếu containerd có bên trong Docker stack thì Kubenetes cần Dockershim làm gì nữa?
Docker không tuân theo CRI. Nếu có thì ta không cần shim chi nữa, nhưng đây không phải là vấn đề. Bạn chỉ cần đổi container runtime từ Docker sang một koại khác được hỗ trợ mà thôi.
Một điểm cần lưu ý là nếu đang dựa trên docker socket cơ bản (/var/run/docker.sock) trong workflow của cluster thì việc chuyển runtime khác có khả năng không dùng được nữa. Pattern này thường được gọi là Docker in Docker. Có nhiều lựa chọn cho trường hợp này như là kaniko, img và buildah.
Điều này có nghĩa là gì? Có cần phải viết Dockerfiles và build các thứ với Docker nữa không?
Thay đổi một môi trường khác sẽ tốt hơn cố gắng tương thích với Docker. Môi trường Docker bạn đang dùng để develop sẽ không liên quan đến Docker runtime bên trong Kubernetes cluster. Mình biết nó khá rắc rối. Đối với lập trình viên thì Docker vẫn hữu ích về mọi mặt trước khi có sự thay đổi lớn này. Container Image mà Docker tạo ra không theo Docker-specific image, mà nó theo chuẩn OCI (Open Conatiner Initiative). Bất kỳ Container Image tương thích với chuẩn OCI, dù tool bạn dùng là gì, đều tương thích với Kubernetes. Cả containerd và CRI-O đều xử lý và chạy Container image như nhau, đó là lý do vì sao có chuẩn dành riêng cho containers của chúng ta.
Tóm lại, sẽ có nhiều thay đổi diễn ra và phát sinh một vài vấn đề, nhưng chung quy đây không hẳn là hung tin hay biến động lớn gì cả. Tùy vào cách mà bạn tương tác với Kubernetes mà việc này ảnh hưởng nhiều hay ít. Xét về mặt lâu dài thì lợi nhiều hơn hại. Tất nhiên sẽ có rất nhiều câu hỏi được đặt ra vì không ai là chuyên gia 100% về lĩnh vực này cả. Hãy chờ xem những update tiếp theo ở các bản release từ Kubernetes nhé.
6 năm làm QA trong ngành IT, mình đã có cơ hội tiếp xúc với rất nhiều mô hình phát triển phần mềm: outsource, enterprise product base, startup product. Tất cả đều cho mình những trải nghiệm tuyệt vời và rất riêng về công việc làm QA. Cho đến bây giờ, khi mình nghe 1 bạn nào đó nói về công việc làm QA ở công ty họ mình thường quy nó về 1 trong 3 hình ảnh sau đây: Cảnh sát, thám tử, và nhà tư vấn ^^! Mỗi hình ảnh là 1 cách rất riêng để mo tả về người QA và công việc của họ.
Khi bạn nhận công việc này, bạn và mọi người hy vọng bạn sẽ là người hết lòng phục vụ nhân dân (ở đây chủ yếu là developers), là người mà nhân dân tin tưởng để giữ gìn trật tự xã hội (đảm bảo quality của sản phẩm). Bạn có luật pháp (process) như là công cụ đắc lực đê giúp bạn hoàn thành tốt công việc.
Nhưng mà, cho dù bạn có thành tâm trở thành 1 người “cảnh sát” tốt, bạn vẫn gặp rất nhiều sự hiểu lầm và kỳ thị. Developer sợ bạn và ghét bạn, đơn giản là vì bạn bắt lỗi của họ, bạn nói rằng cái code mà họ đổ mồ hôi công sức ra làm trong nhiều ngày là thứ không đạt yêu câu, thậm chí là vứt đi. Và rồi vì sợ và ghét bạn, họ tìm cách tránh né bạn, họ tìm cách giấu những lỗi lầm họ làm ra khỏi mắt bạn. Nếu bạn tìm ra nó, họ tìm mọi cách để kỳ kèo, nói rằng nó là lỗi không đáng và thuyết phục bạn cho qua.
Nhưng bạn nhân danh công lý và pháp luật phải làm sao để không có sai phạm nào diễn ra! Quality phải được đảm bảo! Bạn tuyệt vọng cố gắng hoàn thành nhiệm vụ đó mà chẳng ai giúp đỡ! Ai cũng nghĩ rằng bạn có thể làm chuyện đó một mình, giống như tất cả sai phạm của xã hội này đều phải được cảnh sát tìm thấy và giải quyết ^^. Tệ hơn nữa, Bug xảy ra! Và người ta luôn tìm đến QA để trách móc cho chuyện này.
Lâu dần, bạn trở nên cáu gắt, nghi kỵ với tất cả mọi người. Bạn xử lý problem của dự án với tâm trạng căng thẳng vì sợ mình bị quy chụp trách nhiệm. Bạn máy móc khi xử lý và tìm lỗi, tất cả gói gọn trong “trách nhiệm”! Bạn ghét Developer! Bạn không còn bao dung với họ khi tìm ra lỗi mà bạn biết họ không cố ý nữa. Bạn luôn test với nỗinghi ngờ là họ đang giấu mình điều gì đó, và bạn luôn cố gắng “Núp lùm” để canh bắt cho được lỗi, để vạch mặt những con người cố giấu lỗi lầm của họ mà gây hại cho bạn!
Đây từng là mẫu QA mà mình thích ^^. Bạn cũng là người phục vụ cho công lý nhưng bạn có suy luận sáng tạo, tư duy logic . Bạn có kỹ năng suy luận và tìm ra những ngóc ngách vấn đề bằng cách thu thập những chứng cứ ở hiện trường, bằng những câu hỏi thông minh với nghi phạm. Nhân chứng cũng đối xử thân thiện và cởi mở với bạn hơn là với cảnh sát …. Khi bạn phá án xong ai cũng trầm trồ thán phục! Mình từng nghĩ rằng 1 QA như vậy thì đúng là tuyệt vời!
Nhưng nếu bạn để ý kỹ, ngay cả 1 “thám tử” QA cũng mất quá nhiều thời gian để tìm hiểu một chức năng hay 1 vấn đề của dự án. Trước mắt bạn là kết quả của 1 team làm việc trong 2 tuần, đầu tắt mặt tối mỗi ngày để kịp giao cho bạn. Bạn nghĩ bạn sẽ mất bao lâu để tìm hiểu được hệ thống đó, chỉ bằng cách nhìn bề ngoài, nhìn cái kết quả? Bạn sẽ mất bao lâu để tìm thấy những bug nguy hiểm ẩn dấu bên trong?Cũng như thám tử, bạn sẽ phải đi hỏi từng nhân chứng để tái hiện lại trong đầu toàn cảnh vấn đề từ đầu đến cuối, để có thể tìm ra nguyên nhân và hung thủ. Cũng như thám tử, cũng có lúc bạn sẽ ân hận vì lúc bạn tìm ra được vấn đề thì mọi chuyện đã không cứu vãn được nữa, đã có thêm vài người nữa chết rồi!
Thực lòng mà nói, cái title này nghe ít “ngầu” nhất. Không giống như công an, bạn không có “quyền”. Không giống như thám tử, trong mắt mọi người bạn không có “tài” hay ít ra là nếu người bạn tư vấn làm điều tốt, thường thì công chẳng thuộc về bạn.
Nhưng mà khác với 2 hình mẫu phía trước, lần đầu tiên, bạn có thể thực sự ngăn cản bug xảy ra! Bằng kiến thức và lòng kiên nhẫn của mình, bạn và developer cùng tìm hiểu về hệ thống, bạn giúp developer nhận ra những vấn đề mà họ có thể gặp phải trong thời gian sớm nhất. Developer sẽ không bao giờ buồn bực về việc họ mất 2 phút để hiểu và làm cái bạn yêu cầu, thay vì mất 2 tuần để làm ra 1 thứ gì đó rồi phải mất gần bằng ấy thời gian để đập đi làm lại, vì bạn nói rằng “Nó sai rồi!”
Sự chia sẻ trách nhiệm cũng thể hiện ở đây rõ hơn. Dù có những trường hợp developer đổ lỗi cho “nhà tư vấn”, nhưng về mặt tổng thể, họ hiểu rằng mình là người cuối cùng quyết định đoạn code này làm thế nào, nên họ cũng phải chịu trách nhiệm. Thông thường thì, nếu bạn không chỉ ra được risk, lỗi của bạn là phần lớn. Nếu họ đã biết risk mà vẫn làm sai, là lỗi của Developer phần lớn. Nhưng có gì quan trong? Dù sao thì, chúng ta lại học hỏi va tiếp tục fix bug này bằng cách dối thoại đúng không? ^^
Mix role
Cả 3 role vừa rồi đều có những điểm mạnh và điểm yếu của họ, và trong dự án không phải lúc nào 1 role cũng có hiệu quả. Nhưng việc bạn thiên về hình mẫu nào sẽ quyết định cách suy nghĩ và hành động của bạn cũng như cách mà member chia sẻ thông tin với bạn.
Vậy câu hỏi của mình là, bạn muốn bạn là ai: Cảnh sát, thám tử, hay là nhà tư vấn?
Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
Cân bằng tải (load balancing — LB) là một thành phần nữa cũng cực kỳ quan trọng trong bất kỳ một distributed system nào, nó giúp cho hệ thống có thể phân tải các request tới đều các Server (Application hoặc Database), giúp cho hệ thống có tính availability hơn. LB sẽ liên tục kiểm tra (health checks) những trạng thái của các server trong hệ thống, nếu trạng thái của server là khỏe mạnh (healthy) thì nó sẽ gửi quest tới, còn nếu server không available hoặc không có response trả về (not healthy) thì LB sẽ không gửi request tới server đó nữa (đá ra khỏi LB), và cho tới khi server đó healthy trở lại thì LB sẽ thêm lại server đó vào LB.
Có rất nhiều thuật toán để LB điều phối các request tới các resource của mình như thuật toán đơn giản nhất là thuật toán “Round Robin”. Là thuật toán luân chuyển vòng, các máy chủ sẽ được xem ngang hàng và sắp xếp theo một vòng quay, các truy vấn dịch vụ sẽ lần lượt được gửi tới các máy chủ theo thứ tự sắp xếp. Ngoài ra còn rất nhiều thuật toán phức tạp khác nữa, tuy nhiên trên thực tế chưa có một thuật toán LB nào thực sự hoàn hảo, nó chỉ một phần nào tương đối chấp nhận được thôi. Nếu có hứng thú tìm hiểu về các thuật toán của LB thì đây cũng là một câu chuyện dài và thú vị đấy các bạn .
Bằng cách cân bằng tải các request tới ứng dụng trên nhiều server, LB sẽ giảm tải cho từng server và ngăn bất kỳ một máy chủ server nào trở thành một điểm lỗi duy nhất (Single point of failure) , do đó cải thiện khả năng đáp ứng và tính sẵn sàng của ứng dụng. Nhất là khi bạn scaling hệ thống theo chiều ngang (horizontal scaling) như đã đề cập ở phần Scalability.
Mô hình mô tả một hệ thống distributed system được horizontal scaling và sử dụng LB để cân bằng tải.
Để hệ thống có tính high availability, thì ta có thể áp dụng LB nhiều lớp (layer) của hệ thống như LB cho nhiều DB, LB cho Web-Server hay LB cho Application Server, ví dụ như mô hình dưới.
Mô hình Load Balancing nhiều tầng.
NHỮNG LỢI ÍCH CỦA LB:
– Trải nghiệm người của người dùng sẽ tốt hơn, và không bị gián đoạn bởi bất kỳ một sự cố nào xảy ra trên một hoặc vài server, ngoài ra cũng tăng tốc độ truy vấn của người dùng nhờ năng lực của nhiều server hợp lại.
– LB giúp cho quản trị viên rất dễ scale up hoặc scale down hệ thống mà không làm gián đoạn trải nghiệm của người dùng.
– Một LB thông minh sẽ giúp người quản trị viên xác định được những tắc nghẽn hay quá tải (traffic bottlenecks) trước khi nó xảy ra, để người quản trị có thể hành động kịp thời, như scale up hệ thống.
– LB giúp người quản trị viên (devops/system admin) đỡ căng thẳng hơn vì thay vì chỉ một Server duy nhất thực hiện nhiều công việc thì ta sẽ chia nhiều công việc nhỏ hơn cho nhiều server, từ đó việc cả hệ thống fail sẽ ít xảy ra hơn.
Tuy nhiên LB có thể trở thành một single point of failure, nếu nó bị quá tải hay lỗi phần cứng/mềm khiến LB sụp đổ dẫn đến cả hệ thống sụp đổ theo. Để khắc phục điều này tốt nhất hay có ít nhất 2 LB kết hợp với nhau thành một cụm LB chạy dưới dạng active-standby tức là luôn có một LB backup cho một LB còn lại đang chạy để phục vụ cho trường hợp LB chính bị hỏng thì LB còn lại sẽ đảm nhiệm.
Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh
Chào các bạn, lại là tôi Xuân Quỳnh đây. Trong bài trước, bạn đã biết ém hàng để tấn công em C rồi. Còn bài này ta sẽ nói say goodbye với em ấy thật ra thì thế này, bọn con gái nế bạn nói chuyện sến súa nhiều, làm quen bằng mấy câu như “bạn ơi cho tớ làm quen nhé..” thì có mùa quit nó mới để ý tới bạn. Hãy làm gì khác biết khác với những đối thủ của mình, hãy làm cho nàng cảm thấy đặc biệt, họ sẽ chú ý tới bạn. “Em ơi anh nhìn em quen quen. Có phải em là bạn của A không?” “Em ơi, hình như hôm trước anh thấy em đi học bên khu XXX, em học lớp à? Trông em rất là xinh này” Đấy, mở lời bằng những thứ làm con gái tò mò đi, đảm bảo em ấy sẽ đáp lại. Mà thôi, tôi lại chém gió rồi, tôi đang FA này =))
OK, bài trước tôi nhắc lại là bàn đã có gcc trên window để chơi với ẻm này rồi. Bây giờ tôi cần bạn dùng notepad để code vài dòng code. Bạn sẽ không IDE(Dev-C hay visual C..), nói không với nó, bạn sẽ hiểu cách C hoạt động như nào, C là gì, mông má ra sao, sinh nở như nào? vân vân mây mây.
Tôi sẽ chứng minh cho bạn thấy chỉ cần notepad và trình build gcc thôi là bạn cũng build ra được file exe. Bạn hãy mở notepad lên bằng cách nhấn nút cửa sổ ghì chặt và nhấn thêm nút R rồi nhấn notepad và ENTER cái rụp. bạn gõ code như sau rồi nhấn CTRL+S để save như hình:
voidmain(){}
Bạn chọn All files và đặt đuôi là c nhé. NHỚ NHÉ, là đuôi C và chọn all file nhằm đảm bảo nó không phải là là goodbyec.c.txt như nhiều bạn làm không chuẩn là ra như vậy đó. Tiện đây tôi chỉ cho bạn cách hiển thị đuôi file, dân code mà. Mình phải khác cái em học kinh tế ở đây, phải xem được file đuôi là gì. Chỉ cần làm như này:
Vậy là bạn đã bắt đầu đẹp trai ra rồi đó. OK, uống ngụm nước, làm điếu thuốc rồi chơi tiếp nào. Bây giờ bạn quay lại với em cmd để nghịch với thằng C này. Tôi đã lưu cái file vừa tạo vào đường dẫn F:\C_project\goodbyec.c
Bạn muốn lưu đâu thì tùy, nhưng khuyến khích không nên lưu ra desktop nhé. Bây giờ bạn bật cmd lên và gõ như này:
cd /d <đường dẫn thư mục chứa file code C>
Ví dụ tôi là:
cd /d F:\C_project\
Bạn nhớ dấu cách giữa cd và /d nhé. Cái /d là để trỏ đường dẫn tuyệt đối, không có nó thì bạn không vô được cửa nhà nàng C đâu :))
Rồi ok tôi có cái màn hình này, tôi gõ tiếp dir để chắc chắn là có em code C nằm trong đó, chờ chén:
Đấy, em ấy đấy!
Rồi bây giờ tôi tiến hành cởi hết xiêm y em ấy này. Tôi gõ gcc goodbyec.c -o goodbyec và tôi ENTER thì nó thù lù ra file exe như hình:
Ở 1 là đoạn code tôi gõ. Ở đây bạn cần lưu ý gcc là tham số bắt buộc để build code C, tiếp theo tham số goodbyec.c là tên chương trình tôi đặt(MẸO: Bạn chỉ cần nhấn good rồi Tab là nó ra đầy đủ tên). Còn -o là tham số chỉ định build ra file output, đằng sau nó là tên file output(exe) sẽ sinh ra. Bạn nhìn vào dòng 2 tôi vạch đó. Không tin thì bạn vào chính thư mục đó kiểm tra thử.
Rồi bây giờ muốn chạy chương trình như nào? Bạn vào cmd và bạn đang ở thư mục đó, bạn chỉ cần gõ tên em ấy là goodbyec.exe là nó chạy ầm ầm à. À mà nó chả in ra gì đâu. Chương trình tôi viết chả có gì chạy cả, mỗi 1 hàm main trống không. Đây có lẽ là chương trình c không thể đơn giản hơn. main chính là trái tim của em C, nơi em ấy thổn thức, sinh ra mọi thứ trong đó. Bạn muốn làm gì cũng phải đưa vào trong main, trong 2 cái cặp dấu {} đó nhé. Và main là duy nhất, nếu có 2 main thì chương trình kiểu gì nó cũng báo lỗi :)) Không tin cứ thử xem. Đúng kiểu em ấy chỉ yêu có 1 người thôi đó. :v
Rồi qua bài này bạn đã biết à hóa ra IDE nó cũng thực ra là nhấn nút Run(F5 trên visual hay F11 trên dev-c) về bản chất cũng là câu lệnh gõ trên mà thôi.
Thấy hấp dẫn chưa? Đấy, cơ bản nó đơn giản thế đấy. Các bài tiếp theo tôi sẽ yêu cầu bạn chơi với dòng lệnh, only dòng lệnh cho tới lúc nào bạn không còn sợ nó, bạn gõ toành toạch như 1 thằng hacker thì bạn bè nó nhìn bạn ghê lắm đó nha
Webpack và Rollup yêu cầu phải có file config riêng.
Rollup có sẵn polyfill cho import/export, webpack chưa có
Rollup hỗ trợ relative path, webpack phải dùng path.resolve hoặc path.join
Config webpack phức tạp nhất, được cái hỗ trợ nhiều third-party
Loại bỏ code không sử dụng
Loại bỏ code không sử dụng, còn gọi dead code, Tree shaking rất cần thiết để nâng cao hiệu năng.
Parcel vẫn là số 1. Hỗ trợ tree-shaking cả ES6 và CommonJS
Rollup đứng thứ 2.
Webpack thì phải thủ công config để có tree-shaking.
Rollup và webpack tập trung tree-shaking với ES6.
Code splitting
Webpack số 1, đúng kiểu làm ít hưởng nhiều. Có 3 lựa chọn
Sử dụng config entry
Sử dụng plugin CommonsChunkPlugin
Dynamic import
Rollup và Parcel hỗ trợ splitting ngay từ đầu, nhưng đang vướng nhiều issue bị report.
Webpack vẫn là lựa chọn hàng đầu.
Live reload
Parcel gặp một số vấn đề với HTTP logging, Hooks và middleware
Rollup phải cài thêm rollup-plugin-serve, rollup-plugin-livereload chứ không có sẵn.
Webpack cài thêm webpack-dev-server.
Khả năng tùy chỉnh của webpack sẽ cao hơn Rollup và Parcel.
Module transform
Các bundler chỉ hỗ trợ file JS, với các file khác chúng ta cần thêm plugin
Parcel hỗ trợ sẵn tất cả những kiểu file quen thuộc, không cần đụng đến config. Không những vậy, khi gặp các file config .babelrc, .postcssrc, .posthtml nó sẽ tự handle
Webpack và Rollup cần thêm plugin và config mới có transform và transpiler.
Đáp ứng nhu cầu giải đáp về mức lương phù hợp, nhiều trang web hướng nghiệp ra đời. Tuy nhiên, liệu bạn đã tìm đúng cho mình các nguồn tư vấn uy tín hay chưa? Cùng TopDev điểm qua top những trang web nổi bật giúp bạn giải đáp các thắc mắc về mức lương.
Trang web quản lý nghề nghiệp của bạn Businessweek có một loạt các bài báo và các mục đề dọc theo phía bên phải, giống như bài viết từ Harvard Business Review. Nói chung, nó giống như các bước tiếp theo từ các trang web About.com với rất nhiều lời khuyên tổng quát.
Các nền tảng trang web về mức lương
1. Salary.com
Salary.com được biết đến là một nền tảng thông minh tích hợp công cụ tính lương nhanh chóng. Chỉ cần một số thông tin cơ bản về bản thân, bạn dễ dàng hoàn tất tìm kiếm và xác định được các chỉ số của mức lương.
Điểm nhấn quan trọng từ Glassdoor là sở hữu một động cơ tìm kiếm việc làm tốt hơn được tích hợp vào trang web của họ. Từ nền tảng này, bạn có thể đọc về mỗi công ty, quá trình phỏng vấn của mình. Đồng thời những nhận xét của các ứng cử viên khác cũng được phân tích rõ.
Indeed.com là trang web dễ sử dụng và khá thú vị. Mọi người đều nắm bắt nhanh vì tính linh động và cập nhật nhanh các thông tin mới nhất. Bạn sẽ dễ dàng tra cứu được những thông tin để tính lương nhanh chóng và thuận tiện.
Nguồn tra cứu khác
Ngoài các nền tảng là các nền tảng trang web, chúng ta có thể tra cứu các thông về lương thông qua các trang mạng xã hội
Nhiều người Facebook chỉ đơn thuần là post bài, đang các dòng trạng thái cá nhân,… Thực tế cho thấy facebook là nguồn tìm kiếm thông tin về mức lương hiệu quả. Dù là mạng xã hội nhưng nhiều nhà tuyển dụng cũng đề cập chi tiết các mức lương một cách rõ ràng. Đồng thời việc tuyển dụng các vị trí như freelancer IT, Senior Developer cũng nhận được sự quan tâm lớn. Vì thế, không quá để nói facebook là kênh social phù hợp để tra cứu về lương; thu hút tuyen dung it.
5. LinkedIn.com
mức lương
LinkedIn luôn được biết đến là mạng xã hội phổ biến và chuyên nghiệp nhất. Nhiều nhà tuyển dụng đã chia sẻ về các kiến, nhu cầu tuyển dụng của mình trên nền tảng này. Không những thế, các thông tin về mức lương cũng được đề cập chính xác, luôn cập nhật các vị trí tuyển dụng mới nhất để đáp ứng nhu cầu tìm việc của ứng viên. Đây thật sự là một nền tảng hiệu quả phục vụ cho việc khai thác thông tin về mức lương đáng tin cậy.
Bài viết được sự cho phép của tác giả Kien Dang Chung
Điểm lại một số vấn đề của bài trước, component trong Vue có thể được tạo ra với phương thức Vue.component() với đầu vào là một đối tượng chứa các tùy chọn như data, template… Trong template có thể sử dụng dữ liệu đã được khai báo trong data của component và không thể sử dụng được các dữ liệu được đăng ký trong data của Vue instance cũng như của các component khác một cách trực tiếp.
Chúng ta kỳ vọng rằng màn hình sẽ hiển thị câu chào “Xin chào Allaravel” nhưng không nó chỉ hiển thị “Xin chào” mà không in ra tên. Mở tab console lên xem có lỗi gì không?
Chúng ta thấy đấy lỗi thông báo như sau: “Thuộc tính userName không được khai báo nhưng vẫn tham chiếu đến khi render”. Như vậy trong template chỉ được tham chiếu đến các thuộc tính dữ liệu được khai báo trong data của component? Đúng vậy, template chỉ có thể tham chiếu đến các thuộc tính trực tiếp nếu thuộc tính đó của component. Với các thuộc tính, dữ liệu ở phạm vi ngoài component chúng ta phải sử dụng đến một cách khác sẽ được giới thiệu trong phần tiếp theo.
2. Truyền dữ liệu vào một component
Nếu các bạn đã đọc phần cơ bản về component, bạn đã quen với cách đặt vấn đề là component là một khối mã nguồn bao gồm cả HTML, Javascript, CSS giống như function trong các ngôn ngữ lập trình. Vậy nó cũng cần có các tham số để có thể truyền dữ liệu từ ngoài vào trong khối mã nguồn đó. Vue.component() làm việc này thông qua thuộc tính props. Truyền dữ liệu vào một component bao gồm 2 bước như sau:
Bước 1: Khai báo các thuộc tính có thể tham chiếu trong template với tùy chọn props.
Bước 2: Truyền dữ liệu cho thuộc tính khai báo với v-bind khi sử dụng component.
Ví dụ Hello component ở phần đầu sẽ được hoàn thiện lại như sau:
Bạn đang có một thắc mắc nhỏ, tại sao là v-bind:user-name mà không phải v-bind:userName? Do các thuộc tính trong HTML là không phân biệt hoa thường (case insensitive), như vậy trình duyệt sẽ thông dịch các ký tự viết hoa cũng như các ký tự viết thường. Do đó, khi bạn sử dụng các template với các thành phần DOM, các prop có tên kiểu camelCase cần được chuyển sang tương đương với dạng kebab-cased. Xem thêm Các chuẩn đặt tên trong lập trình.
Chú ý, khi thuộc tính ở ngoài component thay đổi, thì nó ngay lập tức sẽ cập nhật trong component, tuy nhiên không thể từ trong component mà thay đổi được giá trị thuộc tính ở ngoài này. Luồng dữ liệu như vậy gọi là one-way-down binding.
3. Các dạng dữ liệu có thể truyền vào một component
Trong ngôn ngữ HTML, khi muốn truyền một giá trị cho thuộc tính của thẻ HTML nào đó ta chỉ việc dùng cú pháp:
<html-tag property="value">
Với framework Vue.js chúng ta có thể sử dụng cả cách thông thường như trên hoặc sử dụng v-bind, hai cách có một số điểm khác nhau.
<html-tag v-bind:property-a="propertyB">
Chú ý: v-bind:property có thể viết ngắn gọn thành :property
<html-tag :property-a="propertyB">
Chắc bạn còn nhớ v-bind được sử dụng để gán một biểu thức Javascript vào một thuộc tính của thẻ HTML. Do vậy, khi bạn sử dụng v-bind:my-number=”78″ thì 78 được hiểu như là một biểu thức Javascript hơn là một chuỗi. Với cách truyền giá trị kiểu HTML thì giá trị truyền vào sẽ là một chuỗi thông thường.
3.5 Truyền một thuộc tính của một đối tượng vào component
post:{
id:1,
title:'My Journey with Vue'}<blog-post
v-bind:id="post.id"
v-bind:title="post.title"></blog-post>
4. Component bên trong một component khác
Cái hay nhất của component là có thể sử dụng lại trong một component khác, như vậy các ứng dụng chỉ đơn giản là các component được lắp ghép với nhau. Chúng ta cùng xem một ví dụ tiếp theo:
Trong ví dụ này chúng ta có 3 component: hello-component để hiển thị lời chào, form-component để nhập vào tên người dùng và greeting-component sử dụng hai component trước đó tạo thành một component mới. Chúng ta cũng gặp lại cú pháp truyền dữ liệu từ ngoài vào trong component, nó cũng được áp dụng khi truyền dữ liệu từ component cha vào component con.
Mọi thứ hiển thị bình thường nhưng khi bạn thử thay đổi ô nhập liệu tên người dùng, bạn sẽ nhận được một lỗi từ Vue.js:
Đại ý lỗi này là tránh thay đổi giá trị được truyền vào một cách trực tiếp, thay vào đó sử dụng một thuộc tính được khai báo trong data hoặc computed dựa trên giá trị truyền vào. Giá trị bị thay đổi ở đây là userName. Thay đổi lại code trên theo gợi ý core Vue.js đưa ra:
<template id="form-template"><div class="row"><div class="col-md-3"><label for="name">Tên bạn là gì?</label></div><div class="col-md-9"><input class="form-control"v-model="name"type="text"></div></div></template>
Trong form-component chúng ta không sử dụng trực tiếp thuộc tính userName nữa mà khai báo một thuộc tính khác là name trong data và khởi tạo nó bằng giá trị của userName được truyền vào. Như vậy, khi bạn thay đổi tên người dùng trong ô nhập liệu, nó chỉ tác động đến thuộc tính name cục bộ. Với lời chào chúng ta muốn sẽ loại bỏ ký tự trống ở hai đầu chuỗi tên người dùng và viết hoa tên người dùng, tạo ra một thuộc tính computed để làm việc này (Tại sao dùng computed, xem lại bài viết Cơ bản về computed trong Vue.js):
Tuy nhiên, code sửa đổi vẫn chưa đáp ứng được yêu cầu, chúng ta muốn khi thay đổi tên người dùng thì tên đó phải được cập nhật vào lời chào.
Tức là phần code trên mới chỉ đáp ứng được luồng dữ liệu truyền dữ liệu từ component cha vào component con (chiều 1), còn chiều ngược (chiều 2) lại hiện chưa thực hiện được do khi truyền từ cha vào con chỉ theo một chiều (one-way data binding).
5. Kết luận
Các khái niệm trong component đã dần được giới thiệu đến các bạn, chúng ta đã đi được nửa chặng đường tìm hiểu về component và tôi luôn muốn bạn nhớ vài điều: component là một code block chứa HTML, Javascript, CSS nó giống như “function” trong ngôn ngữ lập trình thông thường và nó cũng có thể có tham số để truyền dữ liệu vào. Ví dụ về component trong component còn dở dang với chiều ngược lại của đường đi dữ liệu nhưng bài viết cũng khá dài, nghỉ ngơi và nhớ dành thời gian xem bài kết tiếp nhé.
Bài viết được sự cho phép của tác giả Nguyễn Hữu Đồng
Hế nhô các bạn, lại là mình đây, nhân dịp hôm nay mình có tìm hiểu qua về HAPROXY nên mình muốn viết vài dòng để chia sẻ về haproxy cũng như lí do chúng ta cần haproxy cho dự án.
HAPROXY là một proxy server, load blancer, system monitoring, được sinh ra để làm nhiệm vụ của một front end web service. Vậy tại sao chúng ta lại cần đến nó. Trước khi khi mình làm việc với dự án nhỏ, web app của mình chỉ cần viết bằng NodeJS dùng Pm2 để có thể chạy multithread sau đó dùng Nginx để serve static file, làm proxy cho nodejs vậy là xong, chưa có khi nào chết cả, chưa bao giờ quá tải vì cơ bản đó cũng chỉ là một app nhỏ. Và nếu chết cũng chẳng sao 😀 chết thì restart lại thôi kk.
Giờ đây khi bước qua một công ty mới, mình sẵp đối mặt với những vấn đề mới, khi lượng request lên tới hàng ngìn request per second thì việc scale hệ thống như thế nào để có thể đáp ứng được lượng request đó là một vấn đề cần phải giải quyết êm gọn.
Về mặt cơ bản, khi lượng request nhiều lên, chúng ta sẽ có thể lựa chọn hai laị hình scale cho hệ thống đó là scale ngang và scale dọc, scale dọc tức là nâng cấp HDD lên SSD dung lượng cao, nâng cấp RAM, Vi xử lí… những đâu phải cứ nâng cấp hoài vậy được đâu, lúc đầu khi cầu hình thấp thì rất dễ nâng cấp lên cấu hình cao, nhưng khi cấu hình đã cao muốn nâng cấp lên cấu hình cao hơn thì rất khó, thứ nhất không phải linh kiện lúc nào cũng có sẵn, và giá cả cũng không phải rẻ. Scale theo chiều ngang tức là dùng thêm nhiều hệ thống tương tự như hệ thống hiện tại để chia nhau xử lí request.
Và thường khi scale chúng ta sẽ kết hợp cả hai kiểu scale sao cho hợp lí nhất và ít chi phí nhất.
Đến đây khi các hệ thống hoạt động cùng với nhau, nảy sinh ra vấn đề làm sao để giao request này cho hệ thống kia xử lí, từ đây mình xin viết gọn một hệ thống sẽ là một node. node x tưng ứng hệ hệ thống x.
Haproxy sinh ra để giải quyết vấn đề này, haproxy sẽ làm vai trò của một proxy server, theo dõi tình trạng các node và sẽ gửi request đến các node.
Nếu còn chưa hiểu về khái niệm proxy các bạn có thể tìm hiểu tại đây.
Cài đặt và sử dụng Haproxy rất dễ dàng. Trên MacOS chỉ cần mở terminal lên rồi chạy hai lệnh sau. Haproxy server của bạn đã sẵn sàng để chạy.
Để chạy được HAPROXY, chúng ta cần phải cấu hình cho nó. Về cơ bản haproxy có thể nhận các thông số cấu hình theo độ ưu tiên như sau
argument -> proxies setting -> global setting và theo mặc định thì những gì được setup trong global setting sẽ được bổ sung vào proxies setting.
Chi tiết hơn các bạn xem trong file dưới đây. Mình sẽ giải thích từng phần có nhiệm vụ như thế nào.
global
log 127.0.0.1 local0
log 127.0.0.1 local1 debug
maxconn 4096
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 2000
timeout connect 5000
timeout client 50000
timeout server 50000
frontend haproxy
bind *:8012
stats enable
stats uri /stats
stats refresh 10s
stats admin if TRUE
stats auth dongnguyen:029
default_backend go-web-server
backend go-web-server
balance roundrobin
server node1 0.0.0.0:6000 check
server node2 0.0.0.0:7000 check
server node3 0.0.0.0:5000 check
option httpchk GET /whatever
Global session : những tham số thiết lập ở đây sẽ mặc định được sử dụng trong proxies session, hoàn toàn có thể overwrite nó trong proxies session
Proxies Session : tên gọi chung cho cả “default session, front end session, back end session”. Vì haproxy là một server proxy nên hẳn nó sẽ phải có cái gì đó là front end. Có thể là chính là http request từ client hoặc cũng có thể là một front-end web server như Nginx.
Ở file trên mình setup Global session có những key là log và maxconn, setup hai key này với giá trị như trên sẽ chỉ cho haproxy ghi 2 loại log vào system log server được lắng nghe mặc định trên cổng 514. Và ở loại log thứ 2 ghi ở level debug, các bạn có thể xem các loại log và level log tại đây.
Phần default session, mình setup mặc định sẽ dùng log được được setup trong Global session, proxy mode là http, ngoài http thì các bạn có thể chọn tcp, khi chọn tcp thì một kết nối đầy đủ sẽ được tạo ra giữa client và server, đây là mode mặc định, còn khi chọn http thì request sẽ được phân tích, những request nào không đáp ứng được chuẩn “RFC-compliant” . Timeout client,timeout server, timeout connect nếu khi một request được tạo ra nếu trong vòng x miliseconds mà không thực hiện được thì haproxy sẽ bỏ qua request đó.
“Front end session” ở đây mình có hai 2 front-end, cái thứ nhất là tool của haproxy giúp mình có thể xem được tình trạng các node, số request đã được các nodejs thực hiện. Trong front-end thứ hai do mình dùng nginx làm front-end web server cho haproxy nên mình sẽ để tên là nginx, mình dùng “back-end” có tên là “nodes” để handle request. Mình cho haproxy lắng nghe request từ front-end nginx trên cổng 9090, và từ nginx mình chỉ cần proxy_pass qua port này là xong.
Tiếp theo đến phần “back-end”, ở đây mình khai bao 3 nodes tương đương với 3 hệ thống cùng chạy song song, mỗi node sẽ lắng nghe trên port khác nhau, mình khai báo haproxy check tình trạng của server trước khi thêm node vào danh sách node để pass_proxy. Một lưu ý là nếu để mặc định thì khi check status server haproxy sẽ gửi request với method “options” đến server của chúng ta và nếu nó nhận đc status code =200 thì có nghĩa là node của chúng ta đang hoạt động, bạn cũng có thể thay đổi mặc định bằng cách set
ví dụ mình muốn haproxy gửi một method get để check vào url “/check”
thì mình sẽ ghi “ option httpchk get /check”
Và cuối cùng là thuật toán mà từ đó Haproxy có thể dùng để xác định nên gửi request vào node nào. Thuật toán “roundrobin” có nghĩa là haproxy sẽ gửi request theo vòng tròn, 1–2–3–1–2… cứ như vậy ngoài ra còn vài thuật toán nữa các bạn có thể xem tại đây.
Hiện tại mình đang có 3 node chạy song song đang lắng nghe request trên cổng 5000,6000 và 7000. Và để khởi chạy HAPROXY mình chỉ cần RUN
haproxy -f path/to/file/config
Như trong trường hợp của mình do mình mình sẽ chạy
haproxy -f haproxy.cfg
Để xem HAPROXY của mình đang có hoạt động không, do mình đa khai báo front-end stats của haproxy đang lắng nghe trên cổng 6789, nên để xem haproxy status, monitoring mình chỉ cần đến “http://localhost:6789/stats”
Để check xem server có phân chia request tới 3 con server mình đang chạy hai không mình tiến hành gửi ba request tới và đây là kết quả.
Tèn tèn vậy là mình vừa setup một load balancer đơn giản với 3 node chạy song song, trong thực tế thì các bạn sẽ phải làm rất nhiều thứ như làm sao để chia sẻ tài nguyên, ví dụ như database, đồng bộ log giữa ba server. Mình sẽ chia sẻ thêm nhiều hơn trong tương lai khi mình được làm việc trực tiếp với nó.
Cảm ơn các bạn đã đọc bài viết của mình. Bye bye các bạn ^_^.
Chia sẻ của bạn Nguyễn Dương Hải về quá trình trở thành một QA chuyên nghiệp. Từ chỗ không biết QA là gì đến yêu nó và gắn bó với nó lúc nào không hay.
Nhìn lại bản thân
Trước tiên mình xin nói là mình chẳng tự hào gì về chuyện này :D. Nhưng sau 6 năm làm việc như 1 QA, mình muốn thẳng thắng nhìn lại bản thân mình. Rất nhiều người từng hỏi “Sao bạn học CNTT không làm Dev mà làm QA?”. Mình chưa bao giờ dám trả lời lý do thực sự vì sao mình lại chọn nghề này. Và mình thấy bây giờ là lúc thích hợp.
Lúc ở trường đại học, có những nhóm thường hay học theo kiểu chia nhau ra làm bài tập. Tức là mình sẽ làm đồ án của môn này, bạn tập trung làm đồ án của môn kia rồi chuyền tay nhau bài giải. Thầy cô cũng biết chuyện này, nên rất nghiêm trong việc xử phạt những đứa chép bài nhau. Mình nhớ có một môn “Lý thuyết đồ thị”, mình làm bài tập và share cho bạn. Cuối cùng cả 2 bị 0 điểm. Bạn mình copy “hiền” quá :(. Lúc ấy mình không thể fail môn đó được nên phải nói nó confirm với cô rằng nó chép bài mình rồi xin cô. Cuối cùng mình 9.5 nó thì vẫn 0 điểm. Nói chung mình là đồ HÈN!
“Luộc bài” cũng cần kỹ năng
Lúc mình chép bài của thằng khác, mình siêu cẩn thận. Thay vì những đứa khác, thường là mang về đổi tên hàm, tên class, mang hàm qua file khác rồi xong. Mình là vô coi thiệt kỹ luôn. Thiệt là mình dở lắm, học đại học mấy năm mà khả năng thích ứng ngôn ngữ mới của mình dở ẹt. Cái đồ án nào mà nói dùng kỹ thuật abc, xyz là mắt mình hoa lên. Còn nữa, project thời đại học mà, bạn mình đặt tên hàm, biến thì thôi rồi! Nhìn vô cái tên mà nhiều lúc nghĩ “Cái này làm cái quái gì vậy??”. Nhìn vô code thôi nhiều lúc cũng thua luôn!
Để bù đắp cho vụ đó, mình mở source code của bạn lên xong rồi DEBUG. Mình input giá trị cho 1 hàm rồi xong debug từng dòng một. Coi tất cả value của những biến trong đó, để coi coi là cái hàm này thực ra là nó làm cái quỷ gì. Rồi xem coi kết thúc hàm này thì nó đi tới hàm nào.
Tốn time dã man nhưng mà mình toàn học bằng kiểu đó. Không có project của bạn lúc đầu chắc mình chẳng bao giờ biết làm gì hết. Riết rồi, cái nó viết nhiều khi nó không hiểu nó viết cái gì nhưng mà mình thì hiểu =)).
Dấu ấn riêng trong code
Rồi, sau khi hiểu rồi thì mình bắt đầu đến màn “cooking” :D. Lúc đầu thì theo kiểu là nó viết kiểu “For” thì mình viết lại thành “While”, tên biến tên hàm cũng đổi. Rồi mình cũng cố gắng thu ngắn code của nó lại. Nhờ lúc debug, thì nếu mình có tìm thấy lỗi, thì 2 đứa cùng sửa.
Cái quan trọng là, mình đọc rất kỹ đề bài của cô và nghĩ ra rất nhiều input, nên cái code của mình sau khi sửa, nhiều khi nhìn “chuối” hơn ( gượng ép đổi code style) nhưng mà nó cover nhiều case hơn. Mình nhớ hồi đó làm toàn bằng If, Else, code như 1 cái nùi giẻ trong đó @@! Cuối cùng thì, cái bài đó gốc là của bạn mình nhưng mà qua tay mình nó có hình ảnh của mình trong đó :).
Đến khi mình ra trường, mình tự nhìn lại mình: Khả năng học ngôn ngữ kém, coding style kém, kiến thức xây dựng hệ thống gần như là 0, nhưng mình có tư duy logic rất chi tiết và khả năng tìm lỗi / Case chưa cover rất cao. Sau khi học course về Testing trong trường mình có cảm giác là mình sẽ phù hợp và mình xinh việc làm intern tester rồi trở thành QA như bây giờ :).
Cảm ơn bạn vì bạn đã chịu khó nghe câu chuyện của mình đến lúc này :). Qua câu chuyện này, mình muốn nói với bạn rằng, bạn tập trung làm việc gì thì cuối cùng bạn sẽ được trả lại bằng 1 skill tương ứng, và học CNTT không có nghĩa là bạn chỉ có con đường làm Developer. Hãy tự mình tìm con đường mình thích và cố gắng đạt được nó các bạn nha!
Được sử dụng để delay việc thực thi một hàm nào đó. Ví dụ khi user nhập vào ô search, chúng ta không thực thi ngay câu lệnh tìm kiếm mà đợi một khoảng thời gian sau khi user đã ngừng việc nhập.
Có thể hình dung cái thang máy, cửa chuẩn bị đóng, nếu có người đưa chân vào nó sẽ không chạy liền, mà cho người đó vào rồi mới chạy.
Trong khoản thời gian đã chỉ định, chỉ thực thi hàm 1 lần duy nhất, bỏ qua mọi lần gọi khác. Ví dụ như user click liên tục vào nút search để gọi API, chúng ta chỉ thực thì đúng lần đầu, các lần click tiếp theo chúng ta cho qua và không gọi API.
Một ví dụ khác làm infinite-scroll, khi user đã load đến vị trí gần cuối trang, chúng ta sẽ đi lấy thêm dữ liệu, chúng không đợi đến khi user đã đến cuối trang. debounce sẽ không hữu ích vì nói chỉ cho thực thi khi user stop việc scroll. throttle sinh ra cho việc này.
Rất hữu dụng khi cần gắn các sự kiện vào DOM. Vì chúng ta có thể hạn chế bớt số lần thực thi không cần thiết.
Ví dụ với sự kiện scroll, nếu chúng ta bắt onScroll để thực thi một hành động, số lần thực thi sẽ rất lớn. Đây là vấn đề vào năm 2011 của Twitter, user khi scroll trên điện thoại sẽ chậm và tệ nhất là memory leak luôn.
Nên sử dụng thư viện có sẵn nếu cần, như lodash, đừng tự viết lại.
requestAnimationFrame
Là một API của trình duyệt, tương tự như _.throttle(doSomething, 16)
Sinh ra để đáp ứng chạy cho thật mượt (đảm bảo 60fps).
Đơn giản vậy thôi.
Cái này giống như kiểu bạn muốn chạy xe máy thì phải đổ xăng vậy đó, printf thuộc thư viện stdio.h. Muốn dùng thì include vào :))
.
