Author: vuongduong7995

  • Differentiate between ephemeral state and app state.

    Theo nghĩa rộng nhất có thể, trạng thái của ứng dụng là mọi thứ tồn tại trong bộ nhớ khi ứng dụng đang chạy. Điều này bao gồm nội dung của ứng dụng, tất cả các biến mà khung Flutter lưu giữ về giao diện người dùng, trạng thái hoạt ảnh, kết cấu, phông chữ, v.v. Mặc dù định nghĩa rộng nhất có thể này về trạng thái là hợp lệ, nhưng nó không hữu ích lắm cho việc kiến trúc một ứng dụng.

    Đầu tiên, bạn thậm chí không quản lý một số trạng thái (như kết cấu). Khung xử lý những điều đó cho bạn. Vì vậy, một định nghĩa hữu ích hơn về trạng thái là “bất kỳ dữ liệu nào bạn cần để xây dựng lại giao diện người dùng của bạn bất kỳ lúc nào”. Thứ hai, trạng thái mà bạn tự quản lý có thể được tách thành hai loại khái niệm: ephemeral state and app state.

    Ephemeral state

    Ephemeral state (đôi khi được gọi là UI state or local state) là trạng thái bạn có thể chứa gọn gàng trong một tiện ích con.

    Đây là một định nghĩa mơ hồ, vì vậy đây là một vài ví dụ:

    • Page hiện tại trong PageView
    • Tiến hành hiện tại trong một animation phức tạp.
    • Tab được chọn hiện tại trong BottomNavigationBar.

    Các phần khác của widget tree hiếm khi cần phải truy cập vào loại trạng thái này. Không cần phải tuần tự hóa nó và nó không thay đổi theo những cách phức tạp.

    Nói cách khác, không cần sử dụng các kỹ thuật quản lý trạng thái (ScopedModel, Redux, v.v.) trên loại trạng thái này. Tất cả những gì bạn cần là một StatefulWidget.

    Dưới đây, bạn thấy cách mục hiện được chọn trong thanh điều hướng dưới cùng được giữ trong trường _index của lớp _MyHomepageState. Trong ví dụ này, _index là ephemeral state.

    Ở đây, việc sử dụng setState() và một trường bên trong lớp StatefulWidget’s State là hoàn toàn tự nhiên. Không phần nào khác trong ứng dụng của bạn cần truy cập _index. Biến chỉ thay đổi bên trong tiện ích MyHomepage. Và, nếu người dùng đóng và khởi động lại ứng dụng, bạn đừng bận tâm rằng _index đặt lại về 0.

    App state

    Đây không phải là ephemeral state mà bạn muốn chia sẻ trên nhiều phần của ứng dụng và bạn muốn giữ lại giữa các phiên của người dùng, chúng ta gọi là application state (đôi khi còn được gọi shared state).

    Ví dụ về application state:

    • Sở thích của người sử dụng
    • Thông tin đăng nhập
    • Thông báo trong một ứng dụng mạng xã hội
    • Giỏ hàng trong ứng dụng thương mại điện tử
    • Trạng thái đã đọc / chưa đọc của các bài báo trong một ứng dụng tin tức

    Để quản lý app state, bạn sẽ muốn nghiên cứu các tùy chọn của mình. Lựa chọn của bạn phụ thuộc vào mức độ phức tạp và bản chất của ứng dụng, trải nghiệm trước đây của nhóm bạn và nhiều khía cạnh khác.

    Không có quy tắc rõ ràng.

    Để rõ ràng hơn, bạn có thể sử dụng State và setState() để quản lý tất cả các trạng thái trong ứng dụng của mình. Trên thực tế, nhóm Flutter thực hiện điều này trong nhiều mẫu ứng dụng đơn giản (bao gồm cả ứng dụng dành cho người mới bắt đầu mà bạn nhận được sau mỗi lần tạo Flutter).

    Nó cũng đi theo hướng khác. Ví dụ: bạn có thể quyết định rằng — trong ngữ cảnh của ứng dụng cụ thể của bạn — tab đã chọn trong thanh điều hướng dưới cùng không phải là trạng thái tạm thời. Bạn có thể cần phải thay đổi nó từ bên ngoài lớp học, giữ nó giữa các phiên, v.v. Trong trường hợp đó, biến _index là trạng thái ứng dụng.

    Không có quy tắc chung, rõ ràng nào để phân biệt một biến cụ thể là ephemeral sate hay trạng thái ứng dụng. Đôi khi, bạn sẽ phải cấu trúc lại cái này thành cái khác. Ví dụ: bạn sẽ bắt đầu với một số trạng thái rõ ràng là tạm thời, nhưng khi ứng dụng của bạn phát triển về các tính năng, nó có thể cần được chuyển sang app state.

    Vì lý do đó, hãy lấy sơ đồ sau với một lượng muối lớn:

    Cảm ơn mọi người đã theo dõi.

  • Flutter: Quản lý state bằng provider.

    Ví dụ.

    Để minh họa, hãy xem xét ứng dụng đơn giản sau.

    Ứng dụng có hai màn hình riêng biệt: danh mục và giỏ hàng (được đại diện bởi các tiện ích MyCatalog và MyCart, tương ứng). Nó có thể là một ứng dụng mua sắm, nhưng bạn có thể tưởng tượng cấu trúc tương tự trong một ứng dụng mạng xã hội đơn giản (thay thế danh mục cho “tường” và giỏ hàng cho “yêu thích”).

    Màn hình danh mục bao gồm thanh ứng dụng tùy chỉnh (MyAppBar) và dạng xem cuộn của nhiều mục danh sách (MyListItems).

    Đây là ứng dụng được hình dung dưới dạng cây tiện ích con.

    Vì vậy, chúng ta có ít nhất 5 lớp con của Widget. Nhiều người trong số họ cần quyền truy cập vào trạng thái “thuộc về” ở nơi khác. Ví dụ: mỗi MyListItem cần có khả năng tự thêm vào giỏ hàng. Nó cũng có thể muốn xem liệu mặt hàng được hiển thị hiện đã có trong giỏ hàng hay chưa.

    Điều này đưa chúng ta đến câu hỏi đầu tiên: chúng ta nên đặt trạng thái hiện tại của giỏ hàng ở đâu?

    Đưa trạng thái lên

    Trong Flutter, bạn nên giữ trạng thái ở trên các widget sử dụng nó.

    Tại sao? Trong các khung công tác khai báo như Flutter, nếu bạn muốn thay đổi giao diện người dùng, bạn phải xây dựng lại nó. Không có cách nào dễ dàng để có MyCart.updateWith (somethingNew). Nói cách khác, thật khó để thay đổi thứ bậc một tiện ích từ bên ngoài, bằng cách gọi một phương thức trên đó. Và ngay cả khi bạn có thể làm cho điều này thành công, bạn sẽ chiến đấu với khuôn khổ thay vì để nó giúp bạn.

    Ngay cả khi code trên hoạt động, bạn sẽ phải xử lý những điều sau trong tiện ích MyCart:

    Bạn sẽ cần phải xem xét trạng thái hiện tại của giao diện người dùng và áp dụng dữ liệu mới cho nó. Thật khó để tránh lỗi theo cách này.

    Trong Flutter, bạn tạo một widget mới mỗi khi nội dung của nó thay đổi. Thay vì MyCart.updateWith (somethingNew) (một cuộc gọi phương thức), bạn sử dụng MyCart (nội dung) (một phương thức khởi tạo). Vì bạn chỉ có thể tạo các tiện ích con mới trong các phương pháp tạo của cha mẹ chúng, nên nếu bạn muốn thay đổi nội dung, tiện ích con đó phải ở chế độ gốc của MyCart trở lên.

    Bây giờ MyCart chỉ có một đường dẫn mã để xây dựng bất kỳ phiên bản giao diện người dùng nào.

    Trong ví dụ của chúng ta, nội dung cần phải tồn tại trong MyApp. Bất cứ khi nào nó thay đổi, nó sẽ xây dựng lại MyCart từ bên trên (sẽ nói thêm về điều đó sau). Do đó, MyCart không cần phải lo lắng về vòng đời — nó chỉ khai báo những gì sẽ hiển thị cho bất kỳ nội dung nhất định nào. Khi điều đó thay đổi, tiện ích MyCart cũ sẽ biến mất và được thay thế hoàn toàn bằng tiện ích mới.

    Đây là ý của chúng ta khi nói rằng widget là bất biến. Chúng không thay đổi — chúng được thay thế.

    Bây giờ chúng ta đã biết nơi đặt trạng thái của giỏ hàng, hãy xem cách truy cập vào nó.

    Truy cập trạng thái

    Khi người dùng nhấp vào một trong các mặt hàng trong danh mục, mặt hàng đó sẽ được thêm vào giỏ hàng. Nhưng kể từ khi giỏ hàng nằm trên MyListItem, chúng ta làm điều đó như thế nào?

    Một tùy chọn đơn giản là cung cấp một lệnh gọi lại mà MyListItem có thể gọi khi nó được nhấp vào. Các hàm của Dart là các đối tượng hạng nhất, vì vậy bạn có thể chuyển chúng theo bất kỳ cách nào bạn muốn. Vì vậy, bên trong MyCatalog, bạn có thể xác định những điều sau:

    Điều này hoạt động tốt, nhưng đối với một trạng thái ứng dụng mà bạn cần sửa đổi từ nhiều nơi khác nhau, bạn sẽ phải chuyển qua nhiều lần gọi lại — điều này sẽ cũ đi khá nhanh.

    May mắn thay, Flutter có các cơ chế để các widget cung cấp dữ liệu và dịch vụ cho con cháu của chúng (nói cách khác, không chỉ con cái của chúng mà bất kỳ widget nào bên dưới chúng). Như bạn mong đợi từ Flutter, nơi mọi thứ đều là Widget, các cơ chế này chỉ là những loại widget đặc biệt — InheritedWidget, InheritedNotifier, InheritedModel, v.v. Chúng ta sẽ không đề cập đến những điều đó ở đây, vì chúng hơi thấp so với những gì chúng ta đang cố gắng thực hiện.

    Thay vào đó, chúng ta sẽ sử dụng một gói hoạt động với các widget cấp thấp nhưng dễ sử dụng. Nó được gọi là nhà cung cấp.

    Trước khi làm việc với nhà cung cấp, đừng quên thêm phần phụ thuộc vào nhà cung cấp đó vào pubspec.yaml của bạn.

    Bây giờ bạn có import ‘package:provider/provider.dart’; và bắt đầu xây dựng.

    Với provider, bạn không cần phải lo lắng về các cuộc gọi lại hoặc InheritedWidgets. Nhưng bạn cần hiểu 3 khái niệm:

    • ChangeNotifier
    • ChangeNotifierProvider
    • Consumer

    ChangeNotifier

    ChangeNotifier là một lớp đơn giản có trong Flutter SDK cung cấp thông báo thay đổi cho người nghe của nó. Nói cách khác, nếu thứ gì đó là ChangeNotifier, bạn có thể đăng ký các thay đổi của nó. (Đây là một dạng có thể quan sát được, dành cho những người quen thuộc với thuật ngữ này.)

    Trong provider, ChangeNotifier là một cách để đóng gói trạng thái ứng dụng của bạn. Đối với các ứng dụng rất đơn giản, bạn có thể sử dụng với một ChangeNotifier duy nhất. Trong những cái phức tạp, bạn sẽ có một số mô hình và do đó là một số ChangeNotifier. (Bạn hoàn toàn không cần sử dụng ChangeNotifier với provider, nhưng đó là một lớp dễ làm việc.)

    Trong ví dụ về ứng dụng mua sắm của chúng ta, chúng ta muốn quản lý trạng thái của giỏ hàng trong ChangeNotifier. Chúng ta tạo một lớp mới để mở rộng nó, giống như vậy

    Code duy nhất dành riêng cho ChangeNotifier là lệnh gọi tới notificationListists (). Gọi phương thức này bất cứ khi nào mô hình thay đổi theo cách có thể thay đổi giao diện người dùng của ứng dụng của bạn. Mọi thứ khác trong CartModel là chính mô hình và logic của nó.

    ChangeNotifierProvider

    ChangeNotifierProvider là widget cung cấp một phiên bản của ChangeNotifier cho con cháu của nó. Nó đến từ provider package.

    Chúng ta đã biết nơi đặt ChangeNotifierProvider: phía trên các widget cần truy cập nó. Trong trường hợp của CartModel, điều đó có nghĩa là ở đâu đó trên cả MyCart và MyCatalog.

    Bạn không muốn đặt ChangeNotifierProvider cao hơn mức cần thiết (vì bạn không muốn làm giảm hiệu suất). Nhưng trong trường hợp của chúng ta, tiện ích duy nhất nằm trên cả MyCart và MyCatalog là MyApp.

    Consumer

    Bây giờ CartModel đã được cung cấp cho các widget trong ứng dụng của chúng ta thông qua khai báo ChangeNotifierProvider ở trên cùng, chúng ta có thể bắt đầu sử dụng nó.

    Điều này được thực hiện thông qua tiện ích Consumer widget.

    Chúng ta phải chỉ định loại mô hình mà chúng ta muốn truy cập. Trong trường hợp này, chúng ta muốn CartModel, vì vậy chúng ta viết Consumer <CartModel>. Nếu bạn không chỉ định chung chung (<CartModel>), provider sẽ không thể giúp bạn. Provider dựa trên các loại và nếu không có loại, nó không biết bạn muốn gì.

    Đối số bắt buộc duy nhất của Consumer Widget là trình tạo. Builder là một hàm được gọi bất cứ khi nào ChangeNotifier thay đổi. (Nói cách khác, khi bạn gọi thông báo () trong mô hình của mình, tất cả các phương thức trình tạo của tất cả Consumer Widget tương ứng sẽ được gọi.)

    Trình tạo được gọi với ba đối số. Điều đầu tiên là ngữ cảnh, mà bạn cũng nhận được trong mọi phương pháp xây dựng.

    Đối số thứ hai của hàm trình tạo là phiên bản của ChangeNotifier. Đó là những gì chúng ta đã yêu cầu ngay từ đầu. Bạn có thể sử dụng dữ liệu trong mô hình để xác định giao diện người dùng sẽ trông như thế nào tại bất kỳ điểm nhất định nào.

    Đối số thứ ba là con, ở đó để tối ưu hóa. Nếu bạn có một cây con tiện ích con lớn trong Consumer Widget không thay đổi khi mô hình thay đổi, bạn có thể tạo nó một lần và lấy nó thông qua trình tạo.

  • Difference between Multiprogramming, multitasking, multithreading, and multiprocessing

    1. Multiprogramming

    Trong một hệ thống máy tính hiện đại, thường có một số tiến trình ứng dụng đồng thời muốn thực thi. Giờ đây, hệ điều hành có trách nhiệm quản lý tất cả các quy trình một cách hiệu quả và hiệu quả.

    Một trong những khía cạnh quan trọng nhất của hệ điều hành là đa chương trình.

    Trong một hệ thống máy tính, có nhiều quá trình đang chờ được thực thi, tức là chúng đang đợi khi CPU sẽ được cấp phát cho chúng và chúng bắt đầu thực thi. Các quy trình này còn được gọi là công việc. Bây giờ bộ nhớ chính quá nhỏ để chứa tất cả các quy trình hoặc công việc này vào đó. Do đó, các quy trình này ban đầu được lưu giữ trong một khu vực được gọi là nhóm công việc. Nhóm công việc này bao gồm tất cả các quy trình đang chờ cấp phát bộ nhớ chính và CPU.

    CPU chọn một công việc trong số tất cả các công việc đang chờ này, đưa nó từ nhóm công việc đến bộ nhớ chính và bắt đầu thực thi nó. Bộ xử lý thực hiện một công việc cho đến khi nó bị gián đoạn bởi một số yếu tố bên ngoài hoặc nó thực hiện một tác vụ I / O.

    Hệ thống không đa chương trình đang hoạt động:

    • Trong một hệ thống không đa lập trình, Ngay sau khi một công việc rời khỏi CPU và thực hiện một số tác vụ khác (ví dụ I / O), CPU sẽ trở nên nhàn rỗi. CPU tiếp tục chờ và đợi cho đến khi công việc này (đã được thực thi trước đó) quay trở lại và tiếp tục thực hiện với CPU. Vì vậy, CPU vẫn miễn phí trong tất cả thời gian này.
    • Bây giờ nó có một nhược điểm là CPU không hoạt động trong một thời gian rất dài. Ngoài ra, các công việc khác đang chờ thực hiện có thể không có cơ hội thực hiện vì CPU vẫn được phân bổ cho công việc trước đó. Điều này đặt ra một vấn đề rất nghiêm trọng là mặc dù các công việc khác đã sẵn sàng thực thi, CPU không được cấp phát cho chúng vì CPU được phân bổ cho một công việc thậm chí không sử dụng nó (vì nó đang bận trong các tác vụ I / O).
    • Không thể xảy ra trường hợp một công việc sử dụng CPU trong 1 giờ trong khi những công việc khác đã chờ đợi trong hàng đợi trong 5 giờ. Để tránh những tình huống như thế này và sử dụng CPU hiệu quả, người ta đã đưa ra khái niệm đa lập trình.

    Nhiều hệ thống được chương trình đang hoạt động

    • Trong một hệ thống đa lập trình, ngay sau khi một công việc thực hiện một tác vụ I / O, hệ điều hành sẽ ngắt công việc đó, chọn một công việc khác từ nhóm công việc (hàng đợi), cung cấp cho CPU công việc mới này và bắt đầu thực thi nó. Công việc trước đó tiếp tục thực hiện hoạt động I / O của nó trong khi công việc mới này thực hiện các tác vụ ràng buộc CPU. Bây giờ giả sử công việc thứ hai cũng áp dụng cho một tác vụ I / O, CPU chọn công việc thứ ba và bắt đầu thực thi nó. Ngay sau khi một công việc hoàn thành hoạt động I / O của nó và quay trở lại với các tác vụ của CPU, CPU sẽ được cấp phát cho nó.
    • Bằng cách này, không có thời gian CPU bị lãng phí bởi hệ thống chờ đợi tác vụ I / O được hoàn thành. Do đó, mục tiêu cuối cùng của lập trình đa là giữ cho CPU luôn bận rộn miễn là có các tiến trình sẵn sàng thực thi. Bằng cách này, nhiều chương trình có thể được thực thi trên một bộ xử lý bằng cách thực thi một phần của chương trình tại một thời điểm, một phần của chương trình khác sau phần này, sau đó là một phần của chương trình khác, v.v., do đó thực thi nhiều chương trình. Do đó, CPU không bao giờ ngừng hoạt động.

    Trong hình dưới đây, chương trình A chạy một thời gian rồi chuyển sang trạng thái chờ. Trong thời gian trung bình, chương trình B bắt đầu thực hiện. Vì vậy, CPU không lãng phí tài nguyên của nó và tạo cơ hội cho chương trình B chạy.

    2. Multiprocessing

    Trong hệ thống đơn bộ xử lý, chỉ có một quá trình thực thi tại một thời điểm.

    Đa xử lý là việc sử dụng hai hoặc nhiều CPU (bộ xử lý) trong một hệ thống máy tính. Thuật ngữ này cũng đề cập đến khả năng của một hệ thống hỗ trợ nhiều hơn một bộ xử lý trong một hệ thống máy tính duy nhất. Bây giờ vì có nhiều bộ xử lý có sẵn, nhiều quá trình có thể được thực hiện cùng một lúc. Các bộ xử lý đa này chia sẻ bus máy tính, đôi khi cả đồng hồ, bộ nhớ và các thiết bị ngoại vi.

    Nhiều hệ thống xử lý đang hoạt động:

    • Với sự trợ giúp của đa xử lý, nhiều quá trình có thể được thực hiện đồng thời. Giả sử các quá trình P1, P2, P3 và P4 đang chờ thực thi. Bây giờ trong một hệ thống xử lý duy nhất, trước hết một quá trình sẽ thực thi, sau đó là quá trình kia, sau đó là quá trình khác, v.v.
    • Nhưng với đa xử lý, mỗi quá trình có thể được gán cho một bộ xử lý khác nhau để thực hiện. Nếu nó là bộ xử lý lõi kép (2 bộ xử lý), hai quá trình có thể được thực thi đồng thời và do đó sẽ nhanh hơn hai lần, tương tự bộ vi xử lý lõi tứ sẽ nhanh hơn bốn lần so với bộ xử lý đơn.

    Tại sao sử dụng đa xử lý?

    • Ưu điểm chính của hệ thống đa xử lý là hoàn thành nhiều công việc hơn trong một khoảng thời gian ngắn hơn. Các loại hệ thống này được sử dụng khi yêu cầu tốc độ rất cao để xử lý một khối lượng lớn dữ liệu. Hệ thống đa xử lý có thể tiết kiệm tiền so với hệ thống xử lý đơn vì các bộ xử lý có thể dùng chung thiết bị ngoại vi và nguồn cung cấp năng lượng.
    • Nó cũng cung cấp độ tin cậy cao hơn theo nghĩa là nếu một bộ xử lý bị lỗi, công việc sẽ không dừng lại mà chỉ chậm lại. ví dụ. nếu chúng ta có 10 bộ vi xử lý và 1 bộ xử lý bị lỗi, thì công việc sẽ không dừng lại, đúng hơn là 9 bộ vi xử lý còn lại có thể chia sẻ công việc của bộ xử lý thứ 10. Do đó, toàn bộ hệ thống chỉ chạy chậm hơn 10 phần trăm, chứ không phải là thất bại hoàn toàn.

    Đa xử lý đề cập đến phần cứng (tức là các đơn vị CPU) chứ không phải phần mềm (tức là các quy trình đang chạy). Nếu phần cứng bên dưới cung cấp nhiều hơn một bộ xử lý thì đó là quá trình đa xử lý. Đó là khả năng của hệ thống tận dụng sức mạnh tính toán của nhiều bộ xử lý.

    Sự khác biệt giữa đa chương trình và da xử lý

    • Một hệ thống có thể được lập trình đa bằng cách có nhiều chương trình chạy cùng lúc và đa xử lý bằng cách có nhiều hơn một bộ xử lý vật lý. Sự khác biệt giữa đa xử lý và đa lập trình là Đa xử lý về cơ bản là thực hiện nhiều quy trình cùng lúc trên nhiều bộ xử lý, trong khi đa lập trình là lưu giữ một số chương trình trong bộ nhớ chính và thực thi chúng đồng thời chỉ bằng một CPU duy nhất.
    • Đa xử lý xảy ra bằng cách xử lý song song trong khi Đa lập trình xảy ra bằng cách chuyển từ quá trình này sang quá trình khác (hiện tượng được gọi là chuyển mạch ngữ cảnh).

    3. Multitasking

    Như tên gọi của chính nó, đa tác vụ đề cập đến việc thực thi nhiều tác vụ (chẳng hạn như quy trình, chương trình, luồng, v.v.) tại một thời điểm. Trong các hệ điều hành hiện đại, chúng ta có thể phát nhạc MP3, chỉnh sửa tài liệu trong Microsoft Word và lướt Google Chrome đồng thời, điều này được thực hiện nhờ đa tác vụ.

    Đa nhiệm là một phần mở rộng hợp lý của đa lập trình. Cách chính mà đa nhiệm khác với đa lập trình là lập trình đa hoạt động chỉ dựa trên khái niệm chuyển đổi ngữ cảnh trong khi đa nhiệm dựa trên chia sẻ thời gian cùng với khái niệm chuyển đổi ngữ cảnh.

    Hệ thống đa nhiệm đang hoạt động:

    • Trong một hệ thống chia sẻ thời gian, mỗi quá trình được ấn định một số lượng thời gian cụ thể để một quá trình thực thi. Giả sử có 4 quy trình P1, P2, P3 và P4 sẵn sàng thực thi. Vì vậy, mỗi người trong số họ được gán một số lượng tử thời gian mà chúng sẽ thực thi, ví dụ lượng tử thời gian 5 nano giây (5 ns). Khi một quá trình bắt đầu thực hiện (ví dụ P2), nó sẽ thực thi trong lượng tử thời gian đó (5 ns). Sau 5 ns, CPU bắt đầu thực hiện quá trình khác (ví dụ P3) trong lượng tử thời gian được chỉ định.
    • Do đó, CPU làm cho các tiến trình chia sẻ các lát thời gian giữa chúng và thực thi tương ứng. Ngay sau khi lượng tử thời gian của một quá trình hết hạn, một quá trình khác sẽ bắt đầu thực hiện.
    • Ở đây về cơ bản cũng có một chuyển đổi ngữ cảnh đang xảy ra nhưng nó xảy ra quá nhanh đến mức người dùng có thể tương tác với từng chương trình riêng biệt trong khi nó đang chạy. Bằng cách này, người dùng có ảo tưởng rằng nhiều quy trình / tác vụ đang thực hiện đồng thời. Nhưng trên thực tế, chỉ có một tiến trình / tác vụ được thực thi tại một thời điểm cụ thể. Trong đa nhiệm, chia sẻ thời gian được thể hiện tốt nhất bởi vì mỗi quá trình đang chạy chỉ chiếm một lượng tử thời gian hợp lý của CPU.

    Nói một cách khái quát hơn, đa nhiệm là việc có nhiều chương trình, tiến trình, tác vụ, luồng chạy cùng một lúc. Thuật ngữ này được sử dụng trong các hệ điều hành hiện đại khi nhiều tác vụ chia sẻ một tài nguyên xử lý chung (ví dụ: CPU và Bộ nhớ).

    • Như được mô tả trong hình trên, Tại bất kỳ thời điểm nào CPU chỉ thực hiện một tác vụ trong khi các tác vụ khác đang chờ đến lượt. Ảo tưởng về sự song song đạt được khi CPU được phân công lại cho một nhiệm vụ khác. tức là tất cả ba nhiệm vụ A, B và C dường như xảy ra đồng thời vì chia sẻ thời gian.
    • Vì vậy, để đa nhiệm diễn ra, trước tiên phải có đa chương trình, tức là sự hiện diện của nhiều chương trình sẵn sàng để thực thi. Và thứ hai là khái niệm chia sẻ thời gian.

    4. Multithreading

    Một luồng là một đơn vị cơ bản của việc sử dụng CPU. Đa luồng là một mô hình thực thi cho phép một quá trình có nhiều đoạn mã (tức là các luồng) chạy đồng thời trong “ngữ cảnh” của quá trình đó.

    Ví dụ. Trình phát phương tiện VLC, trong đó một luồng được sử dụng để mở trình phát phương tiện VLC, một luồng để phát một bài hát cụ thể và một luồng khác để thêm các bài hát mới vào danh sách phát.

    Đa luồng là khả năng của một quá trình quản lý việc sử dụng nó bởi nhiều người dùng tại một thời điểm và quản lý nhiều yêu cầu của cùng một người dùng mà không cần phải có nhiều bản sao của chương trình.

    Hệ thống đa luồng đang hoạt động:

    Trường hợp 1:

    • Giả sử có một máy chủ web xử lý các yêu cầu của khách hàng. Bây giờ nếu nó thực thi như một quy trình đơn luồng, thì nó sẽ không thể xử lý nhiều yêu cầu cùng một lúc. Đầu tiên, một máy khách sẽ đưa ra yêu cầu của mình và hoàn thành việc thực thi và chỉ sau đó, máy chủ mới có thể xử lý yêu cầu của một máy khách khác. Đây là một công việc thực sự tốn kém, mất thời gian và mệt mỏi. Để tránh điều này, có thể sử dụng đa luồng.
    • Bây giờ, bất cứ khi nào có yêu cầu của khách hàng mới, máy chủ web chỉ cần tạo một luồng mới để xử lý yêu cầu này và tiếp tục thực thi để nghe thêm các yêu cầu của khách hàng. Vì vậy máy chủ web có nhiệm vụ lắng nghe các yêu cầu mới của khách hàng và tạo các luồng cho từng yêu cầu riêng lẻ. Mỗi luồng mới được tạo xử lý một yêu cầu của khách hàng, do đó giảm bớt gánh nặng cho máy chủ web.

    Trường hợp 2:

    • Chúng ta có thể coi các luồng là các quy trình con chia sẻ tài nguyên quy trình mẹ nhưng thực thi độc lập. Bây giờ hãy lấy trường hợp của GUI. Giả sử chúng tôi đang thực hiện một phép tính trên GUI (mất rất nhiều thời gian để hoàn thành). Bây giờ chúng ta không thể tương tác với phần còn lại của GUI cho đến khi lệnh này kết thúc quá trình thực thi. Để có thể tương tác với phần còn lại của GUI, lệnh tính toán này nên được gán cho một luồng riêng biệt. Vì vậy, tại thời điểm này, 2 luồng sẽ thực thi, tức là một để tính toán và một cho phần còn lại của GUI. Do đó, ở đây trong một quy trình duy nhất, chúng tôi đã sử dụng nhiều luồng cho nhiều chức năng.

    Hình ảnh dưới đây mô tả hoàn toàn ví dụ về trình phát VLC:

    Ưu điểm của đa luồng

    • Lợi ích của Đa luồng bao gồm tăng khả năng phản hồi. Vì có nhiều luồng trong một chương trình, vì vậy nếu một luồng mất quá nhiều thời gian để thực thi hoặc nếu nó bị chặn, phần còn lại của luồng sẽ tiếp tục thực thi mà không gặp bất kỳ sự cố nào. Do đó, toàn bộ chương trình vẫn đáp ứng cho người dùng bằng các luồng còn lại.
    • Một ưu điểm khác của đa luồng là nó ít tốn kém hơn. Tạo các quy trình hoàn toàn mới và phân bổ tài nguyên là một công việc tốn nhiều thời gian, nhưng vì các luồng chia sẻ tài nguyên của quy trình mẹ nên việc tạo các luồng và chuyển đổi giữa chúng tương đối dễ dàng. Do đó đa luồng là nhu cầu của các Hệ điều hành hiện đại.

    Cảm ơn mọi người đã theo dõi.

    Author: DuongVT19

  • Dart: Tạo packages.

    Ngôn ngữ Dart sử dụng các package để chia sẻ phần mềm như thư viện và công cụ. Bài này cho bạn biết cách tạo một package, tập trung vào loại package phổ biến nhất, package thư viện.

    Điều gì tạo nên một package thư viện?

    Sơ đồ sau đây cho thấy cách bố trí của package thư viện đơn giản nhất:

    Các yêu cầu tối thiểu đối với một thư viện là:

    – tệp pubspec

    Tệp pubspec.yaml cho một thư viện cũng giống như cho một package ứng dụng. Không có ký hiệu đặc biệt nào để chỉ ra rằng package đó là một thư viện.

    – thư mục lib

    Như bạn có thể mong đợi, mã thư viện nằm trong thư mục lib và công khai đối với các package khác. Bạn có thể tạo bất kỳ hệ thống phân cấp nào dưới lib, nếu cần. Theo quy ước, mã thực thi được đặt dưới lib / src. Mã dưới lib / src được coi là riêng tư; các package khác sẽ không bao giờ cần nhập src / …. Để đặt các API dưới lib / src ở chế độ công khai, bạn có thể xuất tệp lib / src từ tệp trực tiếp dưới lib.

    Cấu thành một package thư viện

    Package thư viện dễ bảo trì, mở rộng và kiểm tra nhất khi bạn tạo các thư viện nhỏ, riêng lẻ, được gọi là thư viện nhỏ. Trong hầu hết các trường hợp, mỗi lớp phải nằm trong thư viện nhỏ của riêng nó, trừ khi bạn gặp trường hợp hai lớp được kết hợp chặt chẽ với nhau.

    Tạo tệp thư viện “chính” trực tiếp dưới lib, lib / <package-name> .dart, xuất tất cả các API công khai. Điều này cho phép người dùng có được tất cả các chức năng của thư viện bằng cách nhập một tệp.

    Thư mục lib cũng có thể bao gồm các thư viện có thể nhập khác, không phải src,. Ví dụ: có thể thư viện chính của bạn hoạt động trên nhiều nền tảng, nhưng bạn tạo các thư viện riêng biệt dựa trên dart: io hoặc dart: html. Một số package có các thư viện riêng biệt được nhập với một tiền tố, trong khi thư viện chính thì không.

    Hãy xem cách tổ chức package thư viện trong thế giới thực: giá sách. Package giá sách cung cấp một cách dễ dàng để tạo máy chủ web bằng Dart và được bố trí theo cấu trúc thường được sử dụng cho các package thư viện Dart:

    Trực tiếp bên dưới lib, tệp thư viện chính, shelf.dart, xuất API từ một số tệp trong lib / src. Để tránh để lộ nhiều API hơn dự định – và để cung cấp cho nhà phát triển cái nhìn tổng quan về toàn bộ API công khai của package – chương trình sử dụng books.dart để chỉ định chính xác những ký hiệu nào cần xuất:

    Package shelf cũng chứa một thư viện nhỏ: shelf_io. Bộ điều hợp này xử lý các đối tượng HttpRequest từ dart: io.

    Nhập các tệp thư viện

    Khi nhập tệp thư viện từ một package khác, hãy sử dụng chỉ thị package: để chỉ định URI của tệp đó.

    Khi nhập tệp thư viện từ package của riêng bạn, hãy sử dụng một đường dẫn tương đối khi cả hai tệp nằm trong lib hoặc khi cả hai tệp nằm ngoài lib. Package sử dụng: khi tệp nhập nằm trong lib và tệp nhập ở bên ngoài.

    Hình dưới đây cho thấy cách nhập lib / foo / a.dart từ cả lib và web.

    Nhập và xuất các tệp thư viện có điều kiện.

    Nếu thư viện của bạn hỗ trợ nhiều nền tảng, thì bạn có thể cần nhập hoặc xuất các tệp thư viện có điều kiện. Một trường hợp sử dụng phổ biến là một thư viện hỗ trợ cả nền tảng web và nền tảng gốc.

    Để nhập hoặc xuất có điều kiện, bạn cần kiểm tra sự hiện diện của các thư viện dart: *. Dưới đây là một ví dụ về mã xuất có điều kiện để kiểm tra sự hiện diện của dart: io và dart: html:

    Đây là những gì mã đó làm:

    • Trong một ứng dụng có thể sử dụng dart: io (ví dụ: một ứng dụng dòng lệnh), hãy xuất src / hw_io.dart.
    • Trong một ứng dụng có thể sử dụng dart: html (một ứng dụng web), hãy xuất src / hw_html.dart.
    • Nếu không, hãy xuất src / hw_none.dart.

    Để nhập tệp có điều kiện, hãy sử dụng mã tương tự như trên, nhưng thay đổi export thành import.

    Trên đây là các chia sẽ của mình về tạo package trong ngôn ngữ dart.

    Cảm ơn mọi người đã theo dõi.

    Author: DuongVT19

  • Cách sử dụng các biến môi trường trong Docker Compose

    Sớm hay muộn, tất cả chúng ta đều phải xử lý các biến môi trường trong tệp soạn của mình. Chúng có thể trở thành một nỗi đau, đặc biệt nếu chúng ta không biết cách sử dụng chúng đúng cách. Dưới đây là mọi thứ tôi biết về các biến môi trường và cách sử dụng các biến này dễ dàng và trên hết là an toàn.

    Chúng ta sử dụng các biến môi trường như thế nào?

    Docker Compose cho phép chúng ta chuyển các biến môi trường vào thông qua dòng lệnh hoặc xác định chúng trong trình bao của chúng ta. Tuy nhiên, tốt nhất là giữ các giá trị này bên trong tệp soạn thực tế và bên ngoài dòng lệnh. “Tại sao?” bạn có thể yêu cầu.

    Bởi vì theo cách này, chúng ta không phải nhớ tất cả các biến môi trường mà chúng ta sử dụng mỗi khi triển khai vùng chứa của mình. Bằng cách lưu trữ chúng trong tệp soạn, chúng ta duy trì tính nhất quán trong quá trình xây dựng của mình.

    Có nhiều hướng khác nhau để làm điều đó.

    Sử dụng lựa chọn môi trường.

    Sử dụng tùy chọn môi trường soạn cho phép chúng ta khai báo các biến môi trường và giá trị của chúng bên trong tệp soạn của chúng ta, như thế này.

    Đây là cách dễ nhất, nhanh nhất để lưu trữ các biến môi trường bên trong soạn tệp. Tuy nhiên, nó có một nhược điểm lớn là liên quan đến bảo mật. Bạn có đoán được nó là gì không?

    Đúng rồi.

    Việc lưu trữ các giá trị của các biến môi trường của bạn trong tệp Soạn sẽ – 95% thời gian – chuyển thẳng đến kiểm soát nguồn và đó là một rủi ro bảo mật rất lớn. May mắn thay, chúng ta có một giải pháp thay thế: sử dụng tệp bên ngoài để lưu trữ các biến môi trường của chúng ta.

    Sử dụng tập tin .env

    Ưu điểm chính của việc sử dụng tệp bên ngoài cho các biến môi trường của bạn là bạn có thể giữ tệp đã nói ngoài quyền kiểm soát nguồn của mình. Rốt cuộc, không ai thích có mật khẩu, khóa API hoặc thông tin siêu bí mật khác của họ trên internet.

    Tệp .env là tệp văn bản thuần túy, chúng ta sử dụng để cấu hình. Hãy nhớ rằng, vì tên tệp bắt đầu bằng dấu ‘ . ’ Nên chúng vẫn bị ẩn đối với hệ thống.

    Chú ý: Để liệt kê các tệp ẩn, bạn có thể sử dụng lệnh ls -a trên Linux hoặc lệnh dir / a: h trên Windows.

    Bạn phải tạo tệp .env tại thư mục gốc của dự án, đây cũng là nơi chứa tệp docker-compost.yml của bạn.

    Chúng ta có thể khai báo và gán các biến trong tệp .env của mình. Đặt tên cho các biến theo cách bạn muốn vì chúng ta sẽ chỉ truy cập các giá trị của chúng.

     Đây là tệp .env của tôi:

    Bạn cũng có thể tạo và điền tệp .env của mình từ dòng lệnh bằng cách sử dụng lệnh mèo Linux:

    Chú ý: Hãy nhớ không để lại bất kỳ khoảng trống nào giữa dấu = và giá trị được gán cho biến của bạn, vì chúng sẽ được thêm vào chuỗi.

    Bây giờ chúng ta đã lưu trữ các biến trong tệp .env, hãy sử dụng chúng trong tệp Soạn của chúng ta. Bây giờ là lúc sử dụng phép nội suy chuỗi (đó là một cái tên ưa thích khi sử dụng ký hiệu $ {string}) để gán giá trị của các biến .env của chúng ta cho các biến môi trường trong tệp Soạn.

    Như bạn có thể thấy, chúng ta duy trì tùy chọn môi trường và chỉ cần gán các giá trị bên ngoài của chúng ta cho các biến môi trường Soạn.

    Để kiểm tra xem mọi thứ có hoạt động bình thường hay không, hãy chạy lệnh sau: docker-compile up.

    Chú ý: Bạn có thể kiểm tra giá trị nào được gán cho các biến môi trường bằng cách chạy lệnh sau (trong một thiết bị đầu cuối khác): docker-compile config.

    Mức độ ưu tiên biến môi trường

    Một điều rất quan trọng mà chúng ta phải ghi nhớ là mức độ ưu tiên được Compose sử dụng để lựa chọn giá trị môi trường của nó. Điều đó có nghĩa là gì?

    Nếu chúng ta khai báo cùng một biến môi trường trong một số tệp (ví dụ: trong tệp Soạn và trong tệp .env bên ngoài) với các giá trị khác nhau, thì Soạn sẽ sử dụng giá trị của biến được khai báo trong tệp Soạn. Tại sao? Bởi vì, tùy thuộc vào nơi mà biến được khai báo, Soạn sẽ cấp cho biến đó mức độ ưu tiên cao hơn hoặc thấp hơn. Đây là thứ tự, xếp hạng từ mức độ ưu tiên cao nhất đến mức độ ưu tiên thấp nhất:

    1. Soạn tệp
    2. Biến môi trường Shell
    3. Tệp môi trường
    4. Dockerfile
    5. Biến không được xác định

    Nếu vì lý do nào đó, tính năng Soạn đang chọn và chỉ định một giá trị mà bạn không mong đợi, thì đây có thể là nguyên nhân. Đảm bảo rằng tất cả các biến của bạn được khai báo chính xác ở nơi bạn muốn.

    Sử dụng tùy chọn env file

    Trong phần trước, chúng ta đã nói về các tệp .env thuần túy, nhưng chúng ta chưa bao giờ sử dụng các tệp .env có tên. Nếu chúng ta muốn tệp .env của mình có tên, như secret-things.enf, thì Compose có một tùy chọn nhỏ tiện lợi có tên là env_file.

    Tùy chọn này cho phép chúng ta thông báo cho soạn thảo tệp .env mà nó phải tìm kiếm, trái ngược với hành vi mặc định của nó, đó là tìm kiếm tệp .env không tên. Đây là cách chúng ta sử dụng tùy chọn env_file.

    Như bạn có thể thấy, chúng ta đã thêm tùy chọn env_file, tùy chọn này trỏ đến một tệp có tên tệp secret -uff.env. Tất cả những gì còn lại là đổi tên tệp .env trước đó của chúng ta thành secret -uff.env.

    Bạn có thể nhận thấy tùy chọn môi trường không còn xuất hiện trong tệp soạn thư của chúng ta. Điều này là do việc sử dụng tùy chọn env_file làm nảy sinh một vấn đề – một vấn đề khiến tôi khá đau đầu!

    Để gán các giá trị được khai báo trong tệp .env có tên bên ngoài cho các biến soạn yêu cầu tệp đã nói phải được xác định trong dịch vụ soạn chính. Điều này liên quan đến thứ tự mà Soạn tuân theo khi thực hiện các hoạt động. Tuy nhiên, chúng ta không có dịch vụ chính, vì chúng ta chỉ sử dụng một dịch vụ db. Do đó, nếu chúng ta cố gắng triển khai tệp Soạn của mình, nó sẽ phàn nàn rằng các biến của chúng ta không được xác định và thay thế chúng bằng các chuỗi trống.

    Bạn không cần phải nghe lời tôi, hãy tiếp tục và thử nó! Chạy docker-soạn lên và xem điều gì sẽ xảy ra.

    Vì vậy, làm thế nào để chúng ta giải quyết vấn đề này? Đây là những gì tôi đã tìm ra:

    Nếu chúng ta xóa tùy chọn môi trường khỏi tệp soạn, khi triển khai, soạn sẽ tìm kiếm tệp secret -uff.env được chỉ định, điều mà tùy chọn này không thực hiện khi có tùy chọn môi trường. Vấn đề đã được giải quyết!

    Tuy nhiên, hãy nhớ rằng vì chúng ta không còn tùy chọn môi trường nữa, chúng ta phải khai báo các biến môi trường trực tiếp trong tệp secret -uff.env, như sau:

    Một lần nữa, để kiểm tra xem mọi thứ có hoạt động bình thường hay không, hãy chạy: docker-compile up.

    Đây các cách khác nhau để xử lý an toàn với các biến môi trường trong soạn tệp. Cảm ơn đã theo dõi.

    Author: DuongVT19

  • Cloud Architect

    Ngày càng có nhiều công ty nghe thấy tiếng còi báo động của đám mây. Với chi phí khởi động thấp và dễ dàng thiết lập cơ sở hạ tầng, tại sao lại không?

    Nhưng khả năng loại bỏ phần cứng tại chỗ để chuyển sang sử dụng đám mây – nơi người khác phải tham gia vào việc bảo trì và cập nhật máy chủ – vẫn đòi hỏi các chuyên gia có thể làm cho mọi thứ hoạt động trơn tru.

    Chính xác thì kiến trúc sư đám mây là gì?

    “Khi bạn nghĩ về một kiến ​​trúc sư, bạn sẽ nghĩ đến một người nào đó thiết kế các tòa nhà và lên kế hoạch xây dựng chúng như thế nào; Meg Yahl, kỹ sư đám mây tại Uncomn, một công ty dịch vụ tư vấn công nghệ và quản lý doanh nghiệp cho biết.

    Cụ thể hơn, một kiến ​​trúc sư đám mây giúp một công ty phát triển, thực hiện và duy trì chiến lược điện toán đám mây của mình. Họ cần có hiểu biết sâu sắc về nhu cầu, ràng buộc, quy định ngành và mục tiêu của công ty họ vì nó liên quan đến điện toán đám mây.

    Susanne Tedrick, chuyên gia cơ sở hạ tầng đám mây tại Nền tảng điện toán đám mây Azure của Microsoft và trước đây là chuyên viên kỹ thuật tại IBM Cloud. Mặc dù bản thân không phải là kiến ​​trúc sư đám mây, Tedrick hợp tác chặt chẽ với các kiến ​​trúc sư đám mây trong quá trình giúp khách hàng sử dụng và di chuyển đám mây.

    Cô nói thêm rằng vai trò của kiến trúc sư đám mây đòi hỏi kiến thức kỹ thuật rất sâu về điện toán đám mây và các lĩnh vực bổ trợ như mạng máy tính, dữ liệu và bảo mật.

    Một số tiêu đề thường trùng lặp hoặc được coi là có thể hoán đổi cho nhau với các kiến trúc sư đám mây. Chúng bao gồm các kỹ sư đám mây và kiến trúc sư giải pháp trong các công ty hoặc phòng ban cụ thể về đám mây. Ví dụ: mặc dù chức danh của Yahl là kỹ sư đám mây – với các kỹ sư đám mây có xu hướng là những người thực hiện các thiết kế và kế hoạch do kiến trúc sư đám mây phát triển – cô ấy thường xuyên thực hiện cả các công việc dành riêng cho kỹ sư và kiến trúc sư.

    Tedrick ghi nhận phần lớn các biến thể tiêu đề và sự trùng lặp trong vai trò kiến trúc sư đám mây đối với sự phát triển nhanh chóng của nó khi việc áp dụng đám mây ngày càng phát triển.

    Bà nói: “Đặc biệt khi có những chuyên ngành phụ trong lĩnh vực này, các công ty sẽ thường kết hợp vai trò kiến trúc sư với trách nhiệm kỹ sư hoặc kỹ thuật viên.

    Không chỉ tương tác với đám mây

    Nói chung, trải nghiệm hàng ngày của kiến ​​trúc sư đám mây sẽ xoay quanh việc xác định, đáp ứng và thực hiện nhu cầu đám mây của công ty hoặc khách hàng, Tedrick nói. Điều này có thể có nghĩa là dẫn đầu các cuộc thảo luận chuyên sâu về kỹ thuật, xác nhận rằng giải pháp đám mây sẽ đáp ứng các yêu cầu của công ty hoặc xác định các cách giải quyết tiềm năng, phát triển sơ đồ kiến ​​trúc và giúp phát triển bằng chứng về công nghệ và bằng chứng về khái niệm cho khách hàng. Đôi khi, nó cũng có thể liên quan đến việc cung cấp sản phẩm chung và giáo dục điện toán đám mây.

    Đối với Frank Dagenhardt – kiến ​​trúc sư giải pháp cho Zscaler, một công ty bảo mật thông tin dựa trên đám mây – giáo dục những người khác về đám mây là một tính năng thường xuyên trong những ngày của ông. Điều này có thể liên quan đến việc viết sách trắng và bài đăng trên blog, hoặc tổ chức hội thảo trên web của nhóm người dùng trong ngành. Và các nỗ lực giảng dạy có thể hướng đến đối tượng nội bộ như nhân viên của Zscaler hoặc đối tác hoặc khách hàng bên ngoài.

    “Chúng tôi làm việc dựa trên sự hỗ trợ cho các nhóm nội bộ của chúng tôi và các đối tác của chúng tôi mà chúng tôi làm việc cùng – đảm bảo rằng họ hiểu các giải pháp, biết cách chúng hoạt động, những loại giải pháp khác nhau mà chúng tôi có thể giúp khách hàng và cách họ sẽ giúp khách hàng, ” Anh nói.

    Gặp gỡ khách hàng cũng là một phần chính trong các ngày của Dagenhardt. Anh và nhóm của mình thảo luận với khách hàng về nhu cầu của họ và cách đạt được những nhu cầu đó một cách tốt nhất. Các cuộc họp này thường tạo ra các ý tưởng để cải tiến các sản phẩm và dịch vụ của Zscaler, thông qua yêu cầu của khách hàng hoặc nhóm xác định các tính năng chung có thể phục vụ khách hàng tốt hơn.

    Dagenhardt cho biết: “Nếu có những khoảng trống về tính năng mà chúng tôi có thể mắc phải hoặc những thứ mà khách hàng đang tìm kiếm mà chúng tôi không giải quyết ngay hôm nay, thì chúng tôi có thể tiếp tục và đưa ra những đề xuất đó”.

    Việc chuyển đổi giữa giao tiếp với khách hàng và các nhóm kinh doanh kỹ thuật nội bộ đòi hỏi các kiến ​​trúc sư đám mây phải có kỹ năng giao tiếp mạnh mẽ. Vì kiến ​​trúc sư đám mây làm việc trên cơ sở hạ tầng kỹ thuật số cho phép một công ty hoạt động, họ có cơ hội tương tác và dẫn dắt các cuộc thảo luận kỹ thuật với nhiều đối tượng khác nhau như nhà phát triển, kỹ sư mạng, nhà quản lý, v.v.

    Đối với Yahl, công việc cơ sở hạ tầng là thứ chi phối cuộc sống của cô gần đây. Tại Uncomn, cô ấy đã tìm hiểu khá nhiều về cơ sở hạ tầng mạng và cách triển khai nó. Nhưng rất nhiều việc cô ấy đang làm gần đây đặc biệt liên quan đến rất nhiều cơ sở hạ tầng dưới dạng mã. Điều này giúp tăng tính nhất quán trong toàn công ty và giảm cơ hội mắc lỗi của con người.

    “Bạn muốn đảm bảo rằng nếu bạn cần tạo ra một ngăn xếp khác, một tập hợp máy chủ khác và tất cả những thứ đi kèm với nó, bạn muốn đảm bảo rằng bạn luôn làm theo cùng một cách,” cô nói.

    Học tập là một phần của thói quen hàng ngày

    Đó là kinh nghiệm phổ biến đối với các kiến ​​trúc sư đám mây.

    Yahl nói: “Cánh đồng khác nhau mỗi ngày. “Đó là một trong những điều mà nếu bạn không phấn đấu học hỏi, thì bạn sẽ bị tụt lại phía sau”.

    Dagenhardt cho biết tốc độ phát triển nhanh chóng của công nghệ đám mây là một trong những điều khiến anh ấy thức đêm. Ông chỉ ra rằng AWS đã mở rộng cung cấp của mình lên hơn 200 dịch vụ vào tháng 9. Và đó chỉ là một nhà cung cấp.

    Luôn cập nhật các tùy chọn, cách khách hàng có thể tận dụng các công nghệ mới và các phương pháp hay nhất có thể giúp bảo mật chúng, tất cả đều yêu cầu học hỏi liên tục. Đối với Dagenhardt, việc duy trì các chứng chỉ và học hỏi những điều mới khiến anh ấy cảm thấy mình luôn đứng đầu cuộc chơi.

    “Đó luôn là điều đã giúp ích cho tôi – dành một chút thời gian của tôi cho sự thăng tiến và cải thiện cá nhân,” anh nói.

    Yahl cũng nói về tầm quan trọng của việc tiếp tục học tập và các chứng chỉ của bạn, nhưng cô ấy cũng nhấn mạnh giá trị của việc học hỏi từ những người bạn làm việc cùng.

    “Các bạn học hỏi lẫn nhau, đặc biệt là các phím tắt hoặc công cụ giúp cuộc sống dễ dàng hơn,” cô nói, đồng thời đưa Visual Studio Code và ShellCheck làm ví dụ về các nguồn mà cô học được từ đồng nghiệp.

    Nhưng cô ấy nói rằng không chỉ đơn thuần là chọn những công cụ hữu ích có thể giúp một ngày trở nên dễ dàng hơn. Ngoài ra còn có yếu tố hợp tác là có được những quan điểm khác nhau về cách sử dụng hoặc triển khai các công nghệ khác nhau.

    “Khi bạn đang làm việc một mình, bạn đang ở trong khoảng trống và bạn không có ai để xem mã của mình, không ai để đảm bảo rằng bạn đang tuân thủ các phương pháp hay nhất tốt nhất có thể hoặc biết về những cách làm mới và đang phát triển Yahl nói.

    Trong những tình huống mà một kiến ​​trúc sư đám mây có thể không có đồng nghiệp để học hỏi từ đó, Yahl đề xuất những địa điểm như Reddit, nơi những người khác trong cộng đồng công nghệ đến để đặt câu hỏi cho nhau về các tài nguyên tốt nhất cho các tình huống khác nhau.

    “Về cơ bản, bạn có một danh sách những thứ mà mọi người sẽ giới thiệu và sau đó bạn nhận được quan điểm của người khác về những điều tốt và xấu về những công cụ đó và có một cuộc trò chuyện diễn ra liên tục,” cô nói. “Vì vậy, ngay cả khi bạn không có đồng nghiệp hướng dẫn, bạn vẫn có thể nhìn thấy nhiều quan điểm đó.”

    Mối quan tâm về bảo mật trong lĩnh vực đa đám mây, phát triển nhanh

    Hiểu và có thể làm việc trên nhiều nền tảng là nhu cầu ngày càng tăng đối với các kiến ​​trúc sư đám mây. Dagenhardt khuyên những người sẽ là kiến ​​trúc sư đám mây nên có sự kết hợp giữa các quan điểm khi nói đến nền tảng đám mây vì đó là nơi anh ấy nhìn thấy tương lai của lĩnh vực này.

    “Những gì chúng tôi đã thấy trong ngành công nghiệp đám mây là, trong khi hầu hết khách hàng bắt đầu từ một nhà cung cấp đám mây duy nhất, theo thời gian, họ trở thành một môi trường đa đám mây, nơi họ lưu trữ một số tài nguyên của mình trong một hoặc nhiều đám mây,” ông nói. Ông cũng nói rằng ông đang thấy sự thay đổi ngày càng tăng từ cơ sở hạ tầng như một dịch vụ sang các thùng chứa hoặc thậm chí là các công nghệ không máy chủ.

    Theo Tedrick, xu hướng đa dạng hóa đám mây này, các chiến lược và các yếu tố dựa trên đám mây khác như “cuộc chiến điện toán đám mây lớn hơn giữa AWS, Google và Microsoft” sẽ khiến vai trò kiến ​​trúc sư đám mây trở nên thịnh hành. Điều này có nghĩa là các nhà tuyển dụng đang tìm kiếm kiến ​​trúc sư đám mây sẽ muốn biết các kiến ​​trúc sư có kinh nghiệm thực hành về nền tảng đám mây nào.

    Bảo mật trong môi trường ngày càng mở rộng và không có kỹ thuật này đang và sẽ tiếp tục là mối quan tâm của những người làm việc với đám mây.

    Yahl nói: “Chúng tôi sẽ có những tính toán trong thế giới an ninh, đó là điều chắc chắn. “Có rất nhiều người muốn tham gia vào lĩnh vực này và họ học những kiến ​​thức cơ bản của họ, nhưng họ không học được sự bảo mật đằng sau nó.”

    Điều này một phần là do tốc độ của trường đám mây vượt xa khả năng của hầu hết các nền giáo dục chính quy trong việc cập nhật đào tạo về bảo mật, nhưng cũng bởi vì đám mây, theo Yahl, “rào cản gia nhập thấp nhất đối với bất kỳ ai cần thiết lập cơ sở hạ tầng của họ. ”

    Bà nói: “Đám mây rất tuyệt vời để quay các máy chủ và cơ sở hạ tầng và tất cả điều đó thực sự, rất nhanh chóng và thực sự dễ dàng,” cô nói, đồng thời cho biết thêm rằng nhiều giá trị mặc định trong môi trường đám mây có thể không an toàn. “Đám mây là một cách để thiết lập và chạy rất nhanh nhưng bạn cũng phải bảo mật nó.”

    Tốc độ tiến bộ của công nghệ đám mây cũng khiến Dagenhardt đặt ra các câu hỏi bảo mật về tương lai.

    Ông nói: “Chúng tôi vẫn có công nghệ cũ hơn và kế thừa hơn mà chúng tôi phải có khả năng xử lý và thích ứng. “Làm cách nào để chúng ta bảo vệ môi trường truyền thống cũng như bảo vệ môi trường đám mây và đảm bảo rằng nó có thể quản lý được và không tạo ra gấp đôi công việc cho khách hàng?”

    Làm thế nào để trở thành một kiến trúc sư đám mây

    Nếu không ngừng học hỏi và thích ứng với nhu cầu thay đổi của khách hàng và cảnh quan đám mây đang phát triển nghe có vẻ hấp dẫn, thì có một số lời khuyên cần ghi nhớ. Tedrick cho biết: Đứng đầu trong số đó là các kiến ​​trúc sư đám mây phải biết và hiểu rõ về điện toán đám mây ngoài những điều cơ bản.

    “Họ sẽ cần hiểu các phương pháp hay nhất về bảo mật đám mây doanh nghiệp, quản trị, tối ưu hóa chi phí, kiến ​​trúc đám mây kết hợp – sử dụng môi trường đám mây và tại chỗ – và kiến ​​trúc đa đám mây – sử dụng hai hoặc nhiều đám mây”, cô nói. “Trải nghiệm thực tế trên nền tảng đám mây nơi họ đang tạo và giám sát tài nguyên là điều bắt buộc, ưu tiên một năm kinh nghiệm trở lên.”

    Đối với những người không có cơ hội làm việc trên đám mây tại chỗ, Tedrick đã đề xuất các nền tảng bài học trực tuyến như A Cloud Guru và Pluralsight để cung cấp cho người dùng trải nghiệm thực tế với các nền tảng đám mây khác nhau.

    Khi đề cập đến việc ứng tuyển vai trò kiến ​​trúc sư đám mây, Yahl cho biết những người tìm việc không nên nản lòng nếu một bài đăng bao gồm các yêu cầu bạn không có hoặc liên quan đến các nhiệm vụ bạn không quen thuộc. Cô cũng chỉ ra rằng các tin tuyển dụng đôi khi không được viết bởi các chuyên gia kỹ thuật và yêu cầu những điều không thể. Đây có thể là một cái gì đó giống như yêu cầu nhiều năm kinh nghiệm trong một sản phẩm hơn nó đã tồn tại.

    “Nếu bạn đang muốn dấn thân vào lĩnh vực này, đừng để điều gì khiến bạn sợ hãi về vị trí mà bạn có hầu hết các kỹ năng,” cô khuyên.

    Yahl cũng khuyến khích những người muốn tham gia vào lĩnh vực kiến ​​trúc đám mây để thể hiện kỹ năng của họ và thực tế là họ đã phát triển và thay đổi trong những năm qua. Cô ấy chỉ ra Github hoặc các nền tảng khác nơi người dùng có thể lưu trữ mã là những nơi tuyệt vời để tạo danh mục đầu tư mã hóa.

    Chứng chỉ rất quan trọng đối với các kiến ​​trúc sư đám mây tiềm năng. Đây có thể là nhà cung cấp cụ thể và nhà cung cấp bất khả tri. Các chứng nhận tổng quát hơn có thể hữu ích cho thông tin chung và các phương pháp hay nhất về đám mây, nhưng theo Dagenhardt, các chứng chỉ dành riêng cho nhà cung cấp thường hữu ích hơn vì chúng sẽ giải quyết các sản phẩm đám mây cụ thể và các phương pháp hay nhất của chúng.

    Tedrick cũng chỉ ra rằng các chứng chỉ của các nhà cung cấp chính – Microsoft, AWS, Google và IBM – có nhiều khả năng được các nhà tuyển dụng tiềm năng công nhận hơn.

    Nhưng cô ấy nhấn mạnh rằng “mục tiêu phải là đạt được kỹ năng và kinh nghiệm thay vì đạt được chứng chỉ, vì chứng chỉ sẽ chỉ giúp bạn có được cho đến nay, và các kiến ​​trúc sư vĩ đại được sinh ra từ thử thách, sai lầm và thời gian.”

    Cảm ơn mọi người đã theo dõi. Author: DuongVT19.

  • Giới thiệu FaunaDB

    FaunaDB là một lớp khác biệt với hầu hết các cơ sở dữ liệu xung quanh. Nó cung cấp tính linh hoạt và khả năng mở rộng đáng kinh ngạc. Vì FaunaDB không có máy chủ nên bạn có thể kết nối với cơ sở dữ liệu và sử dụng nó mà không cần lo lắng về bất kỳ điều gì khác.

    Bạn có thể sử dụng FaunaDB làm cơ sở dữ liệu OLTP (xử lý giao dịch trực tuyến) với ACID phân tán (tính nguyên tử, tính nhất quán, tính cách ly, độ bền), làm cơ sở dữ liệu tài liệu hoặc thậm chí là NoSQL dựa trên khóa-giá trị đơn giản. Nó cũng bao gồm hỗ trợ cho các tính năng doanh nghiệp như lưu giữ dữ liệu có thể định cấu hình và cho thuê nhiều lần theo thứ bậc.

    Quan trọng là, FaunaDB không ràng buộc bạn với đám mây. Nó có sẵn dưới dạng dịch vụ đám mây được quản lý hoặc JAR có thể tải xuống, hình ảnh máy hoặc vùng chứa mà bạn có thể chạy tại chỗ.

    Chức năng của FaunaDB

    FaunaDB cung cấp tính linh hoạt cao, cho phép bạn tinh chỉnh một số thông số dựa trên các yêu cầu của dự án của bạn. Chúng ta có thể sử dụng FaunaDB làm cơ sở dữ liệu quan hệ truyền thống, cơ sở dữ liệu khóa-giá trị, dựa trên tài liệu hoặc đồ thị. Chúng ta có thể thực thi một lược đồ trên dữ liệu hoặc chỉ để nó lỏng lẻo.

    FaunaDB là cực kỳ linh hoạt. Chúng ta có thể chạy FaunaDB trên đám mây (dưới dạng cơ sở dữ liệu không máy chủ với cấp miễn phí phong phú), tại cơ sở hoặc dưới dạng cơ sở dữ liệu nhúng, ngay bên trong ứng dụng của chúng ta. Cùng với những điểm cực đoan này, nó cũng cung cấp các hình thức triển khai phổ biến nhất như hình ảnh máy và hình ảnh docker.

    Tất cả điều này đi kèm với các giao dịch ACID và hiệu suất rất cao – mọi thứ mà một kiến trúc sư muốn cho một ứng dụng.

    Fauna Console

    Mặc dù Fauna cung cấp một trình bao lệnh thanh lịch cho đám mây DB (cơ sở dữ liệu), chúng ta hãy bắt đầu với bảng điều khiển web, đây là cách dễ dàng nhất để tham gia.

    Sau khi đăng ký, bạn sẽ thấy trang tổng quan giống như sau:

    Tạo cơ sở dữ liệu

    Để tạo cơ sở dữ liệu, bạn sẽ bắt đầu bằng cách nhấp vào Cơ sở dữ liệu mới (khá trực quan!). Sau khi bạn cung cấp tên DB, bạn đã hoàn tất; bây giờ bạn có một phiên bản DB mới cho ứng dụng của bạn. Nếu bạn chỉ muốn thực hành, bạn có thể chọn tùy chọn điền dữ liệu giả vào DB hoặc bạn có thể thêm dữ liệu của riêng mình.

    Với điều đó, bạn có một phiên bản cơ sở dữ liệu sạch.

    Tạo Collection.

    Tất nhiên, bước tiếp theo là tạo một bộ sưu tập. Fauna cung cấp một số lựa chọn khi chúng ta tạo một collection mới.

    Trang tạo collection trông giống như sau:

    Cùng với tên bộ sưu tập, chúng ta có hai tùy chọn. Ngày lịch sử và TTL (Thời gian tồn tại) cho mỗi bản ghi. Ngày lịch sử là số ngày Fauna sẽ lưu lại lịch sử của tài liệu (trong trường hợp bạn muốn hoàn tác thay đổi). Nếu chúng ta dọn sạch lĩnh vực này, lịch sử sẽ được lưu giữ mãi mãi. Đương nhiên, dữ liệu lịch sử cũng là dữ liệu được tính phí trên đám mây, vì vậy bạn phải cẩn thận khi chọn số này.

    TTL xác định số ngày mà một tài liệu chưa được chỉnh sửa ở lại trong bộ sưu tập sau lần viết cuối cùng. Việc đặt giá trị hợp lý cho TTL khá hữu ích vì nó có thể giúp giảm chi phí.

    Cuối cùng, chúng ta nhấn lưu và – bùng nổ – bạn đã tạo một bộ sưu tập mới. Bây giờ bạn sẽ thấy một giao diện người dùng sạch để thêm tài liệu mới vào bộ sưu tập.

    Tạo Document

    Nhấp vào nút đó sẽ hiển thị cho chúng ta một hộp văn bản nơi chúng ta có thể nhập JSON cho tài liệu mới mà chúng ta muốn thêm vào bộ sưu tập của mình.

    Bảng điều khiển cũng cung cấp một số tùy chọn khác để tạo chỉ mục, chức năng tùy chỉnh, thêm lược đồ GraphQL và cũng để tạo khóa bảo mật để truy cập cơ sở dữ liệu.

    Nếu bạn cảm thấy nhàm chán với giao diện người dùng, bảng điều khiển sẽ cung cấp liên kết để mở giao diện người dùng. Tại đây, chúng ta có thể gõ các lệnh cần thiết để làm việc với cơ sở dữ liệu. Trên thực tế, Fauna cũng cho phép chúng ta mở một trình bao trên thiết bị đầu cuối cục bộ của chúng ta để có thể tương tác với cơ sở dữ liệu. Hãy cùng kiểm tra nào.

    Fauna Shell

    Bất kỳ ai nghiêm túc về việc xây dựng các ứng dụng trong thế giới thực đều nên bỏ bảng điều khiển web và quay lại màn hình đen. Đó là cách tốt nhất để phát triển. Fauna cung cấp một CLI (giao diện dòng lệnh) rất tốt và một shell dựa trên NodeJS để giao tiếp với ứng dụng trên đám mây.

    Hãy bắt đầu với việc cài đặt. Nếu bạn đã hiểu được điều này, ta khá chắc chắn rằng bạn biết cách cài đặt NodeJS và npm (nếu chúng chưa được cài đặt). Vì vậy, hãy bắt đầu sau thời điểm đó. Chúng ta phải cài đặt Fauna shell bằng npm.

     Npm tập hợp tất cả những gì bạn cần để chạy Fauna shell và thiết lập nó.

    Tiếp theo, chúng ta đăng nhập vào tài khoản đám mây Fauna của mình.

    Điều này yêu cầu email và mật khẩu mà chúng ta đã sử dụng để đăng ký. Nó cũng có một tùy chọn để đăng nhập bằng một chìa khóa.

    QUERY DOCUMENTS

    Bây giờ, hãy thử tìm nạp các bản ghi từ bộ sưu tập. Có hai cách để truy vấn dữ liệu này. Bạn có thể sử dụng ID hoặc chỉ mục.

    Lưu ý trong các hoạt động tạo ở trên, chúng ta có một số – 270925464408687111 – trong xác nhận. Bạn có thể sử dụng điều này để truy vấn bản ghi.

    Điều này trả về bản ghi mà chúng ta vừa chèn.

    Tất nhiên, đây là một cách nhàm chán để truy vấn dữ liệu. Tại sao chúng ta tạo chỉ mục? Hãy sử dụng chỉ mục đó để truy vấn bản ghi được yêu cầu.

    Chúng ta có thể truy vấn cùng một bản ghi bằng cách sử dụng chỉ mục trên tiêu đề mà chúng ta đã tạo ở trên.

    Nó trả về cùng một bản ghi.

    Đó chỉ là một cái nhìn thoáng qua về những gì chúng ta có thể làm với bảng điều khiển web và shell. Fauna có tài liệu rất tốt. Bạn có thể xem Sách dạy nấu ăn trên trang web của họ để có một bộ sưu tập tốt các đoạn mã cho các trường hợp sử dụng khác nhau.

    Cảm ơn mọi người đã theo dõi.

    Author: DuongVT19

  • Chu trình phát triển phần mềm: Mô hình Waterfall (SDLC- Waterfall Model)

    Tổng quan:

    Mô hình Waterfall là mô hình vòng đời tuần tự tuyến tính. Nó rất đơn giản để hiểu và sử dụng. Trong mô hình Waterfall, mỗi giai đoạn phải được hoàn thành trước khi giai đoạn tiếp theo có thể bắt đầu và không có sự chồng chéo trong các giai đoạn.

    Mô hình Waterfall là cách tiếp cận SDLC (chu trình phát triền phần mêm) sớm nhất được sử dụng để phát triển phần mềm.

    Mô hình Waterfall minh họa quá trình phát triển phần mềm theo một dòng tuần tự tuyến tính. Điều này có nghĩa là bất kỳ giai đoạn nào trong quá trình phát triển chỉ bắt đầu nếu giai đoạn trước đó hoàn thành. Trong mô hình Waterfall này, các pha không chồng lên nhau.

    Thiết kế Waterfall Model

    Phương pháp tiếp cận mô hình Waterfall là Mô hình SDLC đầu tiên được sử dụng rộng rãi trong kỹ thuật phần mềm để đảm bảo sự thành công của dự án. Trong cách tiếp cận “The Waterfall”, toàn bộ quá trình phát triển phần mềm được chia thành các giai đoạn riêng biệt. Trong mô hình Waterfall này, thông thường, kết quả của một giai đoạn đóng vai trò là đầu vào cho giai đoạn tiếp theo một cách tuần tự.

    Hình minh họa sau đây là đại diện cho các giai đoạn khác nhau của Mô hình Waterfall.

    Các giai đoạn tuần tự trong mô hình Waterfall là:

    • Thu thập và phân tích yêu cầu (Requirement Gathering and analysis): Tất cả các yêu cầu có thể có của hệ thống được phát triển đều được ghi lại trong giai đoạn này và được ghi lại trong tài liệu đặc tả yêu cầu.
    • Thiết kế hệ thống (System Design): Các thông số kỹ thuật yêu cầu từ giai đoạn đầu tiên được nghiên cứu trong giai đoạn này và thiết kế hệ thống đã được chuẩn bị. Thiết kế hệ thống này giúp xác định các yêu cầu phần cứng và hệ thống cũng như giúp xác định kiến trúc hệ thống tổng thể.
    • Thực hiện (Implementation): Với đầu vào từ thiết kế hệ thống, hệ thống được phát triển đầu tiên trong các chương trình nhỏ được gọi là các đơn vị, được tích hợp trong giai đoạn tiếp theo. Mỗi đơn vị được phát triển và kiểm tra chức năng của nó, được gọi là Kiểm thử đơn vị (Unit test).
    • Tích hợp và Kiểm tra (Integration and Testing) Tất cả các đơn vị được phát triển trong giai đoạn triển khai được tích hợp vào một hệ thống sau khi thử nghiệm của từng đơn vị. Sau khi tích hợp, toàn bộ hệ thống được kiểm tra xem có bất kỳ lỗi và hỏng hóc nào không.
    • Triển khai hệ thống (Deployment of system) Sau khi kiểm tra chức năng và phi chức năng được thực hiện; sản phẩm được triển khai trong môi trường khách hàng hoặc được tung ra thị trường.
    • Bảo trì (Maintenance) Có một số vấn đề xảy ra trong môi trường khách hàng. Để khắc phục những vấn đề đó, các bản vá được phát hành. Ngoài ra để nâng cao sản phẩm một số phiên bản tốt hơn được phát hành. Bảo trì được thực hiện để mang lại những thay đổi này trong môi trường khách hàng.

    Tất cả các giai đoạn này được xếp tầng với nhau, trong đó tiến trình được xem như chảy đều đặn xuống dưới (giống như Waterfall) qua các giai đoạn. Giai đoạn tiếp theo chỉ được bắt đầu sau khi đạt được tập hợp mục tiêu đã xác định cho giai đoạn trước và nó được ký kết, vì vậy có tên “Mô hình Waterfall”. Trong mô hình này, các giai đoạn không chồng chéo lên nhau.

    Ứng dụng mô hình Waterfall.

    Mỗi phần mềm được phát triển đều khác nhau và đòi hỏi phải tuân theo một cách tiếp cận SDLC phù hợp dựa trên các yếu tố bên trong và bên ngoài. Một số tình huống mà việc sử dụng mô hình Waterfall là thích hợp nhất:

    • Các yêu cầu được ghi chép rất đầy đủ, rõ ràng và cố định.
    • Định nghĩa sản phẩm là ổn định.
    • Công nghệ được hiểu và không phải là năng động.
    • Không có yêu cầu mơ hồ.
    • Có sẵn các nguồn lực dồi dào với kiến thức chuyên môn cần thiết để hỗ trợ sản phẩm.
    • Dự án ngắn hạn.

    Ưu điểm của mô hình Waterfall.

    Ưu điểm của phát triển mô hình Waterfall là nó cho phép phân thành các phần và dễ dàng kiểm soát. Một lịch trình có thể được thiết lập với thời hạn cho từng giai đoạn phát triển và một sản phẩm có thể tiến hành từng giai đoạn của mô hình quy trình phát triển.

    Sự phát triển di chuyển từ khái niệm, thông qua thiết kế, thực hiện, thử nghiệm, cài đặt, khắc phục sự cố và kết thúc ở vận hành và bảo trì. Mỗi giai đoạn phát triển diễn ra theo thứ tự nghiêm ngặt.

    Một số ưu điểm chính của Mô hình Waterfall như sau:

    • Đơn giản và dễ để hiểu và sử dụng
    • Dễ dàng quản lý do độ cứng của mô hình. Mỗi giai đoạn có các phân phối cụ thể và một quy trình xem xét.
    • Các giai đoạn được xử lý và hoàn thành cùng một lúc.
    • Hoạt động tốt cho các dự án nhỏ hơn, nơi các yêu cầu được hiểu rất rõ.
    • Các giai đoạn được xác định rõ ràng.
    • Các mốc quan trọng được hiểu rõ.
    • Dễ dàng sắp xếp các công việc.
    • Quá trình và kết quả được ghi lại đầy đủ.

    Nhược điểm của mô hình Waterfall.

    Nhược điểm của phát triển Waterfall là nó không cho phép phản ánh hoặc sửa đổi nhiều. Một khi ứng dụng đang trong giai đoạn thử nghiệm, rất khó để quay lại và thay đổi điều gì đó không được ghi chép đầy đủ hoặc được nghĩ đến trong giai đoạn khái niệm.

    Những nhược điểm chính của Mô hình Waterfall như sau:

    • Không có phần mềm đang hoạt động nào được sản xuất cho đến cuối vòng đời.
    • Lượng rủi ro cao và không chắc chắn.
    • Không phải là một mô hình tốt cho các dự án hướng đối tượng và phức tạp.
    • Mô hình kém cho các dự án dài và đang diễn ra.
    • Không phù hợp với các dự án mà các yêu cầu có nguy cơ thay đổi từ trung bình đến cao. Vì vậy, rủi ro và sự không chắc chắn là cao với mô hình quy trình này.
    • Rất khó để đo lường sự tiến bộ trong các giai đoạn.
    • Không thể đáp ứng các yêu cầu thay đổi.
    • Điều chỉnh phạm vi trong vòng đời có thể kết thúc một dự án.
    • Việc tích hợp được thực hiện như một “vụ nổ lớn ở giai đoạn cuối, điều này không cho phép xác định sớm bất kỳ điểm nghẽn hoặc thách thức nào về công nghệ hoặc kinh doanh.

    Cảm ơn mọi người đã theo dõi.

    Author: DuongVT19

  • JSON vs YAML: A Dive Into 2 Popular Data Serialization Languages

    Bất kỳ người nào quan tâm đến lập trình và công nghệ đều biết JSON là gì. YAML không phổ biến như JSON, nhưng nó cũng là một ngôn ngữ tuần tự hóa dữ liệu phổ biến và tuyệt vời. Ví dụ, bất kỳ người nào đã sử dụng Docker chắc chắn biết YAML là gì.

    Trước hết, hãy xem tuần tự hóa dữ liệu nghĩa là gì. Theo Devopedia, tuần tự hóa dữ liệu là quá trình chuyển đổi các đối tượng dữ liệu có trong cấu trúc dữ liệu phức tạp thành một luồng byte cho các mục đích lưu trữ, truyền và phân phối trên các thiết bị vật lý. Vì vậy, JSON và YAML đều là một cách lưu trữ các đối tượng và cấu trúc dữ liệu trong tệp.

    JSON là gì?

    Mặc dù hầu hết chúng ta đều biết JSON là gì, nhưng chúng ta hãy giới thiệu nhanh. JSON là tên viết tắt của JavaScript Object Notation. JSON dựa trên một tập con của tiêu chuẩn ngôn ngữ lập trình JavaScript ECMA-262 3rd Edition-December 1999. JSON được sử dụng rộng rãi với JavaScript nhưng vì nó không phụ thuộc vào ngôn ngữ nên nó có thể được sử dụng với bất kỳ ngôn ngữ lập trình nào.

    JSON có một định dạng tiêu chuẩn để lưu trữ dữ liệu. Nó lưu trữ dữ liệu trong các cặp khóa / giá trị. Các bản ghi được phân tách bằng dấu phẩy và cả tên trường và chuỗi đều được đặt trong dấu ngoặc kép.

    YAML là gì?

    YAML là tên viết tắt của YAML Ain’t Markup Language. Và YAML Ain’t Markup Language là tên viết tắt của YAML Ain’t Markup Language Ain’t Markup Language. Khá tuyệt, phải không? Để làm cho mọi thứ thú vị hơn, trang web chính thức của YAML cũng được hiển thị ở định dạng YAML.

    YAML sử dụng ba dấu gạch ngang (—) để biểu thị phần bắt đầu của tài liệu và ba dấu chấm (…) để biểu thị phần cuối của tài liệu. Không giống như JSON, YAML sử dụng thụt lề giống như trong Python để hiển thị các cấp trong dữ liệu. Các cặp khóa / giá trị được phân tách bằng dấu hai chấm và danh sách bắt đầu bằng dấu gạch ngang trong YAML. Và các tệp YAML cũng được viết với phần mở rộng YML ở một số nơi và cả .YAML và .YML đều có nghĩa là cùng một loại tệp.

    Pros and Cons: JSON vs. YAML

    Về mặt lý thuyết, cả JSON và YAML đều sẽ thực hiện cùng một nhiệm vụ, tức là cung cấp định dạng trao đổi dữ liệu có thể đọc được của người dùng.

    Khả năng đọc và tính linh hoạt

    Mục tiêu thiết kế của JSON là càng đơn giản càng tốt và có thể sử dụng được trên toàn cầu. Điều này đã làm giảm khả năng đọc của dữ liệu ở một mức độ nào đó. Ngược lại, mục tiêu thiết kế của YAML là cung cấp một định dạng tốt mà con người có thể đọc được và cung cấp hỗ trợ cho việc tuần tự hóa các cấu trúc dữ liệu gốc tùy ý. Điều này đã làm tăng khả năng đọc của các tệp YAML, nhưng nó đã làm cho việc phân tích cú pháp và tạo tệp hơi phức tạp. Chúng ta có thể thấy rõ điều này trong trang web chính thức của YAML, nơi nó hiển thị nội dung ở định dạng YAML: Bất kỳ ai truy cập trang web cũng có thể dễ dàng đọc được. Mặt khác, nếu nó được hiển thị ở định dạng JSON, trang web sẽ vô dụng.

    Người ta nói rằng YAML là một tập siêu định dạng JSON. Điều này có nghĩa đơn giản là chúng ta có thể phân tích cú pháp JSON bằng trình phân tích cú pháp YAML. Tuy nhiên, trong các tình huống thực tế, việc phân tích cú pháp này có thể gây ra vấn đề, nhưng về mặt lý thuyết thì hoàn toàn có thể.

    Hiệu suất tuần hoàn

    Trong cuộc thi tuần tự hóa dữ liệu, JSON là người chiến thắng vì khả năng phân tích cú pháp dữ liệu được tuần tự hóa JSON một cách nhanh chóng và dễ dàng với thiết kế đơn giản hơn. Và điều này đã làm cho JSON phổ biến hơn trong số các nhà phát triển, dẫn đến ngày càng có nhiều hỗ trợ gốc hơn và điều này đã cải thiện hiệu suất một lần nữa. Do đó JSON đã trở thành định dạng trao đổi dữ liệu được sử dụng rộng rãi nhất cho các ứng dụng web và dịch vụ web.

    Sự hỗ trợ

    Đối với bất kỳ ngôn ngữ lập trình nào, chúng ta có thể dễ dàng tìm thấy một thư viện JSON được tích hợp với ngôn ngữ này do tính phổ biến, dễ thực hiện và đơn giản của nó. Trang web chính thức của JSON liệt kê nhiều ngôn ngữ với nhiều thư viện hỗ trợ cho JSON. YAML cũng được hỗ trợ rộng rãi và nhiều thư viện để tích hợp nó với nhiều ngôn ngữ khác nhau, nhưng không nhiều như JSON. Bạn có thể lấy danh sách các thư viện và ngôn ngữ hỗ trợ YAML tại đây.

    Khả năng bình luận

    Cho đến nay, chúng ta đã thảo luận về những ưu điểm của JSON so với YAML. Nhưng một số tính năng quan trọng đáng kể của YAML không được tìm thấy với JSON. YAML hỗ trợ nhận xét mà JSON không hỗ trợ. Chúng ta có thể nhận xét ở bất kỳ đâu trong tài liệu bằng ký tự # đơn giản. Điều này đã được chứng minh là có lợi khi viết các tệp cấu hình nơi một nhà phát triển có thể dễ dàng mô tả cấu hình bằng cách sử dụng các nhận xét. Do đó, định dạng YAML được sử dụng trong nhiều ngăn xếp công nghệ như ElasticSearch và Docker để lưu trữ thông tin cấu hình.

    Khả năng sử dụng các cấu trúc phúc tạp

    Một tính năng khác mà YAML cung cấp là khả năng tham chiếu đến các đối tượng dữ liệu khác. Với tham chiếu này, có thể ghi dữ liệu đệ quy trong tệp YAML.

    Đối với điều này, chúng tôi có thể xác định neo trong tệp YAML bằng cách sử dụng & và tham chiếu đến chúng sau này bằng bí danh, *. Đây là một tính năng rất quan trọng trong YAML mà JSON không cung cấp. Trong JSON, không thể tuần tự hóa các cấu trúc phức tạp với các tham chiếu đối tượng. Nhưng tính năng trên trong YAML giải quyết được vấn đề đó. Nhưng một nhược điểm của điều này là khả năng lặp lại vô hạn trong một số bộ chuyển đổi.

    Vì vậy, từ tất cả những điểm này, chúng ta có thể thấy rằng cả JSON và YAML đều có điểm mạnh và điểm yếu của họ. Một nhà phát triển giỏi phải có thể xác định những điều này và sử dụng đúng định dạng ở đúng vị trí.

    Ví dụ:

    Yaml file:

    Json file:

    Tổng kết:

    Trên đây là 1 số chia sẻ về JSON vs YAML mong có thể giúp đỡ mọi người.

    Author: DuongVT19

  • Firebase dùng trong Flutter (Phần 2)

    Cloud Firestore

    Cloud Firestore là gì?

    Firestore là một cơ sở dữ liệu đám mây NoSQL linh hoạt, có thể mở rộng để lưu trữ và đồng bộ dữ liệu. Nó giữ cho dữ liệu của bạn được đồng bộ hóa trên các ứng dụng khách thông qua trình nghe thời gian thực và cung cấp hỗ trợ ngoại tuyến để bạn có thể tạo các ứng dụng đáp ứng hoạt động bất kể độ trễ mạng hoặc kết nối Internet.

    Thêm package depedentcy vào ứng dựng

    • Từ root của ứng dụng, chạy đoạn command dưới đây:

    flutter pub add cloud_firestore

    • Sau khi hoàn tất, hãy xây dựng lại ứng dụng Flutter của bạn.

    flutter run

    • Gọi thư viện vào trong Dart code:

    import ‘package:cloud_firestore/cloud_firestore.dart’;

    Khởi tạo:

                    FirebaseFirestore firestore = FirebaseFirestore.instance;

    Document & Query Snapshots

    Khi thực hiện một truy vấn, Firestore trả về một QuerySnapshot hoặc một DocumentSnapshot.

    a. QuerySnapshot

    QuerySnapshot được trả về từ truy vấn bộ sưu tập và cho phép bạn kiểm tra bộ sưu tập, chẳng hạn như có bao nhiêu tài liệu tồn tại bên trong nó, cấp quyền truy cập vào các tài liệu trong bộ sưu tập, xem bất kỳ thay đổi nào kể từ truy vấn cuối cùng và hơn thế nữa.

    b. DocumentSnapshot

    DocumentSnapshot được trả về từ một truy vấn hoặc bằng cách truy cập trực tiếp vào tài liệu. Ngay cả khi không có tài liệu nào tồn tại trong cơ sở dữ liệu, ảnh chụp nhanh sẽ luôn được trả về.

    c. Một số Query.

    Filter: Dựa theo method where() để lọc dữ liệu theo trường.

    Limiting: Để giới hạn dự liệu trả về sử dụng method limit().

    Ordering: Sự dụng method oderby().

    Start & End Cursors: Để bắt đầu và / hoặc kết thúc một truy vấn tại một điểm cụ thể trong một tập hợp, bạn có thể chuyển một giá trị cho các phương thức startAt, endAt, startAfter hoặc endBefore.

    Updating documents:

    Đôi khi bạn có thể muốn cập nhật một tài liệu, thay vì thay thế tất cả dữ liệu. Phương thức đặt ở trên thay thế mọi dữ liệu hiện có trên DocumentReference nhất định. Nếu bạn muốn cập nhật tài liệu thay thế, hãy sử dụng phương pháp cập nhật:

    Removing Data

    Collections & Documents

    Firestore lưu trữ dữ liệu trong ” documents”, được chứa trong ” collections”. Tài liệu cũng có thể chứa các bộ sưu tập lồng nhau. Ví dụ: mỗi người dùng của chúng tôi sẽ có ” documents” của riêng họ được lưu trữ bên trong collection “users”. Phương pháp thu thập cho phép chúng ta tham chiếu một tập hợp trong mã của chúng ta.

    Ví dụ:

    Đọc dữ liệu.

    Để đọc một bộ sưu tập hoặc tài liệu một lần, hãy gọi phương thức Query.get hoặc DocumentReference.get. Trong ví dụ dưới đây, FutureBuilder được sử dụng để giúp quản lý trạng thái của yêu cầu:

    Cloud Storage

    Cloud Storage là gì?

    Cloud Storage được thiết kế để giúp bạn nhanh chóng, dễ dàng lưu trữ và phục vụ nội dung do người dùng tạo, chẳng hạn như ảnh và video.

    Thêm package depedentcy vào ứng dựng

    • Từ root của ứng dụng, chạy đoạn command dưới đây:

    flutter pub add flutter_storage

    • Sau khi hoàn tất, hãy xây dựng lại ứng dụng Flutter của bạn.

    flutter run

    • Gọi thư viện vào trong Dart code:

    import ‘package:cloud_firestore/ firebase_storage.dart;

    Upload file lên

    Upload và lấy ảnh:

    Delete a File

    Tổng kết:

    Trên đây là 1 số chia sẻ về Firebase dùng trong Flutter mong có thể giúp đỡ mọi người.

    Author: DuongVT19