Điểm nổi bật
Mức sử dụng hiện tính từng giờ trong chu kỳ thanh toán của bạn, vì vậy tổng số credit trên trang Usage & Limits sẽ bao gồm toàn bộ chu kỳ từ giây đầu tiên. Các tổ chức (Organizations) đã có thêm các tính năng tiếp nối còn thiếu tuần trước: người bạn thêm sẽ nhận được thông báo, chủ sở hữu của gói thanh toán cũng vậy, và bộ chọn vai trò cuối cùng đã nêu rõ quyền hạn của từng vai trò. Chúng tôi cũng đã rà soát Dashboard và viết lại các thông báo vốn trước đây viết cho đội ngũ phát triển thay vì cho bạn.
Tính năng mới
Từng giờ trong chu kỳ đều được tính
Chu kỳ thanh toán của bạn bắt đầu vào đúng giây bạn đăng ký. Mức sử dụng được đo lường theo các bucket cố định. Hai yếu tố này hầu như không bao giờ khớp nhau, do đó phép tính ánh xạ giữa chúng phải hoàn toàn chính xác tại các điểm biên.
Hiện tại mọi thứ đã chuẩn xác. Một chu kỳ được chia thành các bucket nguyên vẹn với độ phân giải chi tiết nhất hiện có cho từng phần, không bị chia nhỏ lẻ, không bị tính hai lần. Cả ba nơi đọc dữ liệu mức sử dụng đều dùng chung một implementation, đây mới chính là điểm khắc phục cốt lõi. Việc duy trì ba bản sao của cùng một phép tính chính là lý do khiến một trong số đó bị sai lệch.
Điều bạn sẽ nhận thấy: mọi con số trên trang Usage & Limits đều hiển thị cao hơn một chút so với tuần trước. Lưu lượng truy cập không đổi, nhưng số liệu được tính đầy đủ hơn. Không ai bị vượt giới hạn gói do thay đổi này. Phép tính này cũng trực tiếp kiểm soát quota của bạn, vì vậy độ chính xác có ý nghĩa ở cả hai chiều.
Không ai tham gia tổ chức trong im lặng
Organizations đã ra mắt tuần trước và bạn đã có thể thêm đồng nghiệp, cấp vai trò cho họ, và để họ sử dụng các key do công ty thanh toán. Điều bạn chưa thể làm là thông báo cho họ. Dòng gợi ý dưới biểu mẫu khi đó chỉ yêu cầu bạn tự làm việc đó.
Hiện tại có hai email được gửi đi. Người được thêm nhận một email nêu rõ tên tổ chức, ai đã thêm họ, vai trò của họ có thể làm gì, và cách rời khỏi tổ chức nếu họ không mong muốn điều này. Chủ sở hữu nhận được email khi có người tham gia, vì các key của tổ chức tính phí vào gói của chủ sở hữu và việc có thêm người sử dụng credit là quyền lợi trực tiếp của họ, không phải là một thông báo xã giao. Cả hai email đều không gửi cho người vừa bấm nút. Bạn không cần biên nhận cho hành động của chính mình.
Thông báo cho chủ sở hữu kích hoạt trên cả hai trường hợp: người được thêm trực tiếp, và lời mời được chấp nhận trong lần đăng nhập đầu tiên, trường hợp không có người thực hiện thao tác vì người dùng tự truy cập vào.
Các vai trò giờ đây cũng tự giải thích rõ ràng. Một dòng bên dưới bộ chọn sẽ thay đổi khi bạn chọn, và cột Role có tooltip giải thích cả ba vai trò bao gồm cả owner. Việc phải chọn giữa "Member" và "Admin" mà không biết mỗi vai trò làm được gì chính là lý do người ta thường cấp quyền admin theo mặc định.
Thêm đồng nghiệp chỉ với một bước
Nhập địa chỉ email, nhấn Add. Nếu họ đã sử dụng FourA, họ sẽ tham gia ngay lập tức. Nếu chưa, chúng tôi sẽ gửi thư mời và họ sẽ vào tổ chức ngay khi đăng nhập. Cùng một nút bấm, cùng một xác nhận, cùng một kết quả cho cả hai trường hợp, và trang mô tả cả hai kết quả trong một câu thay vì phải chỉ định trường hợp nào áp dụng cho địa chỉ bạn vừa nhập.
Hộp thoại thứ hai đó đã biến mất, và phản hồi từng cho bạn biết liệu một địa chỉ đã có tài khoản ở đây hay chưa cũng vậy. Liệu một email bất kỳ có đăng ký với chúng tôi hay không không phải là câu hỏi chúng tôi trả lời.
Dashboard đã ngừng ghi log
"Failed to fetch organizations" là dòng dành cho chúng tôi. Nó từng hiển thị ngay trước mắt bạn.
35 thông báo dạng này đã trở thành những câu mà người dùng có thể xử lý, chẳng hạn như "Chúng tôi không thể tải tổ chức của bạn. Vui lòng thử lại sau giây lát." Dạng viết tắt có ở mọi nơi người dùng đọc. "Invalid member id" và các lỗi tương tự hiện giải thích rõ điều gì đã sai thay vì chỉ gọi tên một biến. Các dòng console mà trước đây chúng bị nhầm lẫn vẫn được giữ nguyên, vì những dòng đó thực sự dành cho chúng tôi. Xác thực cấu trúc API trả về khi bạn gọi từ mã nguồn cũng vậy, và các mã đọc được bằng máy mà Dashboard dùng để rẽ nhánh cũng giữ nguyên.
Email cũng được xử lý tương tự. Lời mời yêu cầu một người lạ tham gia "một tổ chức" là loại thư mà mọi người thường ném vào thùng rác, vì vậy tên của các đối tượng bạn đã chọn đã quay trở lại: tài khoản, key, tổ chức, bất kỳ ai đã mời bạn. Văn bản tự do do khách hàng nhập vẫn hoàn toàn không xuất hiện trong bất kỳ thư nào chúng tôi gửi.
Bên dưới hệ thống
Browser từng bị rò rỉ một file handle trên mỗi phiên render, và thủ phạm không phải là mã nguồn của chúng tôi. Một dependency thượng nguồn đóng một trong hai log handle của nó, sau đó return sớm và bỏ qua handle thứ hai, nhưng chỉ xảy ra khi bên gọi cung cấp thư mục profile riêng. Chúng tôi cung cấp thư mục này trong mỗi lần khởi chạy, khiến cho việc rò rỉ vừa chắc chắn xảy ra vừa kéo dài liên tục.
Bản vá bao bọc phương thức duy nhất đó thay vì fork cả dependency. Nó chạy phương thức gốc trước và chỉ can thiệp nếu handle vẫn mở, do đó vào ngày thượng nguồn chuyển dòng đó lên trên lệnh return, bản vá của chúng tôi sẽ tự động trở thành no-op mà không gây ảnh hưởng. Các bản kiểm thử tái hiện lại sự cố rò rỉ trước khi bản vá được cài đặt, nhờ vậy tệp kiểm thử nêu rõ nó đang phòng chống điều gì thay vì chỉ đơn thuần khẳng định mọi thứ đều ổn.
Hiệu quả thực tế: các instance Browser chạy dài hạn duy trì được dung lượng thay vì bị suy giảm tài nguyên khi các phiên tích tụ. Nếu bạn muốn kiểm soát giao diện và hành vi của các phiên đó khi truyền qua mạng, browser profiles đã được phát hành cùng đợt này.
Cả hai bản sửa lỗi trên đều bắt đầu từ cùng một vấn đề. Một thứ gì đó đã vượt qua bước kiểm tra nhưng đó lại không phải là kiểm tra thực sự quan trọng: bộ kiểm thử xanh mướt trong khi một giờ biến mất khỏi mỗi chu kỳ, một tiến trình báo cáo sẵn sàng hoạt động trong khi nó đã cạn kiệt tài nguyên duy nhất cần thiết. Để có màu xanh thì rất dễ. Câu hỏi khó hơn là các công cụ giám sát của bạn phải nhìn thấy điều gì trước khi chúng chuyển sang màu đỏ, và liệu chúng có thực sự nhìn thấy điều đó hay không.