Cảm ơn bạn, sắp tới mình sẽ cho ra những bài về OperationQueue, mong bạn đón xem và góp ý.

Các cách trên của bạn OK. Ngoài ra Eloquent còn support "hàm ăn sẵn" như này

$posts = Post::withCount('comments')->get(10);

echo $posts[0]->comments_count;

Bài viết rất bổ ích. Cám ơn tác giả.

(baiphuc)

Anh cho hỏi khi nào có các phần khác ạ? Em đang làm app sử in bluetooth để in hoá đơn qua máy in hoá đơn bluetooth, mà gặp core bluetooth này khó quá

Nếu như phân mảnh dữ liệu, đến lúc cần thì làm như thế nào cho hợp lý bác nhỉ?

Anh thấy việc dùng alias tiện lợi hơn nhiều mà, không phải nhớ chính xác đường dẫn. Nhất là khi vào tinker gõ =)) Anh thì toàn dùng alias khi có thể thôi

uh, việc bên trong Facade không có gì thật sự gây rất nhiều khó khăn khi tiếp cân =)) Facade tiện lợi cho nhiều người, nhưng cũng nhiều người không thích dùng nó Quan trọng là trong team thống nhất với nhau về việc sử dụng là được rồi, cũng không nên quá khắt khe.

Một comment nhỏ nữa là em không bao giờ dùng class alias khi use cả. Em luôn dùng use Illuminate\Support\Facades\Cache; thay vì use Cache. Đơn giản là em không thích dùng alias quá nhiều anh ạ. :3

@thangtd90 Đúng là bản thân em cũng mất thời gian dài dài để hiểu các cách xử lý của laravel. Nhớ hồi đầu em muốn tra api để gọi phương thức cho nhanh mà thấy toàn class "rỗng" à. Em biết cách khai báo class alias, không chỉ facade mà bất cứ thứ class "quái quỷ" nào cũng alias được. Thực tế thì em cũng hay dùng facade vì nó tiện và quan trọng nhất là các bạn em cũng dùng như thế. :3

Chào Hoàng. Cái Swift Package Manager này có trong Swift 3.0 rồi bạn. Mình chỉ giới thiệu cái thư viện này thôi, còn dùng cái nào quen thuộc với mình, và đáp ứng đủ nhu cầu của mình là được.

Cảm ơn bạn Hoàng đã đọc bài viết này. "Kiểm tra và diễn dịch kiểu của một instance của một class lúc runtime": Cái này là vì ở iOS thì classes có thể kế thừa 1 class khác, còn structs thì không. Nên bên class có 1 cơ chế là có thể kiểm tra kiểu dữ liệu(type) của một thể hiện(instance) có phải là superclass hay là các subclasses bằng từ khoá is. Và có thể cast 1 instance về 1 kiểu khác trong cấu trúc nhánh cha con mà nó ở trong đó. Ví dụ: thường dùng nhất là tableView.dequeueReusableCell sẽ trả về 1 UITableViewCell, nhưng ta có thể cast nó về 1 custom cell như là let cell = tableView.dequeueReusableCell(withIdentifier identifier: String, for indexPath: IndexPath) as! CustomCell cell bây giờ là kiểu CustomCell chứ k đơn thuần là UITableViewCell nữa v.v... website thì mình hay đọc https://developer.apple.com/documentation/ và https://www.raywenderlich.com/ thôi.

Nowaday, it has support android api 14 or higher https://developer.android.com/preview/features/downloadable-fonts.html

Cảm ơn bạn đã quan tâm đến bài viết. Mình xin trả lời câu hỏi của bạn như sau:

1. Không phát sinh lỗi bạn nhé, mình đang cần lấy dữ liệu trong controller PrtController để show thông qua file product.view.html như ở trên, vì thế nên ta phải khai báo controller cho state product ở file app. (Mình đã sửa lại phần chú thích của state product)
2. Điều này hoàn toàn bình thường nhé bạn.

bài viết hay, hình như Swift Package Manager chưa dùng được cho ios đúng không bạn? mình hay dùng ObjectMapper cùng phần mềm "JSONExport" , mình góp ý thêm phần mềm JSONExport này để tạo modal tự động nhanh chóng hơn khi thao tác vs server trong dự án :v. https://github.com/Ahmed-Ali/JSONExport

Tks ông bạn. ahihi đồngôk :v

hay lắm :v

Bài viết hay, rõ. Có rất nhiều người đi làm kinh nghiệm lâu rồi cũng chưa thể (chữa rõ) nói rõ như bạn được . Bạn có thể nói rõ hơn đoạn này được không? "Kiểm tra và diễn dịch kiểu của một instance của một class lúc runtime". Và "website uy tín trên thế giới" bạn hay đọc cho mọi người tham khảo được không? Cám ơn bạn @Le.Van.Tuan về bài viết.

@quynh001 Đúng là dùng Facade như em nói sẽ phải khai báo use class, nhưng đừng quên những class Facade đều được khai báo alias ở file config/app.php, do đó để dùng Facade Request em chỉ cần use Request là được. Trong khi để dùng Dependency Injection thì em sẽ phải nhớ và use một cái class rất dài, và đôi lúc không giống với tên Facade mà thường dùng. (ví dụ như facade Cache thì class tương ứng là Illuminate\Cache\Repository, danh sách em có thể xem ở https://laravel.com/docs/5.4/facades#facade-class-reference) Vì thế nên đôi lúc sử dụng Facade thì tiện lợi và dễ dùng hơn là dependency injection nhiều. Có điều là như anh đề cập ở trên thì dùng Facade sẽ gây khó khăn cho những người mới tiếp xúc với Framework trong việc tìm hiểu sâu bên dưới, như tìm xem một hàm của Facade từ đâu đến, nó nằm ở đâu, được code như thế nào.

Còn việc "Có quá nhiều cách thực hiện một công việc mà giữa chúng chẳng đem lại lợi ích gì khác biệt." thì anh cũng không nghĩ rằng đó lại là một điểm "chưa tốt" của framework. Có thể đôi lúc có nhiều cách thật đấy, nhưng mà bản chất của chúng lại liên quan mật thiết với nhau mà. Và cũng coi như đấy là những giải giáp mà framework cung cấp cho chúng ta đi, còn việc chúng ta sử dụng giải pháp nào là do team quyết định. Trong team nên có những convention, thống nhất trong team thì sẽ tốt hơn Cũng giống như làm việc với một ngôn ngữ lập trình vậy, để giải quyết một vấn đề đơn giản, đôi khi ta cũng có rất nhiều cách mà.

cho tớ skype củ bạn Nguyen Thi Thuy Ngan bạn viết bài hay quá thui bạn add skype tớ : Quý Khả Nguyễn