Refactoring Code - Day 2 - Các nguyên lý cơ bản trong refactoring

Hôm nay mình tiếp tục đọc phần II của cuốn sách “Priciples in Refactoring”. Phần này có lẽ là phần quan trọng nhất của cuốn sách nên mình sẽ đọc và nghiền ngẫm từ từ từng mục một. Dưới đây là những ghi chép ngẫu hứng tóm tắt lại 2 mục con của phần II:

Định nghĩa của Refactoring

  1. Refactoring là thay đổi cấu trúc bên trong của phần mềm làm cho nó “dễ hiểu hơn” và “rẻ hơn” cho việc thay đổi mà không thay đổi hành vi có thể quan sát được => End-user sẽ không thể cảm nhận có sự thay đổi bên trong phần mềm.

  2. Refactoring giống với Performance Optimization là thay đổi cấu trúc bên trong mà không thay đổi hành vi quan sát được. Nhưng lại khác nhau về mục đích: Performance Optimization thường làm code khó hiểu hơn để đổi lại hiệu năng khi cần thiết.

Tại sao phải dùng Refactoring?!

  1. Cải thiện thiết kế phần mềm. Refactoring thường xuyên sẽ giúp code giữ nguyên được hình dáng của thiết kế. Không những thế nó giúp làm tinh gọn những thiết kế nghèo nàn bằng cách giảm đi sẽ lặp đi lặp lại để đảm bảo rằng code chỉ thể hiện đúng 1 và chỉ 1 hành vi duy nhất của nó. Đó là bản chất của một thiết kế tốt.

  2. Làm cho phần mềm dễ hiểu hơn. Dù muốn hay không thì dự án phần mềm sẽ luôn xuất hiện thêm kể thứ 3 ngoài bạn và khách hàng, đó là những lập trình viên khác trong tương lai. Vì thế việc máy tính phải xử lý thêm vài vòng tính toán làm nó chậm đi cũng không quan trọng bằng vấn đề một thay đổi phải mất hàng tháng mà lẽ ra chỉ mất hàng giờ hết người lập trình viên hiểu rõ code của bạn. Ngoài ra, hãy dùng code để diễn tả ý tưởng của bạn, biến code trở thành công cụ ghi chép chủ đạo chứ không phải ghi nhớ trong trí nhớ hoặc viết vào một nơi khác.

  3. Giúp bạn tìm ra bugs dễ hơn. Một khi đã hiểu rõ code một cách rõ ràng, bạn sẽ phần nào đó xoá bở bớt những giả tưởng mơ hồ về hệ thống, từ đó có thể tìm ra lỗi dễ dàng hơn.

  4. Giúp bạn lập trình nhanh hơn (trong tương lai). Một thiết kế hệ thống tốt là thiết yếu cho việc phát triển nhanh hệ thống. Refactoring giúp cải thiện thiết kế hệ thống, giúp bạn đi theo đúng thiết kế => nó sẽ làm tăng tốc độ phát triển hệ thống lên là điều tất yếu!

Hôm nay mình chỉ đọc đến đây thôi vì phần này quan trọng mình không muốn sẽ bị quá tải về kiến thức, “giục tốc bất đạt” mà ;) có thể bạn sẽ thấy mình lặp ý trong các bài liên tục, cái này mình sẽ tổng hợp lại sau khi lĩnh hội xong cuốn sách :)


Nếu bạn muốn mua và tìm đọc cuốn sách thì nhấn vào đây

Ref:

  • Cover photo from Google Search

Refactoring Code - Day 1 - Cơ bản về refactoring

Hôm rài qua nha ông anh chôm (mượn) được cuốn sách kinh điển gối đầu giường của dân Dev. Cuốn sách này là “REFACTORING” của Martin Fowler bản năm 1999 hướng dẫn trên ngôn ngữ Java (có bản 2018 mới trên cũng trên nền Java… nhưng thêm chữ Script 😁 - JavaScript, nhưng theo mình cảm nhận thì nó không tường minh như là trên Java). Và đây là bìa cuốn sách:

Refactoring Book Cover 1999

Hôm nay mình đọc được hết phần 1 gồm 52 trang đầu của sách và cảm nhận được mình học được rất nhiều từ phần này, sau đây là những ghi chép ngẫu hứng tóm tắt lại phần I của mình:

  1. Refactoring bản chất là thay đổi cấu trúc code bên trong nhưng không thay đổi hành vi bên ngoài của code. (Nôm na là bạn học nhiều sẽ thông minh ra nhưng cơ thể bên ngoài vẫn phải vậy) => Vì thế đòi hỏi việc đầu tiên và quan trọng nhất trước khi refactoring là phải có một bộ test tốt.

  2. Nhịp điệu chính (thần chú bạn luôn nên nhớ) khi làm refactoring là thay đổi nhỏ -> test -> thay đổi nhỏ -> test -> thay đổi nhỏ -> … -> hoàn thành -> commit

  3. Code tốt là code tự nó giải thích được bản thân nó là gì, làm gì và chạy ra sao. Và chìa khoá trong việc này là cách đặt tên biến và phương thức. (nếu mọi thứ chưa tường minh thì mới dùng comments) => Đừng ngại trong việc đổi tên nếu nó làm code tường minh, rõ ràng hơn.

  4. Nên giải thoát cho các biến tạm thời không cần thiết, vì nó có thể bị lãng quên và dễ nảy sinh ra vấn đề sau này. => Có thể áp dụng chiến thuật “Replace Temp with Query”

  5. Đừng ngại refactoring sẽ làm chậm chương trình cho tới khi bạn có số liệu profiler chính xác. Và lúc đó thì chuyện tối ưu cũng sẽ dễ hơn là tối ưu trên một đống hỗn tạp phải không?! => Khi refactoring thì tính rõ ràng được ưu tiên hơn hiệu suất.

  6. Ưu tiên tách business logic ra khỏi giao diện để nâng cao tính tái sử dụng.

  7. Và cuối cùng nhưng không kém quan trọng là mục tiêu chính của refactoring:

    • Làm code tinh gọn hơn
    • Rõ ràng hơn, minh bạch hơn (No magic)
    • Dễ test hơn
    • Sẵn sàng cho những thay đổi trong tương lai hơn

PHẦN NÀY TỚI ĐÂY LÀ HẾT RÙI !!


Nếu bạn muốn mua và tìm đọc cuốn sách thì nhấn vào đây

Ref:

  • Cover photo from Google Search
  • “Refactoring - Improving Design Existing Code” book cover from Amazon

[PHP 0 to 1] : Cơ bản về Web

Mục tiêu : Nhằm hiểu ở mức nền tảng, cơ bản Web là gì và hoạt động ra sao

Web là gì ?

Website (viết tắt là Web) là một tập hợp những trang mạng, bao gồm thông tin và nội dung số, thường được định danh bằng một tên miền và được xuất bản trên ít nhất một máy chủ mạng. Một Web có thể truy cập qua mạng với giao thức IP, thường là mạng Internet qua một đường dẫn định vị tài nguyên (URL = Uniform Resource Locator).

Mục đích của Web là để đăng tải, chia sẻ, giao dịch và xử lý thông tin số thông qua mạng máy tính.

URL là địa chỉ được gọi là định danh của một tài nguyên cụ thể trên mạng Internet, thông thường URL khác nhau sẽ cho ra một tài nguyên khác nhau. Một URL thông thường có dạng như sau:

1
<protocol>://<host><:port>/<path/to/resource><?query>

Trong đó:

  • : giao thức, ở đây thường là http hoặc https
  • : địa chỉ host nơi chứa tài nguyên, thường là IP hoặc tên miền (Domain name)
  • <path/to/resource> : đường dẫn tìm tới tài nguyên chứa trong host
  • <?query> : các đối số kèm theo cung cấp thêm thông tin cho server để trả về kết quả phù hợp hơn, bắt đầu bằng dấu ?, mỗi cặp giá trị key=value cách nhau bằng dấu &. Ví dụ như : ?page=1&limit=100&from_year=2018

Internet hoạt động thế nào ? (Internet Protocol)

Mạng internet là mạng giữa các máy tính được kết nối với nhau trực tiếp hay gián tiếp thông qua các điểm trung chuyển khác nhau tạo thành một mạng lưới kết nối rộng lớn. Mỗi máy trực tiếp tham gia vào mạng sẽ được cấp một địa chỉ IP (địa chỉ IPv4 có dạng A.B.C.D với A,B,C,D từ 0-255) duy nhất trong hệ thống mạng. Vì vậy việc gửi dữ liệu từ máy A sáng máy B là việc gửi từ địa chỉ IP của máy A sang địa chỉ IP của máy B. Do các dữ liệu được trung chuyển qua các điểm máy trung gian trong mạng máy tính vì không có đường hướng cụ thể, công đoạn này gọi là Routing. Dữ liệu sẽ được gửi dưới dạng các gói tin từ IP A sang IP B qua hệ thống Routing toàn cầu.

Do việc trung chuyển gói tin qua nhiều điểm mới tới đích, vì thế việc đảm bảo gói tin được toàn vẹn 100% là điều không thể (mà chỉ đảm bảo ở mức nỗ lực cố gắng cao nhất có thể). Vì thế dễ dẫn đến tình trạng gói tin bị mất mát, chỉnh sửa, trùng lặp và sai thứ tự trong quá trình trung chuyển trong mạng máy tính. Vì vậy mà các ứng dụng mạng muốn đảm bảo tính chính xác toàn vẹn dữ liệu được xây dựng trên một lớp Protocol bên trên bao gồm các cơ chế và quy tắc để đạt được tính toàn vẹn này, điển hình là giao thức TCP (Transmission Control Protocol).

HTTP Protocol

HTTP Protocol (HyperText Transfer Protocol) là giao thức truyền tải siêu văn bản (nghe có vẻ vi diệu), nó được xây dựng trên nền tảng giao thức TCP để đảm bảo tính toàn vẹn của dữ liệu giữa 2 máy (thường gọi là máy chủ Server và máy khách Client).

Request

Đầu tiên Client sẽ kết nối tới Server thông qua một cổng nhất định do máy chủ cung cấp dịch vụ HTTP (thường là cổng 80). Sau khi kết nối thành công, Client sẽ chuyển tiếp yêu cầu về dữ liệu (Request) mà nó muốn gửi lên cho Server xử lý. Request đó sẽ bao gồm 2 phần là đầu (HTTP Headers) và thân (HTTP Body).

Ví dụ như sau :

1
2
3
4
5
6
POST /du-lieu HTTP/1.1
Host: example.com
User-Agent: curl/7.54.0
Accept: */*

username=admin&password=secret

Bên trên là một HTTP Request bao gồm 2 phần :

  • Phần Header bao gồm 4 dòng đầu, dòng đầu tiên đặc biệt theo nguyên tắc là [METHOD] [URL] HTTP/[HTTP_VERSION], cung cấp cho ta biết phương thức gửi là gì (POST), điểm cuối chứa dữ liệu (/du-lieu) và phiên bản HTTP (1.1). Các dòng tiếp theo của Header theo nguyên tắc là KEY: VALUE nhằm cung cấp thông tin thêm cho Server hiểu chính xác Client đang cần gì, muốn gì và chấp nhận định dạng trả về như thế nào.
  • Phần Body dòng thứ 6 trở xuống, dòng thứ 5 là dòng trắng để ngăn cách Header và Body. Phần này chứa những thông tin dữ liệu kèm theo đầy đủ của Request.

Response

Sau khi nhận được Request từ Client, Server sẽ xử lý tính toán và trả về cho Client một trả lời (Response). Response này cũng bao gồm 2 phần như Request là Header và Body

Ví dụ như sau :

1
2
3
4
5
6
7
8
9
10
11
HTTP/1.1 200 (OK)
Server: nginx
Date: Wed, 31 Oct 2018 08:07:09 GMT
Content-Type: text/plain; charset=utf-8;
Content-Length: 11
Connection: keep-alive
Access-Control-Allow-Origin: *
Cache-Control: max-age=300

hello
world
  • Phần Header bao gồm 8 dòng đầu, dòng đầu tiên đặc biệt theo nguyên tắc là HTTP/[HTTP_VERSION] [STATUS CODE] [STATUS TEXT], cung cấp cho ta biết phiên bản HTTP (1.1), trạng thái của response qua 3 con số được quy định theo chuẩn RFC 7231 và chú thích cho trạng thái. Các dòng tiếp theo của Header theo nguyên tắc là KEY: VALUE nhằm cung cấp thông tin thêm cho Client hiểu chính xác Server trả về định dạng gì, độ dài bao nhiêu và một số quy tắc khác.
  • Phần Body dòng thứ 10 trở xuống, dòng thứ 9 là dòng trắng để ngăn cách Header và Body. Phần này chứ những thông tin dữ liệu kèm theo đầy đủ của Response.

Hosting, Domain, DNS, Database, HTTPS

Hosting

Hosting là nơi chứa dữ liệu, mã nguồn của trang web. Hosting sẽ nằm trên Server vật lý, và Server này sẽ chia sẻ tài nguyên bao gồm CPU, bộ nhớ và đĩa cứng để phục vụ cho vận hành Website. Có thể xem Hosting là một miếng đất để xây dựng một cái khung nhà (Source Code) trên mảnh đất đó.

Tên miền (Domain Name) và DNS

Như các bạn đã biết Client và Server nói chuyện với nhau qua một kết nối giữa IP của Client và IP của Server. Đồng nghĩa là nếu Client không có, không nhớ địa chỉ IP của Server thì coi như không thể thiết lập kết nối. Do đó người ta đã lập trên một cách dễ nhớ hơn là tạo nên một cuốn sổ danh bạ địa chỉ IP, cơ chế tạo nên cuốn sổ danh bạ này gọi là DNS (Domain Name Resolvers) hay còn gọi là quá trình phân giải tên miền thành địa chỉ IP.

Khi bạn truy cập vào một tên miền dễ nhớ như abc.com, thì lập tức Client sẽ dùng một dịch vụ phân giải DNS của các nhà mạng để tra trong cuốn danh bạ rằng abc.com là địa chỉ IP nào. Sau khi có được địa chỉ IP này, Client sẽ thiết lập kết nối tới địa chỉ IP đó. Nếu không tìm ra địa chỉ IP, Client sẽ báo ra một lỗi là “Thất bại trong quá trình phân giải DNS hoặc tên miền này không tồn tại”.

Ngoài tính năng là tạo sự dễ nhớ, domain còn giúp cho một Server chạy được rất nhiều trang web với domain khác nhau chỉ với 1 địa chỉ IP. Lúc này Web Server sẽ phân biệt domain nào cho dữ liệu nào dựa vào HTTP Header Host: abc.com mà Client gửi lên lúc tạo Request. Như thế, số lượng trang web với domain khác nhau sẽ không bị phụ thuộc vào số địa chỉ IP (tối đa là 255^4 địa chỉ IPv4 , về địa chỉ IPv6 bạn có thể tìm hiểm thêm trên Google).

Database

Database (cơ sở dữ liệu), cái tên này sẽ làm nhiều người lầm tưởng hay mặc định là những phần mềm database lớn như MSSQL, MySQL hay Oracle với hàng triệu dòng mới gọi là database. Nhưng định nghĩa của Database đơn giản chỉ là một nơi có khả năng lưu trữ, hỗ trợ thao tác đọc và ghi dữ liệu vào bộ nhớ lưu trữ. Ví dụ như một file text đơn giản, một file csv, một file excel, một file sqlite, một server MySQL hoặc một server Key-Value đều được gọi là database.

Tuỳ theo nhu cầu mà người phát triển sẽ lựa chọn cho mình một database phù hợp chứ không có một database nào là bá đạo hạt gạo, xịn nhất cả.

HTTPS

Dạo gần đây, khái niệm này mới thật sự nổi lên như một làn sóng về bảo mật thông tin cá nhân. HTTP(S) với chứ S là Secure nghĩa là bảo mật, an toàn hơn.

Như các bạn cũng đã thấy ở phần trên về HTTP, mọi dữ liệu kể cả Request lẫn Response đều được truyền giữa Client và Server dưới dạng là plain text (chữ thường) không được mã hoá. Vì thế nảy sinh ra rủi ro dữ liệu sẽ bị nghe lén, đánh cắp hoặc thậm chí là sửa đổi trên đường trung chuyển qua các nốt trung gian trong hệ thống mạng mà Client và cả Server không hề hay biết.

HTTPS sử dụng công nghệ bảo mật là SSL (hoặc mới nhất là TLS) để mã hoá và chứng thực kết nối giữa Client và Server là an toàn và bảo mật. Về cơ chế làm việc của HTTPS nói riêng là TLS nói chung mình sẽ nói sâu hơn trong một chuyên đề nâng cao về bảo mật.

Request and Response Life Cycle (vòng đời Request và Response)

Bên dưới là hình phác hoạ một vòng đời thông thường của một HTTP Request từ lúc Client gửi yêu cầu tới lúc nhận được HTTP Response, bao gồm 7 bước :

  1. Tra cứu dịch vụ DNS xem IP của tên miền abc.com là gì ?
  2. Dịch vụ tìm thấy IP là 1.2.3.4
  3. Client mở kết nối giao thức HTTP tới server có IP 1.2.3.4
  4. HTTP Web Server ở server nhận được HTTP Request, liền trung chuyển cho mã nguồn website xử lý
  5. Tính toán, xử lý dựa trên HTTP Request có được
    1. Kết nối với Database (nếu cần), rồi truy vấn (query) những dữ liệu cần thiết để hiện thị, tính toán.
    2. Database trả về kết quả cho mã nguồn website dữ liệu để tiếp tục tính toán, xử lý
  6. Sau khi mã nguồn tính toán xong nó sẽ trả về một HTTP Response cho HTTP Web Server
  7. Nhận được HTTP Response từ mã nguồn, HTTP Web Server trung chuyển về cho Client để hiển thị kết quả.

http-request-response-life-cycle

[Series mới] : Học lập trình Web bằng PHP và MySQL

Giới thiệu

Xin chào các bạn, sắp tới mình sẽ cố gắng viết về một chuyên đề mới đó là “Học lập trình Web bằng PHP và MySQL” từ cơ bản đến nâng cao (cơ bản là ở mức chưa biết gì về lập trình web, nâng cao là ở mức bạn có thể xin vào làm ở một công ty về lập trình web dạng kha khá có tiếng).

Chuyên đề này là do mình tự tay biên soạn dựa trên kinh nghiệm ít ỏi 7 năm làm trong mảng này, mình thừa nhận mình cũng không phải là chuyên gia về mảng này nhưng có thể nói là đủ kiến thức nền và kinh nghiệm trong các dự án thực tế từ nhỏ tới tầm trung. Mong rằng những kiến thức mình đúc kết bên dưới sẽ cho bạn nguồn kiến thức bổ ích, hoặc chí ít là cũng có định hướng sẽ nên học gì tiếp theo để nâng cao trình độ mình lên.

Các bạn có thể nghĩ rằng những chuyên đề này trên mạng thiếu gì, tại sao còn làm chi cho tốn công phí sức ? Và chuyên đề này có gì đặc biệt hơn những cái đã có trước đó ?

Mình xin trả lời ngắn gọn đây chỉ là một dự án chuyên đề nhỏ của mình muốn đóng góp cho cộng đồng, những lập trình viên mới vào nghề hay những sinh viên đam mê công nghệ thông tin có thể dễ dàng tiếp cận qua những bài viết tinh gọn và trực quan. Trên mạng đã có những chuyên đề tốt hơn bằng tiếng Anh nhưng mình nghĩ rất khó để các bạn có vốn tiếng Anh không được tốt và cái nữa là do quá nhiều trang thông tin sẽ làm các bạn dễ bị nhiễu thông tin dẫn đến sai đường lạc hướng rồi kết quả không đi tới đâu.

Mọi đóng góp ý kiến, các bạn có thể comment bên dưới từng bài viết trong chuyên đề này hoặc có thể mail trực tiếp cho mình tại [email protected] !

Dưới đây là guidelines bằng tiếng Anh mình soạn ra để mình nháp bố cục nội dung sau này, tất nhiên những bài viết chuyên đề sau này tất cả sẽ bằng tiếng Việt (tất nhiên sẽ có một số từ tiếng Anh chuyên ngành không thể thay thế được).

Guidelines

Học những thứ này trước khi ngỏm !

Chào bạn,

Bài viết này là bản dịch Tiếng Việt của mình một bài viết mà tôi cảm thấy nó rất hay, là một nhắc nhở cho chúng ta trong cuộc sống và đặc biệt là trong công việc.

Bài gốc là Learn these programming skills before your inevitable death!, của Itamar Turner-Trauring. Trong bài gốc có nhắc đến một số lĩnh vực IT nhưng tôi nghĩ nó cũng đúng và phú hợp với tất cả các ngành nghề và ngữ cảnh của bạn.

Bản dịch

Có rất nhiều thứ để học khi là một lập trình viên, thậm chí nó khó tới mức là không biết bắt đầu từ đâu. Và cho dù bạn có bắt đầu đi nữa, sẽ luôn luôn có những thứ mới hơn, lấp lánh hơn hấp dẫn bạn, và bạn sẽ lập cả một danh sách to đùng những thứ cần phải học và nó sẽ trở nên dài hơn, dài mãi rồi bạn sẽ cảm thấy thiệt là vãi c*t về nó nhưng thật sự thì bạn đếch có thời gian để học tất cả những thứ đó, phải không ?

Vậy nên, tại sao không dành một ít phút dừng lo lắng về những thứ bạn nên học, và thay vào đó nói một tí về tất cả những thứ bạn đếch nên học. Và may ra khi bạn nói xong, bạn sẽ cảm thấy ổn hơn tí xíu xìu xiu.

Nhưng đầu tiên, hãy nói về —

CÁI CHẾT.

Chúng ta tất cả ai rồi cũng ngỏm củ tỏi

Vào một ngày nào đó bạn sẽ ngỏm cái tỏm xuống cái giường 6 miếng gỗ. Và rồi tôi cũng thế. Tất nhiên ai cũng vậy, bạn của ta, cả kẻ thù cũng chẳng khác mấy.

Thường thì con người đo lường cuộc đời của một người bằng số ngày hoặc năm, nhưng tôi thì có lần đo nó bằng những quyển sách. Tôi làm một phép tính và tìm ra được sẽ có bao nhiêu cuốn sách mà tôi có thể đọc được trước khi tôi chạm tới cái ngưỡng ước chừng mà tôi chết già. Hiện tại, mỗi tuần tôi đọc được 2 cuốn, nhưng con số đó dường như cũng đếch thấm vào đâu.

Và nó dẫn đến một con cách không lành mạnh mấy, tôi đã còn sai hơn thế. Mỗi lúc tôi đọc một cuốn sách tôi có cái suy nghĩ : “Cuốn sách này có đáng để đọc trước khi chết không ? Có chăng là cuốn sách khác sẽ đáng giá, hay hơn cái thứ thơ văn giải trí rẻ rách này ? Có phải đọc lại cuốn sách đã đọc là lãng phí thời gian ?”. Thay vì tận hưởng cuốn sách đang đọc, tôi đã lo lắng về những thứ tốt hơn mà tôi có thể đọc thay vào lúc đó.

Cuối cùng thì tôi cũng vượt được qua cái chứng đó. Tôi sẽ không bao giờ đọc hết tất cả cuốn sách tôi muốn trước khi ngỏm. Bạn cũng thế thôi !

Xin lỗi chứ,

Việc đó chưa phải là xấu đâu. Khi bạn nằm xuống trước khi ngỏm, bạn sẽ nghĩ về bạn bè và gia đình mà bạn nhớ tới. Hoặc có thể là bạn quá mệt mỏi, và tìm đến một cái kết cho nỗi đau đớn và sợ hãi của bệnh tật. Hoặc là bạn đã có một ngày tồi tệ, bạn sẽ nghĩ rằng bạn không nên uống rượu trước khi lái xe về nhà - mà đừng có uống rồi lái, nhóc ạ. Còn tốt hơn nữa, đừng có lái; đi lại là cách tồi tệ nhất để trải nghiệm cuộc đời.

Và trong mọi trường hợp, khi bạn ngỏm bạn sẽ đếch nghĩ về mấy cuốn sách chưa đọc được đâu. Và khi mà còn nằm trên giường bệnh, nhìn lại cuộc đời, chắc chắc bạn sẽ không lo nghĩ về việc chưa thử cái nền tảng Javascript mới toanh hoanh đâu.

Một vài kỹ năng bạn không cần học

Có rất nhiều thứ tôi nghĩ bạn nên học (thực tế thì tôi có cả một bài viết về nó trên website), nhưng thật ra mà nói - nó cũng chỉ là phần mềm mà thôi. Nếu có chăng bạn chưa học nó trước khi ngỏm, cũng đếch có chi cả.

Phần mềm là một công cụ: công cụ thì hữu ích, và quan trọng, và bạn cần chúng để tạo nên nhiều thứ. Nhưng những công cụ là để phục vụ chúng ta, chứ chúng ta không phục vụ ngược lại nó.

Không cần thiết phải liệt kê ra tất cả những thứ mà bạn thực sự không nên học

Bạn không cần học những thứ chói loà, mới toanh rằng nó sẽ KẾT THÚC NGHÈO ĐÓI và MANG LẠI HẠNH PHÚC CHO NHÂN LOẠI. Nó tất nhiên sẽ không làm được như thế, và có khả năng nó không mang lại điều tốt đẹp cho tất cả chúng ta. Tôi bắt đầu sự nghiệp lập trình với việc tạo nên những đĩa CD-ROMs, đó là những thứ thực sự nổi trong 6 tháng những năm giữa thập kỉ 90s, và bây giờ ở đâu đó vẫn sẽ còn những hộp CDs chưa sử dụng mà tôi đã từng gầy tạo nên, và chẳng có ai quan tâm tới chúng nữa.

Bạn không cần học hết tất cả mọi ngôn ngữ lập trình, tất nhiên là trong khoảng thời gian rãnh. Bạn có thể và nên học nó trong công việc, nhất là khi nó trở nên hữu ích.

Bạn không cần phải học cách sử dụng mọi thư viện mới, công cụ mới hay nền tảng mới. Chỉ cần biết chúng tồn tại là đủ: khi bạn cần tới chúng, bạn sẽ biết chúng tồn tại và sẽ học chúng ngay thôi.

Một vài thứ quan trọng mà bạn cần làm trước khi ngỏm hơn là học một ngôn ngữ lập trình khác

Dành thời gian cho bạn bè.

Dành thời gian cho gia đình của bạn. (trừ khi bạn cô đơn một mình, xin lỗi)

Ăn những đồ ăn ngon, bổ.

Thăm những di sản UNESCO.

Nếu bạn chưa từng xem thấy cái nào, thì nhật thực toàn phần cũng rất là tuyệt vời.

Làm cái gì đó cho thế giới trở nên tốt hơn, mặc dù nó chỉ là một hành động nhỏ.

Mọi thứ bạn nghĩ đều quan trọng và đáng giá.

TLDR;

HỌC & LÀM LÀ VIỆC CỦA CẢ ĐỜI !

TRÁI ĐẤT VẪN QUAY, MẶT TRỜI VẪN CHIẾU !

HÍT MỘT HƠI, CHƠI MỘT TÍ, NGHỈ MỘT ĐÊM !


Ref:

Random Year #2017

Chào,

Thực ra tôi cũng chẳng biết viết gì về năm hai không mười bảy vừa qua cả. Cả một năm với bao nhiêu là trải nghiệm, cảm xúc thăng có trầm có, những điều học được cũng như nhiều điều dở dang còn nằm trên To-do-later-list.

Gần đây tôi vô tình đọc được một câu tweet của người bạn về một câu đại khái là : “Chúng ta có mắt ở đằng trước là để nhìn về phía trước chứ không phải ở sau đầu để nuối tiếc và gặm nhấm quá khứ.”. Vì thế, tôi sẽ không đề cập chi tiết về chuyện đã xảy ra mà là rút ra những gì cần làm vào năm tới.

Đầu năm vừa rồi, tôi những tưởng cuộc sống này xoay quanh 3 yếu tố : LOVE, TIME AND DEATH. Giờ đây tôi lại cảm nghiệm theo một hướng khác, cũng có 3 yếu tố nhưng là : BELIEF, ACTION AND VALUE.

BELIEF

Niềm tin là nền móng cơ bản nhất của mỗi con người và là gốc rễ mọi hoạt động xã hội. Con người sống được với nhau đơn giản xuất phát từ niềm tin.

  • Niềm tin vào chính mình gọi là tự tin.
  • Niềm tin vào người khác gọi là tin tưởng.
  • Niềm tin vào một đấng vô hình gọi là tín ngưỡng, tín thác.

Mất đi cả 3 loại trên, ta chỉ còn một thứ gọi là thể xác, là tổ hợp tế bào sống.

ACTION

Hành động hoặc việc làm thay đổi một trạng thái về vật lý cũng như tinh thần, TIME (thời gian) chỉ là một định nghĩa để diễn tả thời điểm của trạng thái ban đầu và kết thúc của hành động. Ví dụ như nếu tất cả mọi thứ trên vũ trụ này đều đứng yên, thì lúc đó cũng chẳng cần đến khái niệm thời gian làm gì.

Chỉ có hành động mới mang lại sự thay đổi, bản thân thời gian không làm được điều đó. Thời gian không bao giờ xoá đi được vết thương, kí ức buồn mà là hành động tha thứ, nối kết mới làm được điều đó.

VALUE

Là một dân lập trình, đối với tôi mọi thứ trên đời đều như một biến số (variable), và mỗi biến số đều có giá trị (value) của nó. Dù nó có giá trị là null hay nil (giá trị đặc biệt diễn tả sự không có mẹ gì cả) đi nữa.

Cuộc đời mỗi con người được đánh giá là tốt hay không, không phải là việc sở hữu bao nhiêu của cải, hay địa vị. Mà được đánh giá qua giá trị mà chúng ta đã tạo ra và chia sẻ nó cho người khác.

KEEP BELIEF, DO ACTION THEN SHARE VALUE

Mọi hành động với một niềm tin sẽ mang luôn lại giá trị.

Và đây là phương châm sống mới của tôi từ nay về sau.

GIỮ VỮNG NIỀM TIN, THỰC HIỆN HÀNH ĐỘNG VÀ CHIA SẺ GIÁ TRỊ

(Btw, nghe giống giống đa cấp vãiiii ! :)))) )

Be the miracle !

1
Parting your soup is not a miracle, Bruce. It's a magic trick. A single mom who's working two jobs and still finds time to take her kid to soccer practice, that's a miracle. A teenager who says "no" to drugs and "yes" to an education, that's a miracle. People want me to do everything for them. But what they don't realize is they have the power. You want to see a miracle, son? Be the miracle.

God - in Bruce Almighty film

and … HAPPY NEW YEAR ! ;)

#LEBY : Động từ

Định nghĩa

Động từ (verb) diễn tả những gì mà danh từ (người, vật) làm hoặc diễn ra.

  • Một hành động (action) : run, hit
  • Một sự kiện (event) : snow, marry
  • Một tình huống, trạng thái (situation) : be, seem, have
  • Một sự thay đổi (change) : become, develop, shrink

Và về bản chất ngôn ngữ, động từ được gọi là động (move, change, happen) thì luôn luôn phải chịu ảnh hưởng bởi một nhân tố tuyến tính là thời gian (time). Do đó, trong tiếng Anh mỗi động từ sẽ có nhiều hình thái phụ thuộc vào đặc điểm thời gian mà động từ đó diễn tả.

Nếu danh từ có độ khó nhớ vì độ da đạng về số lượng thì động từ là do độ da đạng về hình thái và quy tắc mà chúng ta sẽ biết ở phần ngay dưới.

Timeline (trục thời gian) :

[PAST]—————–[NOW]——————-[FUTURE]

  • PAST : quá khứ, nơi những gì đã xảy ra, không thể thay đổi được
  • NOW : hiện tại - đang diễn ra, là khi bạn đọc tới chữ này
  • FUTURE : tương lai (một cái gì đó mơ hồ, không thể biết được), chỉ đánh dấu bằng cột mốt NOW trở về sau. Tương lai mà bạn có thể một phần quyết định, chi phối được gọi là tương lai gần (mà gần cỡ nào thì cũng chẳng rõ 😅)

Các trạng thái của động từ (tense - thì) theo thời gian

Thì (hoặc thời trong thời gian) là một thuật ngữ trong ngữ pháp để chỉ một trạng thái của động từ theo thời gian. Vì thế chỉ cần nhìn vào động từ trong câu và cấu trúc câu là ta biết được câu đang đề cập về thời gian nào.

Thì Thời gian đề cập Ví dụ
Simple Present Hiện tại, Quá khứ lặp đi lặp lại cho tới nay I write blog everyday
Present Continuous Hiện tại I’m writing this word
Simple Past Quá khứ I writed “Noun” article last month
Past Continuous Quá khứ I was writing while she read my last article
Present Perfect Quá khứ cho tới nay I have worked there since 2011
Present Perfect Continuous Quá khứ cho tới nay I have been working there for years
Past Perfect Quá khứ I had written the email before he apologized
Past Perfect Continuous Quá khứ They had been talking for over hours before I arrived
Future Perfect Tương lai She will have left before I get there
Future Perfect Continuous Tương lai In September, I will have been working at my company for five years
Simple Future Tense Tương lai They will travel to Vietnam next month
Future Continuous Tương lai I will be meeting with customer about new contract
Zero Conditional Không có If air gets hot it expands
Type 1 Conditional Hiện tại dẫn đến tương lai If he is handsome she will love him
Type 2 Conditional Hiện tại tiếc nuối quá khứ If he worked hard he would be successful
Type 3 Conditional Tiếc nuối quá khứ She would have visited me if she had had time
Mixed Conditional Lại tiếc nuối quá khứ nên hiện tại ngang trái I would be playing tennis if I hadn’t broken my arm
Passive Voice Quá khứ This bridge was built by Effel

Các thì này sẽ được viết chi tiết vào những bài sau ! 🤓

Các hình thái biến đổi

  • Infinitive : nguyên mẫu (có sao y zậy)
  • The 3rd Person Singular Present Tense Form : mẫu hiện tại người thứ 3 số ít (thêm -s hoặc -es)
  • Past Form : mẫu quá khứ (thêm -ed)
  • Gerund : hậu tố -ing (biến đổi thành danh từ)
  • Present Participle : hiện tại phân từ (hậu tố -ing)
  • The Past Participle Form : quá khứ phân từ (thêm -ed)