Home Blog Page 122

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Bài viết được sự cho phép của tác giả Giang Phan

Trong các bài viết trước, tôi đã giới thiệu với các bạn cách tự cài đặt RabbitMQ. Trong bài này, tôi sẽ giới thiệu với các bạn CloudAMQP – một RabbitMQ Server trên nền tảng Cloud.

  Bí kíp tạo website nhờ vào GitHub và Cloudflare
  Cloud Computing - Xu hướng toàn cầu đang thâm nhập và thống trị tại thị trường Việt Nam

CloudAMQP là gì?

CloudAMQP cung cấp một RabbitMQ Server trên nền tảng Cloud. CloudAMQP tự động hóa toàn bộ quá trình thiết lập, vận hành và mở rộng quy mô của các RabbitMQ Cluster. CloudAMQP cung cấp giao diện quản lý trực quan, cung cấp hệ thống giám sát, thông báo RabbitMQ thông qua email, webhook, external service.

Khi sử dụng CloudAMQP, chúng ta không cần quan tâm về hạ tầng để quản lý RabbitMQ serrver, chúng ta chỉ tập trung vào phần business của mình. Giá thành của CloudAMQP khá linh động tuỳ thuộc vào nhu cầu sử dụng của bạn.

Trong bài viết này, tôi sẽ hướng dẫn các bạn đăng ký gói dịch vụ miễn phí của CloudAMQP. Gói này thích hợp cho các bạn developer, muốn tìm hiểu về RabbitMQ nhưng không muốn setup server RabbitMQ riêng.

Đăng ký tài khoản miễn phí CloudAMQP

Vào trang đăng ký: https://www.cloudamqp.com/plans.html

Kéo về cuối trang chọn gói FREE:

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Các bạn điền các thông tin đăng ký.

Sau khi hoàn thành đăng ký, ở trang kế tiếp, chúng ta sẽ điền các thông tin để đăng ký RabbitMQ instance mà chúng ta sẽ sử dụng.

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Chọn Region là Singapore hay HongKong. Ở đây mình chọn HongKong –> chọn Review.

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Kiểm tra lại thông tin đăng ký, và chọn Create instance.

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Chọn RabbitMQ Manager để vào trang quản lý RabbitMQ.

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Chúng ta có một trang quản lý RabbitMQ như tự setup RabbitMQ Server ở các bài viết trước.

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Tại trang danh sách Instance, các bạn click vào tên của instance để vào trang thông tin chi tiết instance của bạn trên CloudAMQP.

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Sử dụng CloudAMQP

Các khái niệm và cách sử dụng RabbitMQ tôi đã giới thiệu với các bạn ở các bài viết trước hoàn toàn có thể sử dụng với CloudAMQP.

Đầu tiên, chúng ta cần thêm thư viện RabbitMQ AMQP client:

<dependency>   <groupId>com.rabbitmq</groupId>   <artifactId>amqp-client</artifactId>   <version>5.8.0</version> </dependency>

Tôi sẽ sử dụng lại ví dụ ở bài viết “Kết nối AMQP Client với RabbitMQ Server” để thử kết nối đến CloudAMQP.

Producer

package com.gpcoder.cloudamqp; import com.rabbitmq.client.Channel; import com.rabbitmq.client.Connection; import com.rabbitmq.client.ConnectionFactory; import java.io.BufferedReader; import java.io.InputStreamReader; public class Producer {     private static final String CLOUDAMQP_URL = "amqps://evncuivu:<your_secret_url>.rmq.cloudamqp.com/evncuivu";     private static final String QUEUE_NAME = "gpcoder-queue";     public static void main(String[] argv) throws Exception {         System.out.println("Create a ConnectionFactory");         ConnectionFactory factory = new ConnectionFactory();         factory.setUri(CLOUDAMQP_URL);         factory.setRequestedHeartbeat(30);         factory.setConnectionTimeout(30000);         System.out.println("Create a Connection");         System.out.println("Create a Channel");         try ( Connection connection = factory.newConnection();               Channel channel = connection.createChannel() ) {             System.out.println("Create a queue " + QUEUE_NAME);             channel.queueDeclare(QUEUE_NAME, false, false, false, null);             System.out.println("Start sending messages ... ");             try (BufferedReader br = new BufferedReader(new InputStreamReader(System.in));) {                 String message;                 do {                     System.out.print("Enter message: ");                     message = br.readLine().trim();                     channel.basicPublish("", QUEUE_NAME, null, message.getBytes());                     System.out.println(" [x] Sent: '" + message + "'");                 } while (!message.equalsIgnoreCase("close"));             }         } finally {             System.out.println("Close connection and free resources");         }     } }

Consumer:

package com.gpcoder.cloudamqp; import com.rabbitmq.client.*; public class Consumer {     private static final String CLOUDAMQP_URL = "amqps://evncuivu:<your_secret_url>.rmq.cloudamqp.com/evncuivu";     private static final String QUEUE_NAME = "gpcoder-queue";     public static void main(String[] argv) throws Exception {         System.out.println("Create a ConnectionFactory");         ConnectionFactory factory = new ConnectionFactory();         factory.setUri(CLOUDAMQP_URL);         factory.setRequestedHeartbeat(30);         factory.setConnectionTimeout(30000);         System.out.println("Create a Connection");         System.out.println("Create a Channel");         Connection connection = factory.newConnection();         Channel channel = connection.createChannel();         System.out.println("Create a queue " + QUEUE_NAME);         channel.queueDeclare(QUEUE_NAME, false, false, false, null);         System.out.println(" [*] Waiting for messages. To exit press CTRL+C");
         System.out.println("Start receiving messages ... ");         DeliverCallback deliverCallback = (consumerTag, delivery) -> {             String message = new String(delivery.getBody(), "UTF-8");             System.out.println(" [x] Received: '" + message + "'");         };         CancelCallback cancelCallback = consumerTag -> { };         String consumerTag = channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);         System.out.println("consumerTag: " + consumerTag);     } }

CLOUDAMQP_URL: các bạn lấy từ trang thông tin chi tiết instance của CloudAMQP.

Chạy thử ứng dụng để kiểm tra kết quả. Tham khảo bài viết trước: https://gpcoder.com/6885-ket-noi-amqp-client-voi-rabbitmq-server/#Chay_ung_dung

Chạy Producer và gửi một vài message:

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Chạy Consumer, các bạn sẽ thấy các Message được Consume:

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Vào trang quản lý RabbitMQ, bạn có thể thấy một Queue được tạo và các Message được gửi đến Queue này.

Giới thiệu CloudAMQP – Một RabbitMQ server trên Cloud

Trên đây là hướng dẫn cơ bản về CloudAMQP, các bạn có thể nhanh chóng tìm hiểu RabbitMQ mà không cần setup RabbitMQ server riêng. Còn rất nhiều tính năng khác được hỗ trợ bởi CloudAMQP, các bạn có thể tìm hiểu thêm ở link bên dưới.

Tài liệu tham khảo:

Bài viết gốc được đăng tải tại gpcoder.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

10 năm đã qua, tại sao vẫn chưa có một ứng dụng nổi bật nào dành cho Blockchain?

Cơ hội nào cho blockchain

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

Là một fan của Blockchain nhưng cũng phải thừa nhận rằng chưa thấy đường tiến cho công nghệ này.

Cho đến nay, danh tiếng của blockchain chủ yếu vẫn xuất hiện trong các hoạt động đầu cơ tiền tệ và đôi khi cả các giao dịch bất hợp pháp, vẫn chưa có ứng dụng thực sự nào nổi bật trong thực tiễn cho nền tảng công nghệ mới này.

Mọi người đều nói về blockchain, công nghệ nền tảng cho các loại tiền mã hóa như Bitcoin, sẽ thay đổi MỌI THỨ. Tuy nhiên, sau nhiều năm nỗ lực không mệt mỏi và hàng tỷ USD đầu tư, vẫn không có gì thực sự nổi bật lên từ việc ứng dụng blockchain – ngoại trừ hoạt động đầu cơ tiền tệ và các giao dịch bất hợp pháp.

Mỗi mục đích sử dụng của blockchain – từ thanh toán tới các tài liệu pháp lý, từ việc giao kèo tới các hệ thống bỏ phiếu – cuối cùng chỉ xoay quanh việc bổ sung dữ liệu vào một sổ cái phân tán, mã hóa, hoặc ẩn danh nào đó, những thứ mà chẳng ai cần. Phải chăng chẳng có ứng dụng thực sự nào cho sổ cái phân tán? Phải chăng 10 năm sau khi được phát minh ra, nguyên nhân của việc chẳng ai chấp nhận sổ cái phân tán ở một quy mô hợp lý là vì chẳng ai muốn nó cả?

Tham khảo tuyển dụng blockchain lương cao tại đây

Thanh toán và ngân hàng

Ý tưởng ban đầu của blockchain là cung cấp cho các tiền mã hóa như Bitcoin một cách để lưu trữ và trao đổi giá trị như các loại tiền tệ khác. Giờ đây mọi người sẽ có trong tay một cách để trao đổi giá trị tức thời, không mất phí và không có bên trung gian, cũng như không phải dựa trên một hệ thống tiền tệ do các chính phủ kiểm soát. Một cuộc cách mạng về ngân hàng và tiền tệ.

Thế nhưng rất nhanh sau đó, giấc mơ tan vỡ. Trên thực tế, đã có một cách để trao đổi giá trị tức thời, không mất phí cũng như không có bên trung gian: tiền mặt. Trong khi đó, các dịch vụ thanh toán như Visa hay MasterCard, dù mất phí, nhưng đi kèm là hàng loạt dịch vụ gia tăng như giúp các ngân hàng lần theo các bên lừa đảo và xác định danh tính bên mua và bên bán.

Không những vậy, đây cũng không phải một hệ thống thanh toán tốt. Trong khi Visa có thể xử lý 60.000 giao dịch mỗi giây, còn mức cao lịch sử của Bitcoin chỉ là 7 giao dịch mỗi giây. Dù có nhiều chỉnh sửa về mặt kỹ thuật để cải thiện hiệu quả của Bitcoin, nhưng vẫn không đủ. Ngoài ra, tốc độ 7 giao dịch Bitcoin mỗi giây này còn tiêu tốn năng lượng gấp 35 lần so với Visa. Nếu bạn đẩy khối lượng giao dịch Bitcoin lên ngang với Visa, nó sẽ ngốn một lượng năng lượng bằng cả phần còn lại của thế giới cộng lại.

  Blockchain cơ bản - Học về Solidity (P2)
  Blockchain là gì? Nguyên lý hoạt động và ưu điểm nổi bật của Blockchain

Tự do giao dịch không có sự giám sát của chính phủ

Trong ý nghĩ của rất nhiều người, khả năng che giấu một số thứ khỏi sự giám sát của chính quyền có thể làm thế giới tốt đẹp hơn. Nhưng vẫn còn có hai lý do quan trọng làm điều này không hoàn toàn tuyệt vời như người ta tưởng: đó là các lợi ích của chính phủ với cá nhân và các lợi ích của chính phủ với xã hội.

Sàn giao dịch bitcoin, Mt. Gox đã phải đóng cửa khi làm mất tiền của nhà đầu tư.

Các ngân hàng nhà nước do chính phủ hỗ trợ có thể đưa ra các khoản bảo hiểm tiền gửi, đảo ngược lại các thanh toán bù trừ tự động (hệ thống ACH), xác định danh tính, phát hành các tiêu chuẩn kiểm toán, và điều tra khi có sai lầm xẩy ra. Trong khi đó, theo thiết kế của Bitcoin, nó không thể có được những điều này.

Những câu chuyện về việc người dùng mất sạch số Bitcoin của mình khi email bị hack và mật khẩu bị đánh cắp đầy rẫy trên mặt báo. Không những thế, vào năm 2014, khi sàn giao dịch Bitcoin số một lúc đó, Mt. Gox bị mât 400 triệu USD tiền của nhà đầu tư do các lỗ hổng bảo mật, không ai lấy lại được tiền cho đến gần đây. Tương tự như vậy là trường hợp của Bitfinex.

Ngoài ra, các chính sách của chính phủ cũng được thiết kế để phá vỡ các hoạt động tài trợ khủng bố và tội phạm có tổ chức, ngăn chặn đường đi của các hàng hóa bất hợp pháp. Ưu tiên chính của điều này là đảm bảo tính riêng tư của giao dịch nhưng vẫn có thể phát hiện ra nếu có lệnh của tòa. Sự tự do của Bitcoin sẽ bớt thú vị đi rất nhiều nếu 100% băng thông của nó dùng cho các hàng hóa và dịch vụ bất hợp pháp.

Thanh toán nhỏ (micropayment) và chuyển khoản liên ngân hàng

Đây là hai ứng dụng thanh toán làm mọi người đặc biệt phấn khích về các loại tiền mã hóa dựa trên blockchain. Mọi người kỳ vọng rằng, với blockchain, các giao dịch Bitcoin sẽ miễn phí và tức thời. Vì vậy, nhiều người đề xuất sử dụng nó trong các khoản thanh toán nhỏ, ví dụ, 2 cent cho một bài hát họ nghe trên internet hay 4 cent để đọc một bài báo.

Trên thực tế, mỗi giao dịch Bitcoin mất khoảng 8 phút để hoàn thành và chi phí 4 cent để xử lý. Và thay vì các khoản thanh toán nhỏ như trên, những nhà cung cấp nội dung đã đưa ra các gói thuê bao trả phí, và người dùng không phải đợi đến 8 phút để đọc bài báo mình muốn nữa, họ chỉ việc click chuột, và nội dung họ yêu cầu sẽ hiện ra.

Còn đối với chuyển tiền liên ngân hàng, cái tên Ripple thường được nhắc đến như một cái tên đầy hứa hẹn. Thế nhưng sau ba năm có mặt tại các ngân hàng chiếm đến 90% lượng ngoại tệ giao dịch trên toàn thế giới, trong 30 ngày cuối năm 2017, mạng lưới Ripple mới chỉ xử lý khoảng 2 tỷ USD – quá nhỏ bé so với quy mô mạng lưới liên ngân hàng SWIFT hiện tại.

Tại sao các ngân hàng không mặn mà với công nghệ mới này? Câu trả lời nằm ở việc cổng thanh toán Ripple Gateway thực ra không khác nhiều so với hệ thống tài khoản đối ứng hiện tại – ngoại trừ việc mất mật khẩu hay token bảo mật sẽ gây ra các thiệt hại lớn hơn nhiều. Ngoài ra các ngân hàng cũng đã có sổ cái, và không cần phải phân tán chúng, ẩn danh, mã hóa, công bố chúng, và làm chúng không thể đảo ngược để hoạt động hiệu quả.

Hợp đồng thông minh

Các hợp đồng thông minh là những hợp đồng được viết bằng phần mềm, thay vì các ngôn ngữ pháp lý. Vì bạn có thể mã hóa chúng trực tiếp trên blockchain, chúng có thể truyền giá trị dựa trên sự đồng thuận về mã hóa của các bên liên quan. Về mặt lý thuyết, các hợp đồng viết bằng phần mềm sẽ rẻ hơn khi diễn giải – bởi vì hoạt động của chúng hoàn toàn là toán học và tự động. Điều này cũng có nghĩa là các cuộc chiến pháp lý đắt đỏ sẽ không còn cần đến nữa.

Những nhà đầu tư và các startup trong lĩnh vực hợp đồng thông minh hứa hẹn rằng, blockchain sẽ cho phép việc thực thi và thanh toán diễn ra siêu nhanh. Ví dụ trong việc mua bảo hiểm y tế, “thay vì phải chờ đến 90-180 ngày để xử lý yêu cầu, hay chờ hàng giờ trên điện thoại để thanh toán hóa đơn, về lý thuyết nó có thể được thực hiện chỉ trong nháy mắt.”

Thế nhưng, điều này cũng đúng đối với bất kỳ hệ thống mua hàng dựa trên phần mềm nào. Ví dụ việc mở rộng sức mạnh máy chủ đám mây Amazon có thể diễn ra tự động dựa trên lượng truy cập vào website và tính phí trên những gì người mua sử dụng.

Ý tưởng cho rằng hợp đồng thông minh có thể thay đổi điều này là một sự ngộ nhận – họ cho rằng mình có thể dùng để thực thi hợp đồng pháp lý trong khi bản thân hợp đồng pháp lý đó đã được lập trình như phần mềm.

Điều khoản dịch vụ của Amazon không phải là hợp đồng thông minh, nhưng hệ thống thanh toán của họ đã thực thi các điều khoản đó như hợp đồng thông minh. Điều tương tự cũng đúng với việc thanh toán bảo hiểm y tế. Có lẽ ý tưởng của hợp đồng thông minh để tự động hóa việc thực thi rất thú vị nhưng nó giống như việc phát minh lại bánh xe vậy, mọi thứ đã có sẵn rồi.

Lưu trữ, điện toán và nhắn tin phi tập trung

Một ý tưởng đáng chú ý khác của blockchain là sử dụng nó như một cơ chế lưu trữ phân tán. Về cơ bản, bạn sẽ đặt tài liệu của mình vào các block, mã hóa chúng và đặt chúng vào một sổ cái phân tán … Nó sẽ được sao lưu ở nhiều nơi, bảo mật và dễ theo dõi xem điều gì đang xảy ra.

Nhưng cũng như các ứng dụng về hợp đồng thông minh hay khả năng chuyển khoản trực tiếp giữa các ngân hàng, các tác vụ về lưu trữ và điện toán này đã được các công ty cung cấp dịch vụ đám mây như Dropbox, Box.com, Microsoft, Google, Amazon hay thậm chí Apple, đều đang làm rất tốt. Không những thế, các công ty này còn đang cung cấp nhiều tính năng bổ sung khác rất có giá trị, hiệu quả hơn nhiều so với việc lưu trữ trên blockchain.

Ngoài ra, vẫn còn các vấn đề về bảo mật của blockchain. Đầu tiên, bạn dựa vào một lớp mã hóa duy nhất – mã khóa của riêng bạn – và nó sẽ kém hơn các hệ thống tinh vi với xác thực hai lớp, phát hiện xâm nhập, tường lửa và điều khiển IP từ xa, cũng như khả năng ngắt kết nối hệ thống trong trường hợp khẩn cấp xảy ra.

Hơn nữa, việc vận hành các chuỗi blockchain đang cho thấy hoạt động này thiểu hiệu quả năng lượng đến mức nào. Chuỗi blockchain Bitcoin tiêu tốn đến hàng tỷ USD tiền điện chỉ để mã hóa một lượng dữ liệu mà với 6 USD phí thuê bao hàng tháng, bạn có thể có được chúng từ các công ty dịch vụ lưu trữ đám mây kể trên.

Lập luận tương tự cũng đúng với các ứng dụng nhắn tin bảo mật hay điện toán phân tán trên blockchain. Việc mã hóa dữ liệu, lưu trữ và đồng bộ nó trên toàn bộ mạng lưới kéo theo vô số chi phí liên quan so với những gì bạn nhận được. Các giải pháp hữu hiệu và tuyệt vời cho các tác vụ này đã có sẵn trên thị trường, cũng như có khả năng mã hóa và đồng bộ mà mọi người cần và còn nhiều tính năng hữu ích khác nữa – tốt hơn nhiều so với giải pháp dựa trên blockchain.

Xác thực danh tính

Một ý tưởng khác cho tiềm năng blockchain là sử dụng khả năng đưa ra các tuyên bố công khai nhưng không thể chỉnh sửa hay xóa bỏ để ghi lại số phiếu bầu, xác nhận nguồn gốc của hàng hóa có thương hiệu, xác thực danh tính người dùng, giải quyết vấn đề về sở hữu tên miền, tiết lộ bằng sáng chế tạm thời, hoặc công chứng tài liệu, ….

Nhưng cũng như các ứng dụng trên của blockchain, lý do cho đến nay chúng chưa trở nên nổi bật trong thực tế là vì nó không thực sự là một bước đột phá so với những giải pháp truyền thống. Đối với việc bỏ phiếu, để đảm bảo tính ẩn danh của người bỏ phiếu cũng như lá phiếu bầu và người bỏ phiếu là một và chỉ một, các tờ giấy làm tốt hơn nhiều so với blockchain.

Còn với việc xác thực danh tính ư, công nghệ mã khóa công khai PGP đã có sẵn cho điều này. Còn nếu bạn muốn xác thực viên kim cương hay chiếc túi da bạn mua có nguồn gốc hợp pháp, công ty sản xuất chỉ cần đính kèm một chứng nhận xác thực online, như cách họ đã làm trong quá khứ.

Đối với việc sở hữu tên miền, dù lời hứa hẹn về một bản ghi kỹ thuật số cho các hợp đồng thông minh có vẻ hấp dẫn, nhưng trong thực tế, vẫn có khả năng các tên miền giá trị bị lọt vào tay các tên trộm do vấn đề về bảo mật, lúc này người ta thực sự cần ghi đè lên sổ cái để lấy lại tên miền đó. Việc chấp nhận blockchain có thể làm cho việc mạo danh hoặc trộm cắp còn nhiều hơn nữa chứ không ít đi.

Vậy còn lại gì cho blockchain?

Như đã thấy ở trên, với đại đa số các ý tưởng ứng dụng đáng chú ý nhất của blockchain cho đến thời điểm này, chúng đều đang được triển khai trên thực tiễn. Không chỉ vậy, chúng còn đều đang được thực hiện hiệu quả hơn hẳn so với việc triển khai trên blockchain, với chi phí thấp hơn hẳn so với khối lượng công việc nó triển khai được.

Vấn đề không chỉ nằm ở phía các ý tưởng ứng dụng blockchain, mà còn xuống sâu hơn khi nó đụng đến vấn đề bản chất của nền tảng này. Trong khi các chuỗi blockchain đều phụ thuộc vào mạng lưới phân tán từ người dùng với các máy tính có phần cứng hạn chế, các công ty cung cấp dịch vụ điện toán tập trung lại có ưu thế hơn hẳn về sức mạnh phần cứng và phần mềm tối ưu.

