SQL Injection là gì? Ngăn chặn SQL Injection như thế nào?

1. SQL Injection là gì?

SQL Injection xảy ra khi kẻ tấn công có thể giả mạo các thao tác truy vấn để nhằm mục đích thực hiện một câu lệnh truy vấn SQL khác so với những gì mà nhà phát triển ứng dụng đã dự định ban đầu.

Khi thực thi câu lệnh truy vấn, chúng ta có hai tùy chọn cơ bản là:

• Sử dụng statement (ví dụ, java.sql.Statement)
• Hoặc sử dụng prepared statement (ví dụ, java.sql.PreparedStatement)

Khi xây dựng các câu truy vấn căn bản, nếu chúng ta thực hiện việc nối chuỗi thì cả hai loại java.sql.Statement và java.sql.PreparedStatement đều rất dễ bị tấn công SQL Injection.

Để có thể thực hiện một câu lệnh truy vấn thì trong hai lớp java.sql.Statement và java.sql.PreparedStatement có định nghĩa ra hai phương thức là:

• executeQuery(String sql) để thực thi câu lệnh SQL SELECT
• executeUpdate(String sql) để thực thi các câu lệnh SQL INSERT, UPDATE, DELETE

Tùy thuộc vào sự kết hợp của Statement/PreparedStatement và executeQuery/executeUpdate, mà mục tiêu tấn công SQL Injection sẽ thay đổi, được thể hiện bằng các kịch bản dưới đây.

2. Statement và executeUpdate

Đây là sự kết hợp dễ bị tấn công nhất. Giả định, chúng ta có một phương thức dùng để cập nhật giá trị column review của một bản ghi thuộc bảng post_comment:

public void updatePostCommentReviewUsingStatement(Long id, String review) {
    doInJPA(entityManager -> {
        Session session = entityManager.unwrap(Session.class);
        session.doWork(connection -> {
            try(Statement statement = connection.createStatement()) {
                statement.executeUpdate(
                    "UPDATE post_comment " +
                    "SET review = '" + review + "' " +
                    "WHERE id = " + id);
            }
        });
    });
}

Và chúng ta sẽ thường gọi phương thức trên như sau:

updatePostCommentReviewUsingStatement(1L, "Awesome");

Một kẻ tấn công giả mạo chỉ đơn giả thực hiện cuộc tấn công SQL Injection như sau:

updatePostCommentReviewUsingStatement(1L, "'; DROP TABLE post_comment; -- '");

Và đay là những gì mà database sẽ thực thi:

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]

• Câu lệnh UPDATE sẽ được thực thi trước tiên
• Sau đó sẽ là câu lệnh DROP
• Cú pháp comment -- sẽ đảm bảo bỏ qua điều kiện trong mệnh đề WHERE trong phần còn lại của câu truy vấn.

Sau khi thực hiện tấn công SQL Injection trên, hãy thử truy vấn lại dữ liệu từ bảng post_comment để xem câu lệnh tấn công SQL Injection của chúng ta có thành công hay không.

ORACLE

Trên Oracle 11g, câu lệnh SQL Injection phía trên sẽ bị lỗi, vì JDBC driver không nhận ra dấu ;

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 911, SQLState: 22019
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - ORA-00911: invalid character
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]

SQL Server

Trên SQL Server 2014, câu lệnh SQL Injection sẽ được thực thi thành công và bảng post_comment đã bị xóa.

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]
 
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 208, SQLState: S0002
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - Invalid object name 'post_comment'.
INFO  [Alice]: o.h.e.i.DefaultLoadEventListener - HHH000327: Error performing load command : org.hibernate.exception.SQLGrammarException: could not extract ResultSet

PostgreSQL

Trên PostgreSQL 9.5, câu lệnh SQL Injection sẽ được thực thi thành công và bảng post_comment đã bị xóa.

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 0, SQLState: 42P01
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - ERROR: relation "post_comment" does not exist

MySQL

Trên MySQL 5.7, câu lệnh SQL Injection sẽ bị lỗi vì JDBC driver không biên dịch đúng nhiều câu lệnh DML

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 1064, SQLState: 42000
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DROP TABLE post_comment; -- '' WHERE id = 1' at line 1
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]

Mặc dù, lần tấn công SQL Injection đầu tiên không thành công trên tất cả các database, nhưng bạn sẽ nhận thấy rằng mọi cơ sở dữ liệu đều có ít nhất một biến thể của SQL Injection.

3. PreparedStatement và executeUpdate

Chúng ta sẽ thay đổi ví dụ trước để sử dụng PreparedStatement nhưng sẽ tránh sử dụng đến tham số ràng buộc

public void updatePostCommentReviewUsingPreparedStatement(Long id, String review) {
    doInJPA(entityManager -> {
        Session session = entityManager.unwrap(Session.class);
        session.doWork(connection -> {
            String sql = 
                "UPDATE post_comment " +
                "SET review = '" + review + "' " +
                "WHERE id = " + id;
            try(PreparedStatement statement = connection.prepareStatement(sql)) {
                statement.executeUpdate();
            }
        });
    });
}

Và thự hiện lại test case trước:

updatePostCommentReviewUsingPreparedStatement(
    1L, "'; DROP TABLE post_comment; -- '");
 
doInJPA(entityManager -> {
    PostComment comment = entityManager.find(
        PostComment.class, 1L);
    assertNotNull(comment);
});

Chúng ta cùng xem kết quả sau khi thực hiện tấn công SQL Injection

ORACLE

Trên Oracle 11g, câu lệnh SQL Injection phía trên sẽ bị lỗi, vì JDBC driver không nhận ra dấu ;

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 911, SQLState: 22019
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - ORA-00911: invalid character
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]

SQL Server

Trên SQL Server 2014, câu lệnh SQL Injection sẽ được thực thi thành công và bảng post_comment đã bị xóa.

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]
 
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 208, SQLState: S0002
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - Invalid object name 'post_comment'.
INFO  [Alice]: o.h.e.i.DefaultLoadEventListener - HHH000327: Error performing load command : org.hibernate.exception.SQLGrammarException: could not extract ResultSet

PostgreSQL

Trên PostgreSQL 9.5, câu lệnh SQL Injection sẽ được thực thi thành công, vì mặc định PreparedStatement chỉ mô phỏng câu lệnh trong giai đoạn chuẩn bị để chỉ phải thực thi câu truy vấn một lần.

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 0, SQLState: 42P01
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - ERROR: relation "post_comment" does not exist

MySQL

Trên MySQL 5.7, câu lệnh SQL Injection sẽ bị lỗi vì JDBC driver không biên dịch đúng nhiều câu lệnh DML

Query:["UPDATE post_comment SET review = ''; DROP TABLE post_comment; -- '' WHERE id = 1"], Params:[]
WARN  [Alice]: o.h.e.j.s.SqlExceptionHelper - SQL Error: 1064, SQLState: 42000
ERROR [Alice]: o.h.e.j.s.SqlExceptionHelper - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DROP TABLE post_comment; -- '' WHERE id = 1' at line 1
 
Query:["select p.id as id1_1_0_, p.post_id as post_id3_1_0_, p.review as review2_1_0_ from post_comment p where p.id=?"], Params:[(1)]

PreparedStatement không bảo vệ bạn khỏi một cuộc tấn công SQL Injection nếu bạn không sử dụng các tham số ràng buộc.

4. Ngăn chặn tấn công SQL Injection như thế nào?

Giải pháp rất đơn giản, bạn chỉ cần luôn chắc chắn sử dụng các tham số ràng buộc:

public PostComment getPostCommentByReview(String review) {
    return doInJPA(entityManager -> {
        return entityManager.createQuery(
            "select p " +
            "from PostComment p " +
            "where p.review = :review", PostComment.class)
        .setParameter("review", review)
        .getSingleResult();
    });
}

Bây giờ, khi cố thực hiện hack vào câu truy vấn trên:

getPostCommentByReview("1 AND 1 >= ALL ( SELECT 1 FROM pg_locks, pg_sleep(10) )");

tấn công SQL Injection sẽ bị ngăn chặn:

Time:1, Query:["select postcommen0_.id as id1_1_, postcommen0_.post_id as post_id3_1_, postcommen0_.review as review2_1_ from post_comment postcommen0_ where postcommen0_.review=?"], Params:[(1 AND 1 >= ALL ( SELECT 1 FROM pg_locks, pg_sleep(10) ))]
 
javax.persistence.NoResultException: No entity found for query

view raw SQL Injection là gì? Ngăn chặn SQL Injection như thế nào?.md hosted with ❤ by GitHub

Tìm kiếm với Git

Git là một công cụ quản lý phiên bản tuyệt vời, bạn sẽ không bao giờ "để lỡ" bất cứ điều gì với công cụ này. Tuy nhiên, đôi khi sẽ rất khó khăn trong việc tìm kiếm lại thông tin của những thứ bạn cần. Hầu hết, chúng ta sẽ sử dụng git log, nhưng sẽ không phải là cho tất cả mọi thứ.

1. Tìm kiếm file

Thỉnh thoảng, chúng ta biết chắc chắn là có một file cụ thể nào đó trong repository, nhưng lại không thể biết được chính xác vị trí của file đó nằm ở đâu. git ls-files là thứ mà chúng ta sẽ cần.

$ git ls-files | grep security
lib/dynamo-db/security.js
test/security-test.js

Bạn có thể sử dụng bất kì tùy chọn cụ thể nào mà bạn thích của lệnh grep, ví dụ như -i để không biệt chữ hoa, chữ thường.

2. Tìm những file có từ phù hợp

Nếu bạn muốn tìm thông tin bên trong file thì bạn có thể sử dụng lệnh git grep. Lệnh git grep hoạt động tương tự lệnh grep đệ quy grep -r . trong linux, nhưng nó chỉ tìm kiếm những file được quản lí bởi git.

# Tìm tất cả những dòng phù hợp với pattern *crypt* trong version hiện tại
$ git grep 'crypt'
lib/dynamo-db/security.js:var crypto = require('crypto');
lib/dynamo-db/security.js: var hmac = crypto.createHmac('sha256', key);

# Thêm thông tin số dòng vào kết quả tìm được
$ git grep -n 'crypt'
lib/dynamo-db/security.js:2:var crypto = require('crypto');
lib/dynamo-db/security.js:15: var hmac = crypto.createHmac('sha256', key);

# Chỉ liệt kê tên file
$ git grep -l 'crypt'
lib/dynamo-db/security.js

# Liệt kê số lượng pattern xuất hiện trong file
$ git grep -c 'crypt'
lib/dynamo-db/security.js:2

Cũng có thể chỉ ra phiên bản để grep nhằm tìm ra những thay đổi giữa các phiên bản

# Tìm tất cả các file kèm với số dòng mà phù hợp với điều kiện tìm kiếm *type* trong các phiên bản `master` và `8f0fb7f`
$ git grep -l type master 8f0fb7f
master:lib/dynamo-db/index.js
master:lib/dynamo-db/security.js
master:package.json
8f0fb7f:lib/dynamo-db/index.js
8f0fb7f:package.json

Git có thể kết hợp với hầu hết các lệnh cơ bản của Linux như grep, find, ack,... Nhưng Git là một công cụ quản lí phiên bản, vì vậy làm cách nào để ta có thể tìm kiếm những việc đã xảy ra trong quá khứ?

3. Tìm kiếm người đã xóa file

Giả sử, bạn đang làm việc trong một số dự án, và "gấu" của bạn bất ngờ bị ốm, bạn phải ở nhà làm việc để tiện chăm sóc cho "gấu", khi công việc quay trở lại bình thường thì bạn nhận thấy đã có ai đó xóa file của bạn khỏi dự án. Bạn muốn biết ai đã làm việc đó. git log sẽ giúp bạn giải quyết được vấn đề này.

git log sẽ cho bạn thấy nội dung log của các commit. Đây là đôi mắt của bạn để nhìn được về quá khứ.

# File của tôi bị xóa khi nào?
$ git log --diff-filter=D -- test/create-table-test.js
commit ba6c4d8bc165b8fb8208979c3e5513bd53477d51
Author: Nguyen Van A <nguyen.van.a@example.com>
Date: Thu Nov 30 09:46:52 2017 +0700

Removed the stupid failing test.

Có vẻ như chính bạn đã xóa file đó đi khi đang làm việc tại nhà và phải chăm sóc "gấu" đang bị ốm. Nhưng liệu thực sự file đó bị xóa trong commit này. Để xem thêm thông tin, hãy thêm tùy chọn --summary

# Tìm thời gian và commit mà file bị xóa
$ git log --diff-filter=D --summary -- test/create-table-test.js
commit ba6c4d8bc165b8fb8208979c3e5513bd53477d51
Author: Nguyen Van A <nguyen.van.a@example.com>
Date: Thu Nov 30 09:46:52 2017 +0700

Removed the stupid failing test.

delete mode 100644 test/create-table-test.js

Có vẻ như file đó đúng là do chính bạn đã xóa đi.

Chúng ta cùng phân tích câu lệnh trên:

• test/create-table-test.js - Đường dẫn tương đối đến file của bạn.
• -- - Sử dụng hai đấu gạch nối để báo cho Git biết đây không phải là một branch hoặc là một tùy chọn của một lệnh.
• --summary - Cho bạn biết những file nào đã bị xóa hoặc thêm mới. Ta cũng có tùy chọn khác có chức năng tương tự --name-status.
• --diff-filter - Giới hạn log bằng việc chỉ định loại thay đổi, trong trường hợp này là D nghĩa là Deleted. Các tùy chọn khác gồm có: Added (A), Coppied (C), Modified (M) và Renamed (R).

4. Tìm thời gian mà file được thêm vào

Cách thực hiện tương tự với kĩ thuật bên trên, nhưng tôi sẽ thay đổi nó vì không muốn gõ đường dẫn đầy đủ của file

# Tìm thời gian mà các file integration test được thêm vào.
$ git log --diff-filter=A --name-status | grep -C 6 'integ'
commit 09420cfea8c7b569cd47f690104750fec358a10a
Author: Nguyen Van A <nguyen.van.a@example.com>
Date: Thu Nov 30 09:46:52 2017 +0700

Extracted integration test

A	integration-test/sts-test.js

commit 205db3965dec6c2c4c7b2bb75387a591d49e1951
Author: Nguyen Van A <nguyen.van.a@example.com>
Date: Thu Nov 30 09:46:52 2017 +0700

Như các bạn có thể thấy, ở đây tôi đang sử dụng tùy chọn --name-status làm biến thể của --summary.

Tôi sử dụng lệnh grep -C 6 để lấy ra bối cảnh xung quanh các yếu tố được tìm thấy, trong trường hợp này sẽ là sáu dòng trước và sau dòng có nội dung thỏa mãn với điều kiện tìm kiếm.

5. Tìm người cuối cùng sửa code

Để xem thông tin người cuối cùng tác động đến một dòng code của một file, bạn có thể dùng đến lệnh git blame.

$ git blame test/security-test.js
205db396 (Nguyen Van B 2017-11-21 10:03:59 +0700  1) var vows = require('vows'),
205db396 (Nguyen Van B 2017-11-21 10:03:59 +0700  2)     assert = require('assert');
205db396 (Nguyen Van B 2017-11-21 10:03:59 +0700  3) 
09420cfe (Nguyen Van B 2017-11-24 16:23:52 +0700  4) var access = 'access';
09420cfe (Nguyen Van B 2017-11-24 16:23:52 +0700  5) var secret = 'secret';
90b65208 (Nguyen Van B 2017-11-21 11:58:21 +0700  6) 
205db396 (Nguyen Van B 2017-11-21 10:03:59 +0700  7) var security = new Security({
90b65208 (Nguyen Van B 2017-11-21 11:58:21 +0700  8)   access: access,
90b65208 (Nguyen Van B 2017-11-21 11:58:21 +0700  9)   secret: secret
205db396 (Nguyen Van B 2017-11-21 10:03:59 +0700 10) });
...

Như bạn thấy, mỗi dòng đều được đánh dấu bởi commit mới nhất đã tác động đến nó và tác giả của commit đó.

6. Tìm commit có chứa chuỗi kí tự chỉ định

Ta có thể tìm được những commit đã xóa bỏ hoặc thêm mới một chuỗi kí tự bằng cách sử dụng lệnh git log -S<string> hoặc git log -G<regex>.

# Tìm những commit có thay đổi chuỗi 'aws' và hiển thị tất cả thay đổi trong những commit đó.
$ git log -Saws --diff-filter=M --patch
commit b96c68b839f204b310b79570bc3d27dc93cff588
Author: Anders Janmyr <anders@janmyr.com>
Date:   Sat Jan 21 12:33:50 2012 +0100

    We have a valid request, tjohoo

diff --git a/lib/dynamo-db/security.js b/lib/dynamo-db/security.js
index bee6936..8471527 100644
--- a/lib/dynamo-db/security.js
+++ b/lib/dynamo-db/security.js
@@ -2,6 +2,7 @@
 var crypto = require('crypto');
 var _ = require('underscore');
 var request = require("request");
+var xml2js = require('xml2js');
 
 function Security(options) {
   this.options = options;
@@ -23,7 +24,7 @@ mod.timestamp = function() {
 mod.defaultParams = function() {
   return {
     AWSAccessKeyId: this.options.access,
-    Version: '2010-05-08',
+    Version: '2011-06-15',
     Timestamp: this.timestamp(),
     SignatureVersion: 2,
     SignatureMethod: 'HmacSHA256'
@@ -57,9 +58,10 @@ mod.url = function(host, path, params) {
 
 mod.makeRequest = function(method, host, path, params, callback) {
   var extParams = _.extend({}, this.defaultParams(), params);
-  var signedParams = this.signedParams('GET', 'iam.amazonaws.com', '/', extParams);
-  console.log(extParams,signedParams);
-  return request({ method: method, url: this.url(host, path, signedParams) },
+  var signedParams = this.signedParams(method, host, path, extParams);
+  var url = this.url(host, path, signedParams);
+  console.log(url,signedParams);
+  return request({ method: method, url: url },
...

view raw Tìm kiếm với Git.md hosted with ❤ by GitHub

Thực hiện tùy biến Spring AOP Annotation

1. Annotation AOP là gì?

Giới thiệu nhanh thì AOP là viết tắt của lập trình hướng khía cạnh (Aspect Oriented Programming), đây là kĩ thuật chèn thêm hành vi vào đoạn code đã tồn tại mà không cần phải sửa code trực tiếp.

Bài viết giả định bạn đọc đã có những kiến thức cơ bản về lập trình hướng khía cạnh. Nếu bạn chưa có kiến thức về AOP, hãy tìm hiểu qua về khái niệm của pointcut và advice trong lập trình hướng khía cạnh.

Loại AOP mà chúng ta sẽ thực hiện tùy biến trong bài viết này là annotation driven. Chắc hẳn mọi người đều cảm thấy rất quen thuộc nếu đã từng sử dụng qua Spring @Transaction annotaion.

@Transaction
public void saveOrder(Order order) {
    // Gọi một loạt các thao tác với database trong transaction
}

Điểm mấu chốt ở đây đó là không tác động trực tiếp vào code. Bằng cách sử dụng annotation meta-data, những logic nghiệp vụ cơ bản của ứng dụng của bạn sẽ không bị trộn lẫn với những đoạn code quản lí transaction. Việc này sẽ làm cho code của bạn dễ dàng được giải thích, tái cấu trúc và kiểm thử trong transaction isolation.

Đôi khi, những lập trình viên phát triển các ứng dụng của hệ sinh thái Spring lại coi đây là điều "vi diệu" của Framework này, mà không suy nghĩ nhiều về cách thức hoạt động chi tiết của nó. Thực tế, những gì đang xảy ra không thực sự quá phức tạp. Một khi hoàn thành các bước của bài viết này, bạn sẽ có thể tự tạo ra các annotation tùy biến của riêng mình, hiểu được cách thức hoạt động và tận dụng các lợi ích của AOP mang lại.

2. Maven Dependency

Đầu tiên, hãy thêm các Maven dependency cần thiết.

Trong ví dụ này, chúng ta sẽ sử dụng Spring Boot, vì cách tiếp cận cấu hình của module này sẽ giúp chúng ta bắt đầu ví dụ một cách nhanh nhất có thể:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.5.7.RELEASE</version>
</parent>
 
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-aop</artifactId>
    </dependency>
</dependencies>

Cần lưu ý là phải thêm AOP starter, nó sẽ kéo các thư viện mà ta cần để có thể triển khai AOP.

3. Tạo annotation tùy biến

Annotation sau đây mà tôi sẽ tạo ra là một annotation được sử dụng với mục đinh log khoảng thời gian thực thi của một phương thức:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface LogExecutionTime {

}

Mặc dù cách thực hiện khá là đơn giản, nhưng bạn hãy chú ý đến hai meta-annotation được sử dụng.

Annotation @Target sẽ cho bạn biết nơi mà annotation tùy biến có thể áp dụng. Ở đây ta đang sử dụng ElementType.Method, điều này có nghĩa là annotation tùy biến sẽ chỉ làm việc trên các phương thức. Nếu bạn cố gắng thử sử dụng annotation đã tạo ra ở những nơi khác, thì đoạn code của chúng ta sẽ báo lỗi trong quá trình biên dịch.

Và annotation @Retention sẽ chỉ rõ liệu annotation tùy biến của chúng ta có sẵn dùng trong quá trình runtime hay không. Mặc định điều này sẽ là không, vì vậy Spring AOP sẽ không thể nhận biết được annotation mà chúng ta đã tạo ra. Đó là lí do tại sao nó được cấu hình lại.

4. Tạo Aspect

Bây giờ, chúng ta đã có một annotation, hãy tạo thêm aspect. Đây chính là điều chúng ta cần quan tâm nhất, tất cả những gì chúng ta cần là một class được đánh dấu bởi @Aspect annotation:

@Aspect
@Component
public class ExampleAspect {

}

Bạn cũng sẽ cần phải sử dụng đến annotation @Component vì class này cũng cần phải là một spring bean trong Spring container. Về cơ bản, thì đây là class mà ta sẽ thực hiện những logic mong muốn.

5. Tạo Pointcut và Advice

Bây giờ, hãy tạo ra các pointcut và advice. Đây sẽ là một phương thức chú thích được đặt bên trong class Aspect của chúng ta:

@Around("@annotation(LogExecutionTime)")
public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
    return joinPoint.proceed();
}

Về mặt kĩ thuật, điều này sẽ không thay đổi hành vi của bất cứ điều gì, nhưng vẫn còn rất nhiều điều đang cần phân tích.

Đầu tiên, ta đánh dấu phương thức bằng annotation @Around. Đây là advice của chúng ta, và around advice nghĩa là chúng ta đang thêm code bổ sung trước và sau khi thực thi phương thức. Cũng có một số loại advice khác, ví dụ như before, after nhưng trong phạm vi bài viết này, ta sẽ không sử dụng đến chúng.

Tiếp theo, hãy chú ý đến annotation @Around của chúng ta có một đối số point cut. Pointcut của chúng ta nói rằng: 'Áp dụng advice này lên bất kì phương thức nào được đánh dấu với annotation @LogExecutionTime.'. Cũng có rất nhiều loại pointcut khác nữa, nhưng một lần nữa chúng ta sẽ không đề cập đến chúng trong phạm vi bài viết này.

Chính phương thức logExecutionTime() sẽ là một advice, phương thức này có một đối số là ProceedingJoinPoint. Trong trường hợp của chúng ta, thì đây sẽ là một phương thức thực thi mà đã được đánh dấu bằng annotation @LogExecutionTime.

Cuối cùng, bất cứ khi nào một phương thức đã được đánh dấu được gọi đến, thì advice của chúng ta sẽ được gọi đầu tiên. Sau đó, tùy thuộc vào advice của chúng ta quyết định làm gì tiếp theo. Trong trường hợp này, advice của chúng ta không làm gì khác ngoài việc gọi đến phương thức proceed(), điều này sẽ chỉ gọi đến phướng thức gốc đã được đánh dấu.

6. Log thời gian thực thi

Bây giờ chúng ta đã có một bộ khung, tất cả những gì chúng ta cần làm là thêm một vài logic vào trong advice. Chúng ta sẽ ghi lại thời gian thực thi của phương thức ban đầu.

@Around("@annotation(LogExecutionTime)")
public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
    long start = System.currentTimeMillis();
 
    Object proceed = joinPoint.proceed();
 
    long executionTime = System.currentTimeMillis() - start;
 
    System.out.println(joinPoint.getSignature() + " executed in " + executionTime + "ms");
    return proceed;
}

Một lần nữa, chúng ta không làm bất cứ điều gì quá phức tạp ở đây cả. Chúng ta chỉ lưu lại thời gian hiện lại, thực thi phương thức, sau đó in ra console khoảng thời gian đã tính toán được. Chúng ra cũng log cả tên của phương thức, api này được cung cấp bởi joinpoint instance. Ta cũng có thể truy cập được một tá các thông tin khác nếu muốn, ví dụ như các đối số của phương thức.

Bây giờ, hãy thử đánh dấu một phương thức bằng @LogExecutionTime, và sau đó thực thi nó để xem điều gì sẽ xảy ra. Chú ý rằng, phương thức mà chúng ta muốn đánh dấu phải thuộc về một Spring bean:

@LogExecutionTime
public void serve() throws InterruptedException {
    Thread.sleep(2000);
}

Sau khi thực thi, ta sẽ thấy kết quả trên console như sau:

void com.example.Service.serve() executed in 2030ms

view raw Thực hiện tùy biến Spring AOP Annotation.md hosted with ❤ by GitHub

The introduction to Reactive Programming you've been missing

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

So you're curious in learning this new thing called Reactive Programming, particularly its variant comprising of Rx, Bacon.js, RAC, and others.

Learning it is hard, even harder by the lack of good material. When I started, I tried looking for tutorials. I found only a handful of practical guides, but they just scratched the surface and never tackled the challenge of building the whole architecture around it. Library documentations often don't help when you're trying to understand some function. I mean, honestly, look at this:

Rx.Observable.prototype.flatMapLatest(selector, [thisArg])

Projects each element of an observable sequence into a new sequence of observable sequences by incorporating the element's index and then transforms an observable sequence of observable sequences into an observable sequence producing values only from the most recent observable sequence.

Holy cow.

I've read two books, one just painted the big picture, while the other dived into how to use the Reactive library. I ended up learning Reactive Programming the hard way: figuring it out while building with it. At my work in Futurice I got to use it in a real project, and had the support of some colleagues when I ran into troubles.

The hardest part of the learning journey is thinking in Reactive. It's a lot about letting go of old imperative and stateful habits of typical programming, and forcing your brain to work in a different paradigm. I haven't found any guide on the internet in this aspect, and I think the world deserves a practical tutorial on how to think in Reactive, so that you can get started. Library documentation can light your way after that. I hope this helps you.

"What is Reactive Programming?"

There are plenty of bad explanations and definitions out there on the internet. Wikipedia is too generic and theoretical as usual. Stackoverflow's canonical answer is obviously not suitable for newcomers. Reactive Manifesto sounds like the kind of thing you show to your project manager or the businessmen at your company. Microsoft's Rx terminology "Rx = Observables + LINQ + Schedulers" is so heavy and Microsoftish that most of us are left confused. Terms like "reactive" and "propagation of change" don't convey anything specifically different to what your typical MV* and favorite language already does. Of course my framework views react to the models. Of course change is propagated. If it wouldn't, nothing would be rendered.

So let's cut the bullshit.

Reactive programming is programming with asynchronous data streams.

In a way, this isn't anything new. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. Reactive is that idea on steroids. You are able to create data streams of anything, not just from click and hover events. Streams are cheap and ubiquitous, anything can be a stream: variables, user inputs, properties, caches, data structures, etc. For example, imagine your Twitter feed would be a data stream in the same fashion that click events are. You can listen to that stream and react accordingly.

On top of that, you are given an amazing toolbox of functions to combine, create and filter any of those streams. That's where the "functional" magic kicks in. A stream can be used as an input to another one. Even multiple streams can be used as inputs to another stream. You can merge two streams. You can filter a stream to get another one that has only those events you are interested in. You can map data values from one stream to another new one.

If streams are so central to Reactive, let's take a careful look at them, starting with our familiar "clicks on a button" event stream.

A stream is a sequence of ongoing events ordered in time. It can emit three different things: a value (of some type), an error, or a "completed" signal. Consider that the "completed" takes place, for instance, when the current window or view containing that button is closed.

We capture these emitted events only asynchronously, by defining a function that will execute when a value is emitted, another function when an error is emitted, and another function when 'completed' is emitted. Sometimes these last two can be omitted and you can just focus on defining the function for values. The "listening" to the stream is called subscribing. The functions we are defining are observers. The stream is the subject (or "observable") being observed. This is precisely the Observer Design Pattern.

An alternative way of drawing that diagram is with ASCII, which we will use in some parts of this tutorial:

--a---b-c---d---X---|->

a, b, c, d are emitted values
X is an error
| is the 'completed' signal
---> is the timeline

Since this feels so familiar already, and I don't want you to get bored, let's do something new: we are going to create new click event streams transformed out of the original click event stream.

First, let's make a counter stream that indicates how many times a button was clicked. In common Reactive libraries, each stream has many functions attached to it, such as map, filter, scan, etc. When you call one of these functions, such as clickStream.map(f), it returns a new stream based on the click stream. It does not modify the original click stream in any way. This is a property called immutability, and it goes together with Reactive streams just like pancakes are good with syrup. That allows us to chain functions like clickStream.map(f).scan(g):

  clickStream: ---c----c--c----c------c-->
               vvvvv map(c becomes 1) vvvv
               ---1----1--1----1------1-->
               vvvvvvvvv scan(+) vvvvvvvvv
counterStream: ---1----2--3----4------5-->

The map(f) function replaces (into the new stream) each emitted value according to a function f you provide. In our case, we mapped to the number 1 on each click. The scan(g) function aggregates all previous values on the stream, producing value x = g(accumulated, current), where g was simply the add function in this example. Then, counterStream emits the total number of clicks whenever a click happens.

To show the real power of Reactive, let's just say that you want to have a stream of "double click" events. To make it even more interesting, let's say we want the new stream to consider triple clicks as double clicks, or in general, multiple clicks (two or more). Take a deep breath and imagine how you would do that in a traditional imperative and stateful fashion. I bet it sounds fairly nasty and involves some variables to keep state and some fiddling with time intervals.

Well, in Reactive it's pretty simple. In fact, the logic is just 4 lines of code. But let's ignore code for now. Thinking in diagrams is the best way to understand and build streams, whether you're a beginner or an expert.

Grey boxes are functions transforming one stream into another. First we accumulate clicks in lists, whenever 250 milliseconds of "event silence" has happened (that's what buffer(stream.throttle(250ms)) does, in a nutshell. Don't worry about understanding the details at this point, we are just demoing Reactive for now). The result is a stream of lists, from which we apply map() to map each list to an integer matching the length of that list. Finally, we ignore 1 integers using the filter(x >= 2) function. That's it: 3 operations to produce our intended stream. We can then subscribe ("listen") to it to react accordingly how we wish.

I hope you enjoy the beauty of this approach. This example is just the tip of the iceberg: you can apply the same operations on different kinds of streams, for instance, on a stream of API responses; on the other hand, there are many other functions available.

"Why should I consider adopting RP?"

Reactive Programming raises the level of abstraction of your code so you can focus on the interdependence of events that define the business logic, rather than having to constantly fiddle with a large amount of implementation details. Code in RP will likely be more concise.

The benefit is more evident in modern webapps and mobile apps that are highly interactive with a multitude of UI events related to data events. 10 years ago, interaction with web pages was basically about submitting a long form to the backend and performing simple rendering to the frontend. Apps have evolved to be more real-time: modifying a single form field can automatically trigger a save to the backend, "likes" to some content can be reflected in real time to other connected users, and so forth.

Apps nowadays have an abundancy of real-time events of every kind that enable a highly interactive experience to the user. We need tools for properly dealing with that, and Reactive Programming is an answer.

Thinking in RP, with examples

Let's dive into the real stuff. A real-world example with a step-by-step guide on how to think in RP. No synthetic examples, no half-explained concepts. By the end of this tutorial we will have produced real functioning code, while knowing why we did each thing.

I picked JavaScript and RxJS as the tools for this, for a reason: JavaScript is the most familiar language out there at the moment, and the Rx* library family is widely available for many languages and platforms (.NET, Java, Scala, Clojure, JavaScript, Ruby, Python, C++, Objective-C/Cocoa, Groovy, etc). So whatever your tools are, you can concretely benefit by following this tutorial.

Implementing a "Who to follow" suggestions box

In Twitter there is this UI element that suggests other accounts you could follow:

We are going to focus on imitating its core features, which are:

• On startup, load accounts data from the API and display 3 suggestions
• On clicking "Refresh", load 3 other account suggestions into the 3 rows
• On click 'x' button on an account row, clear only that current account and display another
• Each row displays the account's avatar and links to their page

We can leave out the other features and buttons because they are minor. And, instead of Twitter, which recently closed its API to the unauthorized public, let's build that UI for following people on Github. There's a Github API for getting users.

The complete code for this is ready at http://jsfiddle.net/staltz/8jFJH/48/ in case you want to take a peak already.

Request and response

How do you approach this problem with Rx? Well, to start with, (almost) everything can be a stream. That's the Rx mantra. Let's start with the easiest feature: "on startup, load 3 accounts data from the API". There is nothing special here, this is simply about (1) doing a request, (2) getting a response, (3) rendering the response. So let's go ahead and represent our requests as a stream. At first this will feel like overkill, but we need to start from the basics, right?

On startup we need to do only one request, so if we model it as a data stream, it will be a stream with only one emitted value. Later, we know we will have many requests happening, but for now, it is just one.

--a------|->

Where a is the string 'https://api.github.com/users'

This is a stream of URLs that we want to request. Whenever a request event happens, it tells us two things: when and what. "When" the request should be executed is when the event is emitted. And "what" should be requested is the value emitted: a string containing the URL.

To create such stream with a single value is very simple in Rx*. The official terminology for a stream is "Observable", for the fact that it can be observed, but I find it to be a silly name, so I call it stream.

var requestStream = Rx.Observable.just('https://api.github.com/users');

But now, that is just a stream of strings, doing no other operation, so we need to somehow make something happen when that value is emitted. That's done by subscribing to the stream.

requestStream.subscribe(function(requestUrl) {
  // execute the request
  jQuery.getJSON(requestUrl, function(responseData) {
    // ...
  });
}

Notice we are using a jQuery Ajax callback (which we assume you should know already) to handle the asynchronicity of the request operation. But wait a moment, Rx is for dealing with asynchronous data streams. Couldn't the response for that request be a stream containing the data arriving at some time in the future? Well, at a conceptual level, it sure looks like it, so let's try that.

requestStream.subscribe(function(requestUrl) {
  // execute the request
  var responseStream = Rx.Observable.create(function (observer) {
    jQuery.getJSON(requestUrl)
    .done(function(response) { observer.onNext(response); })
    .fail(function(jqXHR, status, error) { observer.onError(error); })
    .always(function() { observer.onCompleted(); });
  });
  
  responseStream.subscribe(function(response) {
    // do something with the response
  });
}

What Rx.Observable.create() does is create your own custom stream by explicitly informing each observer (or in other words, a "subscriber") about data events (onNext()) or errors (onError()). What we did was just wrap that jQuery Ajax Promise. Excuse me, does this mean that a Promise is an Observable?

         

Yes.

Observable is Promise++. In Rx you can easily convert a Promise to an Observable by doing var stream = Rx.Observable.fromPromise(promise), so let's use that. The only difference is that Observables are not Promises/A+ compliant, but conceptually there is no clash. A Promise is simply an Observable with one single emitted value. Rx streams go beyond promises by allowing many returned values.

This is pretty nice, and shows how Observables are at least as powerful as Promises. So if you believe the Promises hype, keep an eye on what Rx Observables are capable of.

Now back to our example, if you were quick to notice, we have one subscribe() call inside another, which is somewhat akin to callback hell. Also, the creation of responseStream is dependent on requestStream. As you heard before, in Rx there are simple mechanisms for transforming and creating new streams out of others, so we should be doing that.

The one basic function that you should know by now is map(f), which takes each value of stream A, applies f() on it, and produces a value on stream B. If we do that to our request and response streams, we can map request URLs to response Promises (disguised as streams).

var responseMetastream = requestStream
  .map(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

Then we will have created a beast called "metastream": a stream of streams. Don't panic yet. A metastream is a stream where each emitted value is yet another stream. You can think of it as pointers: each emitted value is a pointer to another stream. In our example, each request URL is mapped to a pointer to the promise stream containing the corresponding response.

A metastream for responses looks confusing, and doesn't seem to help us at all. We just want a simple stream of responses, where each emitted value is a JSON object, not a 'Promise' of a JSON object. Say hi to Mr. Flatmap: a version of map() that "flattens" a metastream, by emitting on the "trunk" stream everything that will be emitted on "branch" streams. Flatmap is not a "fix" and metastreams are not a bug, these are really the tools for dealing with asynchronous responses in Rx.

var responseStream = requestStream
  .flatMap(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

Nice. And because the response stream is defined according to request stream, if we have later on more events happening on request stream, we will have the corresponding response events happening on response stream, as expected:

requestStream:  --a-----b--c------------|->
responseStream: -----A--------B-----C---|->

(lowercase is a request, uppercase is its response)

Now that we finally have a response stream, we can render the data we receive:

responseStream.subscribe(function(response) {
  // render `response` to the DOM however you wish
});

Joining all the code until now, we have:

var requestStream = Rx.Observable.just('https://api.github.com/users');

var responseStream = requestStream
  .flatMap(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

responseStream.subscribe(function(response) {
  // render `response` to the DOM however you wish
});

The refresh button

I did not yet mention that the JSON in the response is a list with 100 users. The API only allows us to specify the page offset, and not the page size, so we're using just 3 data objects and wasting 97 others. We can ignore that problem for now, since later on we will see how to cache the responses.

Everytime the refresh button is clicked, the request stream should emit a new URL, so that we can get a new response. We need two things: a stream of click events on the refresh button (mantra: anything can be a stream), and we need to change the request stream to depend on the refresh click stream. Gladly, RxJS comes with tools to make Observables from event listeners.

var refreshButton = document.querySelector('.refresh');
var refreshClickStream = Rx.Observable.fromEvent(refreshButton, 'click');

Since the refresh click event doesn't itself carry any API URL, we need to map each click to an actual URL. Now we change the request stream to be the refresh click stream mapped to the API endpoint with a random offset parameter each time.

var requestStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

Because I'm dumb and I don't have automated tests, I just broke one of our previously built features. A request doesn't happen anymore on startup, it happens only when the refresh is clicked. Urgh. I need both behaviors: a request when either a refresh is clicked or the webpage was just opened.

We know how to make a separate stream for each one of those cases:

var requestOnRefreshStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });
  
var startupRequestStream = Rx.Observable.just('https://api.github.com/users');

But how can we "merge" these two into one? Well, there's merge(). Explained in the diagram dialect, this is what it does:

stream A: ---a--------e-----o----->
stream B: -----B---C-----D-------->
          vvvvvvvvv merge vvvvvvvvv
          ---a-B---C--e--D--o----->

It should be easy now:

var requestOnRefreshStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });
  
var startupRequestStream = Rx.Observable.just('https://api.github.com/users');

var requestStream = Rx.Observable.merge(
  requestOnRefreshStream, startupRequestStream
);

There is an alternative and cleaner way of writing that, without the intermediate streams.

var requestStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  })
  .merge(Rx.Observable.just('https://api.github.com/users'));

Even shorter, even more readable:

var requestStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  })
  .startWith('https://api.github.com/users');

The startWith() function does exactly what you think it does. No matter how your input stream looks like, the output stream resulting of startWith(x) will have x at the beginning. But I'm not DRY enough, I'm repeating the API endpoint string. One way to fix this is by moving the startWith() close to the refreshClickStream, to essentially "emulate" a refresh click on startup.

var requestStream = refreshClickStream.startWith('startup click')
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

Nice. If you go back to the point where I "broke the automated tests", you should see that the only difference with this last approach is that I added the startWith().

Modelling the 3 suggestions with streams

Until now, we have only touched a suggestion UI element on the rendering step that happens in the responseStream's subscribe(). Now with the refresh button, we have a problem: as soon as you click 'refresh', the current 3 suggestions are not cleared. New suggestions come in only after a response has arrived, but to make the UI look nice, we need to clean out the current suggestions when clicks happen on the refresh.

refreshClickStream.subscribe(function() {
  // clear the 3 suggestion DOM elements 
});

No, not so fast, pal. This is bad, because we now have two subscribers that affect the suggestion DOM elements (the other one being responseStream.subscribe()), and that doesn't really sound like Separation of concerns. Remember the Reactive mantra?

       

So let's model a suggestion as a stream, where each emitted value is the JSON object containing the suggestion data. We will do this separately for each of the 3 suggestions. This is how the stream for suggestion #1 could look like:

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  });

The others, suggestion2Stream and suggestion3Stream can be simply copy pasted from suggestion1Stream. This is not DRY, but it will keep our example simple for this tutorial, plus I think it's a good exercise to think how to avoid repetition in this case.

Instead of having the rendering happen in responseStream's subscribe(), we do that here:

suggestion1Stream.subscribe(function(suggestion) {
  // render the 1st suggestion to the DOM
});

Back to the "on refresh, clear the suggestions", we can simply map refresh clicks to null suggestion data, and include that in the suggestion1Stream, as such:

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  })
  .merge(
    refreshClickStream.map(function(){ return null; })
  );

