THẢO LUẬN

thg 11 20, 2020 3:44 SA

Nếu bạn thấy bài bổ ích thi bạn có thể upvote nhé. mình mới tìm hiểu thôi bạn 🖖

0
Avatar
đã bình luận câu trả lời trong câu hỏi
thg 11 20, 2020 3:42 SA

@NanaCongchua Mình đoán thôi 😄

'question.*.*' => 'required',

nhưng mà trường của bạn mình nghĩ sao cần thiết phải đặt name là question[$id][$var] nhỉ. Đơn giản là bạn có 1 cái name cần truyền lên để check thì dùng thằng cái name là question cũng được mà. Hay bạn muốn cái params truyền lên phải là array nhỉ. Nếu mà muốn truyền lên dạng array thì cũng phải thêm multiple vào thẻ select nữa

0
Avatar
đã bình luận câu trả lời trong câu hỏi
thg 11 20, 2020 3:35 SA

em mới edit câu hỏi anh xem dùm em với

0
Avatar
đã bình luận câu trả lời trong câu hỏi
thg 11 20, 2020 3:31 SA

em viết thiếu, thực ra input có dạng <select name="question[$id][$var]"> nên check question.* luôn đúng, em nghĩ phải là question[].* mới đúng nhưng mà không biết viết kiểu gì ạ

0
thg 11 20, 2020 3:21 SA

jQuery cho kết quả thật bất ngờ, hơn 10 năm qua jQuery vẫn đứng vững mặc cho các "hậu duệ" vươn lên mạnh mẽ!

+1
thg 11 20, 2020 3:16 SA

👍

0

master ko'

0
thg 11 20, 2020 2:29 SA

vậy việc phân tích dữ liệu của cmnd là do server xử lý ah ??

0
thg 11 20, 2020 1:00 SA

👍👍

0
thg 11 20, 2020 12:54 SA

@khangnd Theo như mình biết thì HEX sử dụng kết hợp 6 số và ký tự với nhau, RGB sử dụng bộ ba số với phạm vi từ 0 - 255. Cho nên mỗi loại sẽ có cách sử dụng khác nhau, cũng như tùy từng trường hợp. Sự khác nhau có chăng là khi sử dụng màu RBG thì mình có thể thêm đối số thư 4 cho nó để làm tăng giảm độ mờ cho màu bằng giá trị từ 0,0 đến 1,0. Vậy nên cuối cùng thì mình nghĩ chủ yếu là do sở thích cá nhân của mỗi người thôi ạ, vì HEX và RBG nó chỉ khác nhau cách viết thôi chứ thực ra nó vẫn là một màu khi hiển thị. Còn về vấn đề hiệu suất một vài byte thì nó cũng không tạo nên được nhiều sự khác biệt cho lắm.

+1

@thanhtungs Bạn cập nhật lại nội dung câu hỏi được không? Mình vẫn hơi lấn cấn.

0
thg 11 19, 2020 2:42 CH

Bài chia sẻ rất hay, cảm ơn bạn. Sẵn cho mình hỏi là có best practice về việc nên sử dụng màu hex hay rgb color ko bạn?

+1

thoải mái e, API e viết ở routes/api.php cũng được.

Lỗi 404 in ra là do e đang thiếu tiền tố /api khi gọi API nên lỗi in ra là 404 ko tìm thấy đó.

Chú ý là tất cả các API viết ở routes/api.php thì khi gọi e phải thêm có tiền tố là /api. Ví dụ: http://localhost:8000/api/users (bình thường nếu viết bên web.php thì sẽ gọi là /users luôn)

0

Chả hiểu sao loạt bài hay như vậy lại tương tác ít, cảm thấy chạnh lòng...

0

chào bạn,

Ở ảnh đầu tiên lỗi của bạn là do supervisor ban đầu được chạy bằng non-root user sẵn rồi, sau đó ở cấu hình process cronjob của bạn thì bạn lại tiếp tục set user=<1 user khác>, và điều này là ko đc, khi chạy container với non-root thì process cronjob của bạn phải được chạy chính bằng user chạy supervisor luôn. Cách giải quyết là trong file cấu hình cho cronjob của bạn bạn bỏ user=... đi.