Bất chấp những lời hứa hẹn về tiềm năng của một nền tảng phân tán, việc chi phí quá lớn và hiệu năng thấp so với các giải pháp hiện tại khi thực hiện một tác vụ nào đó làm các ý tưởng ứng dụng cho blockchain vẫn cứ mãi nằm ở dạng tiềm năng. Việc đánh đổi quá lớn giữa chi phí lớn cho các lợi ích mơ hồ càng khiến nó trở nên xa cách hơn với người dùng thông thường.

Do vậy không lạ khi cho đến nay, ứng dụng phổ biến nhất của blockchain vẫn chỉ là các hoạt động đầu cơ tiền tệ và đôi khi đi kèm với nó là các giao dịch bất hợp pháp. Có lẽ tiềm năng của nó sẽ trở nên rõ ràng hơn khi năng lực phần cứng mạnh mẽ hơn trong tương lai, nhưng cho đến lúc đó, có lẽ hai ứng dụng này vẫn sẽ là những gì người ta nhắc đến nhiều nhất khi nói về blockchain.

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm tuyển dụng ngành cntt hấp dẫn trên TopDev

Cài đặt Elasticsearch trên CentOS

Cài đặt Elasticsearch trên CentOS

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh

Trong bài viết này, TopDev sẽ hướng dẫn các bạn cách cài đặt Elasticsearch trên CentOS các bạn nhé. Elasticsearch, từ tên gọi của nó, các bạn cũng có thể đoán nó liên quan đến tìm kiếm phải không? Nó là một công cụ tìm kiếm được xây dựng từ Apache Lucene, giúp chúng ta tìm kiếm nhanh chóng sử dụng RESTful Web Service. Nó được phát triển bằng ngôn ngữ Java và là một hệ thống phân tán, có thể dễ dàng mở rộng.

  Cách cài đặt Android Studio phiên bản năm 2020
  Cài đặt Laravel

Đầu tiên, bởi vì mặc định các repository của CentOS không chứa package cài đặt của Elasticsearch nên chúng ta cần phải add repository của Elasticsearch vào.

Để làm được điều này, các bạn hãy chạy câu lệnh sau để thêm Elasticsearch public signing key vào máy của mình để package manager trust package từ Elasticsearch repository:

Kết quả của mình như sau:

Cài đặt Elasticsearch trên CentOS

Tiếp theo, các bạn cần tạo mới một tập tin để thêm Elasticsearch repository:

rồi thêm vào tập tin này nội dung như sau:

[elasticsearch-7.x]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Bây giờ thì các bạn có thể bắt đầu cài đặt Elasticsearch rồi,

Hãy chạy câu lệnh sau các bạn nhé:

Các bạn sẽ thấy Elasticseach được cài đặt như sau:

Cài đặt Elasticsearch trên CentOS

Nhập “Y” để tiếp tục các bạn nhé!

Kết quả cài đặt:

Cài đặt Elasticsearch trên CentOS

Mặc định thì Elasticsearch sẽ chạy ở port 9200 và chỉ truy cập được bằng localhost. Các bạn có thể chỉnh sửa cấu hình của Elasticsearch ở /etc/elasticsearch/elasticsearch.yml để thay đổi những điều này.

Sau khi chỉnh sửa xong thì có thể start Elasticseach service sử dụng câu lệnh:

Chạy Elasticsearch lúc khởi động máy:

Bây giờ, nếu các bạn mở trình duyệt rồi đi đến địa chỉ http://localhost:9200, các bạn sẽ thấy kết quả như sau:

Cài đặt Elasticsearch trên CentOS

Bài viết gốc được đăng tải tại huongdanjava.com
Có thể bạn quan tâm:
Xem thêm Việc làm Developer hấp dẫn trên TopDev

50+ tiêu đề tuyển dụng nhân sự cực ấn tượng, thu hút lượng tương tác cao

tiêu đề tuyển dụng
tiêu đề tuyển dụng

Nhu cầu về tuyển dụng ngày cao. Do vậy, các thách thức đặt ra là liệu làm thế nào để lập kế hoạch truyền thông cho việc tuyển dụng. Hiểu được nhu cầu đó, một trong số những cách thức được tối ưu chính là tập trung truyền tải thông điệp tuyển dụng thông qua các tiêu đề tuyển dụng.

Tiêu đề tin tuyển dụng thật sự có ý nghĩa quan trọng; góp phần không nhỏ đến việc thu hút các ứng viên tiềm năng. Cùng TopDev điểm qua Top 50+ tiêu đề viết bài tuyển dụng cực thu hút; giúp tạo ấn tượng mạnh đối với ứng viên.

Một số lưu ý khi viết tiêu đề tuyển dụng

Đối tượng bạn hướng đến là rất quan trọng. Cụ thể bạn cần xác định rõ các users của mình là ai: những người tìm việc, nền tảng tuyển dụng, mô hình web trung gian kết nối công ty tuyển dụng trực tuyến,…

tiêu đề tuyển dụng
tiêu đề tuyển dụng

Từ cơ sở đó, bạn mới biết rõ và nắm được các đặc tính để thiết lập nên những tiêu đề  tin tuyển dụng hấp dẫn. Việc bạn cần làm sau này chỉ là thu hút, tạo điểm nhấn để các ứng viên có thể tìm kiếm, khai thác thông tin từ các bài tin tiêu đề tuyển dụng.

Những tips giúp tiêu đề tuyển dụng cực thu hút

Trước khi đến với những tiêu đề tuyển dụng cụ thể, chúng ta cùng checklist các tip sau đây để có những hiểu biết cơ bản về cách thức tiếp cận; viết một tiêu đề tuyển dụng gây “thương nhớ” các ứng viên.

Làm CV Online tại đây

1. Chú trọng dùng các thuật ngữ phổ biến – thông dụng

Thuật ngữ thông dụng có tính phổ quát, dễ hiểu và dễ tiếp cận nhất với đa số mọi đối tượng người đọc. Sử dụng thuật ngữ chuyên biệt tạo ra một  rào cản lớn trong việc hiểu và tiếp cận chính xác thông tin người đăng tin tuyển dụng muốn truyền tải.

Do vậy, bạn nên sử dụng các thuật ngữ thông dụng, có tính chất đại chúng. Đừng dùng thuật ngữ riêng vì bản chất thực tế, bạn còn không hiểu chính xác về nghĩa của chúng.

Tùy từng vấn đề, các trường hợp và vị trí cụ thể, việc dùng thuật ngữ sẽ tự linh động đáp ứng. Tuy nhiên, vẫn phải đảm bảo mọi thông điệp phải đúng trọng tâm, không gây mơ hồ.

2. Quy ước chung về việc sử dụng bộ từ ngữ để mô tả công việc  

Ở đây, chúng ta có thể hiểu là việc sử dụng các từ ngữ có tính chất kết nối; được xác lập trong một bộ từ ngữ chung nhằm áp dụng để giải quyết các vấn đề trọng tâm xoay quanh nội dung và tiêu đề tuyển dụng.

Các từ ngữ cần chung một trường từ vựng và không bị lạc quá xa so với phạm vi nghĩa chung được sử dụng đối với lĩnh vực tuyển dụng nhân sự.

Hãy lọc ra các bộ từ ngữ quan trọng, phù hợp và rồi triển khai chúng trong từng bài viết, tiêu để tin tuyển dụng. Như thế, nội dung và thông điệp sẽ đều được tối ưu hóa một cách tốt nhất.

3. Tập trung vào tiêu đề viết bài tuyển dụng nhưng đừng đặt áp lực vào nó!

Tiêu đề tuyển dụng cần bạn tập trung để tạo nên các điểm nhấn. Tức mặt hình thức, gây ấn tượng thẩm mỹ và kích thích sự tò mò. Đó là những lý do tại sao có nhiều tiêu đề giật tít ra đời.

Tuy nhiên, nếu một chiến lược tuyển dụng có thể đạt được hiệu quả, bạn cần quan tâm đến việc cân bằng giữa hình thức lẫn nội dung bên trong. Đừng cố gắng sáng tạo các tiêu đề tin tuyển dụng; quên đi trọng tâm nội dung tuyển dụng phải được ứng viên nắm rõ.

4. Truyền thông và duy trì tính ổn định về khả năng tìm kiếm của tiêu đề tuyển dụng

Khi đã có những tiêu đề chuẩn – hấp dẫn ứng viên. Việc bạn cần làm là đặt ra các giải pháp để truyền thông cho nó. Có thể chia sẻ bài bài viết, tiêu đề tuyển dụng trên các nền tảng khác nhau.

tiêu đề tuyển dụng
tiêu đề tuyển dụng

Từ những hướng đi đó, bạn cần đạt được sự ổn định và khả năng tìm kiếm của tiêu đề tuyển dụng. Đo lượng mức độ, phân tích chúng để có một chiến lược nâng cao hơn cho những định hướng phát triển tiếp theo.

5. Thông tin tuyển dụng chính xác, phù hợp

Chính xác ở đây được hiểu là việc bạn tiếp cận, xây dựng, hoàn thiện và phát triển nội dung tiêu đề lẫn nội dung về vị trí tuyển dụng.

Nếu tuyển dụng về các vị trí như tuyển dụng data scientist, senior developer,… thì tiêu đề cần phải rõ ràng, tránh mơ hồ chung chung. Ngành IT có rất nhiều vị trí, bạn cần tối ưu chuẩn các vị trí. Đồng thời, nội dung tuyển dụng cũng cần phải trình bày cụ thể, để không khiến các ứng viên có sư nhầm lẫn đến các vị trí khác có liên quan.

Tiêu để tin tuyển dụng và nội dung tuyển dụng cần có sự phụ ứng, đồng nhất với nhau. Đó là điều thật sự quan trọng và bạn cần phải lưu tâm. 

Top 50+ tiêu đề tuyển dụng nhân sự cực thu hút cho ứng viên tài năng

Làm CV Online tại đây

tiêu đề tuyển dụng

Tiêu đề tuyển dụng thông dụng nhất

  1. Việc làm Nhân sự lương cao
  2. Top việc làm nhân sự, tuyển dụng nhân sự cực hot
  3. Tổng hợp các vị trí việc làm Nhân sự hot nhất hiện này
  4. Tuyển dụng Nhân sự – Việc tốt & Lương cao
  5. Cơ hội phát triển nghề nghiệp cho các vị trí Nhân sự hấp dẫn
  6. Tuyển dụng Nhân sự đi làm ngay
  7. Nhiều vị trí nhân sự tuyển dụng – Lương thưởng tốt
  8. Tuyển dụng – Tìm việc lương cao cực kỳ hấp dẫn
  9. Cơ hội cho sinh viên mới ra trường – Nhiều vị trí Nhân sự chất lượng
  10. Gấp – Tuyển dụng nguồn lực Nhân sự tiềm năng
  11. Tuyển dụng việc làm Nhân sự tại Hồ Chí Minh
  12. Ngành Nhân sự – Tuyển dụng các vị trí hấp dẫn lao động trẻ
  13. Tuyển dụng nhân sự đa ngành nghề – Thu nhập cao
  14. Tuyển dụng Nhân viên Nhân sự  – Việc tốt & Lương cao
  15. Nhân viên Nhân sự  – Cơ hội trải nghiệm từ các Tập đoàn đa quốc gia
  16. Tuyển dụng các vị trí Nhân sự đa ngành
  17.  Tìm việc, tuyển dụng Nhân sự lương cao uy tín nhất
  18. Tuyển dụng hàng trăm vị trí Nhân sự với mức lương cực kỷ hấp dẫn
  19.  Cơ hội trở thành ứng viên nhân sự tiềm năng cho các Tập đoàn lớn
  20. Tuyển dụng vị trí Nhân sự cấp cao – Cơ hội lớn dành cho các bạn trẻ
  21.  Tuyển dụng việc làm Nhân sự không yêu cầu kinh nghiệm
  22.  Cập nhật 20 vị trí tuyển dụng nhân sự tại….
  23.  Tuyển dụng nhân sự Part-time và Full-time (Toàn thời gian)
  24.  Nhiều vị trí tuyển dụng nhân sự với mức lương cao
  25. Tuyển dụng nhân sự mới  – Nhiều vị trí Nhân sự hot
  26. Các việc làm nhân sự mới nổi – Thu nhập ổn định
  27. Tổng hợp việc làm Nhân sự nổi bật nhất

Tiêu đề có yếu tố sáng tạo trong câu từ

  1. Chiêu mô anh tài Nhân sự 
  2. Tuyển dụng CTV, Part-time, Toàn thời gian cho các vị Nhân sự mới
  3. Phỏng vấn đi làm ngay – Tuyển dụng lương offer cao
  4. Tuyển Nhân sự cho các vị trí 
  5. Tuyển đồng đội Cộng tác viên, Intern, Part-Time, Full-time, Freelancer 
  6. Job nhân sự mới – Apply liền tay, chớp ngay cơ hội
  7. Hot Job tuyển dụng các vị trí Nhân sự  – Apply ngay kẻo lỡ
  8. Bạn sẽ là ứng viên tiềm năng? – Tuyển dụng Nhân sự cho các vị trí mới
  9. Truy tìm đồng đội nhân sự mới, lương thưởng hấp dẫn
  10. Cơ hội lớn để bước vào ngành Nhân sự 
  11. O tròn như quả trứng gà; Ô thì đội mũ; Ơ thì Job ngon – Tìm đông đội nhân sự, trải nghiệm tại các tập đoàn tiềm năng
  12. Tuyển dụng vị trí nhân sự – phúc lợi ổn định
  13. Các cơ hội tuyển dụng nhân sự hot nhất
  14. Tuyển dụng lương hấp dẫn, môi trường năng động – thăng tiến nhanh
  15. Việc làm Hot cho các bạn đam mê ngành Nhân sự
  16. Gió đưa cành trúc la đà – Ai chưa có việc thì vào Apply
  17. Nếu là tín đồ của ngành Nhân sự  – Đừng bỏ qua Job này!
  18. Ứng tuyển Job HR ngon  – Pass phỏng vấn – Đi làm ngay!
  19. Tìm đồng đội Nhân sự cùng chiến với các Project
  20. Apply tiền tay – Có ngay việc mới
  21. Cơ hội cho các bạn yêu thích ngành Nhân sự
  22. Tuyển gấp các đồng đội Nhân sự  – Lương up to hấp dẫp
  23. Truy tìm ứng viên Nhân sự tiềm năng cho các dự án
  24. Top những vị trí nhân sự hot nhất
  25. Đi đầu mà vội mà vàng  – Dừng chân đứng lại một hàng Job ngon
  26. Thách thức mới với vị trí Nhân sự – Bạn có dám thử không

Lời kết

Mỗi tiêu đề được đặt ra đều có ý nghĩa. Bạn cần nắm rõ những lưu ý về việc tổ chức xây dựng nội dung tiêu đề sao cho thu hút. TopDev hi vọng, bài viết đã có những chia sẻ bổ ích cho bạn đọc.

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

Có thể bạn quan tâm:

Xem thêm việc làm ngành it hàng đầu tại TopDev

Những chứng chỉ cần có của một quản lý công nghệ thông tin

chứng chỉ it
Những chứng chỉ cần có của một quản lý công nghệ thông tin

Tác giả: Ryan Vergara

Giới thiệu

Chúng ta đang sống trong thời kỳ công nghệ 4.0 chính vì vậy nên các vị trí công việc dành cho lĩnh vực công nghệ thông tin ngày một nhiều hơn. Và để vươn lên vị trí là một quản lý công nghệ thông tin, bên cạnh kỹ năng và kiến thức, bạn cần có những bằng cấp liên quan để chứng minh năng lực của mình với nhà tuyển dụng.

lập trình
Có thêm những chứng chỉ này giúp việc thăng tiến phần nào “nhẹ nhàng” hơn

Những chứng chỉ IT cần có một quản lý công nghệ thông tin

Cisco Certified Network Associate (CCNA)

CCNA có lẽ là bằng phổ biến và quen thuộc nhất hiện tại dành cho các chuyên gia CNTT. Đây là một khóa học cấp chứng chỉ trung cấp. Người sở hữu bằng CCNA là người có năng lực trong việc định cấu hình, vận hành và khắc phục sự cố mạng được định tuyến.

Để có được chứng chỉ này, bạn phải vượt qua kỳ thi CCNA 200-301. Trong đó bài kiểm tra này đề cập đến các nguyên tắc cơ bản về bảo mật mạng, giao thức internet, tự động hóa và các kỹ năng liên quan đến bảo mật khác.

Xem thêm các việc làm tại Gear Inc tuyển dụng hấp dẫn với TopDev

Kỳ thi bao gồm 120 câu hỏi trong đó mỗi câu hỏi có một điểm liên quan. Để vượt qua kỳ thi, bạn phải có số điểm ít nhất là 800 (điểm cao nhất có thể đạt được là 1.000). Chi phí cho kỳ thi này là 300 USD.

Chứng chỉ IT Cisco Certified Network Professional (CCNP)

Trong khi CCNA là chứng chỉ bao gồm các cấp độ kỹ năng từ cơ bản đến trung cấp, chứng chỉ Cisco Certified Network Professional là chứng chỉ dành cho những người muốn đạt được trình độ cao hơn, có tính chuyên môn sâu hơn.

Để sở hữu chứng chỉ CCNP, ứng viên phải trải qua hai kỳ thi: kỳ thi cốt lõi bao gồm các khái niệm mạng cơ bản và kỳ thi tập trung trong bất kỳ lĩnh vực trọng tâm dự định (thiết kế mạng, tự động hóa, v.v.).

Tốt nhất bạn nên lấy chứng chỉ CCNP sau ít nhất ba năm kinh nghiệm trong ngành này. Bạn không cần phải thi CCNA trước khi thi CCNP. Chi phí cho các kỳ thi CCNP nằm trong khoảng từ 900 – 1200 USD.

Xem thêm các việc làm tuyển dụng Tester chưa có kinh nghiệp hấp dẫn tại TopDev

Secure Access Service Edge (SASE)

SASE là một công nghệ mới (được giới thiệu trong “Tương lai của An ninh mạng là trong đám mây” của tác giả Gartner). Kiến trúc này tích hợp Mạng diện rộng (WAN) và một số giao thức bảo mật riêng của đám mây.

Cato Networks là một công ty cung cấp nền tảng SASE dựa trên đám mây và họ cũng cung cấp một khóa học cấp chứng chỉ cho SASE để bạn có thể làm quen với công nghệ mới này. Đối với kiến ​​trúc cụ thể này, trung tâm truy cập mạng của một công ty là các trung tâm dữ liệu vật lý của nó. Đối với SASE, trung tâm đó chuyển qua đám mây.

Xem thêm 15 chứng chỉ “vàng” đáng giá trong ngành lập trình

Tóm lại, SASE giúp các Nhà quản lý CNTT quản lý mạng hiệu quả hơn vì nó loại bỏ một số phức tạp liên quan đến thiết lập trung tâm dữ liệu vật lý truyền thống. Để được cấp chứng chỉ SASE, bạn cần tham gia khóa học SASE Expert Level 1 và vượt qua bài kiểm tra liên quan (điểm tối thiểu phải là 85%).

chứng chỉ IT
Có nhiều loại chứng chỉ IT khác nhau để các dev tham khảo

Chứng chỉ CompTIA cloud+

CompTIA’s cloud+ của CompTIA dành cho những người muốn tìm hiểu việc quản trị hệ thống, bảo trì dịch vụ đám mây cũng như các kiến ​​thức và kỹ năng liên quan đến hệ thống mạng khác.

Hiện tại, để có thể lấy chứng chỉ này bạn phải tham gia hai kỳ thi với điều kiện cần có là ít nhất 2 năm kinh nghiệm làm việc trong ngành.

CV0-002 (ra mắt vào tháng 2 năm 2018) được thiết kế cho các ứng viên bao gồm tích hợp các giải pháp khác nhau vào một hệ thống dành riêng cho doanh nghiệp. Nó có tối đa 90 câu hỏi và có thể được thực hiện trong 90 phút. Điểm đậu (từ 100 đến 900) là 750. Chi phí để tham dự kỳ thi này là 329 USD.

CV0-003 (vẫn đang ở chế độ beta) được thiết kế để các ứng cử viên không có khả năng tạo ra các giải pháp cho tổ chức của họ. Nó có 110 câu hỏi có thể được trả lời trong 165 phút. Hiện tại, không có bất kỳ điểm vượt qua cuối cùng nào và vì nó đang ở giai đoạn thử nghiệm, chi phí để có chứng nhận cụ thể này chỉ là 50 USD.

  AWS, Azure và Google Cloud là gì? Chứng chỉ nào tốt nhất cho sự nghiệp của bạn?

AWS Certified Solutions Architect

Chứng chỉ này của AWS dành cho các chuyên gia thiết kế kiến ​​trúc mạng liên quan đến AWS. Nó yêu cầu ứng viên có ít nhất hai năm kinh nghiệm trong việc vận hành và quản lý các ứng dụng AWS.

Đây là một trong những chứng chỉ được tìm kiếm nhiều hiện nay vì Amazon là nhà cung cấp hàng đầu cho các dịch vụ điện toán đám mây. Do đó, ngày càng nhiều tổ chức thuê các chuyên gia có thể điều hướng thông qua cơ sở hạ tầng này.

Với mức giá 300 USD để tham gia kỳ thi, bạn nên chuẩn bị cho kỳ thi thật kỹ lưỡng. Điều tuyệt vời là Amazon cung cấp một số tài liệu chuẩn bị cho những người quan tâm đến việc đạt được chứng nhận được đánh giá cao này.

Xem thêm các việc làm tuyển dụng Tester HCM hấp dẫn tại TopDev

Salesforce Certified Development Lifecycle and Deployment

Vì Salesforce là một giải pháp quan trọng của các doanh nghiệp CRM nên các tổ chức thường dựa vào nền tảng SaaS này để quản lý mối quan hệ của họ với khách hàng cũng như cung cấp quyền truy cập tập trung cho các bộ phận liên quan.