And when rendering, we interpret null as "no data", hence hiding its UI element.

suggestion1Stream.subscribe(function(suggestion) {
  if (suggestion === null) {
    // hide the first suggestion DOM element
  }
  else {
    // show the first suggestion DOM element
    // and render the data
  }
});

The big picture is now:

refreshClickStream: ----------o--------o---->
     requestStream: -r--------r--------r---->
    responseStream: ----R---------R------R-->   
 suggestion1Stream: ----s-----N---s----N-s-->
 suggestion2Stream: ----q-----N---q----N-q-->
 suggestion3Stream: ----t-----N---t----N-t-->

Where N stands for null.

As a bonus, we can also render "empty" suggestions on startup. That is done by adding startWith(null) to the suggestion streams:

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  })
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);

Which results in:

refreshClickStream: ----------o---------o---->
     requestStream: -r--------r---------r---->
    responseStream: ----R----------R------R-->   
 suggestion1Stream: -N--s-----N----s----N-s-->
 suggestion2Stream: -N--q-----N----q----N-q-->
 suggestion3Stream: -N--t-----N----t----N-t-->

Closing a suggestion and using cached responses

There is one feature remaining to implement. Each suggestion should have its own 'x' button for closing it, and loading another in its place. At first thought, you could say it's enough to make a new request when any close button is clicked:

var close1Button = document.querySelector('.close1');
var close1ClickStream = Rx.Observable.fromEvent(close1Button, 'click');
// and the same for close2Button and close3Button

var requestStream = refreshClickStream.startWith('startup click')
  .merge(close1ClickStream) // we added this
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

That does not work. It will close and reload all suggestions, rather than just only the one we clicked on. There are a couple of different ways of solving this, and to keep it interesting, we will solve it by reusing previous responses. The API's response page size is 100 users while we were using just 3 of those, so there is plenty of fresh data available. No need to request more.

Again, let's think in streams. When a 'close1' click event happens, we want to use the most recently emitted response on responseStream to get one random user from the list in the response. As such:

    requestStream: --r--------------->
   responseStream: ------R----------->
close1ClickStream: ------------c----->
suggestion1Stream: ------s-----s----->

In Rx* there is a combinator function called combineLatest that seems to do what we need. It takes two streams A and B as inputs, and whenever either stream emits a value, combineLatest joins the two most recently emitted values a and b from both streams and outputs a value c = f(x,y), where f is a function you define. It is better explained with a diagram:

stream A: --a-----------e--------i-------->
stream B: -----b----c--------d-------q---->
          vvvvvvvv combineLatest(f) vvvvvvv
          ----AB---AC--EC---ED--ID--IQ---->

where f is the uppercase function

We can apply combineLatest() on close1ClickStream and responseStream, so that whenever the close 1 button is clicked, we get the latest response emitted and produce a new value on suggestion1Stream. On the other hand, combineLatest() is symmetric: whenever a new response is emitted on responseStream, it will combine with the latest 'close 1' click to produce a new suggestion. That is interesting, because it allows us to simplify our previous code for suggestion1Stream, like this:

var suggestion1Stream = close1ClickStream
  .combineLatest(responseStream,             
    function(click, listUsers) {
      return listUsers[Math.floor(Math.random()*listUsers.length)];
    }
  )
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);

One piece is still missing in the puzzle. The combineLatest() uses the most recent of the two sources, but if one of those sources hasn't emitted anything yet, combineLatest() cannot produce a data event on the output stream. If you look at the ASCII diagram above, you will see that the output has nothing when the first stream emitted value a. Only when the second stream emitted value b could it produce an output value.

There are different ways of solving this, and we will stay with the simplest one, which is simulating a click to the 'close 1' button on startup:

var suggestion1Stream = close1ClickStream.startWith('startup click') // we added this
  .combineLatest(responseStream,             
    function(click, listUsers) {l
      return listUsers[Math.floor(Math.random()*listUsers.length)];
    }
  )
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);

Wrapping up

And we're done. The complete code for all this was:

var refreshButton = document.querySelector('.refresh');
var refreshClickStream = Rx.Observable.fromEvent(refreshButton, 'click');

var closeButton1 = document.querySelector('.close1');
var close1ClickStream = Rx.Observable.fromEvent(closeButton1, 'click');
// and the same logic for close2 and close3

var requestStream = refreshClickStream.startWith('startup click')
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

var responseStream = requestStream
  .flatMap(function (requestUrl) {
    return Rx.Observable.fromPromise($.ajax({url: requestUrl}));
  });

var suggestion1Stream = close1ClickStream.startWith('startup click')
  .combineLatest(responseStream,             
    function(click, listUsers) {
      return listUsers[Math.floor(Math.random()*listUsers.length)];
    }
  )
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);
// and the same logic for suggestion2Stream and suggestion3Stream

suggestion1Stream.subscribe(function(suggestion) {
  if (suggestion === null) {
    // hide the first suggestion DOM element
  }
  else {
    // show the first suggestion DOM element
    // and render the data
  }
});

You can see this working example at http://jsfiddle.net/staltz/8jFJH/48/

That piece of code is small but dense: it features management of multiple events with proper separation of concerns, and even caching of responses. The functional style made the code look more declarative than imperative: we are not giving a sequence of instructions to execute, we are just telling what something is by defining relationships between streams. For instance, with Rx we told the computer that suggestion1Stream is the 'close 1' stream combined with one user from the latest response, besides being null when a refresh happens or program startup happened.

Notice also the impressive absence of control flow elements such as if, for, while, and the typical callback-based control flow that you expect from a JavaScript application. You can even get rid of the if and else in the subscribe() above by using filter() if you want (I'll leave the implementation details to you as an exercise). In Rx, we have stream functions such as map, filter, scan, merge, combineLatest, startWith, and many more to control the flow of an event-driven program. This toolset of functions gives you more power in less code.

What comes next

If you think Rx* will be your preferred library for Reactive Programming, take a while to get acquainted with the big list of functions for transforming, combining, and creating Observables. If you want to understand those functions in diagrams of streams, take a look at RxJava's very useful documentation with marble diagrams. Whenever you get stuck trying to do something, draw those diagrams, think on them, look at the long list of functions, and think more. This workflow has been effective in my experience.

Once you start getting the hang of programming with Rx*, it is absolutely required to understand the concept of Cold vs Hot Observables. If you ignore this, it will come back and bite you brutally. You have been warned. Sharpen your skills further by learning real functional programming, and getting acquainted with issues such as side effects that affect Rx*.

But Reactive Programming is not just Rx*. There is Bacon.js which is intuitive to work with, without the quirks you sometimes encounter in Rx*. The Elm Language lives in its own category: it's a Functional Reactive Programming language that compiles to JavaScript + HTML + CSS, and features a time travelling debugger. Pretty awesome.

Rx works great for event-heavy frontends and apps. But it is not just a client-side thing, it works great also in the backend and close to databases. In fact, RxJava is a key component for enabling server-side concurrency in Netflix's API. Rx is not a framework restricted to one specific type of application or language. It really is a paradigm that you can use when programming any event-driven software.

If this tutorial helped you, tweet it forward.

---

Legal

© Andre Medeiros (alias "Andre Staltz"), 2014. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Andre Medeiros and http://andre.staltz.com with appropriate and specific direction to the original content.

"Introduction to Reactive Programming you've been missing" by Andre Staltz is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
Based on a work at https://gist.github.com/staltz/868e7e9bc2a7b8c1f754.

view raw introrx.md hosted with ❤ by GitHub

view raw zclickstream.png hosted with ❤ by GitHub

view raw zmantra.jpg hosted with ❤ by GitHub

view raw zmulticlickstream.png hosted with ❤ by GitHub

view raw zresponsemetastream.png hosted with ❤ by GitHub

view raw zresponsestream.png hosted with ❤ by GitHub

view raw ztwitterbox.png hosted with ❤ by GitHub

Tùy biến Thymeleaf

Gần đây, tôi có dịp được tham gia một dự án Java có sử dụng đến Thymeleaf, một trong số các công việc mà đội phát triển chúng tôi thực hiện đó là phải tùy biến các thẻ hoặc thuộc tính của template khi triển khai dự án.

1. Tại sao phải tùy biến thư viện Thymeleaf?

---

Thymeleaf là một thư viện rất mở, hầu hết các tính năng hướng tới người dùng của nó đều không được trực tiếp phát triển bên trong các thành phần cốt lõi, mà chỉ là đóng gói và thành phần hóa các tính năng này thành bộ tính năng gọi là dialect.

Thư viện sẽ cung cấp cho người dùng hai dialect có thể trực tiếp sử dụng đó là: Standard và SpringStandard, nhưng bạn cũng có thể dễ dàng mở rộng, tạo ra thêm các dialect của riêng mình. Hãy cùng xem qua một số lí do có thể khiến bạn phải thực hiện việc này:

Kịch bản 1: thêm các tính năng không tồn tại trong các dialect mặc định

Giả sử, ứng dụng của bạn sử dụng dialect là SpringStandard, và cần hiển thị cho người dùng cuối một thông báo có màu nền là màu xanh lam hoặc màu đỏ dựa vào role của người dùng đã đăng nhập vào hệ thống (ví dụ, admin hoặc non-admin), trong khoảng thời gian từ thứ hai đến thứ bảy hàng tuần, nếu vào chủ nhật sẽ luôn là màu xanh lá. Bạn có thể làm được điều này bằng cách thực hiện tính toán với các biểu thức điều kiện trong html template, nhưng nếu có quá nhiều điều kiện sẽ khiến code của bạn trở lên rất khó đọc, và khó bảo trì về sau.

Giải pháp: hãy tạo ra một attribute gọi là alertClass, sử dụng Java code để tính toán giá trị của attribute này và trả về CSS class mong muốn, đóng gói code này bên trong dialect có tên là MyOwnDialect, thêm dialect này vào trong template engine với prefix là th (giống như SpringStandard) và bây giờ bạn sẽ có thể sử dụng th:alertClass="${user.role}".

Kịch bản 2: view-layer components

Giả sử, công ty của bạn sử dụng Thymeleaf cho rất nhiều dự án khác nhau, và bạn mong muốn tạo ra một repository cho tất cả các chức năng phổ biến, được sử dụng lại rất nhiều lần trong một số dự án (ví dụ, các tag và/hoặc các attribute) để không phải copy-paste những đoạn code tương tự nhau từ dự án này qua các dự án kế tiếp. Bạn mong muốn tạo ra các view-layers component tương tự như các taglib trong công nghệ JSP.

Giải pháp: tạo một Thymeleaf dialect cho mỗi bộ các chức năng có liên quan với nhau, và thêm các dialect này vào ứng dụng của bạn nếu điều đó cần thiết.

Kịch bản 3: Tự tạo một template riêng

Hãy tưởng tượng rằng, bạn có một trang web cộng đồng cho phép người dùng có thể tạo ra các mẫu thiết kế của riêng họ để hiển thị nội dung. Nhưng bạn không hề muốn người dùng có thể thực hiện được toàn bộ công việc trong template của họ, thậm chí là hạn chế một vài tính năng của Standard dialect (ví dụ, các biểu thức OGNL). Vì vậy, bạn cần phải cung cấp cho người dùng khả năng thêm vào template của họ một số tính năng trong tầm kiểm soát của bạn (ví dụ như, hiển thị ảnh cá nhân, nhập nội dung văn bản, ...).

Giải pháp: Bạn cần tạo ra một Thymeleaf dialect có các thẻ hoặc thuộc tính mà bạn cho phép người dùng có thể sử dụng, giống như <mysite:profilePhoto></mysite:profilePhoto> hoặc có thể là <mysite:blogentries fromDate="23/4/2011" />. Sau đó, hãy cho phép người dùng tạo ra các template riêng có thể sử dụng các tính năng này và chỉ cho Thymeleaf cách thực hiện chúng, đảm bảo rằng không một ai có thể thực hiện được những việc mà bạn không cung cấp.

2. Dialect và Processor

---

2.1 Dialect

---

Ngoài các thuộc tính th:x hoặc các thẻ <th:y> đã được cung cấp sẵn bởi Thymeleaf với các tính năng mặc định, thì bạn hoàn toàn có thể tự tạo ra các bộ thuộc tính hoặc thẻ của riêng mình bằng tên bạn muốn và sử dụng chúng để xử lý các template của bạn.

Các Dialect là những đối tượng được implement từ interface org.thymeleaf.dialect.IDialect:

public interface IDialect {

    public String getName();

}

Yêu cầu cốt lõi duy nhất của một dialect là nó phải có tên để có thể xác định được. Tuy nhiên, cách thực hiện chỉ implement duy nhất IDialect rất ít khi được lựa chọn, thay vào đó, chúng ta thường sẽ implement từ một hoặc một số các interface con của IDialect, việc này phụ thuộc vào những gì mà Thymeleaf engine cung cấp:

• IProcessorDialect: dialect cung cấp các processor.
• IPreProcessorDialect: dialect cung cấp các pre-processor.
• IPostProcessorDialect: dialect cung cấp các post-processor.
• IExpressionObjectDialect: dialect cung cấp các object biểu thức.
• IExecutionAttributeDialect: dialect cung cấp các thuộc tính xử lý.

Processor dialects: IProcessorDialect

IProcessorDialect interface:

public interface IProcessorDialect extends IDialect {

    public String getPrefix();
    public int getDialectProcessorPrecedence();
    public Set<IProcessor> getProcessors(final String dialectPrefix);

}

Các Processor là những đối tượng phụ trách hầu hết các xử lý logic trong các Thymeleaf template, đây có thể được coi là thành phần quan trọng nhất trong Thymeleaf:

Trong diaclect này chỉ có ba mục được định nghĩa:

• prefix: đây là phần tiền tố hoặc namespace sẽ được áp dụng mặc định cho các phần tử hoặc các thuộc tính phù hợp với các processor của dialect này. Do đó, một dialect có tiền tố là th giống với Standard Dialect sẽ có thể xác định được các processor phù hợp với các thuộc tính như th:text, th:if, hoặc th:whatever (hoặc bạn cũng có thể sử dụng cú pháp của HTML5: data-th-text, data-th-if, và data-th-whatever). Tiền tố có thể được thiết lập trong cấu hình template engine và chúng có thể nhận giá trị null nếu như bạn muốn các processor có thể được thực thi trên các tag/attribute không cố định.
• dialect precedence: là độ ưu tiên khi sắp xếp các processor trong các dialect
• processors: các processor được cung cấp bởi dialect. Chú ý là phương thức getProcessors(...) nhận dialectPrefix làm tham số đầu vào trong trường hợp dialect này đã được cấu hình trong Template engine với tiền tố khác mặc định. Hầu hết các trường hợp thì ```IProcessor sẽ cần thông tin này khi khởi tạo.

Pre-processor dialects: IPreProcessorDialect

Pre-processor và post-processor khác với các processor đó là thay vì chỉ thực thi trên một sự kiện hoặc mẫu sự kiện đơn lẻ (một fragment của một template), thì chúng sẽ được áp dụng lên toàn bộ quá trình xử lý template như là một bước bổ sung trong chuỗi xử lý của engine. Do vậy, chúng sẽ được thực thi theo API hoàn toàn khác so với các processor, sẽ hướng sự kiện nhiều hơn, và được xác định bởi interface tầng thấp là ITemplateHandler.

Trong trường hợp có sử dụng các pre-processor, chúng sẽ được áp dụng trước khi Thymeleaf engine bắt đầu xử lý các processor cho một template chỉ định.

IPreProcessorDialect interface:

public interface IPreProcessorDialect extends IDialect {

    public int getDialectPreProcessorPrecedence();
    public Set<IPreProcessor> getPreProcessors();

}

Interface này tương tự với IProcessorDialect, nhưng thiếu prefix vì nó không cần thiết cho các pre-processor (chúng sẽ xử lý tất cả sự kiện xảy ra, không riêng bất kì sự kiện cụ thể nào cả)

Post-processor dialects: IPostProcessorDialect

Như đã nêu ở trên, post-processor là một bước bổ sung vào dây chuyền thực thi template, nhưng lần này chúng sẽ được thực thi sau khi Thymeleaf engine đã áp dụng tất cả các processor cần thiết. Điều này nghĩa là post-processor sẽ được áp dụng ngay trước khi template có kết quả (và do đó có thể chỉnh sửa được kết quả trả về).

IPostProcessorDialect interface:

public interface IPostProcessorDialect extends IDialect {

    public int getDialectPostProcessorPrecedence();
    public Set<IPostProcessor> getPostProcessors();

}

IPostProcessorDialect có cấu trúc tương tự với IPreProcessorDialect.

Expression Object dialects: IExpressionObjectDialect

Những dialect implement interface này cung cấp thêm các đối tượng expression object hoặc các expression utility object, các đối tượng này có thể được sử dụng trong các biểu thức ở bất kì nơi nào của một template, ví dụ, Standard Dialect mặc định có cung cấp một số đối tượng sau #strings, #numbers, #dates, #list,...

Còn đây là interface IExpressionObjectDialect:

public interface IExpressionObjectDialect extends IDialect {

    public IExpressionObjectFactory getExpressionObjectFactory();

}

Như chúng ta thấy, interface này chỉ có một phương thức duy nhất và nó không hề trả về chính các đối tượng expression, mà lại là một factory. Lí do là một vài đối tượng expression sẽ phải cần dữ liệu từ ngữ cảnh xử lý để có thể build được, do đó, nó sẽ không thể tự build cho đến khi chúng ta thực sự đang trong quá trình xử lý template... Bên cạnh đó, hầu hết các biểu thức đều không cần dùng đến các đối tượng expression, vì vậy sẽ tốt hơn nếu các đối tượng này chỉ được build khi thực sự cần thiết đối với các biểu thức cụ thể (và cũng chỉ build những gì thật cần thiết).

Đây là interface IExpressionObjectFactory:

public interface IExpressionObjectFactory {

    public Map<String,ExpressionObjectDefinition> getObjectDefinitions();

    public Object buildObject(final IProcessingContext processingContext, final String expressionObjectName);

}

Dialect xử lý thuộc tính: IExecutionAttributeDialect

Các Dialect implement interface này được cung cấp khả năng xử lý các thuộc tính.

Ví dụ, Standard Dialect implement interface này để cung cấp cho mọi processor:

• Thymeleaf Standard Expression parser: các Standard Expression trong bất kì thuộc tính đều có thể được phân tích và thực thi.
• Variable Expression Evaluator: các biểu thức ${...} được thực thi trong OGNL hoặc SpringEL (nếu tích hợp với Spring module).
• Conversion Service: thực hiện các tính toán chuyển đổi trong biểu thức ${{...}}.

Lưu ý rằng, những đối tượng này không có sẵn trong ngữ cảnh, vì vậy, chúng không thể được sử dụng từ các biểu thức template. Tính khả dụng của chúng bị giới hạn trong việc triển khai mở rộng, như là các processor, pre-processor,...

Interface này đơn giản chỉ là:

public interface IExecutionAttributeDialect extends IDialect {

    public Map<String,Object> getExecutionAttributes();

}

2.2. Processor

---

Processor là những đối tượng implement interface org.thymeleaf.processor.IProcessor, và chúng chứa các logic thật sự để áp dụng cho các phần khác nhau của một template.

Interface này có cấu trúc như sau:

public interface IProcessor {

    public TemplateMode getTemplateMode();
    public int getPrecedence();

}

Giống với các dialect, đây là một interface rất đơn giản, chỉ xác định mode của template mà processor có thể được sử dụng và độ ưu tiên của nó.

Nhưng có một vài loại processor tương ứng với mỗi loại sự kiện có thể xảy ra:

• Template start/end
• Element Tags
• Texts
• Comments
• CDATA Sections
• DOCTYPE Clauses
• XML Declarations
• Processing Instructions

Tùy biến Thymeleaf

---

(by @dangquando)

view raw framgia-report-2017-august.md hosted with ❤ by GitHub

Quản lý transaction trong Spring Framework - Spring @Transaction

Spring là một framework Java được sử dụng phổ biến nhất hiện nay, nó mang đến rất nhiều tính năng và nhiều phần bổ trợ cho các ứng dụng Java. Tuy nhiên, hầu hết mọi người đều có khuynh hướng sử dụng những tính năng này mà không thực sự hiểu cơ chế bên dưới của chúng.

1. Cách sử dụng và trường hợp sử dụng

@Transaction(value = "myTransactionManager", propagation = Propagation.REQUIRED)
public void myMethod() {
...
}

Thuộc tính value của annotation @Transaction không bắt buộc phải được khai báo. Nếu không khai báo thuộc tính này thì mặc định Spring sẽ tìm kiếm một bean bất kì được khai báo bên trong context có tên là "transactionManager" (đây là convention mặc định trong Spring).

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
  <property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>

2. Cấu hình sử dụng transaction trong Spring context

Muốn annotation @Transaction có thể hoạt động được, ta sẽ phải khai báo thẻ <tx:annotation-driven> (trong đó tx là rút gọn của namespace "http://www.springframework.org/schema/tx" hoặc cũng có thể tạm hiểu đây là một alias cho namespace này).

3. Phân tích code

3.1. Khai báo spring bean

Ở phần này, chúng ta sẽ xem xét cách mà Spring context xử lý khi khai báo sử dụng thẻ <tx:annotation-driven>

1, org.springframework.transaction.config.AnnotationDrivenBeanDefinitionParser

/**
* Parses the '<code></code>' tag. Will
* {@link AopNamespaceUtils#registerAutoProxyCreatorIfNecessary register an AutoProxyCreator}
* with the container as necessary.
*/
public BeanDefinition parse(Element element, ParserContext parserContext) {
  String mode = element.getAttribute("mode");
  if ("aspectj".equals(mode)) {
    // mode="aspectj"
    registerTransactionAspect(element, parserContext); 
  } else {
    // mode="proxy"
    // DEFAULT MODE
    AopAutoProxyConfigurer.configureAutoProxyCreator(element, parserContext);
  }
  return null;
}

Hầu hết, chúng ta sẽ đều đi vào block else của block điều kiện if-else trong đoạn code bên trên (mode="proxy"), vì vậy chúng ta sẽ gọi AopAutoProxyConfigurer.configureAutoProxyCreator()

Collections Refueled by Stuart Marks

Đánh chỉ mục hiệu quả khi sử dụng PostgreSQL

Hệ quản trị cơ sở dữ liệu PostgreSQL có nhiều loại chỉ mục - index khác nhau, cũng như các cách sử dụng chỉ mục khác nhau. Qua bài viết này, tôi muốn đưa ra một góc nhìn tổng quan về các loại chỉ mục hiện tại đang được PostgreSQL hỗ trợ, và giải thích cách sử dụng khác nhau của loại chỉ mục phổ biến nhất - B-Tree.

Sử dụng chỉ mục là một cách hiệu quả để truy xuất số lượng tương đối nhỏ các bản ghi từ bảng dữ liệu. Nó sẽ chỉ hữu ích khi số lượng các bản ghi được truy vấn ra từ một bảng không quá lớn (ví dụ, truy vấn bản ghi theo điều kiện - mệnh đề WHERE). Chỉ mục B-Tree sẽ rất hữu ích khi ta muốn tránh phải sắp xếp lại các bản ghi đã được lựa chọn.

1. Các loại chỉ mục:

Postgres hỗ trợ các loại chỉ mục sau:

• B-Tree: Hầu như, tất cả các cơ sở dữ liệu hiện nay đều hỗ trợ loại chỉ mục B-Tree, và trong hệ quản trị cơ sở dữ liệu PostgreSQL thì B-Tree là chỉ mục mặc định nếu như thực hiện câu lệnh truy vấn tạo chỉ mục mặc định CREATE INDEX. Chữ B trong B-Tree là viết tắt của từ Balanced - nghĩa là cân bằng, và ý tưởng của thuật toán là số lượng dữ liệu trên cả nhánh của cây dữ liệu sẽ tương đối bằng nhau. Do đó, số lần phải thực hiện tìm bản ghi ở hai bên luôn luôn giống nhau. Các câu truy vấn bằng hay truy vấn phạm vi sẽ rất hiệu quả nếu kết hợp sử dụng cùng với chỉ mục B-Tree, chúng hoạt động với tất cả các kiểu dữ liệu và cả giá trị NULL. Loại chỉ mục B-Tree được thiết kế để có thể làm việc tốt với cơ chế cache, thậm chí ngay cả khi chỉ cache một phần của dữ liệu.

• Hash: Chỉ mục Hash chỉ hữu ích khi truy vấn so sánh bằng, nhưng có thể bạn sẽ không bao giờ sử dụng đến loại chỉ mục này vì nó không an toàn, bạn sẽ cần phải tự đánh lại chỉ mục nếu như có lỗi xảy ra nhưng các đối tượng liên quan sẽ không được thông báo về sự thay đổi này, vì vậy ưu điểm của loại chỉ mục Hash so với loại chỉ mục B-Tree là không đáng kể.

PostgreSQL Concurrency và MVCC

Một trong những điểm hấp dẫn nhất của hệ quản trị cơ sở dữ liệu Postgres đó là cách mà nó thực hiện điều khiển tương tranh giữa các transaction, nghĩa là read sẽ không bao giờ chặn write và ngược lại. Nói một cách dễ hình dung hơn, nếu hai transaction thực thi cùng một lúc thì nguyên tắc thực thi là thực thi độc lập, Postgres thực hiện được điều này là nhờ một cơ chế gọi là Multi Version Concurrency Control (MVCC). Kĩ thuật này không phải chỉ riêng Postgres mới có, mà đã có nhiều hệ quản trị cơ sở dữ liệu khác cũng đang thực hiện các cách tương tự với MVCC để điều khiển tương tranh giữa các transaction bao gồm: Oracle, Berkeley DB, CouchDB và các hệ quản trị cơ sở dữ liệu khác nữa. Việc hiểu cách MVCC được triển khai như thế nào trong PostgreSQL rất quan trọng, vì điều này giúp các nhà phát triển phần mềm có thể thiết kế các ứng dụng có tính đồng thời cao mà có sử dụng đến PostgreSQL, hoặc phần nào giúp giải quyết được rất nhiều vấn đề khó có thể gặp phải trong tương lai.

MVCC hoạt động như thế nào?

Mỗi một transaction trong PostgreSQL đều có một transaction id - id này là một số nguyên 32-bit, gọi là XID. Các transaction này bao gồm các câu lệnh đơn như INSERT, UPDATE hoặc DELETE, và một nhóm các câu lệnh tạo thành một khối lệnh được đặt bên trong hai từ khóa BEGIN - COMMIT. Khi bắt đầu một transaction, Postgres tạo ra một XID và gán nó cho transaction hiện tại. Ta có thể nhìn thấy được XID của transaction hiện tại bằng cách gọi hàm txid_current() có sẵn trong PostgreSQL.

SELECT CAST(txid_current() AS TEXT);

Postgres lưu tất cả thông tin của một transaction vào bên trong table data của hệ thống, những thông tin này sẽ được Postgres dùng để xác định một bản ghi sẽ có trạng thái ẩn hay hiện đối với một transaction.

Một điều thú vị nữa trong cơ chế MVCC này của Postgres đó là ngoài các column đã được khai báo trong quá trình tạo bảng thì mỗi bản ghi của một bảng sẽ có thêm hai cột bổ sung:

• xmin - xác định XID của transaction đã insert bản ghi này
• xmax - xác định XID của transaction đã delete bản ghi này

Nếu ta không truy vấn tới hai cột này, mặc định chúng sẽ bị ẩn đi. Ta có thể truy vấn giá trị của hai cột này như các cột bình thường khác có trong một bảng.

Hạn chế sai lầm tỉ đô khi sử dụng ngôn ngữ Java

Trong ngành điện toán, khái niệm con trỏ rỗng chỉ một biến con trỏ có một giá trị định sẵn khiến cho nó không trỏ được tới bất kì một đối tượng chính tắc nào. Charles Antony Richard Hoare tác giả của ngôn ngữ Algol W từng nói rằng việc phát minh ra tham chiếu rỗng là một sai lầm tỉ đô của ông. Vậy tại sao ông lại gọi đó là sai lầm tỉ đô? Trong ngôn ngữ Java, tham chiếu đến một đối tượng rỗng sẽ sinh ra ngoại lệ NullPointerException, đây là một unchecked exception. Việc xác định exception này có xảy ra hay không, chỉ có thể thực hiện được ở thời điểm runtime và compiler trong quá trình biên dịch không thể giúp lập trình viên xác định được chuyện đó. Chính điều này dẫn đến việc cho dù sản phẩm của bạn đã vượt qua được cơ số các bài test của đội QA tại môi trường test, nhưng đến một thời điểm nào đó sau khi đã lên production thì hệ thống đột ngột lại ngừng hoạt động do phát sinh lỗi, hệ thống sụp đổ dẫn đến thiệt hại có thể lên đến cả tỉ đô la. Dưới đây là một số biện pháp có thể áp dụng để hạn chế điều tồi tệ trên có thể xảy ra trong quá trình phát triển phần mềm khi sử dụng ngôn ngữ Java:

1, Gọi phương thức equals() và equalsIgnoreCase() trên các đối tượng String đã biết sẽ tốt hơn là gọi trên các Object chưa xác định

---

Hãy nhớ luôn gọi phương thức equals() trên một đối tượng String không null đã biết. Vì phương thức equals() là phương thức đối xứng, nên khi gọi a.equals(b) sẽ tương tự như khi gọi b.equals(a), và đây là lí do mà nhiều lập trình viên không chú ý đến hai đối tượng a và b. Hệ quả của việc gọi phương thức bất cẩn như thế có thể dẫn đến việc chương trình ném ra NullPointerException nếu như đối tượng gọi phương thức equals() là null.

Object unknownObject = null;

// Cách thực hiện sai - có thể gây ra NullPointerException
if(unknownObject.equals("knownObject")) {
    System.err.println("This may result in NullPointerException if unknownObject is null");
}

// Cách thực hiện đúng - tránh được NullPointerException thậm chí nếu unknownObject là một đối tượng null
if("knownObject".equals(unknownObject)) {
    System.err.println("better coding avoided NullPointerException");
}

Đây là một trong các cách thực hiện dễ dàng nhất khi sử dụng ngôn ngữ Java để tránh được NullPointerException, nhưng kết quả mà nó mang lại được cải thiện vô cùng lớn vì phương thức equals() là một trong những phương thức được sử dụng phổ biến nhất.

2, Nên sử dụng valueOf() thay vì toString() khi cả hai phương thức trả về cùng một giá trị như nhau

---

Vì khi gọi phương thức toString() trên một đối tượng null, thì nó sẽ ném ra NullPointerException. Nếu sử dụng phương thức valueOf() mà cũng có thể trả về giá trị giống với khi sử dụng phương thức toString() thì ta nên sử dụng valueOf(), vì gọi phương thức valueOf() trên một đối tượng null nó sẽ trả về chuỗi "null", chứ không ném ra NullPointerException, đặc biệt là trong trường hợp các lớp Wrapper như Integer, Float, Double hoặc BigDecimal.

BigDecimal bd = getPrice();

/* Không ném ra NullPointerException */
System.out.println(String.valueOf(bd));

/* Ném ra "Exception trong "main" thread java.lang.NullPointerExxception" */
System.out.println(bd.toString());

Sử dụng cách này nếu bạn không chắc chắn một đối tượng là null hay không null.

3, Nên sử dụng các phương thức và thư viện null safe

---

Trong cộng đồng mã nguồn mở có rất nhiều thư viện có thể giúp bạn dễ dàng hơn trong việc kiểm tra null. Phổ biến nhất trong số này là lớp StringUtils từ thư viện Apache commons. Bạn có thể sử dụng StringUtils.íBlank(), isNumeric(), isWhitSpace() và các phương thức hữu ích khác mà không phải lo lắng về NullPointerException.

// Các phương thức trong lớp StringUtils là null safe, chúng không ném ra NullPointerExcetion
System.out.println(StringUtils.isEmpty(null));
System.out.println(StringUtils.isBlank(null));
System.out.println(StringUtils.isNumeric(null));
System.out.println(StringUtils.isAllUpperCase(null));

Output:
true
true
false
false

4, Không nên viết một phương thức trả về tập hợp là null, thay vào đó hãy trả về một empty collection hoặc empty array

---

Bằng việc trả về một empty collection hoặc empty array, bạn có thể chắc chắn đươc rằng khi gọi các phương thức cơ bản như size() hoặc length() chương trình sẽ xảy ra lỗi vì NullPointerException. Lớp Collections trong Java cung cấp tập hợp các đối tượng List, Set, Map rỗng thuận tiện sử dụng trong các trường hợp phù hợp, ví dụ như: Collections.EMPTY_LIST, Collections.EMPTY_SET và Collections.EMPTY_MAP

Ví dụ:

@Service
public class EmployeeService {

    private EmployeeDao employeeDao;

    public List<Contact> getContacts(Employee employee) {
        List<Contact> contacts;
        try {
            contacts = this.employeeDao.getContacts(employee); 
        } catch (Exception e) {
            contacts = Collections.EMPTY_LIST;
        }
        return contacts;
    }

    @Autowired
    public void setEmployeeDao(EmployeeDao employeeDao) {
        Assert.notNull(employeeDao, "EmployeeDao must not be null!");
        this.employeeDao = employeeDao;
    }
}

Tương tự, bạn có thể sử dụng Collections.EMPTY_SET và Collections.EMPTY_MAP thay vì trả về null.

5, Hãy sử dụng annotation @NotNull và @Nullable

---

Trong khi viết code, ta có thể đánh dấu một đoạn code có khả năng gây ra null bằng cách sử dụng annotation @NotNull và @Nullable, hai annotation này sẽ đánh dấu liệu một phương thức có phải là null safe hay không. Nhiều trình biên dịch, IDE hoặc tool hiện nay đều có thể đọc được hai annotation này và nó sẽ gợi ý cho bạn khi có thiếu sót trong việc kiểm tra null, hoặc những công cụ này cũng có thể sẽ thông báo cho bạn nếu như việc kiểm tra null tại một đoạn code nào đó là không cần thiết. IntelliJ IDE và plugin findbugs là một trong những công cụ có hỗ trợ tính năng này. Hai annotation này là một phần trong JSR 305, nhưng ngay cả khi không có công cụ hoặc IDE nào hỗ trợ thì việc đánh dấu code bằng các annotaiton này thì điều này cũng giống như một tài liệu cho source code, giúp cho các lập trình viên khi nhìn vào có thể đưa ra quyết định có kiểm tra null hay không.

6, Tránh sử dụng autoboxing và unboxing không cần thiết trong code

---

Mặc dù cách thực hiện này gây ra những bất lợi khác như là tạo ra object tạm thời, nhưng vì nếu lớp Wrapper là null thì autoboxing rất dễ gây ra NullPointerException. Ví dụ, khi thực hiện đoạn code sau sẽ bị lỗi và ném ra NullPointerException nếu đối tượng Person không có phone number và chương trình sẽ trả về null nếu bạn cố gắng thực hiện phương thức getPhone().

Person person = new Person("Psyduck");
int phone = person.getPhone();

Không chỉ khi so sánh tương đương mà khi sử dụng các toán tử <, > cũng có thể gây ra NullPointerException nếu như được sử dụng cùng với autoboxing và unboxing.

7, Theo sát Contract đã thiết kế và xác định các giá trị mặc định hợp lí

---

Trong Java, một cách đơn giản khác để tránh được NullPointerException đó là định nghĩa ra Contract và thực hiện theo đúng như thiết kế. Nhiều trường hợp dẫn đến NullPointerException đó là do Object được tạo ra có dữ liệu hoặc các dependency bắt buộc chưa được cung cấp đầy đủ. Nếu bạn định nghĩa ra các Contract không cho phép tạo đối tượng bị thiếu thông tin như vậy thì bạn sẽ có thể ngăn chặn sớm được việc chương trình bị lỗi do NullPointerException. Bạn cũng nên định nghĩa ra các giá trị mặc định hợp lí khi viết code, ví dụ như một đối tượng Employee không thể được tạo nếu thiếu các thuộc tính id, name, nhưng số điện thoại là tùy chọn. Nếu Employee không có số điện thoại thì thay vì trả về null, ta sẽ trả về giá trị mặc định, ví dụ như trả về 0, nhưng lựa chọn này cần phải được thực hiện một cách cẩn trọng vì trong một số trường hợp thì việc kiểm tra null sẽ dễ dàng hơn là gọi một số không hợp lệ.

8, Tạo ràng buộc trong database

---

Nếu bạn đang sử dụng cơ sở dữ liệu cho việc lưu trữ các domain object giống như Customers, Orders, Contacts, ... thì hãy nên định nghĩa ra các ràng buộc xác định rõ một trường dữ liệu có khả năng được nhận giá trị null hay không. Vì cơ sở dữ liệu có thể thu được dữ liệu từ nhiều nguồn khác nhau, vậy nên sử dụng các ràng buộc để kiểm tra dữ liệu đầu vào trước khi insert hay update sẽ đảm bảo được sự toàn vẹn của dữ liệu. Việc cung cấp các ràng buộc kiểm tra giá trị null cũng giảm số lần phải kiểm tra null khi thực hiện viết code Java. Khi thực hiện lấy dữ liệu về từ cơ sở dữ liệu để truyền vào các object, bạn đã nắm rõ được thuộc tính nào của object có thể là null, và thuộc tính nào sẽ không bao giờ có thể nhận giá trị null nên điều này sẽ giảm số lần kiểm tra != null không cần thiết trong code của bạn tới mức tối thiểu.

9, Sử dụng Null Object Pattern

---

Trong Java thì đây cũng là một cách để đảm bảo chương trình của bạn sẽ không ném ra NullPointerException.

Hạn chế sai lầm tỉ đô khi sử dụng ngôn ngữ Java

---

(by @dangquando)

view raw framgia-report-2017-april.md hosted with ❤ by GitHub

Các toán tử logic trong PL/SQL

1. Toán tử AND

AND	TRUE	FALSE	NULL
TRUE	T	F	NULL
FALSE	F	F	F
NULL	NULL	F	NULL

2. Toán tử OR

AND	TRUE	FALSE	NULL
TRUE	T	T	T
FALSE	T	F	NULL
NULL	T	NULL	NULL

3. Toán tử NOT

NOT
TRUE	F
FALSE	T
NULL	NULL

view raw Các toán tử logic trong PL SQL.md hosted with ❤ by GitHub