đọc rõ là google dịch mà cũng đăng cho được, thua

Câu trả lời này theo mình là đầy đủ rồi. Mình bổ sung thêm là nếu không muốn thêm biến thì nên gom các biến đó thành một dạng Object (kiểu RequestObject ). Sau này khi muốn thêm param thì mình sẽ bổ sung thêm thuộc tính cho Object đó là xong.

Trong docker compose nó là 2 thứ khác nhau mà e, Dockerfile là e build cho service app (laravel)

Còn webserver là phía nginx (để nhận request và proxy vào app), vì image nginx cho webserver mình k cần sửa gì thêm mà chạy luôn nên mình k cần build nó.

Trong docker compose file, “image” có thể là image mình tự build hoặc cũng có thể là các image đc build sẵn nhé e

Great sharing! ♥️

@maitrungduc1410 cảm ơn bạn nhiều

@phamngoctrio check đc hệ điều hành của user đó bạn, như bên trên có comment ấy, lấy ra user-agent là có bạn ạ

@thongnv2303 thank b

Mình chưa hiểu log này lắm ở đây là log trên console (terminal) hay là log lưu lại trên file z. Nếu lưu trên console thì trên production làm sao debug đc

Anh em sẽ cố gắng

Mình dùng php có cách nào lấy thông tin user đơn giản không bạn vị dụ hệ điều hành tương ứng để đưa ra thông báo cài đặt ứng dụng tương ứng. không dùng thư viện liên quan các store

Cảm ơn bạn việc kiểm tra được user đã cài chưa và cập nhật rất hay nhưng phức tạp quá mình bó tay

@maitrungduc1410 vì là platform nó xử lí thay mình nên nó còn biết show thông báo khi app cần update nữa.

@phamngoctrio nếu bạn đi theo hướng web thì đơn giản là bạn code HTML đặt cái banner ở dưới, có button khi bấm vào thì mở CHplay hoặc app store là đc mà, về rating thì bạn sẽ phải gọi api để hiển thị (sẽ cách rách hơn và bạn sẽ k biết đc liệu user đã cài app đó chưa, nếu cài rồi thì sẽ k mở trực tiếp đc app mà luôn luôn chỉ mở đc store)

cảm ơn bạn còn cách nào không bạn website mình dùng code php

cảm ơn bạn nhưng bạn có thể chi tiết hơn giúp mình được không

Về phần "Extension Functions" khi so sánh Java với Kotlin, bạn đang so sánh hai vấn đề hoàn toàn khác nhau: giữa việc kế thừa trong Java và việc sử dụng một function with receiver trong Kotlin. Ngoài ra, sử dụng function with receiver trong Kotlin như ví dụ của bạn đưa ra cũng không giúp "thêm phương thức mới vào lớp mà không cần mở rộng" như bạn đã nói.

Thông tin thêm: Trong Java hay Kotlin, một lớp đã được định nghĩa thì không thể thêm phương thức mới vào mà không mở rộng được (trừ khi dùng những cách không bình thường), nên người ta mới sinh ra Adapter Pattern để giải quyết vấn đề này trong nhiều trường hợp. Chức năng dạng này xuất hiện trong các ngôn ngữ lập trình hàm dưới dạng typeclass, cũng như một số ngôn ngữ như C++ với concept, Swift với protocol, Rust và Scala với trait, ...

Cảm ơn bạn nhiều 😍

Hello anh, em xin phép hỏi một câu ạ 😅.
Em thấy trong file .dockerignore của anh có ingnore node_modules và anh có chú thích rằng là do mình có chạy npm install trong Dockerfile Em thấy nó đang hơi mâu thuẫn với việc mình phải tạo container tạm thời để chạy npm install khi dev ạ. Anh có thể giải thích cho em rõ hơn chút được k ạ.
Em đang nghĩ là có thể do npm install -g chăng 🤔
Em cảm ơn ạ.

nicee, cảm ơn bài viết của tác giả ạ ^^

Mình hiểu mục đích của bạn, và trước cũng có rất nhiều người nghĩ đến cái này Nhưng mà nếu vậy mọi method trong repo cũng đều phải có trong interface thì khi này bạn dùng mới có giá trị Hoặc không thì chí ít cũng là các public method phải có Vì chỉ cần 1 cái không có thì ắt sẽ sinh ra rủi ro khi bạn đổi db (ví dụ như có tầm 20 cái method trong repo mà có 19 cái trong interface, rủi ro là 1 service nào đó gọi đúng cái method đó trong repo mà lúc đổi db team dev không biết lại chẳng tạo method 20 này thì chắc chắn là toang) Và cũng như trên mình nhận định ngoài chuyện nó lưu cả 2 db đã hiếm thì chuyện đổi db có khi lại càng không và vì nó quá quá hiếm nên mình nghĩ không nên mà chỉ nên viết là 1 optional trong ngữ cảnh như bạn nói trên, chứ mọi người thấy vậy lại cứ làm theo thì tốn effort mà thấy nó lại rắc rối hơn thôi. Mình thấy đây là 1 bài rất hay có nói rõ về cách dùng repo https://martinjoo.dev/domain-driven-design-with-laravel-repositories Và mình thấy câu chốt của ông này khá hợp lý cho cách dùng phổ biến kia theo trải niệm của ổng là "This is the reason behind the interfaces. Now, here's my opinion on it: this is number one bullshit."