Bỏ đi thì cronjob đã chạy đc hay chưa?

Câu trả lời là chưa 😄. Lỗi ở ảnh 2 sẽ xuất hiện (hoặc 1 lỗi tương tự)

Vì master process của crontab yêu cầu phải được chạy bằng user root, tức là command để khởi động crontab là crontab -b... phải được chạy bằng user root, sau đó các cronjob được khởi tạo từ crontab mới có thể chạy được bằng non-root hay root thì tính sau.

Vấn đề ở đây là, vì container của chúng ta chạy bằng non-root user, nên ở CMD cuối Dockerfile khi ta khởi động supervisor, thì supervisor sẽ được chạy bằng non-root -> tất cả các process ta cấu hình sẽ được chạy bằng non-root theo -> crontab được khởi động bằng non-root -> Lỗi.

Mình đã thử nhiều cách để thử fix việc này: chạy supervisor trước khi đổi user, thử entrypoint, dùng gosu,... nhưng đều ko được.

Và cuối cùng mình chốt lại là phải khởi động crontab bằng tay mỗi lần ta khởi động container như sau:

docker-compose exec -u root app sh       # exec vào container bằng user root
crond -b      # chạy master process của crontab

Cũng ko vất lắm chỉ là hơi bất tiện chút thôi. Nếu bạn tìm được cách nào chạy ngay được trong lúc build image thì comment cho mình biết nhé (mình vẫn nghĩ là có cách giải quyết nhưng chưa có tgian để vọc tiếp)

Bạn có thể tham khảo project realtime chat laravel docker của mình ở đây, ở đó mình có setup đầy đủ các thành phần: mysql, redis, horizon, worker, cronjob, nginx,... có cả cronjob và tất cả đều được chạy bằng non-root user (branch docker-non-root nhé). Và ở readme mình có note là để chạy cronjob thì phải khởi động master process crontab thủ công sau khi chạy container.

Ở project của mình bạn xem cấu hình supervisor mình để ở folder .docker nhé. Ở đó master process của supervisor mình chạy bằng user www, các file cấu hình các process (trong folder supervisor.d) như horizon, php-fpm ko cần thêm user=... mà sẽ tự lấy theo user chạy master process luôn. Còn cronjob thì mình set trực tiếp trong Dockerfile (bạn tách nó thành 1 file rồi dùng COPY cũng đc)

0

Mình cũng chã dám động vào mớ tk đó luôn ạ, sợ bóc lịch dài hạn bác ơi :v

0
thg 11 19, 2020 10:18 SA

1.PNG Em có chút thắc mắc mong được giải đáp ạ! Thứ nhất là khi viết web bằng Laravel+VueJs thì phần API viết bằng PHP như trong route/api.php bình thường được không ạ? Vì em viết phần API cho web bằng PHP nhưng khi load thử link để đc file Json thì nó luôn hiện lỗi 404, theo như e thấy là do nó chỉ ưu tiên duyệt qua phần route/web.php trước rồi trả kết quả thay vì duyệt qua phần api ( vì những link e để sau phần khai báo vue kia cũng đều ko load đến được mà đều trả 404) Có cách nào khắc phục chuyện này không ạ?

0

vấn đề là b làm gì đc với đống tài khoản đó 😄

0
thg 11 19, 2020 8:16 SA

Bạn ơi minh đang muốn mua code này vs muốn dk bạn vs Mạnh hướng dẫn chi tiết. Bạn liên hệ giúp mình qua sdt 033 711 4319 hoặc gmail nguyenduykhanh92bkhn@gmail.com Thank bạn

0
thg 11 19, 2020 8:08 SA

@buiquangmanh Mạnh ơi bạn có bán sản phẩm code này không. Từ giờ tới thứ 6 bạn mà không bạn, mình gặp nhau được không bạn. Check mail giúp mình với. Thank bạn

0
Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí