hay đấy ô ơi (y) dạo này tiêu yên sướng chứ

không biết Viblo viết bằng gì nhỉ?

Thực sự mình cũng thấy đối với sinh viên thì mức giá như vậy là quá cao và mình vẫn phải dùng đọc tài liệu lậu.

Nhưng cái I3E này có cái bạn hiểu sai, họ không thu phí trên công sức lưu trữ, họ được biết đến là 1 tổ chức phi lợi nhuận. Khi tác giả viết paper submit paper của mình lên IEEE conferences, họ đã được hưởng lợi từ conference rồi và conference có quyền sở hữu đối với những paper đấy, thu phí bằng việc "bán" chúng và khách hàng tiềm năng không phải là sinh viên mà là các doanh nghiệp, start-up muốn phát triển dựa vào tri thức của người khác. Các tác giả paper không được publish ra bên ngoài, khi IEEE thu được phí, họ tài trợ lại cho các conference đó đảm bảo cho việc diễn ra được thường niên và đúng quy mô. Còn mình thích đọc, thích nghiên cứu mà không muốn dùng hàng lậu thì mail riêng cho tác giả xin cũng được, thỉnh thoảng mình cũng phải xin

Mình nghĩ bạn có thể bắt đầu bằng việc cố gắng nẵm vững các tính chất của OOP, cũng như tìm hiểu về Object Oriented Design Principles hay các Object Oriented Design Patterns

Đúng rồi bạn. Mình viết nhầm nhé. bạn sửa đường dẫn directive thành component nhé. Do viết bài là mình có sửa 1 số nội dung so với project thực tế của mình nên nó có sai sót. Project mình sẽ check lại và đẩy lên github nhé.

Bạn có thể post cả project ko? vì mới học thôi nhưng thấy chạy ko dc.

Trong thư mục component ta tạo 1 folder có tên là manage-users. Trong đó chứa 3 file directive, template, controller(có thể có hoặc không tùy thuộc vào directive mà mình tạo).

bạn ghi là trong foler component. nhưng lúc import vào html thì là

/index.html

<script src="directive/manage-users/manage-user-directive.js"></script> <script src="directive/manage-users/manage-user-controller.js"></script>

Cảm ơn bạn đã đọc bài và chia sẻ ý kiến của bạn, mình có 2 lý do như sau:

1. Đối với mình thì với tính chất công việc của bản thân, sử dụng docker và môi trường linux, mình sử dụng terminal (command line) khá nhiều. Cũng bởi lẽ đó nên mình sử dụng git luôn trên terminal để tiện tay hơn. Ngoài ra thì khi làm việc trên server, mình cũng không có gì khác ngoài cái terminal.
2. Công việc develop sản phẩm hàng ngày, sử dụng IDE là PHPStorm, mình kết hợp dùng git trên terminal của IDE + Version Control của PHPStorm (thông qua shortcut) khi cần xem lại Git Log trên GUI dễ tìm kiếm. Cũng bởi lẽ này nên mình không cần dùng thêm tool khác như sourcetree nữa.

Mình nghĩ trên đây là hai lý do của mình khiến mình không dùng thêm sourcetree. Hầu hết mang tính chất thói quen của bản thân sao cho "tiện tay" trong công việc. Có thể bạn dùng quen sourcetree, bạn hãy cứ dùng nó để công việc không bị gián đoạn, không sao cả. Tuy nhiên, bạn vẫn hãy ghi nhớ các lệnh git hữu ích để có thể thao tác trên server khi cần nhé.

Sao không dùng sourcetree ạ

Mình đã làm theo tutorial của bạn, tuy nhiên ở Model User mình có tùy biến primaryKey của nó từ ID thành USER_ID nên khi gọi các hàm của Vue thì nó tự động chuyển thành cột user_USER_ID như ở dưới SQL: insert into push_subscriptions (endpoint, public_key, auth_token, user_USER_ID, updated_at, created_at) . Mình đã google nhưng ko thấy có mấy tài liệu, bạn xem có cách nào tùy chỉnh lại hàm này giúp mình được ko? Thank bạn!!!