Kỳ thi này cũng có một mức giá khá cao 400 USD. Đề thi có 60 câu hỏi trắc nghiệm và yêu cầu thí sinh trả lời đúng ít nhất 60% trong số đó. Những người không đạt kỳ thi được phép thi lại với lệ phí 200 USD.

Xem thêm các việc làm tại Gear Inc tuyển dụng hấp dẫn với TopDev

Kết luận

Những chứng chỉ này hoàn toàn không phải là những chứng chỉ duy nhất có thể nâng cao kỹ năng của Người quản lý CNTT mà còn có nhiều chứng chỉ khác để bạn tham khảo thêm. Việc có thêm các chứng chỉ chuyên môn không chỉ giúp bạn làm việc hiệu quả hơn mà còn là cơ hội cho triển vọng nghề nghiệp tương lai của mình.

Bài viết gốc được đăng tải tại freecodecamp.org

Có thể bạn quan tâm:

Xem thêm việc làm tuyển dụng Tester hấp dẫn tại TopDev

JavaScript Executor trong Selenium Webdriver

JavaScript Executor trong Selenium Webdriver

Bài viết được sự cho phép của tác giả Vân Anh

Hôm nay sẽ cùng các bạn tóm lược về thành phần khá là mạnh mẽ trong Selenium Webdriver như tiêu đề bài viết. Hi vọng rằng bài viết sẽ giúp các bạn biết hơn về Javascript Executor còn có hiểu hơn không thì chưa biết. :v

1. Tổng quan về Javascript Executor

Javascript Executor là một interface của Selenium Webdriver, nó có chức năng tương tự như của Java Script và có thể tương tác với các phần tử HTML DOM. Thay vì sử dụng method driver.findElement của Selenium Webdriver thì chúng ta có thể sử dụng JavaScriptExecutor Interface để thực hiện những thao tác tương tự trên trang ứng dụng.

Javascript Executor cho phép chúng ta có thể chạy mã Javascript thuần túy bất kể là chúng ta đang sử dụng ngôn ngữ nào với Selenium như Java, C# hay Python…

Thường thì chúng ta sẽ chỉ sử dụng Javascript Executor trong những trường hợp mà khi sử dụng các method thông thường khác với Selenium nó không thể thực thi được như mong muốn.

Để sử dụng được Javascript Executor, không nhất thiết bạn phải có kiến thức và hiểu biết quá sâu về Javascript mới làm được, một thực tế là bạn chỉ cần tìm kiếm Google là ra cả tá :v từ Stackoverflow cho đến Guru99 hay ToolSQA … sau đó copy về dùng thôi. Nhưng sẽ tốt hơn nếu bạn hiểu về nó, để có thể linh hoạt sử dụng trong nhiều những trường hợp có thể gặp sau này! 

Như đã nói phía trên, Javascript là một interface thuộc package org.openqa.selenium trongSelenium Webdriver. Có hai abstract method là:

  1. executeScript()
  2. executeAsyncScript()

Để sử dụng các method trong Javascript Executor interface ta phải ép đối tượng driver thành kiểu Javascript Executor, theo cú pháp dưới đây:

// chuyển kiểu của đối tượng driver thành JavascriptExecutor
JavascriptExecutor js = (JavascriptExecutor) driver;

// sử dụng các methods
js.executeScript("javascript command");
js.executeAsyncScript("javascript command");

Hầu như là chúng ta sẽ sử dụng method executeScript() còn về executeAsyncScript() mình cũng chưa dùng và chưa tìm hiểu nên sẽ không nhắc đến ở đây – nên cũng đừng thắc mắc mình nha. :v

Tham khảo tin đăng tuyển Javascript mới nhất trên TopDev

Bên cạnh cú pháp trên, cũng có một cách khác ngắn hơn để sử dụng Javascript Executor, nhưng theo khuyến cáo đây không phải là cách hoàn hảo nhất, tuy nhiên khi tìm kiếm từ Google lại ra rất nhiều kết quả hướng dẫn giống như này và mình cũng chưa hiểu tại sao mà nó lại không phải là một cách hoàn hảo nhất như lời khuyến cáo  :

((JavascriptExecutor) driver).executeScript("javascript command");
  Giới thiệu về Reactive Programing trong javascript

2. Sử dụng Javascript Executor

2.1. Tìm 1 phần tử với Javascript Executor (Find an element)

Ở ví dụ phía dưới, mình sử dụng ID để tìm một phần tử trên một trang, chúng ta cũng có thể thay bằng các thuộc tính khác tương ứng của phần tử cần tìm như Name, hay CSS.

Cú pháp:

JavascriptExecutor js = (JavascriptExecutor) driver;
Object searchTextbar = js.executeScript
                       ("return document.getElementById('lst-ib')");
((WebElement) searchTextbar).sendKeys("abc");

2.2. Click vào một phần tử nào đó (Click an element)

Tương tự như khi tìm kiếm một phần tử, với Javascript Executor ta cũng có thể thực hiện thao tác click vào một phần tử dựa trên thông tin của phần tử đó. Ở ví dụ phía dưới đây mình thực hiện lấy phần tử dựa theo tên của nó, ta có cú pháp như sau:

JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("document.getElementsByName('btnI')[0].click()");

2.3. Thực hiện sendKey

Ta có thể sử dụng Javascript Executor để thực hiện truyền giá trị cho các phần tử cho phép nhập dữ liệu là textbox hay text area trong Selenium Webdriver. Các bạn có thể tham khảo cú pháp dưới đây:

JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("document.getElementById('lst-ib').value='chercher tech'");

2.4. Thực hiện scroll webpage (cuộn trang)

Trường hợp này có lẽ là quen thuộc hơn cả, đó là khi mà trang ứng dụng quá dài, và không thể hiển thị hết chiều dài nội dung trong khung màn hình được, do vậy mà ta sẽ cần phải thực hiện cuộn trang để có thể di chuyển đến vị trí tọa độ cụ thể mong muốn trên trang ứng dụng. Đây là công việc mà ta sẽ không thể dùng Selenium webdriver để thực hiện được. Lúc này, Javascript Executor sẽ giúp bạn làm việc này một cách dễ dàng, với cú pháp:

JavascriptExecutor js = (JavascriptExecutor)driver;
js.executeScript("window.scrollBy(0,300)");

Giải thích một chút chỗ js.executeScript(“window.scrollBy(0,300)”);

scrollBy(horizontalDistance,verticalDistance): ta có hai tham số đầu vào là:

  1. horizontalDistance – Là khoảng cách được cuộn theo chiều ngang
  2. verticalDistance – Khoảng cách được cuộn theo chiều dọc

Như ví dụ phía trên mình có scrollBy(0, 300) có nghĩa là cuộn xuống phía dưới 300px theo chiều dài của trang web. Tương tự bạn có thể thay bằng các giá trị khác tùy theo yêu cầu và mong muốn.

  Javascript ES6 – Đôi điều thú vị có thể bạn chưa biết

2.5. Scroll into view

Vốn từ mình hơi ít nên không biết dùng từ diễn đạt sang Tiếng Việt như nào cho dễ hiểu, ở đây có thể hiểu nôm na rằng là cuộn trang đến một vùng cụ thể hoặc một phần tử cụ thể nào đó trên trang. Ví dụ: ta có thể gặp trường hợp như muốn tương tác đến một trường A nào đó trên trang ứng dụng, nhưng vì có nhiều thông tin nên trường này không thể hiển thị được trên một màn hình mà phải cuộn  trang web xuống phía dưới trường này để nhập thông tin, lúc này sử dụng “scroll into view” để cuộn xuống phía dưới, ta sẽ nhìn thấy trường này ở trên màn hình hiển thị, và cho đến thời điểm này bạn mới thực hiện tương tác được với trường A thông qua Selenium.

Không biết với ví dụ trên các bạn đã hình dung được chưa, nhưng tóm váy lại là Javascript Executor có thể giúp bạn làm cái công việc mô tả loằng ngoằng phía trên kia.

Ta sử dụng hàm scrollIntoView() – tên gọi đúng như mục đích sử dụng, và có cú pháp như sau:

JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("document.getElementById('default').scrollIntoView(true)");

2.6. Một số việc khác mà Javascript Executor có thể làm được

Bên cạnh những công việc bên trên Javascript Executor có thể xử lý ngon lành thì cũng còn có rất nhiều những tác vụ khác mà ta có thể “lợi dụng” Javascript Executor làm nếu thấy “thích” như:

1. Lấy ra thông tin title của ứng dụng web với cú pháp:

js.executeScript("return document.title");

2. Lấy ra thông tin địa chỉ URL của ứng dụng:

js.executeScript("return document.URL");

3. Kiểm tra trạng thái của trang web đã được tải về hay chưa:

js.executeScript("return document.readyState");

4. Điều chỉnh mức độ phóng to thu nhỏ hiển thị của nội dung trang web:

js.executeScript("document.body.style.zoom='90");

5. Lấy ra thông tin về kích thước của ứng dụng web:

// Độ cao
js.executeScript("window.innerHeight");
// Độ rộng
js.executeScript("window.innerWidth");

6. Lấy ra thông tin về kích thước của trình duyệt:

js.executeScript("window.outerHeight");
js.executeScript("window.outerWidth");

7. Điều hướng đến một địa chỉ URL nào đó:

js.executeScript("window.location="https://google.com";");

Và còn kha khá những thứ hay ho khác nữa. Tuy nhiên chắc chẳng mấy khi dùng đến đâu ấy, liệt kê ra cho mọi người biết được là Javascript Executor đích thị là một “soái ca” hay ho và đa năng :v. Có cái gì mà anh không làm được đâu? Chỉ là các em không biết tận dụng anh thôi =))

Nhưng mà có phải Javascript Executor thực sự không có nhược điểm gì? Đọc tiếp để xem “soái ca” này cuối cùng có phải là “Mr. Right” với Selenium Webdriver không nhé!

  JavaScript là gì? Làm thế nào để trở thành lập trình viên JavaScript?

3. Javascript Executor có phải là “soái ca” đích thực?

Đầu tiên phải nhắc lại một lần rằng, Selenium Webdriver hoạt động tương tự như một người dùng cụ thể của ứng dụng. Selenium Webdriver thực thi những thao tác mà một người dùng thực sự có thể làm đối với một phần tử nào đó trên ứng dụng web.

Nếu như trên thực tế, Selenium Webdriver không thể tương tác với một phần tử nào đó trên trang ứng dụng thì ta cũng cần phải cân nhắc xem liệu rằng đó có phải là một lỗi hay không trước khi sử dụng Javascript Executor để ép buộc nó phải chạy theo ý mình. Biết đâu lỗi thật thì có phải là nguy hiểm không? :v

Bạn nên kiểm tra kỹ trên tất cả các trình duyệt với code Selenium Webdriver thông thường (các trình duyệt mà ứng dụng được yêu cầu cần phải được test), có thể phần tử đó chỉ có thể hoạt động đúng trên một trình duyệt nào đó – thì có thể cân nhắc sử dụng Javascript Executor, còn nếu như trên tất cả trình duyệt bạn kiểm tra, phần tử đó không hoạt động đúng thì cần đánh False testcase thay vì sử dụng Javascript Executor.

Điều này sẽ đảm bảo rằng bạn không bị lọt bug, trong trường hợp sử dụng Javascript Executor thì có thể chạy ngon lành nhưng trên thực tế thì phần tử đó lại không hiển thị, (do một vài lỗi trong quá trình phát triển) và đối với người dùng thực tế bằng xương bằng thịt lại chẳng thể thao tác được.

[[ Tất nhiên sẽ không tính những trường hợp đặc biệt khác – mà bắt buộc phải sử dụng Javascript Executor mới làm được. ]]

Thế nên đã trả lời cho các bạn rằng, đây cũng có thể là một “sói ca” và các bạn cần hết sức cẩn trọng nhé! 

Hi vọng rằng bài viết sẽ giúp các bạn có thêm thông tin hữu ích về Javasript Executor trong Selenium Webdriver.

Các bạn cũng có thể tham khảo thêm tại link:

https://chercher.tech/java/javascript-executor-selenium-webdriver#sendkeys

Bài viết gốc được đăng tải tại vananhtooo.wordpress.com

Xem thêm việc làm IT hấp dẫn trên TopDev

Phân biệt các thuật ngữ trong Distributed System (Tập 2)

distributed system

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

SCALABILITY – KHẢ NĂNG MỞ RỘNG

Scalability hay gọi tắt là scale là yếu tố đầu tiên mà architect sẽ consider khi thiết kế hệ thống. Làm sao để hệ thống sẽ scale được với kiến trúc và công nghệ đã chọn. Một hệ thống được gọi là có khả năng scale nếu có thiết kế để làm sao có thể add/remove thêm tính năng, module vào một cách dễ dàng, hay làm sao để có thể tiếp nhận một lượng lớn các request tăng đột biến do nhu cầu sử dụng của user tăng lên.

  Giải mã bí ẩn "system load" trên Linux
  Phân biệt các thuật ngữ trong Distributed System (Tập 1)

Về vấn đề thêm thắt module vào hệ thống, chúng ta có thể quay về với nguyên lý thiết kế Open-Closed trong SOLID, một hệ thống cần phải được thiết kế để có thể dễ dàng, open cho sự thay đổi mà vẫn close, không được đập đi làm lại. Ở mức độ coding thì có thể hiểu là sử dụng interface, abstract class để isolate, tách bạch detail implementation và các quy tắc, contract. Hoặc sử dụng các message queue để loose coupling giữa các components.

Còn về việc đáp ứng lưu lượng request lớn thì đòi hỏi system phải có các tính chất eslasticity, giúp co giãn kích thước hợp lý. Khi có nhiều request thì cần scale out hoặc scale up các component để tăng tải, còn khi nhàn rỗi thì lại scale in hoặc down để tiết kiệm chi phí. Hoặc áp dụng các kỹ thuật caching, CQRS, non-blocking để tăng performance

RESILIENCY – KHẢ NĂNG PHỤC HỒI

Resiliency cũng là một yếu tố để bảo đảm tính Reliability của hệ thống. Resiliency đề cập đến các kỹ thuật để giúp khắc phục các lỗi trong quá trình vận hành. Một số kỹ thuật được nhắc đến như health check, monitoring và self healing (tự chữa bệnh, một component tự nhiên lăn ra chết thì phải tự mà sống dậy), circuit breaker and retry (bộ ngắt mạch, để tránh xảy ra sự cố dây chuyền), fail-over (chuyển sang node khác để tiếp tục vận hành)

Dự phòng và khả năng phục hồi thường bị nhầm lẫn với nhau. Tuy cả hai đều có liên quan với nhau nhưng chúng không thể hoán đổi cho nhau. Dự phòng có thể hiểu là việc thực hiện để ngăn chặn thất bại, ngụ ý rằng nó sẽ xảy ra trước khi một vấn đề xảy ra. Khả năng phục hồi liên quan đến việc tìm giải pháp sau khi một vấn đề đã xảy ra. Tóm lại, dự phòng là trước khi vấn đề xảy ra, ngược lại phục hồi là sau khi vấn đề xảy ra.

Ví dụ, cơ sở dữ liệu dự phòng với khả năng replication có thể được tận dụng. Nhiều thành phần và bản sao của dữ liệu tạo ra một redundant design. Nếu primary side của cặp cơ sở dữ liệu không thành công, primary side sẽ đẩy mạnh đến primary và bắt đầu nhận tải trong lúc bên failed side tự sửa lỗi. Chức năng failover và self-healing chính là khả năng phục hồi. Cả hai đều có liên quan, nhưng không thể hoán đổi cho nhau.

DISASTER RECOVERY – KHÔI PHỤC SAU THẢM HỌA

Disaster recovery cũng giống như Resiliency đều là những phương pháp để khắc phục lỗi, nhưng khác ở chỗ Resiliency chỉ giải quyết các vấn đề về vận hành và lỗi ứng dụng, hoặc sự cố cục bộ. Còn disaster recovery nó ở đẳng cấp khác, đẳng cấp của thảm họa như động đất, sóng thần, bom đạn. Rõ ràng không ai muốn có thảm họa xảy ra. Tuy nhiên trong thực tế, đã có case như vậy, đơn cử là vụ sập điện tại bang Virginia của Mỹ khiến do bão gây ra khiến cho các data center của AWS ở đó sập hoàn toàn, trên phạm vi toàn region, khiến rất nhiều website sử dụng dịch vụ này bao gồm Pinterest, Netfilx, Heroku… “tắt điện” nhiều giờ liền.

Thật ra thì mình cũng chưa đạt đến tầm phải consider đến các thảm họa khi thiết kế hệ thống, vì chi phí cho việc dự phòng rủi ro thảm họa là không nhỏ. Bạn phải deploy, backup các server ở nhiều region địa lý khác nhau để khi 1 region sập thì có thể fail-over sang region khác. Thôi thì đợi có deal to như của Netflix rồi tính cũng không muộn, chứ Multi-AZ cũng đủ xài đối với đa số hệ thống.

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Chương Trình Giả Lập trong kiểm thử di động

Chương Trình Giả Lập trong kiểm thử di động

Bài viết được sự cho phép của vntesters.com

Theo thống kê, trong kiểm thử di dộng, chúng ta phải kiểm thử các phần mềm trên khoảng 30-40 thiết bị trên thị trường, và 30% trong số đó bị lỗi thời trong vòng một quí. Ôi… $$$$. Bên cạnh đó, sử dụng thiết bị thật sẽ gặp phải các vấn đề về bảo mật như mở cổng USB để chia sẻ dữ liệu hay nguy cơ mất thiết bị trong môi trường làm việc.

  Biện hộ: Vì sao các Developer không test phần mềm của họ?
  Các công cụ hữu ích hỗ trợ bạn trong việc tạo testdata

Để khắc phục các vấn đề này, chúng ta có thể sử dụng các Chương Trình Giả Lập thiết bị – Emulator/Simulator – trong việc kiểm thử của chúng ta.

Phân biệt Emulator – Simulator

Về cơ bản, cả hai Emulator/Simulator đều chỉ về các chương trình Giả Lập thiết bị di động, nhưng bên cạnh đó, hai thứ có những khác biệt rất đặc trưng.

Simulator:

  • Các chương trình thuộc về Simulator hướng về giả lập các hành vi của thiết bị.
  • Các chương trình thuộc về Simulator chỉ có thể giả lập được phần mềm – Software.

Emulator:

  • Các chương trình thuộc về Emulator hướng về giả lập các công việc bên trong của thiết bị.
  • Các chương trình thuộc về Emulator giả lập cả phần cứng lẫn phần mềm – Hardware/Software.

Chúng ta sử dụng Simulator khi chúng ta chỉ quan tâm đến phần mềm hoạt động như thế nào, còn Emulator sẽ cho chúng ta biết hệ thống làm việc như thế nào.

Điềm mạnh của việc sử dụng các chương trình Giả Lập:

  • Tiết kiệm: Các chương trình Emu/Sim đều miễn phí và được cung cấp như một phần của bộ phát triển phần mềm.
  • Đơn giản: Chúng ta chỉ cần download phần mềm, cài đặt vào máy và mọi thứ đã sẵn sàng để sử dụng.
  • Nhanh chóng: Một chương trình Giả Lập Emu/Sim cũng chỉ là một phần mềm hoạt động trên máy PC, cho nên nó sẽ không tốn quá nhiều thời gian để kết nối với hệ thống như một thiết bị thật.

Điểm yếu của việc sử dụng các chương trình Giả Lập:

  • Tăng độ rủi ro: Với việc sử dụng các chương trình Giả Lập, chúng ta không kiểm thử chương trình với cùng một nền tảng của người dùng cuối. Chúng ta không thể đảm bảo 100% rằng chương trình làm việc với thiết bị thật như cách chương trình làm việc trên Emu/Sim
  • Khác biệt về môi trường mạng: Khi sử dụng Emu/Sim, chúng ta kết nối Internet thông qua các đường truyền cáp, trong khi thiết bị thật lại sử dụng kết nối thông qua sóng radio.
  • Mạng viễn thông: Không có biện pháp kiểm thử mạng viễn thông.

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Khái niệm về OOD – Object oriented design

Khái niệm về OOD – Object oriented design
Bài viết được sự cho phép của tác giả Lê Chí Dũng
Trong việc Design Parttern cho OOP  người ta bàn về vấn đề thiết kế một pattern làm sao để lớp con kế thừa lớp cha nhưng tự loại bỏ những method mà nó không mong muốn. Điều đó có nghĩa là lớp con không tuân thủ nguyên tắc định trước, tức là nó không tuân thủ một trong những nguyên tắc cơ bản của thiết kế hướng đối tượng (OOD – Object oriented design) là Liscov substitution principle.
Điều đó cho thấy khi thiết kế, tìm giải pháp cho một vấn đề nào đó, việc nắm rõ các nguyên lí cơ bản của OOD là vô cùng quan trọng. Bài này xin giới thiệu về 5 nguyên tắc cơ bản của OOD là:
  1. Open closed
  2. Liskov substitution
  3. Dependency inversion
  4. Interface segregation
  5. Single responsibility

Open closed

Ivar Jacobson từng nói: “Để thiết kế các hệ thống lâu dài, cần luôn tâm niệm rằng các hệ thống luôn thay đổi trong quá trình sử dụng”. (All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version.”). Năm 1988, Bertrand Meyer đưa ra mục tiêu để thực hiện điều mà Ivar Jacobson nói trên mà sau này trở thành nguyên lí open-closed nổi tiếng. Đó là: SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.

Các chương trình áp dụng nguyên lí open-close được thay đổi bằng cách thêm code mới chứ không phải sửa code có sẵn. Bằng cách này, tránh được thay đổi dây chuyền trong toàn bộ chương trình. Tuy nhiên, mỗi entity của chương trình có thể đóng với thay đổi này nhưng lại không đóng với thay đổi nào đó khác. Do đó, tính đóng này chỉ là tương đối và nhiệm vụ của người thiết kế là với mỗi đặc thù của chương trình, ưu tiên đóng các thuộc tính dễ thay đổi nhất.

Để “đóng” các entity của chương trình, có thể sử dụng giải pháp abstraction, data driven, ..
Open-closed là nguyên li trung tâm, rất quan trọng trong thiết kế hướng đối tượng vì chính nguyên lí này làm cho lập trình hướng đối tượng có tính tái sử dụng (reusability) và dễ bảo trì (maintainability).

Liskov substitution

Nguyên lí này được phát biểu như sau:

FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.

Tức là hoạt động của các function có sử dụng reference hay pointer tới object của lớp cha cần được đảm bảo là không bị ảnh hưởng khi thay thế reference hay pointer tới object của lớp cha bởi reference hay pointer tới object của lớp con và function đó không cần biết về sự tồn tại của lớp con. Khi đó, các virtual member functions ở lớp cha cũng phải có ở lớp con, và phải thực hiện một công việc có nghĩa.

Nếu nguyên lí này bị vi phạm, function có sử dụng reference hay pointer tới object của lớp cha phải kiểm tra kiểu của object để đảm bảo chương trình có thể chạy đúng, và việc này vi phạm nguyên lí open-closed nhắc đến ở trên.

Dependency inversion

Việc áp dụng hai nguyên lí open-closed và Liskov substitute một cách chặt chẽ có thể tổng quát hóa thành nguyên lí depndency inversion được phát biểu như sau:

  1. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
  2. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTION.

Thực hiện một bằng cách dùng abstract layer như hình dưới.

Interface segregation

Nguyên lí này được phát biểu như sau:

CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE
Khi một client bị ép phải phụ thuộc vào những interface mà nó không sử dụng thì nó sẽ bị lệ thuộc vào những thay đổi của interface đó. Chúng ta cần phải tránh điều này nhiều nhất có thể bằng cách chia nhỏ interface.

Single responsibility

Nguyên lí này được phát biểu như sau:

THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
Chú ý: để hiểu bài này, cần có kiến thức cơ bản về lập trình hướng đối tượng, nhất là các khái niệm encapsulation, inheritance, polimorphism.
Bài viết gốc được đăng tải tại lcdung.top
Có thể bạn quan tâm:

Freelancing Tips: Làm sao để tự tin kiếm tiền hơn?

freelancing tips
Freelancing Tips: Làm sao để tự tin kiếm tiền hơn?

Tác giả: Thomas Weibenfalk

Giới thiệu

Cá nhân tôi đã có nhiều năm kinh nghiệm làm freelance và đã tư vấn cho rất nhiều bạn trẻ về công việc này như thế nào cũng như nên làm gì để làm việc hiệu quả hơn. Trong bài viết này tôi muốn giới thiệu với bạn cách để tự tin hơn và kiếm tiền tốt hơn với công việc freelancing của mình.

thói quen của freelancer
Freelancing tips giúp bạn tự tin kiếm tiền hơn

Vậy freelancing tips gồm những gì?

1. Nuôi dưỡng suy nghĩ làm chủ chính mình

Tôi nghĩ nhiều người bỏ lỡ điểm này. Tôi đã thấy rất nhiều người muốn trở thành một freelancer để được “tự do” hoặc được “là của riêng họ”. Thành thật mà nói, đó cũng là những điều thúc đẩy tôi đến với công việc freelance này. Tôi yêu sự tự do và có thể tạo ra cuộc sống của riêng mình và kiểm soát nó tốt hơn. Nhưng làm nghề tự do cũng rất vất vả dù thật sự khá vất vả.

  Freelancer IT là gì? Những điều thú vị về Freelancer lập trình
  Học lập trình tới khi nào có thể làm freelancer?

Tôi luôn thích tạo ra mọi thứ. Và tôi luôn muốn có công ty của riêng mình (không chỉ là một freelancer). Sự thật là khi bạn làm việc tự do, bạn sẽ phải tự điều hành công việc của riêng mình. Bạn phải học cách yêu thích việc điều hành công việc của mình như trong một công ty và cố gắng tạo ra nhiều giá trị nhất có thể.

Xem thêm các việc làm tại Gear Inc tuyển dụng hấp dẫn với TopDev

2. Freelance có phải là một khía cạnh khác của sale?

Tôi luôn ghét việc bán hàng và coi đó là một từ xấu. Nhưng trên thực tế, chúng ta luôn bán mình – thông qua việc khi chúng ta giao tiếp, làm việc trong các dự án và trong cuộc sống của chúng ta. Mỗi người đều là nhân viên bán hàng cho chính mình. Cách chúng ta nói chuyện, cách chúng ta nhìn và cách chúng ta thể hiện bản thân.

Hãy chấp nhận sự thật rằng khi bạn là một freelancer, bạn cũng chính là một người bán hàng. Bạn phải “bán bản thân” và thuyết phục khách hàng nhìn nhận về giá trị của bạn và những gì bạn có thể mang lại. Điều này là hoàn toàn hợp lý. Nhưng đây cũng có thể trở thành trở ngại với nhiều người.

Xem thêm các việc làm tuyển dụng Tester HCM hấp dẫn tại TopDev

Nhiều người rất dễ mất niềm tin khi những sản phẩm mà họ bán được quá ít. Nỗi sợ bán hàng thực sự đã trì hoãn quyết định bắt đầu làm freelancer của tôi. Tôi sợ không đủ doanh số để có thu nhập kha khá. Nhưng cuối cùng tôi đã “thành lập công ty” của mình và kể cả khi doanh số bán hàng đôi khi chậm, tôi vẫn quyết định đối mặt với mọi thứ và tiếp tục công việc freelance của mình.

3. Học cách đối mặt với những khó khăn

Khi quyết định dấn thân cho lối sống tự do, bạn cần biết rằng sẽ có những khoảng thời gian bạn không có một dự án nào. Có nghĩa là không có thu nhập!

Điều này có thể đáng sợ và thật sự khó khăn với những người đã quen với việc nhận tiền lương vào mỗi tháng. Tôi hoàn toàn hiểu điều đó. Nhưng đây thực sự cũng là một cơ hội để bạn học cách quý trọng tiền bạc hơn. Tôi đã luôn cố gắng tiết kiệm cho mình một khoản riêng vào những lúc không thể kiếm thêm thu nhập.

Xem thêm Là Freelance Developer, bạn nên “định giá” bản thân như thế nào?

Tôi cũng đã nhận thức được một quan điểm khác về giá trị của đồng tiền. Đối với tôi, thu nhập mà tôi kiếm được với tư cách là một freelancer thực sự có giá trị hơn một khoản lương thông thường. Chỉ vì tôi biết tôi có thể mất nó dễ dàng như thế nào.

Tôi cũng biết rằng tôi đã làm việc chăm chỉ hơn để có được khoản thu nhập đó so với việc tôi nhận lương hàng tháng thông thường. Điều đó làm cho số tiền đó có giá trị hơn đối với tôi. Nó cũng giúp bù đắp cho nỗi sợ không có tiền. Vì vậy, bạn phải học cách sống chung với những thăng trầm, những khó khăn khi là freelancer để làm việc tốt hơn.

freelancer
Sử dụng những mẹo này khi làm việc giúp freelancer thoải mái hơn

4. Quen dần với việc làm việc độc lập

Ít nhất với cá nhân mình tôi nghĩ đây là điều tốt. Là một freelancer, bạn có thể không tham gia vào mọi khía cạnh của dự án như một nhân viên toàn thời gian. Một số dịch giả tự do cảm thấy thất vọng vì điều này nhưng tôi nghĩ nó tốt, vì đôi khi bạn sẽ cảm thấy rất tệ nếu tham gia vào các quy trình của dự án và nhận ra các vấn đề bên trong nó.

Một freelancer thường được thuê như một “phương sách cuối cùng”, nghĩa là bạn tham gia dự án khá muộn trong quá trình này. Vì vậy, bạn đã bỏ lỡ phần đầu của dự án. Nhưng thực ra điều này có thể khá tốt vì bạn không cần phải tham gia tất cả các cuộc họp và làm tất cả các công việc hành chính. Tất nhiên, sẽ có những dự án kéo dài trong thời gian dài. Đối với những dự án này, bạn có thể sẽ được đối xử như một nhân viên bình thường.

Xem thêm các việc làm tại Gear Inc tuyển dụng hấp dẫn với TopDev

5. Cống hiến bản thân bằng cách không ngừng học hỏi

Tôi tin vào việc học hỏi những điều mới mỗi ngày trong cuộc sống của tôi. Vì vậy, ngay cả khi tôi không làm việc tự do, tôi vẫn sẽ học mọi lúc. Nhưng học tập đặc biệt quan trọng hơn với tư cách là một freelancer.

Nếu bạn liên tục học hỏi những điều mới, bạn có thể đảm nhận nhiều nhiệm vụ hơn. Là một nhân viên bình thường, bạn thường có thể tránh xa việc không học những thứ mới trong một thời gian dài trước khi bất cứ điều gì xảy ra. Bạn có thể ngồi và làm công việc của bạn như bạn thường làm từ ngày này qua ngày khác.

Nhưng một freelancer thường được thuê vì chuyên môn của họ trong một số lĩnh vực nhất định. Ví dụ, tôi thường được thuê làm việc với vai trò là React Developer. Không ngừng học hỏi những thứ mới chắc chắn sẽ giúp bạn thu hút được bất kỳ nhà tuyển dụng tiềm năng nào.

Xem thêm các việc làm tuyển dụng Tester chưa có kinh nghiệp hấp dẫn tại TopDev

Kết luận

Để trở thành một freelancer thành công và kiếm được nhiều tiền hơn, bạn cần biết cách tự tin với chính mình và dám đối mặt với những khó khăn. Hi vọng bài viết trên đây sẽ phần nào giúp các bạn có thêm thông tin về công việc freelance và cách tận dụng công việc này tốt nhất.

Bài viết gốc được đăng tải tại freecodecamp.org

Có thể bạn quan tâm:

Xem thêm việc làm tuyển dụng Tester hấp dẫn tại TopDev

Top lý do xin nghỉ việc sếp không thể từ chối

lý do xin nghỉ việc
lý do xin nghỉ việc

Quyết định nghỉ việc không phải là một quyết định đơn giản. Và dường như, mỗi nhân viên đều đã suy nghĩ và cân nhắc rất kỹ lưỡng trước mọi quyết định nghỉ việc. Thế nhưng, lá đơn xin nghỉ việc của bạn liệu có được chấp thuận bởi một lý do thuyết phục? Hay sẽ bị từ chối bời những lý do xin nghỉ việc chưa chính đáng? Vậy làm thế nào để có cho mình những lý do xin nghỉ việc thật sự hợp lý? Cùng TopDev xem bài viết sau đây để điểm qua những lý do xin nghỉ việc thuyết phục nhất nhé!

Câu hỏi thực tế – Tại sao nhân viên lại nghỉ việc?

Không khó để đưa ra những nguyên nhân khiến các nhân viên nghỉ việc. Có rất nhiều lý do dẫn đến việc các nhân viên rời đi. 

lý do xin nghỉ việc
Đâu là những lý do khiến nhân viên nghỉ việc?

Đó có thể là những lý do khách quan như: việc dịch chuyển đến một chỗ ở mới, ảnh hưởng từ việc học thêm các khóa học – kỹ năng phát triển chuyên môn nghề nghiệp, môi trường làm việc tốt hơn,…

Hoặc có thể là những lý do cảm tính (bị chi phối bởi yếu tố cảm xúc): nghỉ việc vì có lý do riêng; những mâu thuẫn bất đồng – tranh chấp trong các mối quan hệ với cấp trên lẫn đồng nghiệp; chế độ phúc lợi còn bị giới hạn, cơ hội thăng tiến dường như bằng không,… 

  "Vì sao nghỉ việc tại công ty cũ?": 5 lý do thuyết phục nhà tuyển dụng

Dù bất kế lý do là gì, bạn vẫn phải giữ một tâm thế sẵn sàng. Việc tiếp theo của bạn sau khi có một lý do hợp lý là viết một lá đơn xin nghỉ việc chuyên nghiệp. Hãy đảm bảo rằng đơn xin nghỉ việc của bạn đúng chuẩn.

Đặc biệt, dù kỹ năng giao tiếp thường ngày của bạn không tốt. Nhưng khi viết đơn xin nghỉ việc với một lý do xin nghỉ việc chính đáng, bạn cần phải lưu tâm:

  • Nên bày tỏ thái độ vui vẻ và sự trân trọng đối với tổ chức của mình.
  • Đừng nhắc đến những điều tiếng tiêu cực! Thay vào đó là hãy gợi nhắc những thành quả mà bạn và tổ chức đã trải qua.
  • Tính chuyên nghiệp và chuẩn mực phải được đặt lên hàng đầu.

Những lý do nghỉ việc thuyết phục nhà quản lý nhất

1. Lý do cá nhân

Lý do xin nghỉ việc cá nhân thường là lý do phổ biến nhất. Việc lựa chọn cách thức truyền tải nào sẽ phụ thuộc vào bạn. Tuy nhiên, hãy trình bày rằng vì một số lý do riêng, bạn không thể tiếp tục đồng hành cùng công ty trong thời gian sắp tới. Tất nhiên, bạn sẽ hứa hẹn hoàn tất nốt các công việc còn lại trong thời gian sớm nhất. Đồng thời, bàn giao nhiệm vụ để không làm ảnh hưởng tiến độ chung của công ty.

lý do xin nghỉ việc
lý do xin nghỉ việc

Đây thật sự là một lý do nghỉ việc chính đáng. Bởi lẽ, đã đến lúc bạn suy nghĩ đến những dự định khác cho bản thân. Đâu là nơi thật sự phù hợp với bạn và năng lực của bạn. Cách truyền tải cũng rất quan trọng và là điều bạn nên lưu tâm.

2. Trải nghiệm học tập cao hơn

Ngày này, việc trau dồi nhiều kỹ năng khác nhau như kỹ năng giao tiếp, phân tích vấn đề, kỹ năng đàm phán,… đều quan trọng. Không những thế, nhiều người đã lựa chọn học lên cao hơn để giúp cho sự nghiệp của mình thăng tiến hơn sau này.

Có người lựa chọn vì đam mê ngành học. Có người muốn đổi mới trong quỹ thời gian phát triển cá nhân mỗi ngày. Chẳng hạn như việc, một Junior hay Senior Developer mong muốn tìm kiếm các cơ hội học lên Thạc sĩ, Tiến sĩ,… nhằm theo đuổi những mục tiêu mới. Do vậy, đơn xin nghỉ việc cho developer giúp họ gửi lời đến tổ chức; thông báo về việc kết thúc quá trình dài làm việc của mình.

Tất nhiên đơn xin nghỉ việc cho developer vẫn phải đảm bảo những tiêu chí quan trọng về nội dung, hình thức và một lý do xin nghỉ việc chính đáng.

Cụ thể hơn, bạn sẽ học thêm các khóa học chuyên sâu để nâng cao trình độ. Đó cũng là lúc bạn hướng đến mục tiêu là một bằng cấp khoa học nào đó. Đây thật sự là một điều tốt. Vì ai cũng có quyền trải nghiệm và update bản thân mỗi ngày. Do thực hiện kế hoạch học tập, nghiên cứu sắp tới, bạn khó có thể tiếp tục công việc hiện tại. Chọn 1 trong 2 là điều kiện tiên quyết bắt buộc để vạch ra định hướng phát triển tiếp theo của mình.

3. Một môi trường làm việc mới tốt hơn

Khi đã có những trải nghiệm đủ nhiều tại một tổ chức/doanh nghiệp, bạn chợt nhận ra một yếu tố quan trọng – chính là sự phù hợp. Môi trường hiện tại không còn phù hợp với bạn. Hoặc bạn muốn tìm kiếm một môi trường khác năng động hơn, với nhiều tính cạnh tranh hơn.

Bạn muốn làm việc trong một tập đoàn đa quốc gia; học hỏi và tiếp thu những điều mới; tiếp cận văn hóa và tác phong làm việc của các thị trường quốc tế,…

Hãy chuẩn chị một lá đơn xin nghỉ việc thật hợp chuẩn; trình bày đầy đủ các ý muốn cá nhân để gửi đến nhà quản lý của bạn.

4. Nghỉ việc vì lý do sức khỏe

Sức khỏe luôn là một vấn đề quan trọng đối với một nhân viên. Có sức khỏe, bạn sẽ thật sự ổn định hơn về tinh thần. Đồng thời, sẵn sàng hoàn thành nhiệm vụ một cách tốt nhất. Do vậy, mà bên cạnh các yếu tố về phúc lợi, lương bổng,… sức khỏe là một tiêu chí quan trọng ảnh hưởng đến việc xác lập lý do xin nghỉ việc.

lý do xin nghỉ việc
lý do xin nghỉ việc

Thực tế cho thấy, đây cũng là một lý do xin nghỉ việc chính đáng. Bởi lẽ, ai cũng cần có sức khỏe. Nếu tình hình sức khỏe hiện tại không cho phép bạn tiếp tục công việc, nghĩ đến việc dừng lại đúng lúc. Chưa kể nếu bạn gặp phải những vấn có tính chất phức tạp hơn, bạn lại cần thời gian để nghỉ ngơi.

Đừng lo sợ mà hãy bày tỏ chân thành với nhà quản lý. Họ sẽ hiểu và thông cảm cho bạn. Đồng thời chấp thuận nếu bạn có một lá đơn xin nghỉ việc hợp lý kèm một lý do xin nghỉ việc phù hợp.

Hãy nhớ rằng việc quan trọng lúc này của bạn là thời gian dành cho bản thân. Việc đưa ra quyết định dừng việc sớm sẽ tốt hơn cho công tác quản lý và tiến độ phát triển công việc chung của tổ chức.

5. Nghỉ việc vì muốn phát triển kinh doanh

Nhiều nhân sự khi họ làm được một thời gian, họ nhân sự nhiều sự chuyển hướng khác nhau thích hợp với mình hơn. Sự chuyển hướng trong ngành nghề ấy dựa trên các cơ sở về cá tính, sở thích và quan trọng nhất là việc họ muốn mình trở thành ai.

Không có một giới hạn nào cho sự thay đổi phạm vị nghề nghiệp. Họ có thể thay đổi sang các ngành cũng lĩnh vực. Và thậm chí một số khác thì không. Việc theo đuổi phát triển kinh doanh riêng là một trong số đó. Khi họ thật sự mong muốn và đó là thời điểm thích hợp, họ sẽ bắt tay thực hiện. Nếu có ước mơ, đủ thời gian và tâm sức; các yếu tố vật chất cộng hưởng, đó là lúc chín muồi để họ lựa chọn đưa ra quyết định chuyển mình khác hơn.

Phát triển kinh doanh có thể là: mở quán cà phê, nhà hàng; hoặc chính các công ty startup, agency riêng của họ. Họ đã có đủ những trải nghiệm cơ bản trong một hoặc nhiều tổ chức doanh nghiệp. Họ đã nắm được việc tổ chức vận hành và thiết lập hệ thống nhân sự thì khi cơ hội đến, việc của họ là nắm bắt chúng. Song, dù thế nào, bạn vẫn phải trình bày lý do này trên một lá đơn xin nghỉ việc thật chỉn chu nhất.

Mọi công ty sẽ hiểu và thông cảm vì đây thật sự là lý do xin nghỉ việc chính đáng. Điều quan trọng chính là bạn hãy cố gắng để lại ấn tượng đẹp sau cùng nơi tổ chức mà mình đã đồng hành.

Những lý do xin nghỉ việc không nên dùng

Lý do xin nghỉ việc chính đáng rất quan trọng. Vì nó là cơ sở giúp lá đơn xin nghỉ việc của bạn có được thông qua hay không? Hãy cân nhắc những lý do thật sự phù hợp. Dưới đây là list các lý do bạn nên tránh dùng khi viết đơn xin nghỉ việc.

1. Lương thấp

Thật sự đây là một lý do hợp lý. Tuy nhiên, không ai lại viết trong đơn một cách trực tiếp như vậy. Nếu là một nhân viên chuyên nghiệp, bạn cần có cách trình bày vấn đề với sắc thái nhẹ nhàng hơn. Không nên đi nhanh vào trọng tâm và nhấn mạnh việc lương tại tổ chức quá thấp. Bạn hãy phủ đầu bằng một loạt các lý do về điều kiện phát triển, những vấn đề khó khăn bạn gặp phải,… Đó là những minh chứng rõ nhất khiến họ có hình dung cụ thể hơn về tình hình hiện tại của bạn.

Lúc đó, bạn mới cần liên hệ qau vấn đề phúc lợi chưa thật sự làm bạn hài lòng. Và đây là lúc phù hợp để bạn rời đi. Bạn ra đi không vì công ty có môi trường làm việc không tốt; mà là cuộc sống của bạn còn nhiều thứ phải lo. Vì vậy, hãy thật tế nhị, thể hiện sự tôn trọng với tổ chức thông qua lá đơn xin nghỉ việc nhé!

2. Tôi bị giới hạn về chuyên môn phát triển

Mỗi công ty có một quy trình phát triển khác nhau. Do đó mà cách thức tổ chức, vận hành cũng khác. Bạn có thể được chỉ đạo làm tốt các nhiệm vụ, trách nhiệm thông qua phần tasks được giao. Hoặc bạn cũng được hỗ trợ và làm chung các kế hoạch, dự án khác để có thể học hỏi thêm các kinh nghiệm.

Tuy vậy, mọi vấn đề nảy sinh đều từ bạn. Nếu bạn cảm nhận rằng mọi thứ hiện tại vượt ra khỏi giới hạn sự chịu đựng; bạn không học thêm được cái mới thì tốt nhất, bạn nên kết thúc mọi việc càng sớm càng tốt.

Hãy tìm kiếm một môi trường phù hợp hơn với mình. Đó là nơi cho bạn nhận thấy mình có thể trải nghiệm và tiếp thu, phát triển năng lực bản thân lên những trình độ cao hơn.

Lời kết

Tóm lại, việc bạn đưa ra một lý do xin nghỉ việc hợp lý sẽ giúp là đơn xin nghỉ việc trở nên thuyết phục hơn. Hãy quan tâm đến bản thân, hiểu mình muốn gì để xác định một lý do xin nghỉ việc chính đáng nhất. Bạn chỉ cần có cách truyền tải chân thật và bày tỏ sự tôn trọng, thì chắc chắn lý do xin nghỉ việc của bạn sẽ được phê duyệt. TopDev hi vọng, thông qua bài viết, các bạn sẽ có những thông tin thật sự hữu ích.

Có thể bạn quan tâm:

Xem thêm việc làm Developers hàng đầu tại TopDev

Xác định bug dựa vào “nấc cục”

Xác định bug dựa vào “nấc cục”

Bài viết được sự cho phép của vntesters.com

“Bug” một trong những mối bận tâm lớn của kỹ sư kiểm thử. Nó mang lại niềm vui cho kỹ sư kiểm thử khi tìm được bug, nó gieo rắc nỗi sầu cho kỹ sư lập trình, nó cũng là cội nguồn của “cuộc chiến giữa các…kỹ sư kiểm thử và kỹ sư lập trình”. Tìm bug đã khó, để thuyết phục mọi người “đó là bug” lại càng đau đầu hơn. Các bạn cùng xem đoạn hội thoại sau:

  Bài học cho các Developer sau lỗi bug video từ Facebook
  Debug là gì?

– Kỹ sư kiểm thử: “Yeah, chỗ này có bug nè sư huynh”

– Kỹ sư lập trình: “Đâu, chỉ anh bug coi”

– Kỹ sư kiểm thử mô phỏng con bug…

– Kỹ sư lập trình:”Đâu phải bug đâu, tài liệu đặc tả có đề cập cái này đâu”

– (Kỹ sư kiểm thử liền đi lục tài liệu)…“Anh nói đúng, tài liệu không có đề cập nhưng em thấy nó vẫn không ổn lắm.”

– Kỹ sư lập trình (giọng hơi bực rồi): “Không ổn là không ổn làm sao? Tại liệu có đề cập đâu, anh chỉ code theo đặc tả…”.

– Kỹ sư kiểm thử có vẻ đuối lý và bỏ cuộc (dù vẫn còn ấm ức).

Xác định bug dựa vào “nấc cục”

Có những tình huống mà rõ ràng kỹ sư kiểm thử biết là “có gì đó không ổn” nhưng vẫn không biết gọi mặt đặt tên nó như thế nào để thuyết phục mọi người đó là bug. Nếu rơi vào tình huống trên thì kỹ sư kiểm thử hãy khoan bỏ cuộc (kỹ sư kiểm thử giỏi không bỏ cuộc dễ vậy), hãy dựa vào những chỉ dẫn về “nấc cục” để tìm thêm lý lẽ để thuyết phục mọi người.

“Nấc cục” mà mình đang nói đến là “HICCUPPS”. HICCUPPS là chữ viết tắt của “History – Image – Comparable products – Claims – User’s expectation – Product itself – Purpose – Statutes“ là một tập hợp của những nguyên tắc/chỉ dẫn (oracle heuristics) được giới thiệu bởi James Bach (sau đó được Michael Bolton giới thiệu trong blog của ông với bài viết “Testing without a map”). Những nguyên tắc/chỉ dẫn này được định ra dựa trên kinh nghiệm thực tế đúc kết cũng như được nhiều người nhìn nhận là có hiệu quả (nhưng vẫn có thể sai). Về cơ bản nếu có một chức năng nào của sản phẩm đi ngược lại những nguyên tắc của HICCUPPS đều có thể được xem là bug. Chúng ta hãy cùng tìm hiểu xem những nguyên tắc này là gì nhé.

Lịch sử – History

Những chức năng của sản phẩm hiện tại nên nhất quán so với quá khứ (giả định rằng chẳng có lí do gì chính đáng để chức năng đó được thay đổi). Chúng ta nên lưu ý đặc điểm này khi kiểm thử trên một phiên bản mới của ứng dụng.

Nếu trong quá trình kiểm thử, chúng ta thấy một chức năng hoạt động bình thường nhưng trí nhớ mách bảo rằng “lúc trước nó đâu có chạy như vậy”. Nếu trong tài liệu không đề cập đến sự thay đổi đó thì rất có thể chức năng đã vô tình bị thay đổi. Dĩ nhiên, sự thay đổi đó có thể tốt hơn hoặc xấu hơn nhưng vấn đề là nó đã thay đổi và nhiệm vụ của kỹ sư kiểm thử là phải cung cấp thông tin đó.

Hình ảnh – Image

Hình ảnh của sản phẩm (giao diện và chức năng) nên nhất quán với hình ảnh mà sản phẩm thực sự muốn đem tới cho người dùng. Sản phẩm trông có vẻ “dỏm” thì rất có thể là nó “dỏm” thiệt.

Chẳng hạn, một website bán hàng trực tuyến tuyên bố hỗ trợ 24/7 cung cấp hỗ trợ qua Yahoo messenger nhưng người dùng chẳng bao giờ thấy người hỗ trợ đó online. Dĩ nhiên đó không phải là thông điệp “hỗ trợ 24/7” mà sản phẩm đang hướng đến.

Sản phẩm cùng loại – Comparable product

Chúng ta cũng có thể dựa vào sản phẩm cùng loại đang có trên thị trường để làm tiêu chuẩn đánh giá về sản phẩm của mình

Cùng một chức năng nhưng sản phẩm của ta làm không tốt bằng sản phẩm đối thủ. Đó là bug. Chẳng hạn như đa phần những website tin tức ngày nay đều chạy tốt trên cả điện thoại di động và PC nhưng sản phẩm của chúng ta chỉ có có thể chạy tốt trên PC trong khi giao diện trên di động thì bị “hỏng nặng”.

Tuyên bố – Claims

Sản phẩm nên hoạt động giống như những gì đã được tuyên bố hoặc định ra. Những tuyên bố này có thể được định ra trong tài liệu đặc tả, tài liệu hỗ trợ, thông cáo, thư điện tử hay trong một cuộc nói chuyện ở ngoài hành lang bởi những người “có tiếng nói” đối với những tuyên bố đó.

Nếu như bạn thấy sản phẩm chạy giống như đặc tả nhưng bạn nhớ lại rằng trong một cuộc họp với giám đốc sản phẩm trước đó, ông ta muốn sản phẩm chạy khác mà…Hãy viết ngay một email để xác nhận lại vấn đề. Bạn có thể nghe nhầm nhưng cũng rất có thể là người viết tài liệu đã nhầm và không loại trừ khả năng tất cả đều nhầm.

Mong đợi của người dùng – User expectation

Những chức năng của sản phẩm nên hoạt động giống như cách mà người dùng mong đợi nó hoạt động.

Một số con bug thường xuất hiện khi người dùng sử dụng bàn phím thay vì dùng chuột thao tác trên các chức năng. Một số người dùng thích dùng chuột, một số khác thì thích sử dụng bàn phím khi thao tác. Hãy luôn để ý quan sát xem người dùng sẽ dùng sản phẩm của mình như thế nào.

Sản phẩm – The Product itself

Các tính năng giống nhau trên cùng một sản phẩm nên hoạt động nhất quán với nhau trừ khi nó được thiết kế để chạy khác nhau.

VD: Trong cùng một trang tin điện tử, khi người dùng click vào mục trang tin “Xã hội “ thì ứng dụng sẽ hiển thị nội dung ra Tab mới trong khi click vào trang tin “Thể thao” thì nội dung chỉ hiển thị trong cùng một Tab. Đó là bug nếu như không có một yêu cầu nào mô tả ứng dụng phải hoạt động như vậy.

Mục đích – Purpose

Tính năng của sản phẩm nên hoạt động giống với mục đích của tính năng đó bao gồm mục đích tường minh hay hàm ý.

VD: Nhấn nút Add để thêm, Edit để chỉnh sửa, Delete để xóa. Nếu như có tính năng nào của sản phẩm hoạt động không như mục đích mong đợi của nó thì nó có thể là bug.

Qui định về Pháp luật, Tiêu chuẩn – Statutes and Standards

Qui định về pháp luật, tiêu chuẩn khác với Tuyên bố (Claims) được giới thiệu bên trên. Qui định về pháp luật, tiêu chuẩn thường là những quy định không được định nghĩa trong phạm vi của dự án – chẳng hạn như RFC (Request for Comments), FDA (Food and Drug administration), ADA (Americans with Disabilities Act) – nhưng bắt buộc phải tuân theo. Có những sản phẩm đặc thù ngoài việc phải tuân theo đặc tả còn bắt buộc phải tuân theo những quy định về pháp lí. Việc sản phẩm không tuân thủ những quy định pháp lí không chỉ đơn thuần là bug mà nó còn mang đến những rắc rối về pháp lí.

Đó là những nguyên tắc/chỉ dẫn về “HICCUPPS”. Mình cũng xin lưu ý là những nguyên tắc được giới thiệu bên trên là những phát hiện dựa trên kinh nghiệm của cá nhân và được nhiều người đồng tình. Những nguyên tắc này không mang giá trị đúng tuyệt đối. Vì lí do đó, sau này nhiều người đã bổ sung thêm những nguyên tắc khác như: HICCUPPS(F) hay FEW HICCUPPS.

Là kỹ sư kiểm thử, bạn sẽ không muốn và không nên giới hạn mình với những nguyên tắc đã được định ra. Bạn hoàn toàn có thể định ra những nguyên tắc của mình để làm việc vì chỉ có bạn mới biết điều gì là mang lại hiệu quả cho công việc của bạn. Tuy nhiên, nếu bạn rơi vào những tình huống khẩn cấp thì hãy nhớ “nấc cục” (HICCUPPS) nhé.

Lược dịch từ http://www.developsense.com

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

View Hierarchy, Optimize Layout và Custom View (Phần 2)!

View Hierarchy, Optimize Layout và Custom View (Phần 2)!

Bài viết được sự cho phép của tác giả Nguyễn Trương Trung Tín

Tiếp tục với bài viết ở phần 1, sau khi đã hiểu được View là gì, cách android vẽ giao diện lên màn hình, cách tổ chức màn hình. Thì chúng ta sẽ đi đến phần kế tiếp, làm sao để tổ chức layout được tốt, ít tốt thời gian vẽ, 1 số mẹo để cái thiện tốc độ vẽ giao diện của ứng dụng.

Optimize layout.

Nhắc lại tí nội dung của bài trước thì layout trên màn hình sẽ được tổ chức theo dạng cây, và việc đo kích thước cũng như vẽ các view lên màn hình đều là các phép duyệt cây từ cao xuống thấp. Nên tốc độ vẽ 1 màn hình có thể được xem là tổng tốc độ các lần duyệt cây layout. Nên trong phần này mình sẽ nói về cách làm PHẴN 1 cây giao diện, tổ chức 1 cây giao diện theo cách RỘNG và CẠN, thay vì HẸP mà SÂU.

Relative Layout hay Linear Layout??

Chắc hẵn một android developer không thể không biết tới 2 loại ViewGroup – Layout này. Nói sơ qua thì LinearLayout tổ chức và sắp xếp các view con theo 1 CHIỀU CỐ ĐỊNH và có thể căn chỉnh theo tỉ lệ từng thành phần. Còn RelativeLayout thì tổ chức và sắp xếp các view con theo vị trí của view cha hoặc các view con trước đó.

(Bổ sung hình)

Vậy nếu một người mới lập trình android sẽ dễ dàng chọn LinearLayout làm layout chính cho các màn hình của ứng dụng, vì nó rất dễ căn chỉnh các view theo tỉ lệ, dễ dàng sắp xếp các thành phần theo từng thành phần riêng lẽ và dễ quản lí lẫn cài đặt. Còn Relative layout rất khó cho việc căn tỉ lệ, ví trị của từng view, phải xác định vị trí của từng view đối với các view còn lại, nên sẽ rất khó trong việc cài đặt. Thử xét ví dụ với màn hình sau:

Đang viết…

Bài viết gốc được đăng tải tại tinntt.github.io

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Phân biệt các thuật ngữ trong Distributed System (Tập 1)

System Design

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

Trong một hệ thống phân tán hiện đại ngày nay cùng với việc move lên Cloud thì có rất nhiều thuật ngữ, từ ngữ mô tả về hệ thống rất dễ gây nhầm lẫn như High Availability, Redundancy, Resiliency, Fault Tolerrance, Failover,… Hãy cùng phân tích và so sánh các thuật ngữ đó để có thể dùng chúng chính xác hơn trong từng ngữ cảnh.

  Bài toán đồng thuận trong Distributed Systems
  Distributed cache là gì? – điều gì khiến nó trở nên mạnh mẽ?

HIGH AVAILABILITY – TÍNH SẴN SÀNG CAO

High Availability (HA) hay còn gọi là Tính Khả Dụng/Sẵn Sàng Cao. Từ này gặp rất nhiều khi làm việc với các Cloud Service để đề cập đến việc 1 hệ thống hay service đó có tỷ lệ sống sót là bao nhiêu % trong 1 khoảng thời gian. Ví dụ nếu nói hệ thống có HA = 99% thì tức là sẽ có downtime (thời gian chết) là 3.65 ngày trong 1 năm, 7.31 giờ trong một tháng, 14.4 phút trong 1 ngày. Thời gian downtime có thể là do hệ thống cần được tắt để bảo trì nâng cấp hoặc bị cúp điện chẳng hạn. Vậy làm thế nào để có thể tăng tính HA cho hệ thống? Ví dụ có 1 số service sẽ có SLA (Service Level Agreement) hay Cam kết chất lượng dịch vụ cho HA lên đến 9 số 9 ( 99.9999999%) hoặc như DNS service sẽ có HA = 100%. Tất nhiên để HA càng cao thì chi phí càng đắt. Do đó, trong mỗi hệ thống cần suy nghĩ xem HA bao nhiêu là vừa đủ. Để làm được điều này thì chúng ta sẽ cần áp dụng một số kỹ thuật như redundancy, replication, zero-downtime deployment, fail-over,…

RELIABILITY – ĐỘ TIN CẬY

Một hệ thống có độ tin cậy cao thì HA sẽ cao, nhưng ngược lại không đúng. 1 hệ thống có khả năng sẵn sàng cao không có nghĩa là một hệ thống ưu việt. Ví dụ có con server đang sống và nhận, xử lý request đều đều, bỗng dưng không hiểu vì sao mà thời gian xử lý request mỗi lúc một lâu, có khi timeout luôn. Thì khi đó mặc dù ta nói HA vẫn cao nhưng độ tin cậy lại thấp.

Thật ra khi làm system design, mình chỉ hay chú ý đến High availability mà ít khi nghĩ đến tính Reliability. Phần này mình sẽ dựa theo Reliability pillar, một trong 5 pillars được định nghĩa trong AWS Well-Architected Framework.

Reliability is the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.

Độ tin cậy là khả năng hệ thống phục hồi từ sự gián đoạn cơ sở hạ tầng hoặc dịch vụ, tự động có được tài nguyên điện toán để đáp ứng nhu cầu và giảm thiểu sự gián đoạn như cấu hình sai hoặc các sự cố mạng tạm thời.

Nói ngắn gọn là để đạt được độ tin cậy cao thì cần phải áp dụng rất nhiều kỹ thuật, mà nổi bật nhất trong đó là High Availability. Ngoài ra còn có họ còn khuyến khích:

  • Triển khai tự động nhằm loại bỏ các yếu tố lỗi do con người.
  • Kiểm thử tính khả dụng, chịu tải, giả lập các tình huống gây lỗi tìm phương hướng khắc phục.
  • Cần giám sát hệ thống chặt chẽ và báo động, tìm giải pháp (tự động hoặc thủ công) nhằm khắc phục.
  • Thường xuyên kiểm tra (audit) để tìm ra các khuyết điểm của hệ thống.

REDUNDANCY VÀ REPLICATION – DỰ PHÒNG VÀ SAO CHÉP

Redundancy thường được thể hiện bằng cách có nhiều hơn 1 node/process trong 1 system để nhằm đảm bảo khi có sự cố xảy ra trên 1 node thì vẫn còn node khác có thể tiếp tục handle request, quá trình này gọi là fail-over. Có nhiều kiểu thiết lập redundancy như active-active hay active-passive bao gồm Cold-standby, Warm-standby hoặc Hot-standby. Các bạn có thể xem lại ở bài trước để hiểu rõ hơn ưu nhược của 2 hình thức này.

Replication thì tất nhiên là phải bao gồm việc đầu tiên là thiết lập redundancy kèm với việc sao chép data qua các redundant node luôn. Điển hình như việc sao chép dữ liệu giữa active DB node với các standby/passive node. Hoặc sao chép dữ liệu vào các backup node nhằm tránh tình trạng bị mất dữ liệu.

Hoặc có thể là có thêm máy phát điện dự phòng cho trường hợp cúp điện cũng là 1 ví dụ để tăng tính HA, nếu servers được host on-premises

Tuy nhiên, việc thiết lập 2 hoặc nhiều hơn các node có thực sự giúp cho HA cao hay không thì còn tùy vào cách setup. Ví dụ văn phòng bị chập mạch đường truyền internet vô data center bị đứt thì có bao nhiêu server trong đó đi chăng nữa cũng vô phương cứu chữa. Khi lên Cloud thì với lợi thế global infrastructure của mình, các nhà cung cấp hạ tầng, dịch vụ cloud cũng offer nhiều lựa chọn hơn cho khách hàng, ví dụ như thiết lập redundancy và replication ở nhiều khu vực vật lý khác nhau (multi AZ, multi Region, multi continent), và đương nhiên là giá cả sẽ khác nhau.

FAIL-OVER – CHUYỂN ĐỔI DỰ PHÒNG

Việc backup nhiều server dự phòng thôi là chưa đủ, ví dụ khi 1 server sập, làm thế nào để server khác có thể tiếp tục th

Trong một hệ thống phân tán hiện đại ngày nay cùng với việc move lên Cloud thì có rất nhiều thuật ngữ, từ ngữ mô tả về hệ thống rất dễ gây nhầm lẫn như High Availability, Redundancy, Resiliency, Fault Tolerrance, Failover,… Hãy cùng phân tích và so sánh các thuật ngữ đó để có thể dùng chúng chính xác hơn trong từng ngữ cảnh.

HIGH AVAILABILITY – TÍNH SẴN SÀNG CAO

High Availability (HA) hay còn gọi là Tính Khả Dụng/Sẵn Sàng Cao. Từ này gặp rất nhiều khi làm việc với các Cloud Service để đề cập đến việc 1 hệ thống hay service đó có tỷ lệ sống sót là bao nhiêu % trong 1 khoảng thời gian. Ví dụ nếu nói hệ thống có HA = 99% thì tức là sẽ có downtime (thời gian chết) là 3.65 ngày trong 1 năm, 7.31 giờ trong một tháng, 14.4 phút trong 1 ngày. Thời gian downtime có thể là do hệ thống cần được tắt để bảo trì nâng cấp hoặc bị cúp điện chẳng hạn. Vậy làm thế nào để có thể tăng tính HA cho hệ thống? Ví dụ có 1 số service sẽ có SLA (Service Level Agreement) hay Cam kết chất lượng dịch vụ cho HA lên đến 9 số 9 ( 99.9999999%) hoặc như DNS service sẽ có HA = 100%. Tất nhiên để HA càng cao thì chi phí càng đắt. Do đó, trong mỗi hệ thống cần suy nghĩ xem HA bao nhiêu là vừa đủ. Để làm được điều này thì chúng ta sẽ cần áp dụng một số kỹ thuật như redundancy, replication, zero-downtime deployment, fail-over,…

RELIABILITY – ĐỘ TIN CẬY

Một hệ thống có độ tin cậy cao thì HA sẽ cao, nhưng ngược lại không đúng. 1 hệ thống có khả năng sẵn sàng cao không có nghĩa là một hệ thống ưu việt. Ví dụ có con server đang sống và nhận, xử lý request đều đều, bỗng dưng không hiểu vì sao mà thời gian xử lý request mỗi lúc một lâu, có khi timeout luôn. Thì khi đó mặc dù ta nói HA vẫn cao nhưng độ tin cậy lại thấp.

Thật ra khi làm system design, mình chỉ hay chú ý đến High availability mà ít khi nghĩ đến tính Reliability. Phần này mình sẽ dựa theo Reliability pillar, một trong 5 pillars được định nghĩa trong AWS Well-Architected Framework.

Reliability is the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.

Độ tin cậy là khả năng hệ thống phục hồi từ sự gián đoạn cơ sở hạ tầng hoặc dịch vụ, tự động có được tài nguyên điện toán để đáp ứng nhu cầu và giảm thiểu sự gián đoạn như cấu hình sai hoặc các sự cố mạng tạm thời.

Nói ngắn gọn là để đạt được độ tin cậy cao thì cần phải áp dụng rất nhiều kỹ thuật, mà nổi bật nhất trong đó là High Availability. Ngoài ra còn có họ còn khuyến khích:

  • Triển khai tự động nhằm loại bỏ các yếu tố lỗi do con người.
  • Kiểm thử tính khả dụng, chịu tải, giả lập các tình huống gây lỗi tìm phương hướng khắc phục.
  • Cần giám sát hệ thống chặt chẽ và báo động, tìm giải pháp (tự động hoặc thủ công) nhằm khắc phục.
  • Thường xuyên kiểm tra (audit) để tìm ra các khuyết điểm của hệ thống.

REDUNDANCY VÀ REPLICATION – DỰ PHÒNG VÀ SAO CHÉP

Redundancy thường được thể hiện bằng cách có nhiều hơn 1 node/process trong 1 system để nhằm đảm bảo khi có sự cố xảy ra trên 1 node thì vẫn còn node khác có thể tiếp tục handle request, quá trình này gọi là fail-over. Có nhiều kiểu thiết lập redundancy như active-active hay active-passive bao gồm Cold-standby, Warm-standby hoặc Hot-standby. Các bạn có thể xem lại ở bài trước để hiểu rõ hơn ưu nhược của 2 hình thức này.

Replication thì tất nhiên là phải bao gồm việc đầu tiên là thiết lập redundancy kèm với việc sao chép data qua các redundant node luôn. Điển hình như việc sao chép dữ liệu giữa active DB node với các standby/passive node. Hoặc sao chép dữ liệu vào các backup node nhằm tránh tình trạng bị mất dữ liệu.

