10 dự đoán hàng đầu của ngành IT trên toàn thế giới

Theo báo cáo thứ ba từ International Data Corporation (IDC), đến năm 2023, gần như mọi doanh nghiệp sẽ hoạt động theo cơ chế ‘digital native’ khi nền kinh tế toàn cầu số hóa tiếp tục mở rộng. Tổ chức này đã đưa ra 10 dự đoán cho bối cảnh nền công nghiệp IT chuyển sang năm 2019 và hơn thế nữa, khi các nhà lãnh đạo CNTT và doanh nghiệp tiếp tục trải qua chuyển đổi kỹ thuật số (Digital Transformation).

Các tổ chức đang được xây dựng lại xung quanh các công nghệ nền tảng thứ 3 như Cloud, Mobile, phân tích big data, phương tiện truyền thông xã hội và được kích hoạt thêm bởi các “công cụ tăng tốc đổi mới” như Internet of Things (IoT), trí tuệ nhân tạo (AI) và tăng cường và thực tế ảo (AR / VR). Mặc dù nhiều tổ chức đang trên đường chuyển đổi bằng cách sử dụng các công nghệ này, nhưng chương tiếp theo về đổi mới công nghệ sẽ yêu cầu các công ty mở rộng phạm vi kỹ thuật số, cải thiện trí thông minh, tăng phát triển ứng dụng và dịch vụ cũng như đáp ứng nhu cầu bảo mật và nhu cầu của khách hàng. Còn bây giờ, hãy điểm qua 10 dự đoán hàng đầu của ngành IT trên toàn thế giới của IDC.

1. Đến năm 2022, hơn 60% GDP toàn cầu sẽ được số hóa với sự tăng trưởng trong mọi ngành được thúc đẩy bởi các dịch vụ, hoạt động và mối quan hệ được tăng cường kỹ thuật số.

Theo báo cáo, các nỗ lực chuyển đổi kỹ thuật số phải dẫn đầu trong danh sách ưu tiên của các nhà lãnh đạo doanh nghiệp cấp cao. Và những người không chuyển đổi hoạt động cũng như dịch vụ của họ sẽ thua trong cuộc cạnh tranh này vì thị trường truyền thống đã bị phá vỡ.

2. Đến năm 2023, 75% tổng chi tiêu cho CNTT sẽ dành cho các công nghệ platform thứ 3, vì hơn 90% tất cả các doanh nghiệp muốn xây dựng một môi trường CNTT đúng chất “digital native” để phát triển mạnh trong nền kinh tế kỹ thuật số.

Theo IDC, gần một nửa số doanh nghiệp nói rằng họ “digitally determined”, có nghĩa là họ đã đặt ra để phát triển một chiến lược và kiến trúc kỹ thuật số tích hợp khả năng bắt chước các tổ chức “digital native” (dân cư số). Điều này có nghĩa là họ sẽ sử dụng Cloud, Agile và DevOps, các nền tảng và cộng đồng đổi mới kỹ thuật số và quản lý dữ liệu tích hợp và kiếm tiền.

3. Đến năm 2022, hơn 40% triển khai Cloud của các tổ chức sẽ bao gồm Điện toán ranh giới (edge computing) và 25% thiết bị và hệ thống điểm cuối sẽ thực hiện các thuật toán AI.

Cơ sở hạ tầng đám mây và các ứng dụng và dịch vụ doanh nghiệp đã chuyển sang Edge Computing để tăng sự kết nối với các thiết bị và nguồn dữ liệu. “Các dịch vụ AI sẽ là một trong những dịch vụ Cloud công cộng đầu tiên và biến đổi nhất, được phân phối trên các rìa biên giới.

4. Đến năm 2022, 90% tất cả các ứng dụng sẽ có kiến trúc microservice góp phần cải thiện khả năng thiết kế, gỡ lỗi, cập nhật và tận dụng code của bên thứ ba; 35% của tất cả các ứng dụng sản xuất sẽ có nguồn gốc từ Cloud.

Trong nền kinh tế kỹ thuật số, các công ty phải cung cấp các ứng dụng chất lượng cao và đủ nhanh để đáp ứng nhu cầu kinh doanh. Điều này đang thúc đẩy sự chuyển đổi sang “ứng dụng hyperagile” hoặc những ứng dụng có tính mô đun hóa cao, phân tán, cập nhật liên tục và sử dụng các công nghệ dựa trên đám mây như container và máy tính không có máy chủ. Việc kết hợp các ứng dụng này với các phương pháp Agile và DevOps sẽ giúp cho doanh nghiệp có thể tăng tốc khả năng đổi mới so với các phương pháp trước đây.

5. Đến năm 2024, một thế hệ mới các developer sẽ code mà không cần kịch bản tùy chỉnh, điều này sẽ giúp mở rộng nguồn nhân lực về developer thêm 30%, đẩy nhanh chuyển đổi kỹ thuật số.

Sự gia tăng của các nền tảng phát triển low code, no code và các công cụ phát triển theo mô hình sẽ cung cấp cho các doanh nghiệp tiếp cận đến một lớp các nhà phát triển mới mà ở đó có thể ứng dụng nhiều giải pháp kỹ thuật số hơn. Đến năm 2024, IDC dự đoán các nhà phát triển mới sẽ tăng tổng số developer toàn cầu lên gần một phần ba.

6. Từ năm 2018 đến năm 2023, với nhiều công cụ/nền tảng mới hơn, nhân lực nhiều hơn, các phương thức agile và cả những lần sử dụng lại code, tất cả sẽ tạo ra hơn 500 triệu ứng dụng logic mới tương đương với số lượng được xây dựng trong hơn 40 năm qua.
7. Báo cáo lưu ý, việc chuyển sang các công nghệ ứng dụng hyperagile và sự bùng nổ của nhân lực developer nhờ low code và các công cụ không cần code sẽ dẫn đến sự tăng trưởng nhanh chóng trong phát triển ứng dụng và dịch vụ cũng như tốc độ và quy mô triển khai.
   “Khả năng tăng tốc khối lượng và tốc độ đổi mới kỹ thuật số sẽ là chuẩn mực mới quan trọng nhất cho các tổ chức cạnh tranh trong nền kinh tế kỹ thuật số”, Gens cho biết trong bản phát hành.
   7. Đến năm 2022, 25% điện toán đám mây công cộng sẽ dựa trên các bộ xử lý không nhất thiết phải là x86; đến năm 2022, các tổ chức sẽ đầu tư nhiều hơn cho các ứng dụng SaaS dọc (đáp ứng nhu cầu của một ngành cụ thể) so với các ứng dụng ngang (tập trung vào một danh mục phần mềm).
   Số lượng các trường hợp sử dụng được phục vụ bởi CNTT sẽ tăng đáng kể trong những năm tới, tạo ra nhiều nhu cầu CNTT chuyên biệt. Các yêu cầu xử lý AI đang thúc đẩy nhu cầu về bộ xử lý mạnh hơn và các tổ chức đang chọn Saas dọc nhiều hơn  gần gấp đôi so với các ứng dụng ngang.
   
   8. Đến năm 2024, giao diện người dùng hỗ trợ AI và tự động hóa quá trình sẽ thay thế một phần ba số lượng screen-based apps ngày nay. Đến năm 2022, 30% doanh nghiệp sẽ sử dụng công nghệ đàm thoại để thu hút khách hàng.
   AI sẽ ngày càng được sử dụng làm giao diện người dùng chính cho một số ứng dụng và dịch vụ, đồng thời, tự động hóa quá trình do AI điều khiển sẽ hợp lý hóa và thay thế các nhiệm vụ của con người. Điều này sẽ ngày càng trở thành định mức để tối đa hóa năng suất của nhân viên, theo báo cáo.
   9. Đến năm 2022, 50% máy chủ sẽ mã hóa dữ liệu khi tiến vào trạng thái nghỉ ngơi và cả vận hành; hơn 50% cảnh báo bảo mật sẽ được xử lý bằng tự động hóa do AI cung cấp; và 150 triệu người sẽ có ID kỹ thuật số dựa trên Blockchain.
   
   
   
   Các công nghệ mới nổi như mã hóa lan tỏa, blockchain, học máy và phân tích sẽ được sử dụng để cải thiện các biện pháp bảo mật trên toàn doanh nghiệp.
   10. Đến năm 2022, top 4 “megaplatforms” hàng đầu sẽ lưu trữ 80% việc triển khai IaaS/PaaS, đến năm 2024, 90% các tổ chức G1000 sẽ giảm thiểu khóa thông qua các công cụ cũng như các công nghệ đám mây đa nền tảng và hybrid.
   Trong những năm tới, các doanh nghiệp sẽ nắm lấy các công cụ và chiến lược tích hợp và đa đám mây, báo cáo cho biết. “Thiếu một chiến lược tích hợp sẽ dẫn đến việc phân bổ nguồn lực dưới mức tối ưu, truy cập hạn chế vào các đổi mới công nghệ có sẵn tốt nhất, thời gian giải quyết và xác định vấn đề dài hơn và giới hạn
   Techtalk via techrepublic.com

Read More

Chỉ với mẩu giấy dán mặt đường, phòng nghiên cứu bảo mật của Tencent hack thành công xe Tesla

Đây không phải lần đầu tiên Keen Lab tìm ra lỗ hổng bảo mật trên xe Tesla.

Nhóm hacker tại Trung Quốc vừa tìm ra cách đánh lừa xe Tesla rất ư đơn giản: bằng những hình dán trên đường được đặt một cách có tính toán, họ dụ được chiếc Tesla Model S đi vào làn đường sai. Cách thức trên do Keen Lab, một trong những nhóm nghiên cứu bảo mật công nghệ hàng đầu trên thế giới, thực hiện.

Không chỉ một, mà họ còn khám phá ra hai cách để tấn công vào hệ thống nhận dạng làn đường của hệ thống tự lái xe Tesla.

Đầu tiên, họ tìm cách thay đổi các dấu mốc nhận biết dưới mặt đường, bằng cách đặt thêm những miếng dán lên vạch phân làn để làm cho nó mờ đi trước camera nhận dạng. Thử nghiệm chứng minh phương cách này hiệu quả, nhưng theo các nhà nghiên cứu bảo mật, việc dán giấy lên vạch phân làn rất lộ liễu, chưa kể đây là hành động phạm pháp rõ ràng.

Thế nên các nhà nghiên cứu tạo ra những “làn đường giả”. Họ phát hiện ra hệ thống lái tự động của Tesla sẽ phát hiện làn đường nếu như nhận thấy có 3 hình dán nhỏ được đặt một cách có tính toán trên mặt đường.

Khi họ đặt những miếng dán tại một giao lộ, họ dự đoán chiếc Tesla sẽ nhận nhầm miếng dán là dấu hiệu cho thấy nó vẫn đi đúng đường. Trên đường chạy thử, hệ thống tự lái của Tesla đã đi nhầm lối, đúng như những gì các nhà nghiên cứu bảo mật dự tính.

“Thí nghiệm của chúng tôi chứng minh hệ thống có lỗ hổng bảo mật và cho thấy nhận dạng đường ngược chiều là một trong những yếu tố tối quan trọng của hệt hống tự lái“, báo cáo nghiên cứu của Keen Lab ghi rõ.

“Trong thử nghiệm chúng tôi dựng lên, nếu như chiếc xe biết làn đường nó đang đi sẽ dẫn sang đường một chiều, nó sẽ biết được đây là làn đường giả để không đi vào, tránh gây tai nạn“.

Để chiếm được quyền điều khiển vô lăng, các nhà nghiên cứu bảo mật phải qua một loạt các bước phức tạp để thâm nhập vào hệ thống. Có điều đáng chú ý là lúc hack hệ thống, họ đang ngồi ngay trên xe; bên cạnh đó, việc hack không thể thành công khi xe bắt đầu chạy với tốc độ trên 8 km/h. Tuy nhiên, khi xe đang bật chế độ hỗ trợ lái Cruise Control, việc hack diễn ra “không có trở ngại”.

Để chiếm quyền điều khiển … cần gạt nước, các nhà nghiên cứu có vẻ còn tốn công sức hơn: Họ phải lừa chiếc Tesla để nó tin rằng trời đang mưa. Làn đường giả để đi nhầm thì dễ, chứ theo Keen Lab, đổi nắng thành mưa hơi vất vả.

Bạn có thể xem video về toàn bộ quá trình hack tại đây.

Đây không phải lần đầu tiên Keen Lab tìm ra vấn đề với hệ thống bảo mật của Tesla. Hồi 2016, đã có lần họ tìm ra cách chiếm quyền điều khiển hệ thống phanh.

