Phân trang đơn giản là ta sẽ chia một tập dữ liệu lớn và truyền cho user thành từng phần nhỏ hơn. Hãy tưởng tượng, bạn đang thiết kế một hệ thống backend cho phía frontend của một trang tin tức, phía FE muốn một lệnh API để có lấy dữ liệu các bài viết từ database của bạn.
Bài toán sẽ khá đơn giản nếu bạn chỉ có 10-20 bài viết, bạn chỉ cần làm theo cách truyền thống, lấy dữ liệu từ database từ backend, gửi một file json chứa dữ liệu cho FE, mọi thứ nghe có vẻ đơn giản.
Tuy nhiên khi tập dữ liệu của ta ngày càng lớn, ví dụ, lúc này 1 Model bài viết có rất nhiều trường (ảnh đại diện, chuyên mục, thời gian đăng, ….), và ta có hàng 1000-10000 bài viết, việc trả 1 lần tập dữ liệu lớn như thế sẽ làm chậm ở 2 chỗ:
Lấy toàn bộ dữ liệu từ database tốn thời gian
Truyền 1 lần dữ liệu lớn như vậy sẽ rất nặng, tốn tiền mạng thật sự của user (tải 1 file lớn mỗi lần), và lúc tải 1 file lớn như thế cũng rất chậm, tốn thời gian, gây khó chịu người dùng
Tổng kết 1
Khi đó, ta có thể sử dụng đến phân trang, và mỗi lần người dùng chỉ có thể xem 1 trang, ta chỉ gửi khoảng 10-15 bài viết 1 lần thôi, khi người dùng sang trang khác ta sẽ gửi tập dữ liệu khác, khá đơn giản.
Triển khai phân trang bằng Spring Boot
Triển khai Model
Triển khai Repository
Để có thể truy cập các JPA Entity trên từ database, ta sẽ tạo 1 PostRepository
JPARepository đã kế thừa sẵn một interface là PagingAndSortingRepository của Spring hỗ trợ việc phân trang và sắp xếp. Dù là một interface, không có implemention, nhưng khi chương trình khởi chạy, Spring sẽ tự động generate các code implemention thật cho chúng ta, thực thi các thao tác với database, và chúng ta chỉ cần define các method có sẵn thôi.
Phân trang
Do Spring đã làm đa số các phần code, giờ ta chỉ cần triển khai thêm 2 việc
Tạo một PostPageRequest class, implement từ Pageable interface của Spring
Truyền tham số cần tìm cho PostPageRequest
Khi implement interface Pageable, ta sẽ phải triển khai một số hàm. Lúc này class PostPageRequest sẽ như một object “trang” , kiểu trang 5 thì là một object Trang, trang 6 là một object khác. Từ object trang đó ta có thể lấy trang tiếp theo, trang phía trước, các bài viết trong trang,….
offset và limit
Bạn có thể thấy trong code trên có các tham số offset và limit. Hai tham số trong sql có ý nghĩa như sau
offset x : Lùi x kết quả từ dãy kết quả trả ra
limit y: Từ danh sách kết quả trả ra, lấy y kết quả đầu tiên.
Ví dụ: ta có các bài viết đánh số từ 1-100. offset 5 thì ta sẽ có danh sách là 6-100. limit tiếp 10 thì ta có danh sách 6-16…
Nếu bạn đã hiểu định nghĩa offset và limit, hãy thử đọc lại code bên trên, bạn sẽ dễ dàng hiểu được các method lấy trang tiếp theo, lấy trang trước, …. đang làm gì.
Tổng kết 2
Như vậy, ta đã triển khai được phân trang bằng Spring Boot, tuy nhiên liệu như vậy đã tối ưu cho trang web của bạn chưa?
Tối ưu limit và offset trong MySQL
Offset
Query Duration (ms)
0
1
50
1
1000
13
10000
150
25000
500
50000
930
100000
1750
Những biểu đồ và bảng
Ta có thể thấy, bằng việc dùng offset để lùi kết quả đi một đoạn, rồi lấy limit để lấy lượng bài ở trang đó nghe có vẻ rất đơn giản, dễ hiểu. Nhưng thực tế trong MySQL chúng được thực hiện như sau:
…the rows are first sorted according to the <order by clause> and then limited by dropping the number of rows specified in the <result offset clause> from the beginning…
…các dòng đầu tiên được sắp xếp (ví dụ theo id, thời gian đăng bài…) sau đó xóa x hàng đầu tiên được yêu cầu khi sử dụng offset
Nếu bạn nghĩ kĩ, câu lệnh offset chỉ nhận đúng 1 tham số: lượng dòng bị bỏ qua cho đến tập kết quả muốn nhận.
Cách duy nhất hệ thống database có thể làm điều này là lấy toàn bộ dữ liệu cần tìm, sau đó ném đi x hàng đầu bạn đã đặt ra yêu cầu. Khi offset đủ lớn, lượng công việc cho database sẽ rất nhiều và thời gian để truy vấn sẽ tăng khó kiểm soát.
Khi sử dụng offset, ta mở trang đầu tiên, trang thứ 2, thời gian mất chỉ 1ms (1 phần nghìn giây), gần như không có vấn đề gì.
Trang thứ 10000, 150ms, vẫn chưa nhận ra điều gì quá lo ngại
100000 1750ms, 1,75 giây.
Ta có thể thấy, nếu người dùng mở 1 trang càng xa, hiệu suất của trang sẽ càng giảm, việc một user mở trang thứ 10000 có thể gây vấn đề hiệu năng hơn nhiều cho database hơn 100 người dùng khác mở trang 1
Hướng khắc phục
Trước hết, ta cần tìm hiểu xem những hệ quản trị cơ sở dữ liệu đang làm gì để sắp xếp dữ liệu của chúng ta. Ta sẽ assume hệ cơ sở dữ liệu đang sử dụng một B-Tree để index database (một bản nâng cấp của cây nhị phân cân bằng).
Nếu bạn chưa từng nghe đến cụm từ trên, bạn có thể tìm hiểu ở link sau:
Lúc này database của chúng ta lưu dữ liệu theo dạng như sau:
Khi ta sử dụng offset 0, limit 5 để lấy 5 bài viết đầu tiên chẳng hạn, database sẽ chạy các kết quả sau
SELECT * FROM my_table ORDER BY id LIMIT 5
Tuy nhiên, với offset, sau khi offset 5 và limit 5, ta có
Như vậy, ta phải đi qua 5 cái đầu trước, bỏ dần nó, rồi sau đó mới limit 5 cái sau. Khá là tốn thời gian
Vấn đề: Database không biết điểm khởi đầu của trang tiếp theo ở đâu, vì vậy nó cứ phải bỏ dần các hàng phía trước cho đến khi đến được vị trí chỉ định
=> Khắc phục: Ta nhớ xem vị trí lần cuối là ở đâu ?
Kĩ thuật: keyset pagination and seek method
Ở một số trang web, bạn sẽ thấy, bạn không thể đi đến thẳng trang cuối, hoặc nhảy đến 1 trang bất kì, mà thông thường sẽ có nút để sang trang kế và trang phía trước. Như vậy ta có thể assume rằng:
Người dùng sẽ chỉ mở trang 10 sau khi mở trang 9.
Vậy, ta chỉ cần nhớ vị trí cuối cùng của bài viết ở trang 9 là ở id bao nhiêu, rồi dùng WHERE để truy vấn từ điểm đó, chứ không cần bỏ dần để đi đến điểm đó nữa
SELECT * FROM my_table WHERE id > 21 ORDER BY id LIMIT 5
Ví dụ: Sort theo thời gian
SELECT *
FROM my_table
WHERE (update_date = '2017-12-21' AND id > 21)
OR update_date > '2017-12-21'
ORDER BY update_date,id LIMIT 5
Cơ bản là ta sẽ chỉ lấy các bài viết có cùng thời gian đăng như bài viết cuối và id > , hoặc thời gian lớn hơn bài viết cuối
Tổng kết
Phương pháp keyset pagination and seek giúp tối ưu việc phân trang cho các bài toán lớn hơn rất nhiều (Tham khảo biểu đồ trên)
Getter, Setter là các method để lấy dữ liệu và cập nhật dữ liệu cho các trường của 1 class
Như ví dụ trên, thay vì viết
Account taiKhoan;
taiKhoan.ID = 10;
//Thay vì viết như trên để cập nhật dữ liệu cho một object Account có ID thành 10, ta sẽ viết rằng
taiKhoan.setID(10);
Tại sao cần phải tạo ra getter, setter như vậy?
Để ngắn hơn chăng? Để đơn giản hơn? Cũng không phải, cách viết hàm trong một số trường hợp còn làm code dài hơn và khó đọc hơn là set thẳng trực tiếp, lí do thực sự là, việc này áp dụng tính chất đóng gói (encapsulation) của OOP.
Tính đóng gói (Encapsulation) từ Getter, Setter
Khi sử dụng getter, setter, ta sẽ để access cho các biến trong class thành private, và để cho các phương thức get, set là public. Lúc này, để có thể truy cập hay cập nhật dữ liệu của các biến của 1 object, ta chỉ còn 1 con đường duy nhất thông qua getter setter
Điều này giúp cho ta có thể thêm một lớp validation (xác thực) dữ liệu khi tác động đến dữ liệu của 1 object. Ví dụ, một con mèo không thể có chiều cao là 0 được, một đồ vật phải luôn có trọng lượng,….
Do lúc này, cách duy nhất để thay đổi chiều cao của con mèo chỉ có thể qua setHeight, ta luôn đảm bảo dữ liệu của chúng ta được xác minh.
Tổng kết
Việc sử dụng getter, setter và sử dụng access modifier (private) cho các biến và public cho getter/setter giúp ta đóng gói class, chỉ để lại duy nhất 1 con đường để truy cập/cập nhật
Khi chỉ còn 1 con đường, lập trình viên có thể thêm 1 lớp xác thực để tránh dữ liệu bị cập nhật xấu, sai.
Nếu có bất kỳ nội dung nào liên quan còn thiếu,hãy tạo issues cho nó, tôi sẽ theo dõi và cải thiện。
MIT License
Copyright (c) 2023 QuocHung
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Java được biết đến là ngôn ngữ lập trình bậc cao, hướng đối tượng và giúp bảo mật mạnh mẽ, và còn được định nghĩa là một Platform. Java được phát triển bởi Sun Microsystems, do James Gosling khởi xướng và ra mắt năm 1995. Java vẫn được sử dụng rất nhiều trong các dự án công nghệ mới. Tên ban đầu của Java là OAK, sau đó được Sun Microsystem đổi tên vào năm 1995 và tập trung phát triển các sản phẩm theo trend www (world wide web). Năm 2009, Java được mua lại bởi Oracle.
Các nguyên tắc thiết kế hướng đối tượng – SOLID
SOLID nghĩa là gì
Nguyên tắc SOLID là một phương pháp tiếp cận hướng đối tượng trong thiết kế cấu trúc phần mềm được sử dụng trong Java. Robert C. Martin là người đã đưa ra ý tưởng này (còn được biết đến với tên Uncle Bob). Năm nguyên tắc này đã làm thay đổi toàn bộ lĩnh vực lập trình hướng đối tượng, cũng như cách các phần mềm được viết ra. Nguyên tắc SOLID cũng đảm bảo rằng phần mềm có tính chất mô-đun (dễ tái sử dụng và dùng trong nhiều vị trí), dễ hiểu, dễ gỡ lỗi và dễ refactor (tái cấu trúc, cập nhật).
S: Single responsibility principle – Nguyên tắc một chức năng
O: Open-closed principle – Nguyên tắc đóng và mở
L: Liskov substitution principle – Nguyên tắc thay thế
I: Interface segregation principle – Nguyên tắc chia nhỏ
D: Dependency inversion principle – Nguyên tắc đảo ngược phụ thuộc
Lí do nên áp dụng các nguyên tắc SOLID
Clean: Nguyên tắc SOLID giúp code clean, dễ nhìn hơn và chuẩn hoá format của code để nhiều người hiểu hơn.
Dễ bảo trì: Code dễ bảo trì, sửa lỗi hơn.
Tính co giãn: Dễ dàng refactor, tái cấu trúc lại code. Dễ dàng phát triển các tính năng mới sau này
Tối ưu: Giảm bớt các code dư thừa.
Kiểm nghiệm: Viết unit test dễ hơn
Dễ đọc: Giúp code đọc dễ hiểu hơn
Độc lập: Code hoạt động độc lập, ít phụ thuộc các phần khác, giảm thiểu lỗi
Tái sử dụng: Code được chia nhỏ và độc lập như các module, dễ dàng sử dụng lại.
SOLID trong Java
Nguyên tắc 1: Single responsibility principle – Nguyên tắc một chức năng
Nguyên tắc này được phát biểu như sau:
Một class chỉ nên giữ 1 trách nhiệm duy nhất, chỉ có thể sửa đổi class với 1 lý do duy nhất.
A class should have one and only one reason to change, meaning that a class should have only one job.
Theo nguyên lí này, mỗi class chỉ nên có một vai trò duy nhất. Tức là bạn có thể để 1 class có rất nhiều chức năng, làm đủ thứ, với nhiều method khác nhau. Tuy nhiên việc nhét toàn bộ chức năng vào 1 class khiến code khó bảo trì, khó hiểu hơn, và xử lí một phần nhỏ của cả một class chứa rất nhiều chức năng này có thể làm lỗi toàn bộ các chức năng khác.
Hãy thử xem một class sau:
Việc cho toàn bộ các phương thức gộp vào 1 class NguoiChoi như này đã vi phạm quy tắc, thực hiện rất nhiều thay đổi chỉ trong 1 class như lấy dữ liệu từ database, chuyển sang json để trả về, di chuyển nhân vật, …. Sau này khi nâng cấp thêm chức năng, class này ngày càng phình to ra. Khiến cho việc bảo trì, nâng cấp, test, …. trở lên khó khăn hơn sau này.
Thay vì vậy, ta có thể chuyển thành như sau
Lúc này mỗi class sẽ độc lập hơn và các luồng hoạt động cũng sẽ rõ ràng hơn, khi có lỗi xảy ra hay cần nâng cấp chức năng, bạn có thể dễ dàng sửa đổi vào các class trong 1 luồng chứ không phải thay đổi hay thêm mọi thứ vào 1 class và khiến chúng phình to hơn nữa.
Tuy số lượng class nhiều hơn những việc sửa chữa sẽ đơn giản hơn, dễ dàng tái sử dụng hơn, class ngắn hơn nên cũng ít bug hơn.
Một số ví dụ về nguyên tắc SRP cần xem xét có thể cần được tách riêng bao gồm: Persistence, Validation, Notification, Error Handling, Logging, Class Instantiation, Formatting, Parsing, Mapping, …
Nguyên tắc 2: Open-closed principle – Nguyên tắc đóng và mở
Nguyên tắc này được phát biểu như sau:
Có thể thoải mái mở rộng 1 class, nhưng không được sửa đổi bên trong class đó.
Objects or entities should be open for extension, but closed for modification.
Nghe qua thấy nguyên lý có sự mâu thuẫn do thường chúng ta thấy rằng dễ mở rộng là phải dễ thay đổi, đằng nay dễ mở rộng nhưng không cho thay đổi. Thực sự theo nguyên lý này, chúng ta không được thay đổi hiện trạng của các lớp có sẵn, nếu muốn thêm tính năng mới, thì hãy mở rộng class cũ bằng cách kế thừa để xây dựng class mới. Làm như vậy sẽ tránh được các tình huống làm hỏng tính ổn định của chương trình đang có.
Theo nguyên tắc này, sau khi thiết kế một class với một số chức năng nhất định, cần đảm bảo các chức năng này hoạt động trơn tru trong tương lai, tránh sửa đổi thêm sau này. Như vậy, class luôn “đóng – closed” cho các sửa đổi vào các chức năng đã được thiết kế trước, nhưng lại phải “mở – open” để mở rộng tính năng hơn, để mở thì có 1 số cách phổ biến như:
Tạo ra một class kế thừa
Viết lại chức năng hàm đó từ class cha
Nâng cấp chức năng/hàm của class cha ở class con
Lấy ví dụ như sau:
Với cách thiết kế như trên, khi ta có các class con kế thừa từ class cha NguoiChoi, và cần kiểm tra xem class con có hệ là gì, hay ví dụ ta cần tạo thêm nhiều class con khác tương tự, ta lại phải thêm nhiều if else vào class gốc. Thay vào đó, ta nên thiết kế như sau:
Lúc này, khi cần nâng cấp thêm nhiều hệ mới cho hệ thống, ta chỉ cần tạo các class con và sử dụng chức năng của class chính, không cần thực hiện trực tiếp vào class chính nữa.
Lợi ích của nguyên lý này là đôi khi chúng ta cần sử dụng các class từ các nguồn thư viện thứ 3, hoặc từ chính các thư viện có sẵn trong Java. Chúng ta có thể dễ dàng extend và tạo các class con mới kế thừa từ class cha để phục vụ cho một mục đích, chức năng mới của dự án, mà không cần quá lo lắng về class cha sẽ bị lỗi do ta đã không sửa đổi chúng.
Tuy nhiên, việc kế thừa class cha có thể dẫn tới việc chức năng các class con lại quá khác nhau và không có chung ý nghĩa, nên chú ý vào ý nghĩa của các chức năng, tránh tạo ra quá nhiều class dẫn xuất. Mặc dù những sửa đổi nhỏ trong class thường không ảnh hưởng, chúng ta cũng cần phải test cẩn thận. Và đó là lý do chính tại sao chúng ta cần phải viết test case cho các chức năng, để có thể nhận thấy hành vi không mong muốn xảy ra trong code.
Lúc này, ta có thể sử dụng interface như các bản thiết kế cha để có thể làm các chức năng mở rộng sau này, việc sử dụng interface cũng giúp code đạt thêm tính “Loose coupling” – “liên kết lỏng” hơn và tránh sự phụ thuộc quá chặt chẽ vào các class.
Nguyên tắc 3: Liskov substitution principle – Nguyên tắc thay thế
Barbara Liskov đã đưa ra nguyên tắc Liskov Substitution Principle (LSP) này. Nguyên tắc này cho rằng: trong kế thừa, các class con, class kế thừa phải luôn có thể thay thế được class cha. Tức là, nếu class A kế thừa từ class B, thì mình luôn có thể sử dụng class A thay cho class B mà các chức năng không bị thay đổi.
Lấy ví dụ về hình vuông và hình chữ nhật
Như trong toán học được dạy ở các cấp dưới, ta hay được nghe là “hình vuông cũng là hình chữ nhật”, Nhìn ví dụ trên ta thấy mọi tính toán đều rất hợp lý. Do hình vuông có 2 cạnh bằng nhau, mỗi khi set độ dài 1 cạnh thì ta set luôn độ dài của cạnh còn lại bằng cách viết đè phương thức set chiều cao và set chiều rộng.
Tuy nhiên, class HinhVuong sau khi kế thừa class HinhChuNhat đã làm thay đổi các đặc tính vốn có của HinhChuNhat, dẫn đến vi phạm LSP. Thử với một ví dụ như sau
Rõ ràng, lúc này ta khai báo một object class HinhChuNhat theo HinhVuong, set chiều cao và chiều rộng, nhưng do ta đã ghi đè hàm set chiều cao chiều rộng nên chiều cao chiều rộng bị cập nhật thành 10, và tính diện tích ra là 10×10 = 100, rõ ràng không đúng vì hình chữ nhật đúng ra diện tích là 5×10 = 50, hay có thể nói là: Class HinhVuong không thể dùng thay thế cho class HinhChuNhat
Những vi phạm về nguyên lý LSP
Các lớp dẫn xuất có các phương thức ghi đè phương thức của lớp cha nhưng với chức năng hoàn toàn khác.
Các lớp dẫn xuất có phương thức ghi đè phương thức của lớp cha là một phương thức rỗng.
Các phương thức bắt buộc kế thừa từ lớp cha ở lớp dẫn xuất nhưng không được sử dụng.
Phát sinh ngoại lệ trong phương thức của lớp dẫn xuất.
Đây là nguyên lý… dễ bị vi phạm nhất, nguyên nhân chủ yếu là do sự thiếu kinh nghiệm khi thiết kế class. Thuông thường, design các class dựa theo đời thật: hình vuông là hình chữ nhật, file nào cũng là file. Tuy nhiên, không thể bê nguyên văn mối quan hệ này vào code. Hãy nhớ 1 điều:
Trong thực tế, A là B (hình vuông là hình chữ nhật) không có nghĩa là class A nên kế thừa class B. Chỉ cho class A kế thừa class B khi class A thay thế được cho class B.
Nguyên lý này ẩn giấu trong hầu hết mọi đoạn code, giúp cho code linh hoạt và ổn định mà ta không hề hay biết. Ví dụ như trong Java, ta có thể chạy hàm foreach với List, ArrayList, LinkedList bởi vì chúng cùng kế thừa interface Iterable. Các class List, ArrayList, … đã được thiết kế đúng LSP, chúng có thể thay thế cho Iterable mà không làm hỏng tính đúng đắn của chương trình.
Theo đó, để sửa vấn đề hình vuông – hình chữ nhật trên, ta nên để chúng cùng kế thừa một class Shape như sau
Lúc này việc set các chiều cao và chiều rộng thì chỉ class con mới có, và không vi phạm nguyên tắc LSP.
Việc thiết kế áp dụng theo nguyên tắc LSP giúp chúng ta giảm bớt quá lạm dụng việc kế thừa trong class. Ý nghĩa của các chức năng không được thay đổi để có thể sử dụng ở nhiều phạm vi khác nhau hơn.
Nguyên tắc 4: Interface segregation principle – Nguyên tắc chia nhỏ
Nguyên tắc này được phát biểu như sau:
Thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ, với nhiều mục đích cụ thể.
Many client-specific interfaces are better than one general-purpose interface.
Theo nguyên tắc ISP, một class con khi implement các interface thì không nên bị bắt buộc implement các phương thức mà mình không sử dụng bao giờ. Theo cách hiểu trên, nguyên tắc này sẽ ưu tiên việc chia nhỏ các interface ra thành các phương thức sử dụng cho các mục đích đặc thù hơn, tránh sử dụng cả một interface lớn.
Hay nói một cách khác, khi ta implement một interface trong 1 class, mà có 1 vài phương thức mình cứ phải kế thừa dù cũng không cần thiết không phải một cách hay. Ngắn gọn là: Không một client nào nên bị bắt buộc phải kế thừa một phương thức nào đó mà nó không dùng
Hãy tưởng tượng chúng ta có 1 interface lớn, khoảng 100 methods. Việc implements sẽ khá cực khổ, ngoài ra còn có thể dư thừa vì 1 class không cần dùng hết 100 method. Khi tách interface ra thành nhiều interface nhỏ, gồm các method liên quan tới nhau, việc implement và quản lý sẽ dễ hơn.
Như vậy, việc class Bike implement interface Vehicle khiến class Bike phải viết lại cả hàm openDoor() mở cửa, dù xe đạp thì không có cửa, và thường thì ta sẽ phải để nó rỗng. Như vậy khiến code bị dư thừa và nếu mở rộng ra thì các class con ngày càng bị phình to, khó bảo trì hơn
Việc áp dụng nguyên tắc trên giúp code dễ đọc và dễ quản lí bảo trì hơn. Giảm bớt code dư thừa và chỉ phải viết các phương thức cần thiết.
Nguyên tắc 5: Dependency inversion principle – Nguyên tắc đảo ngược phụ thuộc
Lấy ví dụ:
Như ta thấy, các thiết bị như tai nghe dùng cổng 3.5mm, điện thoại Android dùng dây sạc TypeC, điện thoại IOS dùng dây sạc Lightning, cổng cắm của Camera cũng khác, …
Vậy khi ta làm dây sạc, dây kết nối cho các máy này. Ta có chọn trước là nó sẽ dùng cho thiết bị nào không? Rõ ràng là không, các dây sạc này (các module cấp thấp) không quy định là nó dùng cho module cấp cao nào, mà chính các thiết bị như máy ảnh, điện thoại, tai nghe mới quy định nó dùng module cấp thấp nào.
Nguyên tắc này được phát biểu như sau:
Các module cấp cao không nên phụ thuộc vào các modules cấp thấp. Cả 2 nên phụ thuộc vào abstraction.
Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại. ( Các class giao tiếp với nhau thông qua interface, không phải thông qua implementation.)
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
Ví dụ, ta đang thiết kế một hệ thống thanh toán bằng ngân hàng như sau:
Ví dụ lúc này, ta cần thêm phương thức thanh toán bằng tiền mặt, cần có thêm một số tham số thì sao?
Ta thấy lúc này ta lại phải sửa đổi ở module cấp cao (highlevel module) là CuaHang, thêm if else để xử lí phương thức mới, mà sau này, nếu thêm các phương thức mới nữa, ta lại cứ phải thêm rất nhiều if else vào cái class lớn này.
Nó đã vi phạm 2 nguyên tắc là nguyên tắc (Nguyên tắc đảo ngược phụ thuộc) vì một class level cao hơn lại khai báo các chi tiết của class level bé hơn, hơn nữa lại còn sai về (Nguyên tắc một chức năng) vì đã khai báo nhiều chức năng hơn trong class lớn. Đúng ra class lớn chỉ nên thực hiện thanh toán thôi, còn cụ thể thanh toán thế nào thì phải là class khác.
Áp dụng nguyên tắc Dependency inversion principle – Nguyên tắc đảo ngược phụ thuộc
Lúc này các module cấp cao high-level là CuaHang đã có một interface ở giữa là PhuongThucThanhToan với các chức năng của các lớp cấp thấp (low-level module) như ThanhToanTienMat, ThanhToanNganHang. Ta đã đảo ngược sự phụ thuộc.
Như vậy, khi ta muốn thêm các lớp thanh toán khác như PayPal, Thẻ tín dụng, ví điện tử,…. Ta chỉ cần viết thêm các class con khác kế thừa từ interface PhuongThucThanhToan, chứ không cần động gì vào các code cũ này nữa.
Itch.io là một nền tảng cung cấp cho các các lập trình viên game hàng ngàn tài nguyên chất lượng cao để tạo ra những tựa game độc đáo. Nền tảng này cho phép bạn tải xuống các tài liệu như texture nhân vật, item, phong cảnh, map (tile sets), các hiệu ứng kĩ năng (skill effect) và rất nhiều thứ khác nữa để giúp bạn xây dựng một thế giới game hoàn hảo của mình.
Gamefresco, một nền tảng chia sẻ và tạo đồ họa game mới được tạo bởi các game artist, đã công bố ra mắt phiên bản beta vào ngày 1 tháng 2 năm 2023. Gamefresco cung cấp một cách mới để chia sẻ các bộ sưu tập tài sản game chất lượng cao, bao gồm icon, nhân vật, môi trường map và background, cùng nhiều thứ khác.
Với Gamefresco, các nhà phát triển game và thiết kế game có thể khám phá, thu thập và chia sẻ các tài nguyên game từ khắp nơi trên thế giới. Có thể tạo ra bộ sưu tập của riêng mình từ các tài nguyên của nhiều người khác nhau (Giống Pinterest).
GameDev Market là một marketplace tài nguyên lớn dành cho các nhà phát triển indie với nhiều tài nguyên game miễn phí và cả trả phí. Các nhà thiết kế đồ hoạ game khác nhau có thể đăng tải các gói tài nguyên theo chủ đề cùng với các tài nguyên game miễn phí mà bạn có thể tải về tham khảo. Tương tự như Itch.io, bạn có thể tìm thấy tất cả các loại tài sản game. Có các danh mục như 2D, 3D hoặc GUI, …. Có nhiều loại tài nguyên game khác nhau như background, nhân vật, xe cộ, quái, npc, môi trường, cây cối và nhiều hơn nữa.
Một trang có giao diện trông có vẻ hơi lỗi thời một chút, tuy nhiên tại đây có rất nhiều tài nguyên miễn phí để làm game. Đa số tài nguyên đều nằm trong bản quyền chung nên bạn có thể sử dụng trong các dự án mang tính thương mại mà không cần để lại credit. Ngoài ra cộng đồng trên đây cũng khá active và bạn có thể theo dõi và lọc theo đánh giá của cộng đồng. Thường thì các tài nguyên nổi tiếng và được đánh giá cao sẽ được hiện trước
Cũng như đa số các trang bên trên. CraftPix là một marketplace chứa cả các tài nguyên miễn phí và trả phí. Tại đây bạn có thể tìm các asset 2D cho game arcade, chiến thuật, platform, rpg, … CraftPix có một đặc trưng là các asset đều mang một sắc màu độc đáo. Nếu bạn đang muốn tạo một con game mang tính sáng tạo và lạ thì có thể thử trang này
Script hỗ trợ việc xếp lịch TKB, đồng thời chỉnh lại giao diện QLDT một chút theo ý mình. Script được hoàn thành gấp rút trong nửa ngày vì yêu cầu của bạn bè mình, mình cũng chỉ mới học JavaScript nên nếu có lỗi hay vấn đề hi vọng các bạn có thể liên hệ mình qua [email protected]
Sử dụng script theo nhu cầu của bạn, mình không chịu trách nhiệm trước các vấn đề liên quan đến việc sử dụng script này.
Feature
Tool xem xếp lịch TKB theo QLDT
Chọn môn bằng dropdown nhanh chóng, đỡ phải tìm kiếm hay lướt như QLDT cũ
Nếu có bất kỳ nội dung nào liên quan còn thiếu,hãy tạo issues cho nó, tôi sẽ theo dõi và cải thiện。
MIT License
Copyright (c) 2023 QuocHung
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Các thẻ liên quan đến form: form, input, button, label, textarea
Có thể tìm hiểu các thẻ khác ngoài các thẻ trên các thẻ trên
I. Cách thức hoạt động của một trang web
Khi máy tính nhà của mình kết nối đến một trang web trên mạng, ta có thể gọi chúng là các clients (máy khách) và servers (máy chủ).
Ảnh minh hoạ:
Client máy khách sẽ gửi các Requests (yêu cầu) về máy chủ, và máy chủ sẽ trả về Response (Phản hồi) tương ứng với yêu cầu của người dùng.
VD:
Người dùng gửi yêu cầu tìm trang bạn bè, server trả về trang banbe.html
Người dùng gửi yêu cầu nhắn tin, server trả về dữ liệu tin nhắn
Ở thời kì đầu của web, đa phần các web đều là web tĩnh. Tức là các trang web chỉ có thể hiển thị các nội dung cố định, không thể thay đổi được. Ví dụ như các trang web tin tức, các trang web thông tin, các trang web giới thiệu sản phẩm, …
Tuy nhiên, với sự phát triển của công nghệ, các trang web ngày nay có thể thay đổi được nội dung, có thể tương tác với người dùng. Ví dụ như các trang web mạng xã hội, các trang web thương mại điện tử, các trang web chơi game, … (Được gọi là web động). Các trang web động sẽ có dữ liệu hiển thị tuỳ theo người dùng khác nhau, và có thể thay đổi được dữ liệu hiển thị tuỳ theo người dùng. Ví dụ như trang web mạng xã hội, khi bạn đăng nhập vào trang web, bạn sẽ thấy các bài viết của bạn bè, và bạn có thể đăng bài viết của mình lên trang web.
Vậy nhìn chung thì Web là một dữ liệu sẽ được server trả về khi người dùng yêu cầu. Tuy nhiên nếu đào sâu ra thì đây là một quá trình rất dài, tưởng tượng máy bạn là nhà bạn, và web bạn truy cập là một cửa hàng trên phố, lúc này để truy cập web, bạn cần đi qua một tuyến đường để đến cửa hàng đó.
Quá trình xảy ra khi bạn kết nối một trang web:
Đầu tiên tưởng tượng, để đến một cửa hàng (web), ta cần địa chỉ của nó. Các máy chủ hay máy người dùng khi kết nối đến hệ thống internet toàn cầu đều được cấp một địa chỉ, thường là Ipv4 (ví dụ 98.139.180.149)
Tuy nhiên, số lượng ipv4 là có hạn. Vì vậy thông thường các máy tính sẽ nằm trong một mạng cục bộ, và chỉ có một ipv4 bên ngoài quyết định chúng. VD: Toàn bộ máy tính của 1 toà nhà sẽ đều kết nối vào một modem mạng có Ipv4 là (98.139.180.149). Đây sẽ là địa chỉ để bên ngoài có thể kết nối tới. Tuy nhiên khi có yêu cầu gửi tới, ta có thể cài đặt nó sẽ được đi vào máy tính nào trong toà nhà đó, các máy tính lúc này sẽ có một ipv4 cục bộ kiểu: 192.168.0.1, 192.168.0.2, ….. Tưởng tượng: Các cửa hàng nằm trong phố Nguyễn Trãi, ta đi đến Nguyễn Trãi và nó sẽ là số 100 Nguyễn Trãi, số 101 Nguyễn Trãi, …
Như vậy ta đã biết là bằng cách trên. Một server có thể truy cập bằng một địa chỉ Ipv4. Kiểu ta có thể truy cập bằng http://98.139.180.149. Tuy nhiên người dùng không thể nhớ hết số IP này, vì vậy ta cần một hệ thống định dang (tên miền – domain) để biến ip số này thành các tên miền dễ nhớ. VD: http://google.com, http://facebook.com, http://youtube.com, …
Để có thể biết được địa chỉ ip của một tên miền, ta cần một hệ thống DNS (Domain Name System). Hệ thống này sẽ lưu trữ các tên miền và địa chỉ ip tương ứng của nó. VD: google.com -> 20.002.003.149
Các hệ thống DNS như một cuốn từ điển và cho biến tên miền nào chỉ đến ip nào. Thông thường khi kết nối, đầu tiên máy tính sẽ tìm lại vào cache của chính máy mình để xem tên miền đã được lưu chưa, nếu chưa có thì máy tính sẽ tìm đến các dns server của ISP (nhà mạng, ví dụ Viettel, VNPT). Nếu vẫn chưa tìm thấy, máy tính sẽ tìm đến các DNS Server khác như của Google (8.8.8.8), Cloudflare (1.1.1.1), …
Khi người dùng gõ tên miền vào trình duyệt, trình duyệt sẽ gửi yêu cầu tới DNS để lấy địa chỉ ip của tên miền đó. Sau đó trình duyệt sẽ gửi yêu cầu tới địa chỉ ip đó, và server sẽ trả về dữ liệu tương ứng với yêu cầu của người dùng.
II. Cấu trúc của HTML
HTML là một ngôn ngữ đánh dấu siêu văn bản (HyperText Markup Language). Nó được sử dụng để xây dựng các trang web. HTML được sử dụng để đánh dấu các phần tử trong một trang web. Các phần tử này được đánh dấu bằng các thẻ HTML. Mỗi thẻ HTML bắt đầu bằng một ký tự đặc biệt và kết thúc bằng một ký tự đặc biệt. Nội dung giữa các thẻ HTML là nội dung của phần tử đó. Ví dụ: <p> This is a paragraph </p>
Các thẻ HTML có thể được phân thành hai loại: thẻ đóng và thẻ không đóng. Thẻ đóng có một thẻ đóng tương ứng, trong khi thẻ không đóng không có thẻ đóng tương ứng. Ví dụ: <p> This is a paragraph </p> là một thẻ đóng, trong khi <br> là một thẻ không đóng.
III. Thẻ khối và thẻ nội tuyến
Các thẻ HTML có thể được nhóm thành các thẻ khối và các thẻ nội tuyến. Các thẻ khối bắt đầu trên một dòng mới và chiếm toàn bộ chiều rộng của trình duyệt, trong khi các thẻ nội tuyến không bắt đầu trên một dòng mới và chỉ chiếm một phần của chiều rộng của trình duyệt. Ví dụ: <p> là một thẻ khối, trong khi <b> là một thẻ nội tuyến.
Có 2 kiểu giá trị hiển thị chính : block và inline.
Block-level elements (thẻ khối) :
Một block-elements luôn bắt đầu trên một dòng mới và Browser tự động thêm khoảng trắng (margin) và trước và sau phần tử đó. Nó luôn chiếm toàn bộ chiều rộng có sẵn. 2 block-elements thường dùng là : <p> và <div>.
Inline elements (thẻ nội tuyến) :
Một Inline elements không bắt đầu trên một dòng mới. Nó chỉ chiếm chiều rộng cần thiết. Một phần tử inline không thể chưa phần tử block.
<div> là một thẻ khối, nó được sử dụng để nhóm các phần tử HTML lại với nhau. Nó không có bất kỳ ý nghĩa đặc biệt nào. Nó thường được sử dụng để tạo các nhóm phần tử CSS để áp dụng các kiểu CSS cho các phần tử đó. Ví dụ: <div> This is a div </div>
<span> là một thẻ nội tuyến, nó được sử dụng để nhóm các phần tử HTML lại với nhau. Nó không có bất kỳ ý nghĩa đặc biệt nào. Nó thường được sử dụng để tạo các nhóm phần tử CSS để áp dụng các kiểu CSS cho các phần tử đó. Ví dụ: <span> This is a span </span>
IV. Các thẻ liên quan đến table trong HTML
<table> là một thẻ khối, nó được sử dụng để tạo một bảng. Nó có thể chứa một hoặc nhiều thẻ <tr>. Ví dụ: <table> This is a table </table>
<tr> là một thẻ khối, nó được sử dụng để tạo một hàng trong bảng. Nó có thể chứa một hoặc nhiều thẻ <td>. Ví dụ: <tr> This is a table row </tr>
<td> là một thẻ nội tuyến, nó được sử dụng để tạo một ô trong bảng. Nó có thể chứa một hoặc nhiều thẻ <p>. Ví dụ: <td> This is a table cell </td>
<th> là một thẻ nội tuyến, nó được sử dụng để tạo một ô trong bảng. Nó có thể chứa một hoặc nhiều thẻ <p>. Nó khác với thẻ <td> ở chỗ nó được sử dụng để tạo một ô tiêu đề trong bảng. Ví dụ: <th> This is a table header </th>
V. Các thẻ: image, video, links, audio
<img> là một thẻ nội tuyến, nó được sử dụng để chèn một hình ảnh vào trang web. Nó không có thẻ đóng tương ứng. Ví dụ: <img src="image.jpg" alt="Image">
<img src="url" alt="alternatetext">
<video> là một thẻ khối, nó được sử dụng để chèn một video vào trang web. Nó có thể chứa một hoặc nhiều thẻ <source>. Ví dụ: <video> This is a video </video>
<source> là một thẻ nội tuyến, nó được sử dụng để chỉ định một nguồn video. Nó không có thẻ đóng tương ứng. Ví dụ: <source src="video.mp4" type="video/mp4">
<audio> là một thẻ khối, nó được sử dụng để chèn một âm thanh vào trang web. Nó có thể chứa một hoặc nhiều thẻ <source>. Ví dụ: <audio> This is an audio </audio>
<source> là một thẻ nội tuyến, nó được sử dụng để chỉ định một nguồn âm thanh. Nó không có thẻ đóng tương ứng. Ví dụ: <source src="audio.mp3" type="audio/mp3">
<a> là một thẻ nội tuyến, nó được sử dụng để tạo một liên kết đến một trang web khác. Nó có thể chứa một hoặc nhiều thẻ <img>. Ví dụ: <a href="https://www.google.com"> This is a link </a>
<a href="url">link text</a>
attributes quan trọng nhất của thẻ là “href”, nó cho biết đích đến của link.
<div> là một thẻ khối, nó được sử dụng để nhóm các phần tử HTML lại với nhau. Nó không có bất kỳ ý nghĩa đặc biệt nào. Nó thường được sử dụng để tạo các nhóm phần tử CSS để áp dụng các kiểu CSS cho các phần tử đó. Ví dụ: <div> This is a div </div>
<span> là một thẻ nội tuyến, nó được sử dụng để nhóm các phần tử HTML lại với nhau. Nó không có bất kỳ ý nghĩa đặc biệt nào. Nó thường được sử dụng để tạo các nhóm phần tử CSS để áp dụng các kiểu CSS cho các phần tử đó. Ví dụ: <span> This is a span </span>
<header> là một thẻ khối, nó được sử dụng để tạo một tiêu đề cho trang web hoặc một phần của trang web. Ví dụ: <header> This is a header </header>
<footer> là một thẻ khối, nó được sử dụng để tạo một chân trang cho trang web hoặc một phần của trang web. Ví dụ: <footer> This is a footer </footer>
<nav> là một thẻ khối, nó được sử dụng để tạo một thanh điều hướng cho trang web hoặc một phần của trang web. Ví dụ: <nav> This is a nav </nav>
<main> là một thẻ khối, nó được sử dụng để tạo một phần chính của trang web. Ví dụ: <main> This is a main </main>
<section> là một thẻ khối, nó được sử dụng để tạo một phần của trang web. Ví dụ: <section> This is a section </section>
<article> là một thẻ khối, nó được sử dụng để tạo một bài viết. Ví dụ: <article> This is an article </article>
VII. HTML text fundamentals: h1 -> h6, p, ul, li
<h1> là một thẻ khối, nó được sử dụng để tạo một tiêu đề lớn nhất cho trang web hoặc một phần của trang web. Ví dụ: <h1> This is a heading </h1>
<h2> là một thẻ khối, nó được sử dụng để tạo một tiêu đề lớn hơn <h1> cho trang web hoặc một phần của trang web. Ví dụ: <h2> This is a heading </h2>
…
<p> là một thẻ khối, nó được sử dụng để tạo một đoạn văn bản. Ví dụ: <p> This is a paragraph </p>
<ul> là một thẻ khối, nó được sử dụng để tạo một danh sách không có thứ tự. Nó có thể chứa một hoặc nhiều thẻ <li>. Ví dụ: <ul> This is an unordered list </ul>
<li> là một thẻ khối, nó được sử dụng để tạo một mục trong danh sách. Nó có thể chứa một hoặc nhiều thẻ <p>. Ví dụ: <li> This is a list item </li>
<ol> là một thẻ khối, nó được sử dụng để tạo một danh sách có thứ tự. Nó có thể chứa một hoặc nhiều thẻ <li>. Ví dụ: <ol> This is an ordered list </ol>
VIII. Các thẻ liên quan đến form: form, input, button, label, textarea
<form> là một thẻ khối, nó được sử dụng để tạo một biểu mẫu. Nó có thể chứa một hoặc nhiều thẻ <input>, <button>, <label>, <textarea>. Ví dụ: <form> This is a form </form>
<input> là một thẻ nội tuyến, nó được sử dụng để tạo một trường nhập liệu. Nó không có thẻ đóng tương ứng. Ví dụ: <input type="text">
<button> là một thẻ nội tuyến, nó được sử dụng để tạo một nút. Nó có thể chứa một hoặc nhiều thẻ <img>. Ví dụ: <button> This is a button </button>
<label> là một thẻ nội tuyến, nó được sử dụng để tạo một nhãn cho một trường nhập liệu. Nó có thể chứa một hoặc nhiều thẻ <input>. Ví dụ: <label> This is a label </label>
<textarea> là một thẻ khối, nó được sử dụng để tạo một trường nhập liệu dài. Nó không có thẻ đóng tương ứng. Ví dụ: <textarea> This is a textarea </textarea>
<select> là một thẻ khối, nó được sử dụng để tạo một trường nhập liệu dạng danh sách thả xuống. Nó có thể chứa một hoặc nhiều thẻ <option>. Ví dụ: <select> This is a select </select>
<option> là một thẻ khối, nó được sử dụng để tạo một mục trong danh sách thả xuống. Nó không có thẻ đóng tương ứng. Ví dụ: <option> This is an option </option>
IX. Có thể tìm hiểu các thẻ khác ngoài các thẻ trên các thẻ trên
Vừa qua 09/10/2022 Học viện Công nghệ Bưu Chính Viễn Thông đã tổ chức kì thi chung kết ICPC PTIT 2022 với 33 đội (chưa kể miền Nam) tại sảnh A2 của Học Viện. Kì thi 2022 có sự góp mặt phần lớn của khoá sinh viên D21, E21 (Năm nhất), tuy rằng kết quả chung cuộc bị chênh lệch phần lớn bởi thời gian sub bài chứ không có nhiều khác biệt giữa các team top giữa, nhưng kì thi vẫn đã diễn ra vô cùng hấp dẫn và kịch tích
Banner ICPC PTIT 2022
Đội của mình “ProPTIT. GGWP” Gồm mình Nguyễn Quốc Hưng E2105, Nguyễn Mai Phương (D21CN01), Nguyễn Đăng Minh (E2101) đã cố gắng giành thứ hạng #8 với 6 bài, khá tiếc là cây toán của team – Mai Phương đã đưa 2 teammate vào hai bài khó nhất đề bằng câu “hai bài này có vẻ làm được này”, mà bỏ qua 1 câu toán khá vừa tầm đúng ra nên làm.
Một vài hình ảnh đáng chú ý trong kì thi
Thầy Từ Minh Phương phát biểu khai mạcBan tổ chức ICPC PTIT 2022Đội 812 – Đội vô địch cũng là team First Solve bài đầu tiênKhu vực thi – Sảnh A2Khu vực thi – Sảnh A2Các thầy cô ban tổ chứcLễ trao giải ICPC PTIT 2022 – Đội vô địch 812
Lễ trao giải cuộc thi: https://portal.ptit.edu.vn/le-trao-giai-cuoc-thi-lap-trinh-theo-chuan-quoc-te-icpc-icpc-ptit-2022/
Sắc màu ICPC PTIT 2022: https://www.facebook.com/media/set/?set=a.518458426953512&type=3
Chào các bạn, mình là Nguyễn Quốc Hưng. Tại thời điểm cuối cập nhật bài viết này (9/2023), mình là sinh viên năm 3 ngành CNTT CLC của PTIT. Sau một năm học trong ngành này, mình hi vọng những chia sẻ của mình có thể phần nào giúp các bạn hiểu rõ hơn về ngành Công nghệ thông tin (CLC) của trường.
KÌ THI XÉT TUYỂN
Những ngành có thể tham gia kì thi lên CLC:
Điện tử viễn thông
An toàn thông tin
Điện tử
Công nghệ thông tin
Khoa học máy tính
… Có thể sẽ có các ngành mới mỗi năm trường thêm
Để chuyển lên ngành CLC, đầu tiên bạn sẽ cần thi một kì thi tiếng anh vì ngành CNTT CLC để liên quan khá nhiều đến tiếng anh. Bài thi dùng để xét tuyển sẽ là TOEFL ITP do IIG hợp tác với trường tổ chức.
Theo như thời điểm mình thi, thì khoảng 360-400 điểm (Bạn có thể tham khảo quy đổi bên dưới) đã đủ để đỗ, và tổng sinh viên một khóa sẽ khoảng 200 sinh viên (5 lớp). Nếu bạn có chứng chỉ tiếng anh đổi điểm sẵn, bạn sẽ được phân vào lớp E1,E2 với chương trình học khá nhàn ở năm 1 và năm 2. (Do năm 1 năm 2 ngành CLC có khoảng 4 kíp tiếng anh một tuần – 8 tiếng) và nếu bạn đã có chứng chỉ thì sẽ được nghỉ hết các môn đó.
Nếu bạn ở các khoa điện tử viễn thông, điện tử có chương trình học ban đầu thường hướng nhiều về phần cứng hơn, nhưng sau khi thi lên ngành CNTT CLC, bạn sẽ chuyển hoàn toàn chương trình sang Công nghệ thông tin CLC khá giống với ngành Công nghệ thông tin bình thường.
Đầu tiên, các môn chuyên ngành (lập trình) và toán sẽ được dạy bằng tiếng anh. Bài giảng tiếng anh, thi bằng tiếng anh, thầy cô một số cũng dạy bằng tiếng anh nhưng đa số vẫn là tiếng việt. Tuy nhiên tiếng anh khá là nhẹ, nên bạn không cần quá lo lắng về vấn đề này. Dù các bài tập, kì thi đều là tiếng anh, nhưng bạn hoàn toàn vẫn có thể học từ các tài liệu tiếng việt và thi bình thường.
Các môn chuyên ngành hệ thường tại năm 1, năm 2
Kì 1: Tin học cơ sở 1 : Word, Excel, Powerpoint, máy tính, …
Kì 2: Tin học cơ sở 2: Lập trình C
Kì 3: Ngôn ngữ lập trình C++, Toán rời rạc 1
Kì 4: Cấu trúc dữ liệu và giải thuật
Các môn chuyên ngành hệ CLC tại năm 1, năm 2
Kì 1: Introduction to Programming: Lập trình C + Word Excel PowerPoint
Kì 2: Programming with C++: Lập trình C++
Kì 3: Toán rời rạc 1, Data Structure and Algorithm (Cấu trúc dữ liệu và giải thuật)
Như chương trình trên, bạn sẽ được tiếp cận với code sớm hơn hệ thường 1 kì. Điều này mang lại lợi thế khá lớn cho các bạn tham gia vào các câu lạc bộ học thuật, các kì thi trong trường
Ý kiến cá nhân: Việc được tiếp cận các môn code sớm cho mình lợi thế khá lớn khi tham gia các câu lạc bộ trong trường và các kì thi.
Các đề thi thường được dễ hơn hệ thường nên bạn sẽ nhẹ nhàng hơn để tập trung vào môn chuyên ngành.
Điểm của CLC cũng thường nhỉnh hơn khá rõ. (Môn giải tích của CLC còn cho phép mang tài liệu tham khảo vào phòng thi do thi tiếng anh)
Làm đồ án của ngành CLC chỉ cần 2.6 GPA, trong khi hệ thường là 2.9.
Môn tiếng anh tại ngành cũng được học khá nhiều (8 tín), nên nếu bạn đổi điểm tiếng anh sau này thì toàn bộ môn này là 10, buff khá nhiều điểm gpa so với hệ thường.
CƠ SỞ VẬT CHẤT – GIẢNG DẠY
Cho đến thời điểm hiện tại của bài viết (9/2023):
Hệ CLC sẽ học ở tòa A1, và hệ thường học ở tòa A2
Điều hòa của CLC sẽ nhiều hơn và có trong cả sảnh.
Các bạn dự định học cao, thạc sĩ, … thì khá dễ vào lab riêng của CLC, chỉ cần thể hiện tốt và liên hệ trực tiếp với thầy cô giảng dạy để xin vào đội làm lab.
Bạn phải đóng x1.25-2 tiền học phí của mọi môn. Kể cả những thứ bạn không nhận được hơn gì cả (VD: Tiền học phí quốc phòng)
Wifi Free mạnh hơn tòa A2 của hệ thường
Nhà vệ sinh đẹp hơn A2
Ghế công thái học, trong lớp nhiều ổ điện hơn A2.
Thầy cô dạy đa số là trưởng khoa, top trong trường, ở hệ thường sẽ cần tranh đấu để có slot học, tại CLC bạn sẽ được phân bổ tự động
Có nhiều hội thảo tiếng anh
CIE PTIT – Đào tạo quốc tế có vẻ được trường khá quan tâm, nên trong tương lai mình nghĩ cơ sở vật chất, chất lượng sẽ được ưu tiên cải thiện nhiều hơn