Hoặc có thể là có thêm máy phát điện dự phòng cho trường hợp cúp điện cũng là 1 ví dụ để tăng tính HA, nếu servers được host on-premises

Tuy nhiên, việc thiết lập 2 hoặc nhiều hơn các node có thực sự giúp cho HA cao hay không thì còn tùy vào cách setup. Ví dụ văn phòng bị chập mạch đường truyền internet vô data center bị đứt thì có bao nhiêu server trong đó đi chăng nữa cũng vô phương cứu chữa. Khi lên Cloud thì với lợi thế global infrastructure của mình, các nhà cung cấp hạ tầng, dịch vụ cloud cũng offer nhiều lựa chọn hơn cho khách hàng, ví dụ như thiết lập redundancy và replication ở nhiều khu vực vật lý khác nhau (multi AZ, multi Region, multi continent), và đương nhiên là giá cả sẽ khác nhau.

FAIL-OVER – CHUYỂN ĐỔI DỰ PHÒNG

Việc backup nhiều server dự phòng thôi là chưa đủ, ví dụ khi 1 server sập, làm thế nào để server khác có thể tiếp tục thực hiện các công việc hiện thời. Đó là nhờ các kỹ thuật về fail-over (chuyển đổi dự phòng). Các kỹ thuật fail-over thì cũng khá nhiều, tuy nhiên với việc lên Cloud hoặc sử dụng các container management and orchestration platform như Kubernetes thì việc cần làm là thiết lập cấu hình như DB fail-over hoặc container replica thì có thể ngồi rung đùi rồi.

ực hiện các công việc hiện thời. Đó là nhờ các kỹ thuật về fail-over (chuyển đổi dự phòng). Các kỹ thuật fail-over thì cũng khá nhiều, tuy nhiên với việc lên Cloud hoặc sử dụng các container management and orchestration platform như Kubernetes thì việc cần làm là thiết lập cấu hình như DB fail-over hoặc container replica thì có thể ngồi rung đùi rồi.

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Cách trở thành một MarTech Developer trong năm 2024

Cách trở thành một MarTech Developer trong 2021

Nói về MarTech chắc bạn đã nghe nói về các chức danh công việc khác nhau, như lập trình viên giao diện người dùng, lập trình viên phụ trợ, lập trình viên toàn bộ, v.v.

MarTech không phải là một thứ gì đó mới mẻ, nó đã xuất hiện khá lâu rồi, nhưng cách nó bùng nổ và phát triển trong vài năm qua là một hiện tượng.

Tôi chưa từng nghe về nó, cho đến khi làm việc trước đây trong một công ty tiếp thị tăng trưởng, nơi tôi học các khái niệm và nguyên tắc tiếp thị cũng như cách một lập trình viên có thể đóng một vai trò nào đó trong tiếp thị.

Vậy Martech là gì?

Bất kỳ công cụ hoặc phần mềm nào có thể giúp bạn tự động hóa, tối ưu hóa hoặc thậm chí cho phép bạn thực hiện các nỗ lực tiếp thị của mình là Martech hoặc Công nghệ tiếp thị.

Martech đi sau bất kỳ tiến bộ công nghệ nào, cho dù đó là trí tuệ nhân tạo hay blockchain, mọi công nghệ đều có tác dụng và mở ra những cánh cửa cơ hội mới trong martech.

Trước khi trở thành lập trình viên martech, bạn nên biết tại sao phải trở thành lập trình viên martech?

Tại sao chọn Martech?

Cách trở thành một MarTech Developer trong 2021
Bảng thống kê sự bùng nổ của marketing technology app trong một thập kỷ

Do sự bùng nổ của martech, các đại lý tiếp thị và quảng cáo trên khắp thế giới đang thuê các lập trình viên để tự động hóa các quy trình hiện có của họ và xây dựng các công cụ tự động hóa.

Không chỉ vậy, việc làm Martech được xếp hạng #3 trong báo cáo việc làm mới nổi năm 2020 của Linkedin. Điều này cho thấy rõ ràng cảnh quan công nghệ đang phát triển như thế nào và có nhu cầu rất lớn về các lập trình viên.

Bây giờ chúng ta hãy thảo luận về những gì bạn cần chính xác để trở thành một lập trình viên martech.

Một chút kiến thức Marketing

Hầu hết các lập trình viên nghĩ rằng martech chỉ dành cho các marketer, nhưng điều đó không đúng. Bạn không cần phải là một marketeer để trở thành một lập trình viên martech.

Kiến thức tiếp thị hoàn toàn phụ thuộc vào công việc bạn đang tìm kiếm. Ví dụ: nếu một công ty muốn tự động hóa việc báo cáo hoặc quảng cáo của Facebook hoặc Google Ads thì bạn cần phải học các API của Google Ads và Facebook Ads.

Tất cả là về mức độ quen thuộc của bạn với các công cụ tiếp thị và API của chúng.

Tuy nhiên, hầu hết các công ty đều đào tạo cho người mới bắt đầu nhưng bạn vẫn nên có kiến thức cơ bản tốt trước khi đi làm.

Tôi sẽ giải thích bên dưới những API và công cụ cơ bản nào bạn cần học để bắt đầu.

Vậy ngôn ngữ lập trình bạn nên học là gì?

Cách trở thành một MarTech Developer trong 2021

Không có ngôn ngữ lập trình hoàn hảo hoặc ưa thích nào mà bạn cần học để trở thành lập trình viên martech.

Một ngôn ngữ có thể được sử dụng cho bất cứ điều gì là những gì bạn cần.

Có một lệnh tốt của một ngôn ngữ mục đích chung như JavaScript, Python, PHP, v.v. là tất cả những gì bạn cần.

Tôi thích JavaScript hơn, bởi vì cho dù bạn muốn tạo ứng dụng web hay ứng dụng di động, hay thậm chí là ứng dụng máy tính để bàn, JS là tất cả những gì bạn cần biết.

Tất nhiên kỹ năng vững chắc về HTML, CSS cũng là bắt buộc nếu bạn đang muốn xây dựng các công cụ cho web.

Những tool bạn nên biết

Cảnh quan martech đang phát triển hơn bao giờ hết mỗi ngày các công cụ mới xuất hiện, nhưng đừng lo lắng bạn không cần phải học từng công cụ.

Làm quen với các công cụ phổ biến được các đại lý tiếp thị sử dụng hàng ngày. Kiến thức từ sơ cấp đến trung cấp là đủ để xây dựng các giải pháp trên các công cụ này.

Tôi liệt kê các danh mục công cụ với một số ví dụ, tất cả những gì bạn cần là tìm kiếm các công cụ hàng đầu trong các danh mục này để làm quen với chúng.

  • Ads Manager (Facebook Business Manager, Google Ads Manager)
  • Analytics (Google Analytics, Facebook Pixel)
  • Email Marketing tools (MailChimp, Aweber, HubSpot)
  • Integrations tools (Zapier)
  • CRM (Hubspot, Salesforce)

Hãy nhớ rằng những công cụ này được tạo ra cho các marketer, đó là lý do tại sao trọng tâm của bạn là hiểu biết kỹ thuật về công cụ và các API của nó. Là một lập trình viên martech, bạn sẽ tạo ra các giải pháp trên các công cụ này để giúp mọi thứ trở nên dễ dàng hơn cho các marketer.

Vậy bạn có thể học những kiến thức này từ đâu?

Đơn giản vậy thôi, Youtube!

Bất cứ khi nào tôi muốn tìm hiểu một cái gì đó mới, youtube là cách tốt nhất để có được một số kiến thức cơ bản để bắt đầu.

Nhưng điều đó không phải lúc nào cũng đủ để dành chút thời gian cho tài liệu chính thức hoặc hướng dẫn về các công cụ để hiểu sâu đầy đủ về các khái niệm.

Facebook và Google có các tài nguyên chính thức để bạn có thể bắt đầu.

Lời kết

Các agency marketing hiện nay cần những lập trình viên vừa sáng tạo và nhanh nhẹn để thấu hiểu dữ liệu và đưa ra kết quả cũng như báo cáo để hỗ trợ cho team marketing đưa ra các chiến lược hiệu quả.

Giờ đây, các marketer đang khám phá các công nghệ như Machine Learning, Blockchain, Virtual Reality, v.v. để đưa ra những ý tưởng đột phá cho khách hàng của họ và đó là lúc một lập trình viên martech sẽ giúp họ tìm ra công nghệ phù hợp.

Nếu bạn đang có ý định thay đổi sự nghiệp của mình vào năm 2023 thì martech là một lựa chọn đáng cân nhắc.

Có thể bạn quan tâm:

Xem thêm ITJobs for Developer hấp dẫn trên TopDev

10 trình quản lý file hàng đầu trong JavaScript

10 trình quản lý tệp Javascript hàng đầu

Quản lý file là một công cụ hữu ích trong bất kỳ ứng dụng kinh doanh nào. Dưới đây là tổng quan về các Trình quản lý file JavaScript chức năng, trang nhã và phổ biến nhất sẵn sàng được tích hợp vào giải pháp client-server.

Ngay cả khi bạn không có nhu cầu trực tiếp làm việc với file, bạn có thể mượn giao diện trình khám phá file cổ điển cho các tác vụ khác. Ví dụ, có một số trường hợp giao diện cổ điển trở thành cơ sở cho một ứng dụng web mới trong bài viết này.

Vì vậy, chúng ta hãy xem xét các trình quản lý file!

Tuyển Javascript lương cao up to 2000USD

1. Webix File Manager

10 trình quản lý tệp Javascript hàng đầu
Webix File Manager

Webix File Manager là một SPA làm sẵn. Giao diện của nó được thiết kế để tạo điều kiện thuận lợi cho quá trình tùy chỉnh và tích hợp vào các giải pháp của bên thứ ba. Phiên bản mới nhất chứa nhiều tính năng:

  1. dual panel mode
  2. preview panel
  3. thumbnail support for image files
  4. built-in media player
  5. text editor

Người dùng thể hiện nội dung của họ bằng tiện ích. Ví dụ: Emmanual Onah đã sử dụng nó trong một nền tảng quản lý dự án dành cho các dịch giả tự do. Bạn có thể tìm hiểu thêm về kinh nghiệm của anh ấy trong buổi giới thiệu.

Website: https://webix.com/filemanager/

Download link: https://webix.com/filemanager/download.html

2. Syncfusion File Explorer

10 trình quản lý tệp Javascript hàng đầu
Syncfusion File Explorer

Đây là một công cụ quản lý file trong JavaScript đơn giản rất giống với Windows File Explorer. Nó được cung cấp bởi sản phẩm Syncfusion phổ biến. Các nhà phát triển đã cung cấp một thiết kế giao diện đơn giản hóa, giả định rằng người dùng sẽ phát triển và tích hợp tầm nhìn của họ. Control thực hiện tất cả các hoạt động cơ bản của file như tải lên, tải xuống, xóa, tạo, sắp xếp, tìm kiếm và đổi tên cùng với tùy chọn bên ngoài để xem trước hình ảnh trong hệ thống file.

Đây là danh sách các tính năng:

  1. customizable layout design
  2. file upload and download
  3. sorting
  4. searching
  5. drag-n-drop
  6. access control selection
  7. multiple file selection
  8. localization

JavaScript File Manager hỗ trợ một số chủ đề cài sẵn: Material, Bootstrap, Fabric (Office 365) và độ tương phản cao. Bất kỳ chủ đề tích hợp nào trong số này đều có thể được thiết lập hoặc có cơ hội cho người dùng tạo các chủ đề mới. Điều này có thể đạt được bằng cách ghi đè các biến SASS hoặc sử dụng ứng dụng Theme Studio.

Website: https://www.syncfusion.com/javascript-ui-controls/js-file-manager

Download: https://www.syncfusion.com/downloads/essential-js2

3. Bootstrap File Manager SDK

10 trình quản lý tệp Javascript hàng đầu
Bootstrap File Manager SDK

Đây là một epxlorer sáng giá và hùng mạnh khác, từng có tên gọi là AlphaManager. Nếu bạn định phát triển dự án của mình trên nền tảng Bootstrap, đây sẽ là lựa chọn phù hợp. Trình quản lý file DevExpress Bootstrap cung cấp giao diện người dùng trực quan được thiết kế để quản lý file và thư mục tương tự như Microsoft File Explorer.

Bao gồm các tính năng:

  1. Khả năng đổi tên, sao chép, di chuyển và xóa các thư mục và file;
  2. Hỗ trợ các nguồn dữ liệu hệ thống file khác nhau (vật lý, nguồn dữ liệu, lưu trữ đám mây);
  3. Khả năng tải xuống và tải lên file;
  4. Kiểm soát truy cập tích hợp với hỗ trợ cho các vai trò bảo mật.

Website: https://js.plus/products/file-manager

>>> Xem thêm: Javascript empty array – đừng gán [] thêm một lần nào nữa

4. DHTMLX File Manager

10 trình quản lý tệp Javascript hàng đầu
DHTMLX File Manager

DHTMLX cung cấp trình quản lý file trong JavaScript chất lượng cao. Nó là một công cụ thuận tiện để tạo các ứng dụng thân thiện với người dùng để quản lý hệ thống file. Nó giúp người dùng thực hiện các thao tác file phổ biến nhất, chẳng hạn như tải lên, chỉnh sửa và sắp xếp file trong thư mục. Trình thám hiểm hỗ trợ các file ở bất kỳ định dạng nào và cho phép theo dõi không gian còn lại.

Người dùng có thể tận hưởng các tính năng sau:

  1. Chế độ xem trước dạng grid hoặc list
  2. Sắp xếp theo thứ tự chữ cái tăng dần hoặc giảm dần
  3. Hỗ trợ context-menu
  4. Thông tin file

Bên cạnh đó, mẫu trình khám phá file DHX tuyên bố có khả năng điều hướng dễ dàng. Nó cho phép sắp xếp các thư mục theo cấu trúc cây và tìm kiếm các mục cần thiết bằng cách gõ tên vào ô tìm kiếm. Bản trình diễn quản lý file JavaScript này tuân theo nguyên tắc Material Design của Google.

Website: https://dhtmlx.com/docs/products/dhtmlxFileManager/

5. DevExtreme

10 trình quản lý tệp Javascript hàng đầu
DevExtreme

Thư viện này cung cấp một giải pháp đơn giản nhưng ngắn gọn để quản lý file. Tiện ích Trình quản lý file có thể hiển thị một tập hợp các mục phân cấp trình bày cấu trúc hệ thống file. Tiện ích cho phép người dùng cuối dễ dàng tải lên và chọn file cũng như thay đổi cấu trúc thư mục (đổi tên, di chuyển, sao chép và xóa file và thư mục). Khả năng quản lý file và thư mục hoàn toàn có thể tùy chỉnh và có thể tắt nếu cần.

Website: https://js.devexpress.com/Demos/WidgetsGallery/Demo/FileManager/Overview/jQuery/Light/

6. elFinder

10 trình quản lý tệp Javascript hàng đầu
elFinder

Một trình quản lý file trong JavaScript rất đơn giản nhưng đầy đủ chức năng được xây dựng bằng jQuery. Những nhược điểm của trình quản lý bao gồm không thể thay đổi chiều cao của cửa sổ chính, được cố định ở 400px. Công cụ này cho phép bạn xây dựng trong một trình chỉnh sửa trực quan. Nó có một tùy chọn để thêm hình ảnh vào văn bản.

Xem thêm các việc làm Citigo tuyển dụng

Nếu trình quản lý file được bật, bạn có thể tải xuống và nhận liên kết đến hình ảnh bằng hai lần nhấp. Ngoài việc tải hình ảnh lên trang web, bạn cũng có thể tải lên file, lưu trữ, tài liệu, v.v. Có thể chỉ định liên kết tải xuống trên trang đã tạo.

Các tính năng của ElFinder bao gồm:

  1. Tạo và xóa các thư mục và thư mục con
  2. Tải lên các file thuộc bất kỳ loại nào
  3. Tải xuống các file từ trang web
  4. Xem lướt qua
  5. Sao chép và di chuyển file
  6. Lưu trữ và giải nén nội dung
  7. Đổi tên file
  8. Chỉnh sửa hình ảnh (cắt, thay đổi kích thước, xoay)
  9. Tải file lên bộ nhớ đám mây

Website: https://github.com/Studio-42/elFinder

7. MooTools FileManager

10 trình quản lý tệp Javascript hàng đầu
MooTools FileManager

MooTools FileManager cho phép bạn xem, tải xuống và sửa đổi các file và thư mục bằng trình duyệt. Các tính năng của trình quản lý là:

  1. Xem các file và folder trên máy chủ
  2. Đổi tên, xóa, di chuyển (kéo thả), sao chép và tải file xuống
  3. Xem trước hình ảnh, file văn bản, file nén hoặc âm thanh
  4. Giao diện người dùng bắt mắt
  5. Tải file lên qua FancyUpload (tính năng tích hợp)
  6. Thay đổi kích thước của những ảnh có dung lượng lớn khi tải

Website: https://mootools.net/forge/p/mootools_filemanager

>>> Xem thêm: 9 lỗi JavaScript các lập trình viên hay gặp

8. AjaXplorer

10 trình quản lý tệp Javascript hàng đầu
AjaXplorer

AjaXplorer là trình quản lý file miễn phí không thể thiếu để quản lý file từ xa trên web server. Nó phù hợp cho nhiều mục đích khác nhau, chẳng hạn như quản lý file, thư viện ảnh, view code, vân vân. Yêu cầu PHP (4 hoặc 5) và không cần cơ sở dữ liệu.

Trình quản lý có nhiều tính năng:

  1. Đổi tên, sao chép, di chuyển, xóa, tải xuống file hoặc thư mục
  2. Tải lên nhiều file
  3. Theo dõi trạng thái trên thanh tiến trình (yêu cầu Flash)
  4. Tạo thư mục và file
  5. Chỉnh sửa file văn bản và tập lệnh (JS, PHP, HTML, Java, SQL, Perl)
  6. Xem ảnh và hình ảnh
  7. Nghe MP3 trực tuyến mà không cần tải xuống video watchFlash (FLV) ở chế độ toàn màn hình
  8. Xem và giải nén các file ZIP

Website: https://pydio.com/en/

Download: https://pydio.com/download/

9. CKFinder

10 trình quản lý tệp Javascript hàng đầu
CKFinder

CKFinder là một trình quản lý file mạnh mẽ nhưng dễ sử dụng cho các trình duyệt web. Giao diện trực quan và thân thiện với người dùng của nó cho phép bạn nhanh chóng học nó cho mọi đối tượng người dùng, từ chuyên gia đến người mới bắt đầu.

Các tính năng bao gồm:

  1. Up file an toàn
  2. Phản hồi nhanh
  3. Giao diện dễ dàng và thân thiện với người dùng
  4. Tạo, đổi tên và xóa các folder và file
  5. Hỗ trợ đa ngôn ngữ với tính năng phát hiện ngôn ngữ người dùng tự động
  6. Preview với hình ảnh chất lượng cao
  7. Folder tree

Website: https://ckeditor.com/ckfinder/

Download: https://ckeditor.com/ckfinder/download/

10. FileRun

10 trình quản lý tệp Javascript hàng đầu
FileRun

FileRun là một hệ thống quản lý file trong JavaScript (bằng PHP) cho phép bạn quản lý các file được lưu trữ trên máy chủ web của mình bằng giao diện thân thiện với người dùng (Ajax). FileRun được viết hoàn toàn bằng PHP và trình duyệt là thứ duy nhất mà người dùng cần để làm việc với các file. Bạn có thể dễ dàng truy cập tài liệu hoặc file của mình từ bất kỳ máy tính nào có kết nối Internet thông qua trình duyệt tiêu chuẩn.

Các tính năng là:

  1. Giao diện dựa trên Ajax
  2. Tải xuống và lưu trữ các folder
  3. Không giới hạn dung lượng để tải file xuống
  4. Dễ dàng quản lý các flie đã tồn tại trong hệ thống file

Website: https://www.filerun.com/

Download: https://filerun.com/download

Kết bài

Hy vọng qua bài viết này các lập trình viên có thể chọn được phần mềm quản lý file trong JavaScript hợp lý cho dự án của mình. Nếu bạn biết về phần mềm quản lý file hữu ích nào khác, có thể chia sẻ thêm tại comment để mình cải thiện danh sách trên. Xin cảm ơn

Có thể bạn quan tâm:

Xem thêm việc làm IT hấp dẫn trên TopDev

Công cụ performance test Jmeter

jmeter
Công cụ performance test Jmeter

Bài viết được sự cho phép của tác giả Lê Chí Dũng

I. Giới thiệu về Performance Test

1. Performance Test là gì?

  • Là một kiểu dùng để thực thi Non Functional test (kiểm thử phi chức năng)
  • Xác định khả năng hoạt động của hệ thống có phù hợp với yêu cầu hay không
  • Phục vụ nhiều mục đích khác nhau như chứng minh rằng hệ thống có thể đạt được các đáp ứng performance tối thiểu
  Hướng dẫn sử dụng JMeter test hiệu năng website - Phần 1
  Biện hộ: Vì sao các Developer không test phần mềm của họ?

2. Phân biệt test performance vs load vs stress

Refer: https://www.guru99.com/performance-vs-load-vs-stress-testing.html

Performance Testing (PT) Load Testing (LT) Stress testing (ST)
– Thực hiện để kiểm tra, xác định hệ thống thực hiện một khối lượng công việc cụ thể trong thời gian bao lâu.
– Xác định hiệu năng của hệ thống trong điều kiện thông thường
– Thực hiện với 1 hoặc nhiều user và một lượng dữ liệu lý tưởng.		 – Thực hiện để kiểm tra, xác định hoạt động của hệ thống trong điều kiện tải cao.
– Xác định hiệu năng của hệ thống trong điều kiện tải cao
– Thực hiện với một số lượng lớn user cùng truy cập.		 – Thực hiện để kiểm tra, xác định hoạt động của hệ thống khi điều kiện tải cao bất thường.
– Xác định tính tin cậy của hệ thống trong điều kiện khắc nghiệt nhất
– Thực hiện với một số lượng lớn dữ liệu và một số lượng lớn user cùng truy cập.