Tháng Ba vừa rồi, tại hội chợ về bảo mật CanSecWest, có màn thử thách hack xe Tesla với giải thưởng lên tới 900.000 USD. Chỉ có một đội duy nhất tìm ra được khe hở: hai nhà nghiên cứu bảo mật là Richard Zhu và Amat Cama hack trình duyệt trên xe, cho nó hiển thị nội dung như họ mong muốn.

Hai hacker ra về với 35.000 USD đút túi và chiếc xe Tesla.

Techtalk via cafebiz

Read More

Robot chim đà điểu sắp xếp hàng hoá hoàn hảo thế này, nhân viên nhà kho chuẩn bị thất nghiệp đi là vừa!

Viễn cảnh tương lai là nhà kho sẽ vắng bóng người và toàn những robot thế này.

Boston Dynamics là một công ty nghiên cứu và sản xuất robot rất nổi tiếng, họ đã từng làm ra những robot có thể chạy, nhảy, lộn ngược và vừa qua, Boston Dynamics đã ra mắt thêm một robot mới, vốn là bản nâng cấp của robot Handle từ năm 2017. Handle 2019 được cải thiện khả năng sắp xếp các thùng giấy rất đáng kinh ngạc nhờ thiết kế như chim đà điểu.

Robot Handle lúc đầu được Boston Dynamics thiết kế chủ yếu như là một thử nghiệm khả năng làm việc của robot có bánh xe so với robot hình người. Phiên bản mới đã được hoàn thiệt hơn về thiết kế và giờ có thể thật sự tự động chất và bốc dỡ các thùng hộp trong nhà kho, như bạn thấy trong video.

Thật dễ dàng để thấy Handle rất có tiềm năng sử dụng trong các nhà kho lớn, như của Amazon chẳng hạn. Chúng ta có thể tưởng tượng cảnh một “đội quân” robot chạy đi chạy lại để sắp xếp hàng hoá thành từng chồng khổng lồ một cách hoàn hảo.

Về mặt kỹ thuật, Boston Dynamics cho biết Handle có thể nâng một kiện hàng hoá nặng 30 pound (khoảng 13kg) và xếp chồng lên cao đến 167cm. Các hệ thống xử lý hình ảnh sẽ giúp Handle nhìn thấy và cầm các hộp và theo dõi xem chúng nằm ở khu vực nào.

Cũng như nhiều dự án khác của Boston Dynamics, hiện tại Handle chỉ là một phiên bản thử nghiệm, công ty chưa có kế hoạch thương mại hoá. Tuy nhiên, thật dễ dàng để thấy Handle rất có tiềm năng sử dụng trong các nhà kho lớn, như của Amazon chẳng hạn. Chúng ta có thể tưởng tượng cảnh một “đội quân” robot chạy đi chạy lại để sắp xếp hàng hoá thành từng chồng khổng lồ một cách hoàn hảo.

Techtalk via cafebiz

Read More

Mobile First trong Web Responsive Design

1. Mở đầu

---

Đối với các bạn làm Web Developer ở phía Front-end hay Back-end chắc hẳn không còn xa lạ gì với khái niệm Web Responsive Design (WRD) nữa, nó là một phương pháp giúp cho trang web của bạn có thể hiện thị tốt trên các loại màn hình khác nhau như Desktop, Laptop, Tablet hay Mobile

WRD dường như tồn tại trong mọi website mà bạn truy cập hàng ngày và cũng như trong mọi sản phẩm web mà bạn tham gia phát triển. Trước đó mình làm chủ yếu với Back-end bằng Laravel tuy nhiên gần đây mình có cơ hội tham gia làm responsive cho giao diện web và đã thử đang thực hiện WRD theo hướng cả hai hướng Mobile First + Desktop First. Sau khi tìm hiểu kĩ hơn thì hiện tại mình đã chuyển theo phương pháp duy nhất là Mobile First vì những ưu điểm mà theo mình nó mang lại nhiều hơn so với Desktop First. Bài viết này của mình sẽ chia sẻ với các bạn những điều mà mình tìm hiểu về cả hai được.

2. WRD

---

Đầu tiên chúng ta sẽ cùng nhau tìm hiểu về sự khác nhau trong việc phát triển WRDtheo lần lượt Desktop First và Mobile First.

a. Desktop First

Đối với phương pháp Desktop First giao diện của bạn sẽ được ưu tiên code sao cho phù hợp với màn hình Desktop của bạn trước rồi sau đó mới tiếp tục thêm code CSS mới vào bằng @media query sao cho giao diện và bố cục trang web của bạn phù hợp với các màn hình bé hơn lần lượt là Laptop, Tablet và Mobile. Quá trình phát triển sẽ có dạng như sau:

Giả sử chúng ta có một đoạn code HTML và CSS đơn giản như sau (link tham khảo):

1 2 3 4 5 6 7 8 9 10 11 12

<!DOCTYPE html> <html> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <body style="margin: 20px 50px"> <h2 class="title">Setting the Viewport</h2> <p class="content">This example does not really do anything, other than showing you how to add the viewport meta element.</p> </body> </html>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

.title {   color: red; } .content {   color: blue; } @media only screen and (max-width: 1024px) {   .title {     color: orange;   }   .content {     color: aqua;   } } @media only screen and (max-width: 768px) {   .title {     color: brown;   }   .content {     color: green;   } }

Đối với phương pháp Desktop First chúng ta sẽ sử dụng thuộc tính max-width như bạn thấy trong đoạn code CSS. Hay nói cách khác, giao diện của chúng ta sẽ thay đổi nếu chiều rộng (width) của màn hình hiện tại nhỏ hơn hoặc bằng các break point, mà chúng ta đặt ra ở trên. Các break point bạn có thể hiểu chính là chiều rộng (width) của màn hình mà chúng ta muốn giao diện thay đổi và ở đây sẽ là này lần lượt là 1024px và 768px. Kết quả đoạn code trên sẽ cho ta kết quả như sau:

• Ở màn hình Desktop giao diện sẽ có dạng:

• Khi màn hình của chúng ta chạm break point đầu tiên hay nói cách khác có động rộng nhỏ hơn hoặc bằng với 1024px thì sẽ có dạng như sau:
• Và cuối cùng khi chạm break point cuối cùng là chiều rộng màn nhỏ hơn hoặc bằng 768px sẽ có dạng như sau:

Với cách làm nói trên thì với màn Desktop hay có thể nói là mặc định thì tiêu đề và nội dung sẽ có màu đỏ và xanh lục. Với màn hình nhỏ hơn nó cụ thể ở đây có thể coi là màn Tablet (<= 1024px) thì tiêu đề và nội dung sẽ có màu cam và xanh nhạt hơn. Và cuối cùng ở màn hình Mobile (<= 768px) sẽ có màu nâu và xanh lá cây.

b. Mobile First

Ngược lại đối với Desktop First thì ở phương pháp này, giao diện web của bạn sẽ được thực hiện theo hướng từ thiết bị có màn hình nhỏ (Mobile) rồi mới đến các thiết bị có màn hình lớn hơn lần lượt là Tablet, Laptop và Desktop. Tương tự với Desktop First thì chúng ta cũng sẽ sử dụng @media query của CSS để thực hiện quá trình này. Cụ thể nó sẽ như sau:

Chúng ta sẽ sử dụng lại ví dụ giống như trên và chỉ thay đổi lại 1 chút như sau (link tham khảo):
1 2 3 4 5 6 7 8 9 10 11 12

<!DOCTYPE html> <html> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <body style="margin: 20px 50px"> <h2 class="title">Setting the Viewport</h2> <p class="content">This example does not really do anything, other than showing you how to add the viewport meta element.</p> </body> </html>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

.title {   color: brown; } .content {   color: green; } @media only screen and (min-width: 768px) {   .title {     color: orange;   }   .content {     color: aqua;   } } @media only screen and (min-width: 1024px) {   .title {     color: red;   }   .content {     color: blue;   } }

Đối với Mobile First ta sẽ sử dụng thuộc tính min-width thay vì max-width như Desktop First. Lúc này giao diện của chúng ta cũng sẽ thay đổi khi chạm các break point cụ thể nếu màn hình của chúng ta có độ rộng (width) lớn hơn hoặc bằng các break point mà chúng ta đặt ra thì (768px, 1024px). Khi bạn chạy đoạn code trên sẽ thấy kết quả thu được giống hệt với phương pháp đầu tiên, chỉ có điều cách làm ngược lại.
Nói chung với mỗi phương pháp sẽ khác nhau như sau:
Desktop First:
• Sử dụng max-width
• Giao diện thay đổi khi độ rộng màn hình nhỏ hơn hoặc bằng break point
Mobile First:
• Sử dụng min-width
• Giao diện thay đổi khi độ rộng màn hình lớn hơn hoặc bằng break point
Có thể bạn quan tâm
67 công cụ hữu ích, thư viện và tài nguyên để tiết kiệm thời gian cho web developer
Từ MVC đến các Modern Web Framework

3. Tại sao Mobile First ?

---

Như ví dụ mình đưa ra ở trên, bạn có thể thấy chúng ta sẽ thu được kết quả giống hệt nhau thế thì câu hỏi đặt ra là tại sao lại chia ra làm hai hay tại sao lại là Mobile First.

a. Số lượng thiết bị Mobile

Ngày nay số lượng các thiết bị di động được sử dụng ngày càng nhiều lên so với thiết bị desktop. Điều này đơn giản là do sự tiện dụng bởi ta có thể mang theo một chiếc điện thoại di động mọi lúc mọi nơi và truy cập vào internet tức thì. Còn đối với Desktop thì việc này thì không thể, hãy tưởng tượng ta phải luôn vác theo 1 màn hình và 1 cái case máy tính cùng đống dây dợ lằng nhằng xem.

Chính vì lý do này mà số lượng thiệt bị Mobile càng ngày càng tăng đồng nghĩa với việc truy cập internet từ Mobile cũng tăng nên sẽ không có gì lạ nếu người dùng truy cập vào website của bạn từ Mobile nhiều hơn so với các thiết bị khác. Mình có xin được một bức ảnh thu được từ Google Analytic về lượng traffic truy cập vào trang web của bạn mình và kết quả nó như sau:

Như bạn thấy lượng truy cập vào từ Mobile là tận 77.4% so với Desktop chỉ có 17.9%, một khác biệt khá lớn. Vì thế ngay từ đầu nếu bạn đi theo con đường Mobile First thì sẽ tối ưu rất nhiều cho các thiết bị Mobile.

b. Tối ưu nội dung

Đối với mỗi trang web chúng ta có thể thấy chứa rất nhiều nội dung khác nhau nằm trong nó. Với màn hình desktop rộng lớn, ta có thể cho vô vàn các nội dung, các thành phần khác nhau như sidebar, slider, .. để tăng lượng thông tin xuất hiện trên màn hình của chúng ta:

Tuy nhiên khi màn hình của chúng ta bé đi rất nhiều, cụ thể là kích cỡ màn chỉ còn một nửa hoặc 1/6 kích cỡ ban đầu thì chắc chắn chúng ta sẽ cần phải tối ưu hóa lại nội dung, tối ưu hóa lại các thành phần xuất hiện trên trang web bằng cách xóa cái nọ bỏ cái kia và cân đo đong đếm xem trong đống nội dung trong màn hình chỗ nào cần chỗ nào không. Việc bạn mất công thêm thắt đủ các thứ vào cái màn to kia để cho nó là hoàn hảo trong mắt bạn rồi lại phải xóa dần đi thì thật khó chịu. Nhưng với phương pháp Mobile First thì ngay từ đầu màn hình chúng ta chỉ có kích thước vỏn vẹn khoảng 320px chiều rộng nên tất nhiên chúng ta sẽ cần phải tập chung vào nội dung cũng như các thành phần quan trọng nhất mà người dùng mong muốn và có thể chưa cần suy nghĩ đến các thứ màu mè khác.

Sau đó khi phát triển lên các màn hình tiếp theo, ta có thể thoải mái hơn khi thêm các nội dung mới hay các thành phần mới như slider, side-bar vào.

c. Hạn chế lỗi

Như bạn biết tới thời điểm hiện tại, số lượng các thiết bị với kích cỡ màn hình khác nhau là nhiều vô cùng và chúng ta không có cách nào để code giao diện với break point phù hợp với từng màn hình một

Với ví dụ đơn giản nói trên thì tất nhiên không có vấn đề gì cả tuy nhiên giao diện thực tế của bạn sẽ phức tạp hơn rất nhiều. Để minh chứng cho điều trên ta sẽ có thêm một giao diện như sau (link tham khảo) theo hướng Desktop First (với độ rộng ban đầu 1440px):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<!DOCTYPE html> <html> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.7.2/css/all.css" integrity="sha384-fnmOCqbTlWIlj8LyTjo7mOUStjsKC4pOpQbqyi7RrhN7udi9RwhKkMHpvLbHG9Sr" crossorigin="anonymous"> <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/meyer-reset/2.0/reset.min.css"> <link href="https://fonts.googleapis.com/css?family=Roboto" rel="stylesheet"> <body>   <div class="header">     <i class="fas fa-bars"></i>     <h2 class="logo">MY LOGO</h2>     <ul class="nav">       <li>HOME</li>       <li>PRODUCT</li>       <li>PRICING</li>       <li>ABOUT US</li>       <li>CONTACT</li>     </ul>   </div> </body> </html>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

body {   overflow-x: hidden; } body h2, body li{   font-family: 'Roboto', sans-serif; } .header {   background-color: white;   box-shadow: 0 0.25rem 0.125rem 0 rgba(0,0,0,0.05);   height: 64px;   display: flex;   justify-content: space-between;   align-items: center;   padding: 0 20px; } .logo {   font-weight: bold;   font-size: 25px; } .header i {   display: none; } .nav {   display: flex;   flex-flow: wrap; } .nav li {   line-height: 30px;   width: 100px;   text-align: center; } @media only screen and (max-width: 633px) {   .nav {     display: none;   }   .header i {     display: block;     position: absolute;     left: 20px;   }   .header {     justify-content: center;   } }


Như trên là kết quả ta đạt được sau khi thực hiện style cho giao diện desktop. Tiếp theo với giao diện Tablet (với kích cỡ 768px). Do thanh header của chúng ta khá đơn gian nên khi bạn thử thu nhỏ màn hình xuống kích cỡ này sẽ thấy giao diện vẫn rất ổn nên không cần sửa gì cả:

Tiếp theo với giao diện mobile. Các kích thước mình chọn ở đây là các kích thước tương ứng khi ta sử dụng công tụ test responsive trong Chrome Dev Tool:

Kích cỡ màn mobile lớn nhất đầu tiên mình thấy trong Chrome Dev Tool là 633px (kích cỡ khi ta quay ngang màn hình), ta sẽ sửa giao diện thành như sau:

Đến đây nghe chừng có vẻ là ổn ổn rồi, tuy nhiên tự nhiên một ngày nào đó có cái màn quái dị nằm giữa 768px và 633px của bạn thì điều sau đây sẽ xảy ra (644px):

Điều này sở dĩ xảy ra là do giao diện của bạn chỉ thay đổi nếu độ rộng màn hình của nó nhỏ hơn hoặc bằng 633px nên khoảng giữa các break point hoàn toàn có thể xảy ra lỗi nhất là khi bạn có một giao diện phức tạp. Tuy nhiên nếu bạn chọn đi theo con đường Mobile First thì giao diện của bạn ban đầu sẽ có dạng:

Giao diện bạn thấy ở trên sẽ duy trì cho đến khi màn hình của bạn có kích cỡ lớn hơn hoặc bằng 768px thì nó mới chuyển thành như thế này:

Như vậy bạn có thể đảm bảo được rằng giữa các break point theo hướng mobile first sẽ không làm vỡ giao diện của bạn nếu gặp 1 số kích cỡ màn hình hơi lại một chút vì nó sẽ mãi mãi nhìn giống giao diện mobile cho đến khi nó đủ lớn – hay chính xác là kích cỡ màn lớn hơn hoặc bằng 768px. Nếu bạn chưa tin thì có thể xem thử ví dụ trên nhưng với phiên bản Mobile First ở đây.
d. Lý do khác
• Nếu bạn tìm hiểu về SEO thì chắc hẳn bạn cũng biết được rằng chính Google cũng yêu cầu rất cụ thể về mobile friendly nếu bạn muốn trang web của bạn đạt được đánh giá cao
• Chắc hẳn các bạn cũng không hề lạ với các thư viện hỗ trợ việc Front-end như Bootstrap. Chính bản thân Boostrap cũng đi theo hướng Mobile First, nếu không tin bạn có thể tự mở code của bootstrap lên xem sẽ thấy được điều này
4. Kết bài
---
Qua những gì mình vừa chia sẻ trong bài viết mong rằng bạn sẽ tăng thêm được một chút kiến thức về Responsive Web Design. Cám ơn bạn đã đọc bài !!!
Techtalk via Viblo

Read More