ngắn vại =))

Hihi nếu dùng code giữa 2 lần insert là khả năng code bị delay có thể xảy ra bạn ạ, nên cách hay nhất vẫn là dùng Identity :

+1 ít bữa train a React nhé =]]

Cái này theo ngu ý của mình thì cứ mỗi ngày bạn tạo 1 temp table với id auto_increment, cứ insert vào temp table này trước, sau đó update ngược id này lại table bạn cần.

Từ bài toán getmax nên đẻ ra bài toán concurrency bạn ạ Hiện tại thì cách hay nhất vãn là đẩy về database để xử lý hết như bạn Thương Nguyễn vừa nêu ở trên đó :

Thanks Bạn. Mình đã có check lại thì chỗ code reset đang có vấn đề và sẽ gặp lỗi delay như bạn nói khi có quá nhiều user cùng spam. Hiện tại dựa án đang sắp đến đoạn cuối nên kh cũng ko mong muốn đẻ thêm tool nên mình sẽ note lại phương án này để áp dụng sau này

if($qty > 0) { return true; } else { return true; } sao lại return true cả 2

Đây là bài toán concurrency chứ đâu phải GetMax như tiêu đề nhỉ. Nếu SeqNo chỉ là auto increment thì có thể sử dụng 1 biến static và 1 atomic operation như Interlocked.Increment có được không bạn ? Như vậy thì sẽ đảm bảo ko bị race condition.

Chưa làm C# bao giờ nên chỉ đoán vậy thôi

Làm Outsourcing là làm cho thằng khác, không phải của mình. => Cái này đúng, nhưng product thì sản phần cũng đâu phải của các bạn Làm Outsourcing bị thiếu tư duy làm sản phẩm => Không đúng lắm (ý kiến cá nhân) Làm Outsoucing thích lương cao và làm quản lý. => Thằng nào chẳng thích lương cao, làm quản lý thì tùy (mình không thích làm quản lý) Làm Outsourcing khả năng sáng tạo kém, tư duy bảo thủ. => Xạo quần Làm Outsourcing lười. => Lười là do con người chứ không phải do Outsourcing hay Product Làm Outsourcing ảo tưởng sức mạnh. => Chỉ đúng một phần nhỏ (do bản chất của outsource là cần nhanh => số dự án làm được sẽ nhiều hơn Product, so về số lượng thì ảo tưởng cũng có vẻ đúng)

thank you (y)

Search ra thì thấy trên Viblo cũng có khá nhiều bài viết về Appium https://viblo.asia/search?q=appnium Hy vọng @nguyenanltmt2 có thể tham khảo

https://viblo.asia/p/tim-hieu-appium-6J3ZgDNglmB https://viblo.asia/p/su-dung-appium-trong-kiem-thu-tu-dong-ung-dung-tren-android-p1-L4x5xQWwKBM https://viblo.asia/p/su-dung-appium-trong-kiem-thu-tu-dong-ung-dung-tren-android-p2-E375zbMR5GW https://viblo.asia/p/automation-test-test-android-with-appium-and-cucumber-JlkzymlbzZW https://viblo.asia/p/why-to-use-appium-for-mobile-automation-QpmlenPV5rd https://viblo.asia/p/mobile-testing-frameworks-overview-XL6lAYRglek

Mình thấy làm gì cũng vậy, trước tiên cần có nền tảng trước đã. 1/ Theo mình thì nên tìm hiểu về nền tảng của mobile trước đã (ít nhất là nắm đc UI và UX của iOS hoặc Android) Bạn có thể tham khảo: https://developer.apple.com/ios/human-interface-guidelines/overview/design-principles/ https://viblo.asia/p/so-sanh-uxui-tren-ios-va-android-roavrJlbvRM

2/ Sau đó thì nên nắm vững 1 ngôn ngữ lập trình nào đó, theo mình thì nên là java (hoặc có thể C# or ruby..) tùy bạn. Ít nhất là basic cho testing Có thể tham khảo ở đây: http://toolsqa.com/java/java-tutorial/

2 cái trên xong thì hãy vào tìm hiểu kiểm thử mobile bạn nhé. Lúc đó có cái nền rồi thì việc tìm hiểu các framework để kiểm thử mobile sẽ dễ dàng hơn, bạn có thể tham khảo 1 số framework của bạn ở trên Thân!

Bản thân mình thấy người viết bài này, hay những người có cùng tư tưởng như thế này đang ảo tưởng sức mạnh. Mỗi môi trường có những lợi thế khác nhau, và mỗi con người khi phát triển ở từng thời điểm, có các thế mạnh khác nhau. Trên quan điểm của mình, 1 người quản lý giỏi là người biết truyền cảm hứng tích cực về môi trường của anh ta và đánh giá con người dựa trên phẩm chất và giá trị mà họ đã làm được, chứ không phải chỉ đơn thuần là dựa trên nhu cầu đặc thù của môi trường anh ta muốn tuyển dụng, đem ra so sánh, đong đếm với môi trường khác như kiểu cạnh tranh nhau thế này. Quan điểm của bạn là thẳng thắn, nhưng không hề khách quan.

Những điều này mình chỉ đưa ra trên lý thuyết dựa vào bài viết của bạn:

Sử dụng transaction để lock lại quá trình insert, đảm bảo chỉ 1 record đc insert tại thời điểm đó.

Có phải là Insert từ cũng vào bảng Order và read cũng từ bản Order? Mình chưa hiểu lắm đảm bảo chỉ có 1 record được insert một thời điểm là bạn đang lock cái gì. Cá nhân mình thấy cái cần phải lock ở đây là read của bảng Order sau khi read xong thì block lại, sau khi xử lý/insert xong thì mới mở read ra lại. Tại vì nếu bạn chỉ lock insert thì nếu 1 request đến sau, nó vẫn read được cái SeqNo rồi nhưng nó không insert được cho nên sẽ dẫn đến việc bị trùng.

Về phương án identity mình chưa hiểu lắm tại sao nó có thể bị trùng được. Tại vì indentity là built-in của SQL, nếu mà nó bị lỗi thì ví dụ như mình sử dụng identity cho primary key của mình nó cũng sẽ lỗi? Mà nếu không phải do SQL thì lỗi đến từ code? Bị trùng ở đây có phải là bị trùng ở thời điểm chuyển giao ngày hay không?

Tại vì theo mình đọc ở đây, bạn sẽ phải check và set identity mỗi lần insert.

var order = context.Order.FirstOrDefault(x => x.SeqNo == orderModel.SeqNo && x.SeqNoDate == orderModel.SeqNoDate);

Vậy thì nó sẽ vẫn có độ trể mỗi khi insert một record mới.

Giải pháp của mình đưa ra chung với identity là không cần phải check và reset identity mỗi khi insert một record mới. Thay vào đó nhiệm vụ reset sẽ dựa vào schedule, một process khác sẽ chạy mỗi ngày lúc 12:00 AM để reset lại identity. Dĩ nhiên bạn cũng sẽ cần một phương pháp để audit cho những order được tạo vào thời điểm giao ngày vì schedule có thể nó không thể chạy đúng đến từng milisecond được.

Đối với những bài toán như thế này thì cá nhân của mình hay để việc check cho server của SQL, tại vì cho dù mình có làm gì đi nữa ở code thì giữ code và database vẫn có một khoảng delay. Nên nếu cứ dựa hết trên code thì sẽ dễ gặp vấn đề phát sinh.

Chị viết thêm các bài về automation testing for mobile thì hay quá...

tiếp phần 2 đi bác

Bài viết gọn và dễ hiểu

Ở phần index bạn có gắn relate đến nguồn từ sinhvienit. Tuy nhiên nguồn này chia sẻ thông tin thiếu chi tiết và dễ gây hiểu lầm. Do vậy khuyến cáo bạn đọc trang chủ MySQL nhé. Theo sinhvienit

Non-Clustered Index: khác với clustered Index, non-Clustered Index không sắp xếp dữ liệu theo một trật tự vật lý như clustered mà là "loạn xà ngầu" trong bảng thông tin, miễn sao nó nằm trong một logic do index qui định . trong một bảng có thể chứa đến 249 non-clustered index. còn cách hoạt động thì tương tự clustered index, có khác là khi truy xuất đến bảng thông tin cuối thì thông tin không được sắp xếp theo trật tự thôi ví dụ như A--->C---->B----->E---->D.....

Còn đây là trang chủ MySQL, không có cái gì là loạn xà ngầu hết, có quy tắc hết nhé. https://dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html

How Secondary Indexes Relate to the Clustered Index

All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.

Hy vọng bạn có cái nhìn rõ ràng và chính xác hơn, qua đó chuẩn bị cho các lần phỏng vấn sau nếu có

haha khá lắm, qui lại cũng là OT hả chứ không phải do quản lí kém?

Anh ơi cho em hỏi ở trong protocol ProductListViewPresenter không có hàm init() nhưng sao ở dưới class ProductListPresenter lại có require init(...) ???