II. Tổng quan về Jmeter

1. Jmeter là gì?

  • Một mã nguồn mở được viết bằng java
  • Hỗ trợ GUI đơn giản, trực quan dễ sử dụng
  • Công cụ độc lập có thể chạy trên nhiều nền tảng hệ điều hành khác nhau, trên Linux chỉ cần chạy bằng một shell script, trên Windows thì chỉ cần chạy một file .bat
  • Đa luồng, giúp xử lý tạo nhiều request cùng một khoảng thời gian, xử lý các dữ liệu thu được một cách hiệu quả.
  • Đặc tính mở rộng, có rất nhiều plugin được chia trẻ rộng rãi và miễn phí
  • Một công cụ tự động để kiểm thử hiệu năng và tính năng của ứng dụng.
  • Công cụ để đo độ tải và performance của đối tượng, có thể sử dụng để test performance trên cả nguồn tĩnh và nguồn động, có thể kiểm tra độ tải và hiệu năng trên nhiều loại server khác nhau như:
    • Web – HTTP
    • HTTPS
    • SOAP
    • Database thông qua JDBC, LDAP, JMS
    • Mail – SMTP(S), POP3(S) and IMAP(S)
    • …

2. Jmeter hoạt động như thế nào?

Giả lập một nhóm người dùng gửi các yêu cầu tới một máy chủ, nhận và xử lý các response từ máy chủ và trình diễn các kết quả đó cho người dùng dưới dạng bảng biểu, đồ thị,cây… (Xem hình bên dưới)

Ưu điểm của Jmeter

  • Kiểm tra tải và kiểm tra hiệu năng theo nhiều kiểu khác nhau: Web – HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail – POP3(S) and IMAP(S).
  • Rất nhẹ, không cần cài đặt, miễn phí.
  • Nền tảng xử lý đa luồng cho phép mô phỏng nhiều mẫu bởi nhiều thread của các chức năng khác nhau trên các thread group khác nhau
  • Dễ dàng thêm các plugin và tạo các báo cáo phù hợp yêu cầu.
  • Được hỗ trợ mạnh bởi cộng đồng open source

Nhược điểm của Jmeter

  • Sun’s JRE phải được cài đặt.
  • Chỉ sử dụng được với ứng dụng web.
  • Kết quả stress testing có thể khó xác định chính xác.
  • Khó khăn khi thực hiện các kịch bản kiểm thử phức tạp.
  • Khó thực hiện Recording

III. Hướng dẫn cài đặt và thông số của Jmeter

1. Cài đặt Jmeter

  • Download Jmeter http://jmeter.apache.org/download_jmeter.cgi
  • Sau khi download về giải nén và mở thư mục đó ra
    • Trên Windows chạy file : jmeter.bat
    • Trên Linux chạy file: jmeter.sh
      Chú ý: Cần chắc chắn rằng máy tính đã được cài đặt Java

2. Thông số của Jmeter

  • Test Plan: Bao gồm các bước sẽ được JMeter thực thi.
  • Thread Group: Đại diện cho người dùng ảo (virtual user), có thể gồm các thành phần sau:
  • Logic Controller: Cho phép điều chỉnh logic khi gửi các yêu cầu đến đối tượng cần kiểm tra.
  • Sampler: Cung cấp thông tin cho JMeter gửi các yêu cầu đến máy chủ cần kiểm tra. Tùy theo giao thức kiểm tra, JMeter hỗ trợ những loại sampler khác nhau.
  • Config Element: Sử dụng để thêm vào những thay đổi/ cấu hình cần thiết cho các sampler.
  • Timer: Điều chỉnh khoảng thời gian dừng giữa các lần gửi yêu cầu.
  • Listener: Cho phép thu thập thông tin kết quả. Có thể đưa ra các báo cáo kết quả kiểm tra dạng đồ thị, hoặc xuất ra tập tin.

Bài viết gốc được đăng tải tại lcdung.top

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Capacity Planning – Dự toán công suất cho ứng dụng (Tập 2)

Capacity Planning
Capacity Planning

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

Xem lại phần 1

4. THIẾT KẾ VÀ TỐI ƯU HÓA ỨNG DỤNG

Thiết kế của ứng dụng hoặc phần mềm đóng một vai trò lớn trong việc lập dự toán công suất. Nếu một session được tạo cho mỗi người dùng đồng thời, điều này có nghĩa là mức tiêu thụ bộ nhớ cho mỗi session. Đối với mỗi hoạt động, các yếu tố như kết nối cơ sở dữ liệu, số lượng object được lưu trữ trong bộ nhớ và lượng xử lý diễn ra sẽ xác định dung lượng bộ nhớ và dung lượng xử lý cần thiết. Các ứng dụng được thiết kế tốt sẽ cố gắng giữ cho những con số này ở mức thấp hoặc sẽ chia sẻ tài nguyên của hiệu quả. Số lượng tài nguyên được tạo ra cho một ứng dụng cũng đóng một vai trò. Ví dụ, đối với các hoạt động chuyên sâu của cơ sở dữ liệu, kích thước nhóm kết nối cơ sở dữ liệu sẽ là một yếu tố hạn chế. Tương tự, thread pool, thời gian thu gom rác, v.v. cũng xác định hiệu năng của hệ thống. Việc thử và thử nghiệm chịu tải ứng dụng bằng các công cụ (ví dụ: đối với các ứng dụng Java, JProiler, JConsole, JMeter, v.v.) sẽ giúp xác định các điểm tắc nghẽn trong ứng dụng.

  System Design Cơ Bản - Consistent Hashing
  System Design Cơ Bản - Định lý Cap / Cap Theorem

Các tham số tối ưu hóa cũng nên được tính đến như một phần của giải pháp. Các kỹ thuật như bộ nhớ đệm có thể giúp cải thiện hiệu suất và độ trễ – điều này cần được xem xét từ góc độ rộng hơn. Nếu các phản hồi của dịch vụ thay đổi thường xuyên, thì bộ nhớ đệm sẽ không tạo ra quá nhiều sự khác biệt. Bộ nhớ cache thời gian làm nóng cũng cần phải được tính đến.

Cũng khuyến khích để có một dung lượng buffer khi phân bổ các thông số máy chủ. Ví dụ, phân bổ thêm 20-30% thông số kỹ thuật của máy chủ cho các NFR cao điểm để đảm bảo hệ thống không hết dung lượng khi tải tối đa.

Cũng nên dùng các công cụ giám sát để tính toán công suất hệ thống. Thử nghiệm chịu tải, ứng dụng và máy chủ profiling thông qua các công cụ giám sát và profiling có thể giúp xác định công suất hiện tại khá chính xác và giúp xác định trước các điểm tắc nghẽn.

Loại phần cứng cũng là điểm khác biệt. Các máy vật lý truyền thống đang nhanh chóng được thay thế bởi VM và các Cloud. Cách lý tưởng để tính công suất là có điểm chuẩn trên các môi trường khác nhau này. Cấp phát bộ nhớ 4GB trên máy ảo có thể không giống với phân bổ bộ nhớ 4GB trên máy chủ vật lý hoặc phiên bản Amazon EC2. Cũng có những trường hợp hướng đến một số loại hoạt động nhất định. Ví dụ, EC2 có các trường hợp được tối ưu hóa bộ nhớ, tính toán tối ưu hóa hoặc tối ưu hóa I/O dựa trên loại hoạt động chính.

5. TÍNH SẴN SÀNG CAO VÀ KHẢ NĂNG MỞ RỘNG

5.1 KHẢ NĂNG MỞ RỘNG

Khả năng mở rộng là khả năng xử lý các yêu cầu tương ứng với tài nguyên phần cứng có sẵn; một hệ thống có thể mở rộng lý tưởng nên xử lý tăng / giảm yêu cầu mà không ảnh hưởng đến thông lượng chung.

Khả năng mở rộng có hai trường phái; mở rộng theo chiều dọc (vertical scaling) tăng hiệu suất của máy chủ bằng cách tăng bộ nhớ, sức mạnh xử lý, v.v. (ví dụ: chênh lệch hiệu suất giữa máy chủ RAM 4GB và máy chủ RAM 8GB) so với khả năng mở rộng theo chiều ngang (horizontal scaling) hoặc Mở rộng quy mô, nơi bạn triển khai thêm nhiều máy chủ cùng loại.

Dựa trên các yêu cầu về tính khả dụng đã thảo luận ở trên, chúng ta cần xác định mô hình sẵn sàng cao phù hợp. Tính sẵn sàng cao có thể được phân loại như sau:

5.2 TÍNH SẴN SÀNG CAO

Tính sẵn sàng cao có thể đạt được thông qua phương thức active-active, hoặc chuyển đổi dự phòng active-passive. Trong cách đầu tiên, tính khả dụng khá cao trong khi kịch bản thứ hai, chuyển đổi dự phòng sang node thụ động cần can thiệp thủ công hoặc tự động. Tùy thuộc vào điều này, sự sẵn có của sau này sẽ giảm.

Capacity Planning - Dự toán công suất cho ứng dụng (Tập 2)

Figure 7: High Availability Within a Data Center

Phân cụm (Clustering) là một kỹ thuật phổ biến để đạt được tính sẵn sàng cao bằng cách cung cấp dự phòng ở cấp độ phần mềm và phần cứng (Hình 7). Thông thường có 4 điều kiện khác nhau có thể được sử dụng ở đây:

  • Chế độ chờ lạnh (Cold-standby): Trong thiết lập này, node chính đang hoạt động và node phụ là node thụ động. Node phụ là bản sao lưu giống hệt của node chính, nhưng chỉ được cài đặt và khởi động (cả phần cứng và thành phần phần mềm của máy chủ) nếu node chính bị lỗi. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là cần thời gian khá lâu.
  • Chế độ chờ ấm (Warm-standby): Trong thiết lập này cũng là node chính đang hoạt động và node phụ là node thụ động. node phụ là một bản sao lưu giống hệt của node chính và các thành phần phần mềm cần thiết được cài đặt, nhưng không chạy. Node máy chủ vật lý đang chạy mặc dù và trong trường hợp xảy ra lỗi node chính, các thành phần phần mềm trên node phụ được khởi động. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là một vài phút.
  • Chế độ chờ nóng (Hot-standby): Trong thiết lập này một lần nữa, node chính được kích hoạt và node phụ là node thụ động. node phụ là một bản sao lưu giống hệt của node chính và các thành phần phần mềm cần thiết được cài đặt; và máy chủ vật lý và tất cả các thành phần phần mềm đang chạy. Tuy nhiên, node phụ không chấp nhận bất kỳ request nào và chỉ bắt đầu làm như vậy trong trường hợp lỗi node chính. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là một vài giây.
  • Active-active: Cả hai node đang chạy và xử lý các yêu cầu song song. Ở đây, vì cả hai node chấp nhận yêu cầu, không có khái niệm thời gian phục hồi và cân bằng tải là tức thời.

Tính sẵn sàng cao cũng có thể đạt được thông qua các xem xét kiến ​​trúc bổ sung như:

  • Cân bằng tải và định tuyến – cân bằng các yêu cầu của khách hàng giữa các node; các kỹ thuật, chẳng hạn như session affinity, có thể được sử dụng để định tuyến các yêu cầu từ cùng một session đến cùng một node
  • Phân cụm – cho phép tất cả các thành phần trong cụm được xem như là một đơn vị chức năng duy nhất
  • Sao chép trạng thái – sao chép trạng thái của một máy chủ trong số các máy chủ khác có thể hoạt động trơn tru trong trường hợp chuyển đổi dự phòng
  • Hệ thống tự mở rộng – cho phép tự động mở rộng các server tùy thuộc vào yêu cầu
  • Hệ thống tự hồi phục – tự động khởi động lại hệ thống thông qua giám, v.v. cho phép các hệ thống không khả dụng tự phục hồi

5.3 PHỤC HỒI SAU THẢM HỌA (DISASTER RECOVERY)

Phục hồi thảm họa (DR) liên quan đến việc sao chép hệ thống chính lên một vùng riêng biệt về mặt địa lý để hệ thống có thể phục hồi khi hệ thống chính bị hỏng.

5.4 SAO LƯU VÀ PHỤC HỒI

Sao lưu và phục hồi liên quan đến việc sao chép ứng dụng, trạng thái hệ thống và ứng dụng và dữ liệu hệ thống lên phương tiện sao lưu. Điều này sau đó có thể được phục hồi do lỗi hệ thống chính hoặc do ứng dụng đạt đến trạng thái không nhất quán.

5.5 CLOUD

Đám mây cho phép các máy chủ được triển khai ở các vị trí địa lý khác nhau với các mạng tốc độ cao giữa các vị trí địa lý. Chẳng hạn, Amazon EC2 cho phép các máy chủ được triển khai trong một availability zone, cross zone hoặc thậm chí cross region, do đó cung cấp một cách thức rất dễ tiếp cận để đạt được tính sẵn sàng cao, toàn diện.

6. TÍNH TOÁN CÔNG SUẤT

Trên đây chỉ là một vài yếu tố có thể được sử dụng để lập dự toán công suất của một hệ thống và tầm quan trọng của các yếu tố này thay đổi dựa trên loại môi trường.

Các kiến ​​trúc sư khác nhau sử dụng các quy trình khác nhau để tính toán công suất. Một quy trình mẫu được minh họa trong Hình 6; bất kể quá trình nào, nó cần được kết hợp với quy trình kiến ​​trúc giải pháp hiện có của bạn.

Figure 8: Capacity Planning as Part of Deployment Architecture Process

Theo quy trình trong Hình 8, điều quan trọng là phải có một kiến trúc kinh doanh chính xác có thể được chuyển đổi thành kiến trúc giải pháp cấp cao. Dựa trên điều này, nhóm có thể bắt đầu thu thập dữ liệu dung lượng sẽ được sử dụng để tạo ra ma trận hoặc mô hình lập dự toán công suất.

Với các yếu tố này, chúng ta cũng cần một bộ số hiệu suất chuẩn để tính công suất máy chủ. Ví dụ, nếu chúng ta biết rằng một server trong các điều kiện môi trường nhất định với loại công suất nhất định hoạt động ở 3000 TPS, thì chúng ta có thể giả sử rằng một máy chủ có công suất và hoạt động tương tự sẽ cung cấp như nhau.

Tuy nhiên, điều quan trọng là phải hiểu rằng trong khi các điểm chuẩn có thể được sử dụng làm mô hình tham chiếu, thì khả năng áp dụng các số này cho vấn đề của bạn có thể khác nhau; do đó, ngoài khả năng dự báo, điều quan trọng là phải kiểm tra môi trường để xác định công suất cực đại của nó.

7. KẾT LUẬN

Không nghi ngờ gì nữa, lập dự toán công suất là một nghệ thuật cũng như khoa học và rõ ràng kinh nghiệm đóng vai trò quan trọng trong việc lập kế hoạch chính xác về năng lực. Trong bài này, chúng ta đã xem xét các khái niệm khác nhau về lập dự toán công suất và cách chúng ảnh hưởng đến năng lực giải pháp của hệ thống. Good luck!

8. THAM KHẢO

https://wso2.com/whitepapers/capacity-planning-for-application-design-part-1/

Article: ESB Performance Benchmark, Round 7.5
https://wso2.com/library/articles/2014/02/esb-performance-round-7.5/

Whitepaper: WSO2 Carbon Product Performance and Deployment Topology Sizing
https://wso2.com/whitepapers/wso2-carbon-product-performance-and-deploymenttopology-sizing/

Blog: How to measure the peformance of a server:
http://srinathsview.blogspot.com/2012/05/how-to-measure-performance-of-server.html

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

7 lãng phí trong kiểm thử phần mềm

7 lãng phí trong kiểm thử phần mềm

Bài viết được sự cho phép của vntesters.com

Tựa đề “7 lãng phí trong kiểm thử phần mềm” nghe có vẻ quen quen? Vâng, 7 lãng phí nổi tiếng nhất là 7 lãng phí trong sản xuất tinh gọn (Lean manufacturing). Mình biết đến 7 lãng phí này cũng là sự tình cờ. Chuyện là công ty hiện mình đang làm việc là một công ty sản xuất. Mỗi ngày khi đi ăn trưa mình đều đi ngang qua xưởng sản xuất của công ty và có một tấm bảng được đặt dọc lối đi ngay cạnh xưởng sản xuất đã gây được sự chú ý của mình. Đó là tấm bảng nói về 7 lãng phí trong sản xuất tinh gọn. Đọc qua 7 nội dung thì mình thấy rõ ràng 7 lãng phí đó khá đơn giản, dễ hiểu và về cơ bản là đúng cho cả ngành kiểm thử phần mềm. Tìm hiểu kỹ hơn thì mình biết được rằng việc định ra và loại bỏ 7 lãng phí này đóng vai trò cực kỳ quan trọng trong sản xuất tinh gọn nhưng dường như ít ai quan tâm đến vấn đề này trong phát triển phần mềm cũng như trong kiểm thử. Điều đó đã thúc đẩy mình để thực hiện bài viết về 7 lãng phí trong kiểm thử phần mềm. Bài viết lần lượt đi qua 7 lãng phí trong sản xuất tinh gọn và được liên hệ với ngành kiểm thử phần mềm cùng với đó là những đề nghị giải pháp để loại bỏ hay giảm thiểu những lãng phí này.

  10 bước để bắt đầu áp dụng kiểm thử tự động vào dự án
  Các mức độ kiểm thử được sử dụng trong kiểm thử chức năng của một phần mềm

Lỗi (Defects)

Trong ngành sản xuất, lỗi được xem là lãng phí. Thực vậy, khi một lỗi xảy ra, chúng ta sẽ tốn nhiều thời gian của Dev để sửa lỗi, sau đó sẽ tốn thêm thời gian cho kỹ sư kiểm thử để kiểm thử lỗi một lần nữa. Tương tự, nếu một bản build bị hỏng (vì có quá nhiều lỗi nghiêm trọng), chúng ta đã lãng phí cả một quy trình, thời gian và công sức để làm lại từ đầu. Dĩ nhiên, lãng phí sẽ còn lớn hơn nếu sản phẩm bị lỗi sau khi đưa ra thị trường. Khi đó lãng phí không chỉ đơn thuần xảy ra ở bộ phận sản xuất mà còn kéo theo lãng phí cả những bộ phận khác trong công ty. Chắc các bạn cũng còn nhớ chuyện Toyota gần đây triệu hồi hàng chục nghìn xe tại Việt Nam và hàng triệu xe trên thế giới vì hàng loạt lỗi nghiêm trọng có thể ảnh hưởng đến sự an toàn của người sử dụng cho thấy mức độ nghiêm trọng của lỗi sau khi đưa ra thị trường. Rõ ràng không những tốn kém cho chi phí từ việc triệu hồi và sửa những lỗi đó mà còn ảnh hưởng không nhỏ đến hình ảnh của Toyota.

Để tránh lãng phí về lỗi, là kỹ sư kiểm thử, ngoài việc tìm lỗi chúng ta cũng nên chú trọng hơn vào vấn đề ngăn ngừa lỗi thay vì tìm lỗi. Việc chúng ta ngăn ngừa được một lỗi xảy ra có giá trị gấp nhiều lần một lỗi nghiêm trọng mà chúng ta tìm thấy vì khi chúng ta tìm thấy lỗi thì đã xuất hiện sự lãng phí. Để ngăn ngừa lỗi tốt hơn, kỹ sư kiểm thử nên được tham gia vào tất cả các khâu của dự án từ phân tích yêu câu, thiết kế đến viết code và càng sớm càng tốt.

Sản xuất thừa (Overproduction)

over_production

Trong kiểm thử phần mềm, việc chúng ta dành quá nhiều thời gian và công sức để tạo ra và cập nhật bản kế hoạch kiểm thử (test plan), chiến lược kiểm thử (test strategy), trường hợp kiểm thử (test case) mà thực tế thì nhiều khi chẳng ai hoặc ít ai đọc đến. Bi kịch là chúng ta biết điều đó nhưng vẫn phải làm vì nhiều lí do rất “thuyết phục” như “quy trình nó vậy”, “giờ không cần nhưng biết đâu khách hàng cần”, “như vậy mới pro” hay nhẹ nhàng hơn như “làm nhanh mà”. Các bạn đừng hiểu lầm là việc tạo ra các tài liệu kiểm thử là lãng phí, việc tạo ra tài liệu kiểm thử mà không có giá trị hoặc không cần thiết mới là lãng phí.

Trước khi bạn bắt đầu tạo một tài liệu kiểm thử hãy tự hỏi hay hỏi sếp mình những ai sẽ đọc nó và nó mang lại giá trị gì. Nếu không có câu trả lời hay câu trả lời là mơ hồ hay không rõ ràng thì tốt nhất chúng ta không nên tạo ra để tránh tình trạng sản xuất thừa.

Chờ đợi (Waiting)

work_in_progress

Ai đó từng nói “sống là không chờ đợi” ấy vậy mà trong ngành kiểm thử thì việc chờ đợi đã trở nên quen thuộc. Chúng ta đã bao nhiêu lần phải chờ đợi bản build từ đội Dev để kiểm thử, chờ môi trường kiểm thử sẵn sàng, chờ khách hàng kiểm duyệt cho các trường hợp kiểm thử đã tạo ra, chờ tài liệu yêu cầu từ khách hàng gửi sang, chờ khách hàng online để thảo luận, v.v. Lãng phí sẽ còn lớn hơn nếu trong khi chờ đợi và chúng ta không có gì khác để làm. “Tin tốt” là ngày nay sếp ít khi để cho nhân viên của mình nhàn rỗi trong khi chờ đợi và bạn luôn có việc khác để làm. Tin xấu là chúng ta đã tự đặt mình vào tình trạng bị động khi chờ đợi. Nhiều khi những thứ chúng ta chờ đợi lại đến không đúng thời điểm hay khi tất cả những thứ chúng ta đang chờ đợi cùng đến một lúc hay chẳng bao giờ đến. Đó là khi chúng ta chờ đợi 1 build từ đội Dev và gần cuối ngày chúng ta nhận được bản build với yêu cầu từ sếp là phải chạy xong bộ test case…trong ngày.

Hãy kiểm tra lại các khâu trong quy trình kiểm thử xem liệu có tình trạng “nút thắt cổ chai” đâu đó và đề ra giải pháp khắc phục tương ứng. Ứng dụng mô hình phát triển tích hợp liên tục (continuous integration) từ việc coding, triển khai, thực thi kiểm thử tự động, báo cáo kết quả không những tránh được lãng phí do chờ đợi mà còn tận dụng được nguồn lực máy móc một cách tối ưu. Hãy chuẩn bị sẵn cho mình kế hoạch B cũng như tìm ra những kênh liên lạc khác nhau để tránh tình trạng bị động khi phải chờ đợi.

Tồn kho (Inventory)

Việc sản xuất thừa cùng tình trạng chờ đợi ở trên dẫn đến một lãng phí khác là tồn kho. Trong ngành kiểm thử (và cả phát triển phần mềm) thì thuật ngữ “tồn kho” nghe có vẻ lạ lẫm nhưng thực tế thì có tồn tại việc tồn kho. Việc tạo ra quá nhiều tài liệu kiểm thử không cần thiết hoặc quá nhiều thứ đến cùng một lúc (do việc chờ đợi) hay quá nhiều thứ đang đợi để xử lý, dẫn đến tình trạng tồn kho (hay nói cách khác là “lưu trữ”). Ngày nay, với sự hỗ trợ của nhiều công cụ phần mềm cũng như dung lượng lưu trữ của máy tính lớn, chúng ta hầu như không thấy vấn đề về tồn kho trong dự án. Tuy nhiên, về lâu về dài việc tồn kho sẽ gây lãng phí về nguồn lực, thời gian trong quản lí và truy xuất. Ở đây, mình cũng thấy một vòng luẩn quẩn là từ việc chúng ta có hệ thống quản lí tồn kho tốt chúng ta lại vô tình khuyến khích tình trạng sản xuất thừa hay chờ đợi.

Thực tế thì việc tồn kho, quản lí tồn kho là không thể tránh khỏi và cũng không đáng kể trong kiểm thử phần mềm. Tuy nhiên, giải pháp tốt vẫn là tránh sản xuất thừa hay tình trạng chờ đợi ở trên để giảm thiểu việc tồn kho đến mức thấp nhất có thể. Hành động đơn giản mà chúng ta có thể làm ngay là hãy dũng cảm “delete” những tài liệu không cần thiết không những giúp cho kho hàng của bạn nhỏ gọn mà còn giúp bạn tìm kiếm dễ dàng hơn.

Vận chuyển (Transportation) và Hành động thừa (Motion)

Đây là 2 loại lãng phí chuyên biệt trong ngành sản xuất và thật khó để liên hệ với ngành phát triển phần mềm hay kiểm thử. Tuy nhiên, mình xin được phép liên hệ 2 loại lãng phí này với việc lãng phí trong việc phân bổ đội kiểm thử cũng như mô hình kiểm thử trong dự án. Cụ thể hơn, trong kiểm thử phần mềm, thì việc tổ chức sắp xếp các thành viên trong đội kiểm thử hay giữa đội kiểm thử với các đội khác trong dự án không hợp lí dẫn đến lãng phí. Sự không hợp lí này bao gồm cả về mặt địa lí cũng như cấu trúc. Việc đội kiểm thử và đội phát triển cách xa nhau về mặt địa lí (thường thấy trong môi trường outsource) sẽ gây nhiều khó khăn trong việc giao tiếp cũng như trao đổi tài liệu, kết quả kiểm thử. Một số dự án do cách xa nhau về địa lí cùng hệ thống network phức tạp, bảo mật nhiều tầng dẫn đến việc nhận build, cài đặt, kiểm thử, gửi kết quả kiểm thử, debug gặp rất nhiều thời gian và công sức. Việc đưa nhân viên onsite đào tạo hay thăm nom đội dự án giữa 2 bên cũng gây nhiều tốn kém. Ngoài vấn đề khó khăn về địa lí thì việc bố trí đội kiểm thử như là gatekeeper (“người canh cổng”) cho toàn bộ quy trình cũng gây lãng phí nguồn lực. Đội kiểm thử lúc này chỉ đóng vai trò như là người tìm lỗi và tham gia rất ít (hoặc không tham gia) vào quá trình ngăn lỗi. Ngoài những vấn đề nêu trên thì các mô hình quản lí kiểm thử rườm rà phức tạp như quá nhiều vòng kiểm và duyệt dư thừa cho các hoạt động kiểm thử cũng gây lãng phí nhiều thời gian.

Nếu có thể thì nên bố trí đội kiểm thử và đội phát triển “gần nhau” để dễ dàng cũng như giảm thiểu, chi phí trao đổi thông tin. Mô hình phát triển phần mềm linh hoạt (Agile) đã làm rất tốt về mặt này khi góp gần giảm bớt những hoạt động, quy trình không mang lại giá trị và tập trung vào những thứ mang lại giá trị thiết thực cho dự án.

Quy trình thừa (Over-processing)

over_process

Một số dự án nhỏ nhưng vì để “bằng chị bằng anh” đã áp dụng quy trình, mô hình quản lí như CMMI, ISO để quản lí dự án. Kết quả là thời gian mà đội kiểm thử dành để tạo, cập nhật tài liệu, báo cáo còn nhiều hơn thời gian thực tế dành cho công việc kiểm thử. Một ví dụ khác có thể nhìn thấy là vấn đề kiểm thử tự động. Nhiều người lầm tưởng là kiểm thử tự động là tiên tiến là hiện đại nên nhất quyết phải kiểm thử tự động cho bằng được mặc dù bản chất của sản phẩm không phù hợp với kiểm thử tự động hoặc chi phí bỏ ra để kiểm thử tự động lớn hơn giá trị thu về. Nguyên nhân dẫn đến tình trạng trên một phần xuất phát từ cái gọi là “quy trình chuẩn” hay “best practice” cùng góc nhìn chủ quan dựa trên những kinh nghiệm thành công trong quá khứ. Những quy trình chuẩn và những thành công mà chúng ta có được với dự án trước, công ty trước không đồng nghĩa là chúng ta sẽ lại áp dụng thành công ở dự án, công ty hiện tại. Vì bản chất dự án là khác nhau, con người khác nhau, thời điểm khác nhau, môi trường văn hóa công ty khác nhau.

Trước khi ứng dụng 1 quy trình, mô hình hay ứng dụng, chúng ta nên cân nhắc xem liệu “chiếc áo” ta sắp mặc vào có quá to so với mình hay không mặc dù nó rất vừa và đẹp với người khác. Tương tự, cũng nên cân nhắc xem liệu chúng ta có thật sự cần những công cụ quản lí kiểm thử như QC, JIRA, Bugzilla, Rally hay nhu cầu thực sự của chúng ta chỉ là 1 file Excel.

Lời kết

Bài viết nói về 7 lãng phí trong kiểm thử phần mềm dựa trên 7 lãng phí trong sản xuất tinh gọn nhưng điều này không có nghĩa là chúng ta chỉ có 7 lãng phí (tất nhiên rồi). Hãy nhìn vào dự án của mình, nhìn vào các hoạt động kiểm thử chúng ta làm mỗi ngày, các quy trình kiểm thử và xem xem liệu chúng ta có đang lãng phí điều gì không. Lãng phí không nhất thiết gây hại cho dự án nhưng việc định ra và loại bỏ những lãng phí là một trong hoạt động quan trọng trong cải tiến quy trình để hướng đến mục tiêu làm việc hiệu quả và tiết kiệm.

Bạn có quan điểm khác về lãng phí trong kiểm thử phần mềm? Rất vui nếu nhận được ý kiến đóng góp của các bạn.

Bài viết có tham khảo:

http://en.wikipedia.org/wiki/Muda_(Japanese_term)

http://en.wikipedia.org/wiki/Lean_manufacturing#Types_of_waste

http://www.proftest.nl/artikelen/LTM_TE_16_12_11.pdf

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Cách xử lý dữ liệu trong quá trình làm việc với framework

framework
Cách xử lý dữ liệu trong quá trình làm việc với framework

Framework là một tập hợp chứa các thư viện phần mềm, các dữ liệu liên quan, các trình biên dịch, diễn dịch hoặc các API. Framework tạo ra một nền tảng, môi trường để công việc lập trình của các Data Scientist trở nên nhanh chóng và hiệu quả hơn.

  10 Java Web Framework tốt nhất
  Framework có đang giết chết sự sáng tạo trong thiết kế Web?

Về diễn giả

  • Anh Trương Bảo Duy hiện là Data Scientist Manager tại Công ty HEINEKEN Vietnam.
  • Anh đã từng làm việc với vai trò là một Academic Research, Data Scientist ở Tiki. Anh có bằng cử nhân về Công nghệ thông tin và thạc sĩ trong lĩnh vực kinh tế.

Framework dành cho ai và có thể làm được gì?

Những ai nên sử dụng framework?

Framework là sản phẩm chủ yếu dành cho những leader, manager và những bạn lần đầu tiên set-up data sciences, chưa có nhiều kinh nghiệm và không biết nên bắt đầu như thế nào cho hợp lí. Framework cũng hỗ trợ các team data sciences đã có finding và đang muốn apply nó vào sản phẩm.

Bên cạnh đó, framework cũng sẽ giúp cho những bạn làm Data Analyst, Data Scientist và những bạn lần đầu tham gia vào một start-up đang muốn tìm hiểu xem một Data Science Project nên vận hành như thế nào.

Framework có thể hỗ trợ những công việc nào?

Bạn đã từng làm việc ở vị trí manager, leader, và có background về data engineer, data scientist nhưng khi tham gia vào một công ty mới, một môi trường hoàn toàn mới thì sẽ có rất nhiều vấn đề phát sinh mà bạn cần phải giải quyết, những vấn đề mà đôi khi những kiến thức trước đó không thể hỗ trợ được.

framework
Tận dụng kỹ năng của bản thân giúp quá trình làm việc tốt nhất

Đó có thể là data thuộc về nhiều product, nhiều platform khác nhau, thuộc về nhiều team khác nhau cũng như có data owner khác nhau. Hoặc cũng có thể nó liên quan đến chất lượng data. Ngoài ra, đối với các start-up, framework cũng hỗ trợ rất nhiều trong quá trình xây dựng Data Science Project. Với các FMCG nhưng các metrics, KPI vẫn chưa thật sự quá tốt hay những người làm việc ở đó chưa có nhiều trust trong data hoặc các team làm việc độc lập với nhau, họ không quen với teamwork, framework cũng có ảnh hưởng khá lớn.

Điều đương nhiên là framework không thể giải quyết tất cả các vấn đề này nhưng chắc chắn nó sẽ giúp cho hành trình apply data science trở nên dễ dàng hơn. Mỗi người có một background khác nhau và nếu đó là lần đầu tiên bạn setup data science thì mình nghĩ các bạn nên tập trung vào giải quyết các bài toán, các vấn đề là thế mạnh của mình. Đồng thời trong quá trình đó, bạn cũng nên apply một framework để giúp bạn build trust trong việc sử dụng data ở công ty của mình nhiều hơn.

Quá trình làm việc với framework diễn ra như thế nào?

1. Power Decisions

Nếu đã có kinh nghiệm làm việc ở vị trí Data Scientist, bạn sẽ biết được tầm quan trọng của việc xác định được câu hỏi chính xác cần giải quyết có ý nghĩa quan trọng như thế nào. Đây cũng là bước đầu tiên mà bạn cần giải quyết – Power decisions. Trong bước này bạn sẽ kết nối các business owner lại với nhau và cùng brainstorm để xác định đâu là những vấn đề mà công ty đang gặp phải, và câu hỏi nên được đặt ra để giải quyết ở đây là gì.

Chẳng hạn như ở Heineken, mỗi năm Heineken có rất nhiều chương trình cho khách hàng của mình. Các business owner là đối tác với Heineken, thường là Head of a Function hay team, câu hỏi chính của họ sẽ liên quan tới các projects do họ đang quản lý. Các business owner thường rất giỏi trong việc planning và execution nhưng việc optimization lại không phải là chuyên môn của họ nên team anh sẽ tham gia vào project để support họ. Các data analyst hoặc data scientist sẽ thông qua việc phân tích câu hỏi để có thể dùng data giải quyết vấn đề. Khi bạn có thể nắm được vấn đề và hiểu được mình nên giải quyết chuyện gì cho khách hàng thì đó đã là một phần thành công trong project này rồi.

framework
Xác định chính xác câu hỏi cần giải quyết sẽ định hướng hướng đi đúng đắn nhất cho dự án

2. Analytics và modelling

Đây là bước làm việc thứ 2, công việc ở quy trình này chủ yếu do data analyst hoặc data scientist chịu trách nhiệm. Mục tiêu chính của quá trình này là để xác định đâu là nguồn data chính cần phải sử dụng và đâu là các data owner cần liên hệ với business owner để xin data cũng như có thể điều chỉnh data lại theo đúng nhu cầu mình cần để phân tích. Kết quả cuối cùng của bước này là làm sao để translate những data, finding thành actionable insights hoặc productive models. Từ đó chúng ta có thể tiếp tục thực hiện bước thứ 3.

3. Test & Learn

Đây là một bước rất phổ biến ở các công ty công nghệ nhưng đối với các công ty như FMCG thì test & learn vẫn còn là vấn đề khá mới. Theo cá nhân mình quan sát thì khi họ phân tích data xong sẽ tìm kiếm cách scale up data lên toàn thị trường. Mình nghĩ đây là một bước có tính rủi ro khá cao vì 2 lí do.

Thứ nhất việc insights không chính xác. Trong quá trình phân tích để tìm ra insight, mọi người có thể gặp những vấn đề liên quan đến coding, hiểu sai về data, và rất nhiều vấn đề khác có thể xảy ra trong quá trình phân tích data dẫn đến insight này có thể không chính xác. Nên nếu ngay lập tức scale up data lên toàn bộ thị trường thì kết quả cuối cùng vẫn không đạt được đúng kỳ vọng và yêu cầu đề ra. Và việc đi sai hướng ngay từ đâu sẽ khiến thời gian và công sức đầu tư vào đó bị lãng phí.

Thứ hai là khi làm việc với các công ty traditional – những công ty không phải công ty công nghệ, testing cho phép team business learn chuẩn bị cho quá trình scale up. Vì thường bên anh sẽ đề xuất quy trình mới hoặc thay đổi quy trình/cách làm việc. Điều này có thể khiến cho quy trình cũ bị đổ vỡ và cần thay thế. Nếu không lường trước được những tác động của việc đổ vỡ này và tìm cách khắc phục, có thể sẽ làm business bị gián đoạn.

Xem thêm Học ngôn ngữ gì cho Data Science?

4. Scale up

Đây là bước cuối cùng và thật ra khá đơn giản. Bạn sẽ không cần nhiều sự tham gia của Data Analyst hoặc Data Scientist mà phụ thuộc phần nhiều vào Business owner. Business owner cần phải hiểu được vấn đề là sau bước test & learn thì đâu là thứ họ phải test để khi scale up họ có thể rút ra các kinh nghiệm làm việc sau này.

Đây là 4 bước cơ bản mà bạn sẽ trải qua khi làm việc với framework, tuy nhiên nó không chỉ dừng ở 4 bước này. Vì đây là 4 bước khá technical – kỹ thuật, nên để nó có thể gắn liền với business, trở thành sản phẩm không thể thiếu với business thì cách làm việc của con người đóng vai trò cực kỳ quan trọng.

Tổ chức công việc ra sao để framework vận hành trơn tru nhất?

Để làm việc hiệu quả, chúng ta cần có một Core Team gồm Data Scientist và Coordinator.

Data Scientist sẽ tập trung vào việc phân tích data, các vấn đề liên quan đến technical. Trong khi đó, Coordinator sẽ tập trung làm việc với các business. Nếu bạn làm việc ở một công ty startup hoặc công ty hoàn toàn mới chưa được setup thì Data Scientist phải làm cả công việc của Coordinator. Nhưng cá nhân mình nghĩ nên có 2 vị trí riêng biệt vì nó sẽ giúp các Data Scientist tập trung hơn vào công việc và thế mạnh của mình, nhất là khi data vẫn chưa ổn định, không thật sự clean. Data Scientist sẽ phải dành rất nhiều thời gian cho việc clean data, hiểu data, tìm kiếm insight và hiểu model với gì mình đang có.

Core team nên gặp Business Owner ít nhất một tuần hoặc 2 tuần một lần. Đây là một vấn đề cực kỳ quan trọng với hai lý do sau:

Thứ nhất, business owner là người hiểu rõ nhất về business của họ. Họ sẽ là người đưa ra đề bài nên đóng vai trò định hướng lại vấn đề trong trường hợp bạn đi chệch hướng. Ngoài ra, họ cũng sẽ đưa ra những thông tin phụ sau khi bạn bắt đầu quá trình phân tích dữ liệu.

Thứ hai, bạn cần họ tham gia vào Data Science Project vì sự thực là Data Science Project mang nặng tính kỹ thuật và đôi khi các business sẽ không hiểu được những khó khăn mà bên bạn đang gặp phải. Trong quá trình làm việc nếu họ nhận ra những khó khăn mình đang gặp hoặc có vấn đề gì với business thì họ sẽ can thiệp ngay. Đồng thời khi biết quy trình làm như thế nào thì họ có thể hiểu được và cảm nhận được tính quan trọng của công việc hơn.

framework
Core team đóng vai trò cốt lõi trong Data Science Project

Bước cuối cùng là meeting với những người mà mình tạm gọi là Framework Angels. Ở Heineken thì đây là những người thuộc về MT hoặc director. Vậy tại sao lại cần họ? Đối với những công ty nhỏ và mới thì điều này không quá quan trọng nhưng ở những công ty lâu năm, mọi thứ đã ổn định rồi thì họ sẽ giúp cho bạn nhiều thứ. Thứ nhất là họ giúp bạn làm việc với business owner tốt hơn vì đôi khi business owner họ sẽ không hiểu được tầm quan trọng của data scientist team thì các Framework Angels sẽ giúp bạn làm việc tốt hơn, họ giảm những căng thẳng giữa các team khi làm việc với nhau. Thứ hai là bạn cần những người này trong quá trình hoàn thiện và đưa sản phẩm ra thị trường, nó sẽ đảm bảo framework và project vận hành trơn tru.

Một số kinh nghiệm làm việc với framework

Trong quá trình apply framework cho công ty Heineken năm vừa rồi, team Data Scientist đã hoàn thành khoảng hơn 4 power decisions và hơn 3 triệu đô đã được actionable. Con số thực tế sẽ thấp hơn và thậm chí là thấp hơn khá nhiều ở thời điểm hiện tại vì công ty cần có thêm thời gian để build trust, bắt đầu quen dần với câu chuyện test & learn và scale up nó như thế nào nên con số mà team có thể optimize được là khoảng 10% của 3 triệu đô này.

Bài học và kinh nghiệm ở đây như mình đã chia sẻ thì bắt đầu với một câu hỏi đúng – right question thật sự rất quan trọng. Khi MT hiểu được vai trò, khả năng của team Data Science thì họ rất muốn có sự giúp đỡ của team Data Science và đôi khi những yêu cầu của họ không thật sự mang lại quá nhiều giá trị so với scale của công ty. Hoặc khả năng scalable của project khá lớn nhưng nó bắt đầu với một câu hỏi, tức là không tập trung vào một kpi nhất định, không thể giải quyết được các bài toán với những data mà công ty đang có thì việc thất bại là rất dễ xảy ra.

Xem thêm Chuyện nghề: Data Scientist là gì? Và hành trình để trở thành Data Scientist

Đôi khi business sẽ không thể hiểu được những vấn đề mà Data Scientists đang gặp phải nên khi làm việc, chúng ta nên cố gắng tìm ra vấn đề cần phải giải quyết ngay từ đầu. Vì đây thật sự là việc vô cùng quan trọng và cần thiết. Bên cạnh đó, việc chọn một business owner phù hợp cũng quan trọng không kém. Trong quá trình mình làm việc ở Heineken, đã có trường hợp business owner khiến mình nhận ra không ít vấn đề. Họ rất thông hiểu về business của họ và vấn đề mà mình đang cố gắng giải quyết.

Nhưng vấn đề ở đây là business owner không phải là người đưa ra quyết định cuối cùng, dẫn đến việc người phải đưa ra quyết định onboard quá trễ, họ không thể hiểu được toàn bộ dự án là như thế nào và không đồng ý đưa ra quyết định cuối cùng. Chính điều này khiến cho project này bị đình trệ hoàn toàn và không mang lại nhiều giá trị cho công ty nữa. Vậy nên để làm việc hiệu quả, bạn nên cố gắng tìm một business owner vừa hiểu về business vừa có khả năng make final decision. Hoặc nếu không có người như vậy trong tổ chức của bạn thì bạn nên cố gắng kết hợp 2 người như vậy với nhau để đảm bảo là đến cuối project nó sẽ được scale lên.

Thứ 3 là vấn đề testing, với Data Scientist thì đây là việc phải làm. Nó sẽ giúp bạn hạn chế rất nhiều rủi ro trong quá trình làm việc và scale up.

Thứ 4 là MT endorsement. Như mình đã chia sẻ trước đó là khi organization càng lớn và càng có nhiều phòng ban thì khi đó Data Science Project sẽ cần sự phối hợp của nhiều phòng ban lại với nhau. Nếu bạn không có support từ những high manager thì việc team work khi làm việc không hiệu quả. Sự tương tác giữa các MT với nhau giúp cho cỗ máy làm việc hoạt động hiệu quả nhất.

Bài viết được trích dẫn từ phần trình bày của anh Trương Bảo Duy tại sự kiện Vietnam Web Summit 2020 LIVE do TopDev tổ chức

Có thể bạn quan tâm:

Xem thêm các việc làm Developer hấp dẫn tại TopDev

1...121122123...230Page 122 of 230