Sửa background thì chưa đúng ý lắm.

Mình thích Scrum, Một bài viết rất cụ thể, ngôn ngữ cũng rất hài hước. Mình cám ơn bạn chia sẻ và mong chờ bài tiếp theo từ bạn.

để lần tới chị viết phần 2 nhé ^^

không có phần 2 à a

bạn chưa hiểu chỗ nào có thể pm mình nhé :3

(ngon) a (y)

bài viết hay

@d10cn2btt Em chỉ cần làm một cái batch, cứ mỗi một phút check danh sách các order có status là draft một lần, nếu thời gian quá 10 phút thì em chuyển sang expired, và tăng lại số lượng remain_ticket lên

À. Còn cái SELECT ... FOR UPDATE thì khi 1 user đặt vé thì những user khác sẽ không thể thao tác được với bảng ticket này (xem số vé, view....)

Nó chỉ lock trong khi cái transaction của em đang chạy thôi chứ em, em chạy 2, 3 câu lệnh SQL thì nó hết mấy mili giây đâu mà lo những user khác không thể thao tác được

sơ sài quá bạn ơi

Mình thấy Angular 1 vs Angular 2 khác nhau nhiều lắm, nếu không muốn nói là chả liên quan gì đến nhau cả )) Những thứ thay đổi lớn nhất đó là:

• Angular 2 chuyển sang dùng TypeScript thay vì Javascript trên Angular 1,
• Angular 2 dùng Component là chủ yếu, thay vì Directive như trên Angular 1 ....

à. Em quên không note Nếu order có status là draft (đặt tạm) thì nó chỉ được tính trong vòng 10 phút thôi VD: Mình có 10 vé. 1 user đặt tạm 8 vé lúc 15:00 & không thanh toán Từ 15:00:00 - 15:09:59 thì user khác chỉ được đặt tối đa 2 vé Từ 15:10:00 thì số vé sẽ được khôi phục lại là 10 vé

Nên em nghĩ không lưu remain_ticket được ạ

À. Còn cái SELECT ... FOR UPDATE thì khi 1 user đặt vé thì những user khác sẽ không thể thao tác được với bảng ticket này (xem số vé, view....)

Cô giáo Vân ^^

1k em ạ

Anh thử cách tạo luôn thêm trường remain_ticket bên trong ticket sau đó mình lock trường đó lại? Khi mình ghi mình sẽ check một biến dạng như "số lần update" của bản ghi này chẳng hạn. Khi đọc dữ liệu ra thì check lúc update và lúc ghi thì "số lần update" này có bằng nhau không? Nếu bằng nhau chứng tỏ quá trình đọc và ghi của tác vụ này không bị tác vụ nào khác ghi vào trước, để tránh trường hợp 2 tác vụ cùng đọc một lúc nhưng ghi chỉ được một mà thôi, còn nếu khác nhau thì nghĩa là đã có thằng ghi vào rồi, nếu mình ghi tiếp thì sẽ không đúng cần roll back lại và check remain_ticket Ý tưởng em nghĩ như vậy còn cái số lần support kia thì em nghĩ mỗi framework hay database sẽ có hỗ trợ sẵn, cụ thể thì em không rõ lắm ^^

Bài viết dạng step-by-step rất hay và tính ứng dụng thực tế rất cao. Bạn có thể xử lý tiếp để mỗi card tự đổi thuộc tính khi được drag sang cột mới được không? Hiện tại các card vẫn chưa có thuộc tính status

export class CardSchema {
  id: string;
  description: string;
}

Đúng những gì em đang hướng tới. Cảm ơn chị vì bài viết ý nghĩa ạ ^^

Like and share liền a ơi

Bạn ơi, có công cụ nào để thực hiện những điều trên không? Hay phải làm bằng tay hết?

(batngo)

Hi, đúng là những lệnh trên rất hay được sử dụng. Ngoài ra, bạn có thể giải thích cách làm, các lệnh cần sử dụng khi mình lấy code về và code bị conflict không bạn?