me too. Interface và composition của Go thực sự rất linh hoạt và dễ hiểu, có phần giống với C

bạn thử $article->tags xem

Đúng là đối với mục đích development thì tạo persistent stack như vậy là hợp lý rồi.

Cám ơn bạn, mình đã được khai sáng

Mong chờ các bài viết tiếp theo của bạn

Cho mình hỏi, có 1 số bạn khai báo có dấu @ trước biến. Ví dụ: @$a = 1; là có ý nghĩa gì nhỉ?

Ngay từ đầu mình hướng việc tạo persistent stack này phục vụ cho development ở dưới máy, vậy nên chắc chúng ta sẽ chưa phải lo về vấn đề chết hay không ở đây.

Cái mình cần để ý khi dev có chăng là khác biệt về version. Vì persistent stack thì việc khác biệt version xảy ra khá ít (không như application) nên mình mới gộp chung lại chạy bằng 1 service cho đỡ tốn tài nguyên. Tuy nhiên ví dụ 1 app bạn chạy mongo 3, 1 app bạn chạy các chức năng của mongo 4, vậy thì bạn nên tạo ra 2 service riêng để chạy 2 app trên. Chỉ cần bạn thêm 1 service vào persistent stack với tên là mongo4 thì đã có thể giải quyết vấn đề trên rồi.

Còn việc chạy trên production thì nó theo kiến trúc deploy của bạn nữa, vấn đề high availability hay là single point of failure chắc là sẽ để 1 bài viết khác đề cập vậy

Cho mình hỏi ngu phát là khi chạy lệnh RUN pip install -r requirement.txt trong file Dockerfile là nó install vào cái Container hay install vào máy thật mình vậy

Cám ơn tác giả, bài viết rất hay, dễ hiểu và chi tiết

Theo nội dung bài viết, bạn tạo persistent stack để sử dụng chung cho các app. Ví dụ như mình có 3 app đều sử dụng MySQL ở network common, thì MySQL Server đó sẽ lưu dữ liệu của cả 3 app (3 databases) có phải không?

Nếu đúng vậy thì bạn có đánh giá, nhận xét gì giữa việc sử dụng 1 MySQL Server cho nhiều app, và 1 MySQL Server riêng cho mỗi app?

Mình nghĩ rằng nếu 1 MySQL Server dùng chung cho nhiều app, thì có nhược điểm là, nếu MySQL Server đó bị chết, thì các app sử dụng nó đều trở nên vô dụng. Nếu tách ra 1 app 1 MySQL Server thì các app sẽ không bị chết hàng loạt như trường hợp trên. Nhưng tách ra như vậy, thì có lẽ sẽ tốn nhiều tài nguyên hơn (không biết tốn hơn nhiều không?)

Mình chỉ mới tìm hiểu về docker thôi, mong bạn nào biết thì giải đáp, phân tích giúp mình. Mình cảm ơn

Hy vọng là sau một thời gian sẽ không lại bị bỏ xó như bogo Trước giờ mình hay dùng fcitx-unikey, thấy ổn lắm, mỗi tội quá trình cài đặt hơi rắc rối (mình dùng manjaro kde).

@kstn_hut_hat Em trêu mà, ở dưới em có đăng link lấy bài báo. Nhưng xét nghĩ đó là hành động cổ xúy cho tài liệu lậu và vấn đề tác quyền nên không được phép chia sẻ rộng rãi Em biết sai và đã xóa link đi

@QuangPH đã có bài báo =)). Chưa gì đòi tiền rồi Đang mày mò implement theo mà nghe chừng căng phết :v

bạn phải chạy queue ạ. Config queue redis sau đó dùng lệnh queue:work https://laravel.com/docs/5.7/queues bạn tham khảo ở đây nhé