Recent content by CongTuDamDang

Em k nhận offer bên này bác ơi

Tên công ty: GHTK Lương tháng (gross): 32tr BH full lương Vị trí: PHP Developer Thời điểm (năm nào): 2023 Bonus: T13 + Thưởng (chưa rõ) Số năm kinh nghiệm khi nhận offer: 5 Tên công ty: 1office Lương tháng (net): 30tr Vị trí: PHP Developer Thời điểm (năm nào): 2023 Bonus: T13 + Thưởng (chưa rõ)...

Mình cũng vận hành và quan sát team 2 3 năm rồi. Trong ngành cũng 5 6 năm. Không dài lắm nhưng cũng qua vài giai đoạn sản phẩm từ MVP, phát triển rực rỡ, đến đập đi xây lại, hủy sản phẩm. Nhân sự thay đổi hết từ DEV đến PO, BA, Tester. Còn nếu bạn quyết tâm cho giải pháp của mình là hoàn hảo thì...

Thì giảm point và cần 1 2 sprint để xem lại velocity chứ sao. Một vài sprint sau người mới sẽ bù đắp dần vào người cũ. Tất nhiên cần thời gian để thay hoàn toàn. Việc plan thời gian, point cho việc thay đổi nhân sự , rủi ro là việc PM và leader phải làm khi plan đầu Quý hoặc năm. Trường hợp này...

Cái này là ở Mindset của team á. Muốn là Agile, Scrum kiểu này phải đổi được mindset từ việc đổ lỗi sang tập chung vào vấn đề. Và phải build được văn hóa tranh luận tích cực. Nếu ông nào k hợp được thì phải đổi cách quản lý thành cẩm tay chỉ việc thôi. K làm máy móc được đâu. Vấn đề lớn nhất của...

"Một khi bạn đã có con số thì kiểu j nó cũng bị convert ra thời gian" câu này của bạn thì đã chứng tỏ bạn chưa hiểu đủ bản chất của estimate point rồi. Bên mình làm thì mình cho estimate point để phục vụ output cho team và PO trong quá trình planning sprint. Nó cũng là công cụ để cả team hiểu...

Trả lời một số câu hỏi thắc mắc của chủ thớt Làm sao estimate mà không để storypoint liên quan đến thời gian? Kĩ thuật estimate point bản chất không liên quan đến thời gian mà. Bạn hỏi câu này mình nghĩ là chưa bao giờ thực sự setup việc estimate point cho 1 team Làm sao estimate bằng TShirt...

Một số ý đơn giản: DEV: thì log bug để tính, tùy dự án và project, để estimate lượng bug theo issue. Có thể limit theo tỉ lệ bug trên story point theo từng LV hoặc gì đấy. Bug có thể phân loại theo mức độ để đánh trọng số. Test: Số lỗi lọt khi UAT hoặc lên production. Những con số này thì phải...

Vẫn phải có chứ. Transaction còn để đảm bảo các thuộc tính của ACID nữa mà chứ đâu phải mỗi việc update quantity. Tuy nhiên nếu mà lượng request quá lớn thì việc dùng transaction với nhiều request đến song song rất dễ oẳng do dead lock. Như thế thì việc sử dụng queue như 1 chỗ phân tải cũng được...

Cái message queue để hạn chế quá tải khi lượng truy cập tăng nữa bác. Hoặc một số bài toán cần sự tuần tự trong xử lý request.

https://www.rabbitmq.com/tutorials/tutorial-six-python.html Bác xem practice RPC của RabbitMQ nhé

Cái này phải xem sản phẩm hướng đến đối tượng nào chứ.

Mình cũng đang làm 1 sản phẩm dạng ntn Về phần domain thì dùng Wildcard với nginx thôi Server frontend thì dùng nextjs , lấy thông tin domain rồi tìm ra dữ liệu tương ứng với user thôi Về việc build ui mình định nghĩa block, data, cho nta kéo thả rồi render bằng ReactJS Trường hợp của bác muốn...

Bác kiếm chỗ nào đầu sóng ngọn gió mà lao lên. VD nhận một module khó hay deploy cái gì. Toàn phải thế mới động vào được. Cty mà to quá khó làm kiểu ấy. Bác có thể suy nghĩ ra mấy chỗ bé bé hơn. Chịu khó lương thấp xuống 1 thời gian nhưng thành quả đạt được hứa hẹn. Em cũng culi mãi giờ mới bắt...

Mấy bác nghe AWS Cer có gì mà căng thế. Mấy ông dev cứng tay học tầm 1 tháng là pass cái solution architect associate. Quan trọng là triển khai kìa. Chưa thấy ông nào từng học thi kêu là cái chứng chỉ này khó cả.