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

Tản mạn #3 : Khôn Lanh và Khờ Dại

Khắc Nhập (à nhầm Dẫn Nhập)

Chắc khi đọc qua cái tiêu đề, không ít người sẽ nghĩ đây là bài viết lang mang đi so sánh giữa 2 tính từ “Khôn Lanh” và “Khờ Dại”. Nhưng ý định của tôi lại khác hoàn toàn.

Còn nó khác thế nào thì mời đọc tiếp nhaaaa ..

.

.

.

.

.

.

.

.

.

Khôn vs Lanh

Vâng ! Đọc tới đây có ít bạn đã hiểu được ý đồ đen tối của tôi rồi chứ gì ? kaka

Tôi muốn tách một từ ghép mà 2 từ đơn bổ nghĩa cho nhau khi đứng riêng ra nó lại mang một tầng nghĩa đối lập và khác nhau theo một hướng nào đó.

  • Khôn (tính từ) : có tài suy xét nhạy bén - nguồn Từ Điển Tiếng Việt. Từ này được dùng trong giao tiếp mang nghĩa tích cực, chỉ sự thông minh, nhạy bén.
  • Lanh (tính từ) : tinh nhanh, sắc sảo - nguồn Từ Điển Tiếng Việt. Từ này dùng trong giao tiếp mang nghĩa hơi tiêu cực một chút, kiểu như “ma lanh”, khôn nhưng ranh mãnh, luồn lách, lương lẹo.

Tôi nhớ ngày còn bé, người lớn thường hay dạy thế này : “Mày ra đường thì phải lanh lên, không là bị thua thiệt, bị người ta lừa đó con ạ !”. Lớn lên tôi cũng thấy đúng thiệt !! Làm cái gì mà lanh lẹ luồn lách một chút là công việc gì của bản thân cũng nhanh lẹ hẵn lên. 💪

Giả dụ như nạn kẹt xe vậy, những người lanh lẹ họ đều bay lên vỉa hẹ mà chạy, mặc kệ những người chậm chạp ngu muội đợi chờ trong biển xe hít khói. Một số người ngu muội bỗng giác ngộ ra được chân lý, thế là họ trở nên lanh lẹ theo. Thế mới nói thời thế sinh anh hùng !

Thật đáng tiếc là ai cũng lanh hết thành ra xã hội mất đi tổ chức, vì đứa lanh thì khó mà chịu đựng được sự quản lý quy tắc và ràng buộc.

Còn nhớ thuở mới lên Sài Gòn, tôi cũng đã từng học lanh rất nhanh ! Giờ thì mỗi ngày càng ngu dần … Vì biết rằng tôi chẳng khôn hơn ai, nên chỉ có cách là giảm độ lanh của mình xuống thôi.

Khờ vs Dại

Ngày xưa đi học cấp 3, vài lần tôi viết thơ con nhái vui tặng lũ bạn trong tổ. Bên dưới ký bút danh là Khanh Khù Khờ. 😛 Vì cũng thú thật là trước khi vào học đại thì tôi là một đứa khù khờ lờ tờ mờ chỉ biết học và cắm đầu vào máy tính.

Trùng hợp cái nữa là tên của ba, anh tôi và tôi đều bắt đầu bằng âm KH (đọc là khờ). Má tôi hay đùa : “Tao mà đẻ thêm thằng nữa sẽ đặt tên là .. KH…ÙNG” 😂

Chắc khỏi cần tra từ điển Wiki gì đó thì mọi người ai cũng có thể hiểu 2 từ này nghĩa là gì rồi. Ý ở đây tôi muốn nói là con người ta có thể khờ (ngu) một vài lần nhưng đừng dại (dột). Vì đơn giản : cái dại ắt sẽ mang cái hại, những cái hại nhỏ sẽ góp thành cái bại lớn.

Bạn cũng có thể từng nghe qua câu nói nổi tiếng của Steve Jobs

Stay Hungry Stay Foolish

Tạm dịch là : Hãy cứ đói khát trong ngu muội đi ! 😂

Til next time !


Ref :

  • Cover photo from Google Search Image

Tản mạn #2 : Đổi chác - Cộng tác - Phó thác

Đây là một bài viết trải nghiệm của bản thân.

Đổi chác : Anh cho tôi con cá thác lác, tôi đưa lại anh cọng rác

:)) Nghe thì hơi trào phúng nhưng cơ bản thì nó kiểu kiểu như vậy. Chủ đề này tôi được truyền cảm hứng trong bài giảng phúc âm mà cha giảng hôm qua, đoạn ông Judas Iscariot “đổi” Chúa Jesus lấy 30 đồng bạc. Theo lý mà nói, một cuộc trao đổi 2 bên 2 vật gì đó thì 2 người đó phải có chủ quyền sở hữu vật đó. Đằng này, Chúa Jesus lại bị chính môn đệ mình đem ra đổi chác một cách rất nghịch đạo lý (đúng là bi kịch).

Qua đó, phần lớn chúng ta chỉ đổ tội cho một mình ông Judas mà quên đi đôi lúc chính chúng ta cũng đã vài lần “đổi chác” với chính Ngài. Tôi nhớ lúc còn bé, mỗi dịp đọc kinh (nhất là trước khi thi cử gì đó đó), tôi lại cầu nguyện đại ý là Chúa cho con thi tốt, con sẽ chăm hơn, sống tốt hơn, blah blah (nói theo tiếng Anh thì là dạng Conditional Sentence Type 1 - nếu có A thì mới có B).

Ví dụ như : “Lạy Chúa, con mới mua tờ Việt-lốt, Chúa cho con trúng 100 tỉ thôi thì con xin dâng người nghèo 800 triệu luôn. Amen.” (đúng nghĩa con cá thác lác với cọng rác, đúng là con người là loài thông manh nhất mà Chúa trời tạo ra)

Không những thế, sao khi đổi chác, chúng ta tiếp tục “kỳ vọng” vào sự thành công của phi vụ rồi không đã đụng gì vào công việc, sự cố gắng, nỗ lực. Để rồi đến khi biết được phi vụ thất bại, ta lại chìm trong tuyệt vọng, còn trách Ngài sao đối xử tệ với ta. (Tệ vậy cũng đáng ! ai bỉu đổi lại có cọng rác, hehe).

Kỳ vọng càng cao, thất vọng càng nhiều !

Cộng tác : Ngài hãy xem con đây, một mình cân tất

Lớn hơn một chút, sau nhiều lần thất vọng vì những vi phụ đổi chác trước đó (đa phần những lần thi cử của tôi chẳng được như ý, thi thật thì rớt, thi chơi thì đậu). Nhận ra rằng là do mình không tự nỗ lực, tôi chuyển sang tự lực cánh … bay !

Thức khuya, dậy trễ, ngày đêm cắm đầu vào máy tính, vào những dự án ở công ty mà quên ăn, thiếu ngủ, chỉ có cái là chưa tới mức hút lá đu đủ :))

Gọi là cũng có một số kết quả tốt (vì ít ra là có cố gắng nỗ lực), nhưng cũng chẳng đâu vào đâu. Kiến thức tôi nắm qua những năm tháng đó cũng chẳng gọi là vững chắc, chỉ là chắp vá, thiếu ở đâu vá ở đó. Rồi sức khỏe xuống cấp, tình cảm thì nguội lạnh.

Tóm lại là muội còn ngu, ah nhầm còn ngu muội !!

Ahhh quên, trong khoảng thời gian này. Tôi ma lanh hơn, bằng cách nghĩ là cầu nguyện cho người khác thay vì cho mình, may ra được Chúa thương thì sao !? Thế là cầu cho cha mẹ sống lâu nè, anh em nhiều sức khỏe, thành công nè, người thương được vui tươi, hạnh phúc các kiểu nè. Nhưng trong tâm thức, vẫn còn vụ lợi cho bản thân.

Phó Thác : Phó mặc và tín Thác

Không biết là do vô tình hay hữu ý, tôi lại bốc được Lộc lời Chúa này trong đêm giao thừa 2018

“Ơn của Thầy đã đủ cho con, vì sức mạnh của Thầy được biểu lộ trọn vẹn trong sự yếu đuối”

Đoạn này thực sự làm tôi thức tỉnh rất nhiều, lâu nay tôi luôn luôn cầu nguyện dài dòng văn tự, xin đủ thứ cho đủ mọi loại người. Nhưng quên đi rằng là mình chẳng có gì mà đòi hỏi, dù đã được ban nhiều ơn mỗi giây mỗi phút còn hít thở không khí, còn toàn mạng mà trách móc, còn ngóc đầu lên mà nhìn ánh dương.

Vì thế, dạo gần đây. Tôi thay đổi thói quen đọc kinh và cầu nguyện : đọc 1 kinh Lạy Cha, 1 kinh Kính Mừng và một kinh Sáng Danh. Và đây là lời cầu nguyện của tôi :

Lạy Chúa, con cảm ơn Người, Người làm gì con cũng chịu ! Amen.

Như những bài trước, tôi luôn đặt niềm tin là thứ có giá trị nhất ở cuộc đời. Vì thế, khi có được một niềm tin chân lý, ta nên phó mặc và tín thác.

Theo tôi, đã không tin thì thôi, đã tin thì nên tin đến cùng ! Đừng lang mang, đừng sai lệch và đừng nửa vời !

PHỤ LỤC : Xin giải nghĩa chữ nôm na:

  • Phó mặc : Giao đứt cho, khoán hẳn cho mà không dòm ngó đến nữa. (theo wiktionary)
  • Tín thác : Tin cho tới chết (theo KhanhKiKi)
  • Phó thác có thể hiểu là nỗ lực cộng tác trong niềm tin kiên vững không đổi. Ngược hoàn toàn với THOÁI THÁC

Tản mạn thành ra nó chuối chuối, rời rời và đời đời một chút

Hết.


Ref:

  • Cover photo : JESUS WALKS ON WATER, CALMS THE WIND from JW

Tản mạn #1 : Nhanh vs Chờ-ậmmmm

Má tôi thường hay quở trách tôi : “Mày lúc nào cũng chậm chà chậm chạp, y như ba
mày, cái gì cũng để nước tới chân”. Những lúc như thế tôi chỉ biết cười
trừ rồi ghẹo má “Hehe con là phải để nước qua đầu luôn rùi mới bơi !!”.

Ngẫm nghĩ lại thì tôi thấy chậm chạp thì thua thiệt nhưng đôi khi cũng lắm cái
hay, giả như những việc nguy hiểm chẳng hạn - thế là có đứa đi trước test hàng
cho mình kaka.

Nói không phải biện minh cho sự chậm chạp của mình chứ nhiều lúc tôi nghĩ con
người bây giờ sao sao ý :

  • Đi ăn tiệc thì trễ 89 phút, thế mà đèn đỏ còn 8 giây đã nhấp nhấp rồ ga.
  • Lướt Phây-Bút 8 tiếng / ngày, thế mà chẳng có nỗi 30’ gặp gỡ gia đình, bạn bè.
  • Trẻ em bây giờ 2 tuổi đã học sài smart-phone rất nhanh, lại còn được khen là thông minh hơn người nữa chứ

Nói ra là để tự ghi nhớ chứ chẳng có ý chê bai ai cả, vì đơn giản đó là quyền
của mỗi người và cái gì cũng có 2 mặt cả. Nói chứ ngày xưa tôi cũng đi tiệc trễ
45 phút hiệp 1 và lướt 80 tiếng FB / tháng đó chứ :D Tất nhiên thời 2 tuổi làm
đếch gì biết cái điện thoại quay số nói chi tới iPhone Ích-Xì. Thế tôi nói :
“Đời xưa thì khổ, đời nay nhiều cám dỗ !”

Mấy nhà văn hay viết là nên “Nghĩ nhanh, sống chậm”. Riêng tôi thì thích “Nghĩ
chậm, quyết nhanh và sống thì … bình thường thôi”, chứ sống chậm quài lại bị má la ;)

Tản mạn thành ra nó chuối chuối, rời rời và đời đời một chút

Bonus from CHAM Exhibition

cham1

cham2

Hết.


Ref: