text:
Một trong những biện pháp thực tiễn phổ biến để phát triển nhanh là TDD. TDD là một phong cách viết phần mềm có sử dụng các thử nghiệm để giúp bạn hiểu được bước cuối cùng của pha xác định các yêu cầu. Bạn viết các thử nghiệm trước khi bạn viết mã lệnh, củng cố thêm hiểu biết của bạn về những cái mà mã lệnh phải làm.
Hầu hết các nhà phát triển cho rằng lợi ích hàng đầu thu được từ TDD là tập hợp toàn diện các thử nghiệm đơn vị mà bạn nhận được. Tuy nhiên, khi thực hiện đúng, TDD có thể thay đổi thiết kế tổng thể của mã lệnh của bạn thành tốt hơn bởi vì nó trì hoãn các quyết định cho đến thời điểm hợp lý cuối cùng. Bởi vì bạn không thực hiện các quyết định thiết kế từ trước, nó bỏ ngỏ cho bạn các tùy chọn thiết kế tốt hơn hoặc cấu trúc lại để thiết kế tốt hơn. Bài viết này đi từng bước thông qua một ví dụ để minh họa sức mạnh của việc cho phép thiết kế nổi rõ lên từ các quyết định xung quanh các thử nghiệm đơn vị.
Luồng công việc của TDD
Một từ quan trọng trong thuật ngữ phát triển dựa theo thử nghiệm là dựa theo, báo hiệu rằng việc thử nghiệm điều khiển quá trình phát triển. Hình 1 cho thấy luồng công việc của TDD:
Hình 1. Luồng công việc của TDD
Luồng công việc trong hình 1 là:
- Viết một thử nghiệm không thành công.
- Viết mã lệnh để làm cho nó thông qua.
- Lặp lại các bước 1 và 2.
- Đồng thời cấu trúc lại quyết liệt.
- Khi bạn không thể nghĩ đến bất kỳ thử nghiệm nào thêm nữa, bạn đã xong việc.
Dựa theo thử nghiệm so với thử nghiệm sau
Việc phát triển - dựa theo thử nghiệm yêu cầu các thử nghiệm xuất hiện trước. Chỉ sau khi bạn đã viết các thử nghiệm (và thất bại) bạn mới viết mã lệnh được thử nghiệm. Nhiều nhà phát triển sử dụng một biến thể cách làm thử nghiệm được gọi là phát triển thử nghiệm sau (TAD), ở đó bạn viết mã lệnh và sau đó viết các thử nghiệm đơn vị. Trong trường hợp này, bạn vẫn nhận được các thử nghiệm, nhưng bạn không nhận được các khía cạnh thiết kế nổi dần của TDD. Chẳng có gì ngăn cản bạn viết mã lệnh cực kỳ ghớm guốc và sau đó lúng túng tìm cách để thử nghiệm nó như thế nào. Khi viết mã lệnh trước, bạn đã nhúng các định kiến của bạn về cách thức mã sẽ hoạt động ra sao, sau đó thử nghiệm nó. TDD đòi hỏi bạn phải làm ngược lại: viết các thử nghiệm trước và cho phép nó thông báo cho bạn cách làm thế nào để viết mã lệnh làm cho thử nghiệm thông qua. Để minh họa sự khác biệt quan trọng này, tôi sẽ bắt đầu một ví dụ mở rộng.
Các số hoàn hảo
Để cho thấy các lợi ích thiết kế của TDD, tôi cần một bài toán để giải quyết. Trong cuốn sách Phát triển dựa theo thử nghiệm của mình (xem Tài nguyên), Kent Beck sử dụng tiền tệ làm một ví dụ — một sự minh họa khá tốt về TDD, nhưng hơi đơn giản thái quá. Thách thức thực sự là phải tìm ra một ví dụ không phức tạp đến mức mà bạn bị lạc lối trong lĩnh vực của bài toán nhưng đủ phức tạp để cho thấy giá trị thực sự.
Vì mục đích ấy, tôi đã chọn các số hoàn hảo. Đối với những bạn không theo dõi chuyện tầm phào toán học, khái niệm này có nguồn gốc từ trước Euclid (người đã thực hiện một trong các chứng minh sớm nhất về việc tìm ra các số hoàn hảo). Một số hoàn hảo là một số mà bằng tổng của các thừa số của nó. Ví dụ, 6 là một số hoàn hảo bởi vì các thừa số của 6 (trừ chính số 6) là 1, 2 và 3 và 1 + 2 + 3 = 6. Một định nghĩa nhiều tính thuật toán hơn cho một số hoàn hảo là một số mà tổng các thừa số (trừ chính số đó) bằng chính số đó. Trong ví dụ của tôi, phép tính là 1 + 2 + 3 +6 - 6 = 6.
Và đây là lĩnh vực bài toán cần giải quyết: tạo ra một trình tìm kiếm số hoàn hảo. Tôi sẽ thực hiện lời giải cho bài toán này theo hai cách khác nhau. Trước tiên, tôi sẽ tắt một phần của não bộ của tôi muốn thực hiện TDD và chỉ viết giải pháp, sau đó viết các thử nghiệm cho nó. Rồi sau đó, tôi sẽ phát triển một phiên bản TDD của giải pháp để tôi có thể so sánh và đối chiếu cả hai cách tiếp cận.
Đối với ví dụ này, tôi
triển khai thực hiện một trình tìm kiếm một số hoàn hảo bằng ngôn ngữ Java
(phiên bản 5 hoặc mới hơn vì tôi sẽ sử dụng các chú thích trong thử nghiệm
của mình), JUnit 4.x (phiên bản mới nhất) và các trình phối hợp Hamcrest
từ kho mã của Google (xem Tài nguyên). Các trình
phối hợp Hamcrest cung cấp một cú pháp theo cách giao tiếp của con người
phủ bên trên các trình phối hợp JUnit tiêu chuẩn. Ví dụ, thay cho
assertEquals(expected, actual), bạn có thể viết
assertEquals(actual, is(expected)), đọc lên
nghe giống với một câu nói đời thực hơn. Các trình phối hợp Hamcrest có
kèm theo với JUnit 4.x (chỉ cần dùng lệnh nhập khẩu (import) tĩnh); nếu
bạn vẫn còn sử dụng JUnit 3.x, bạn có thể tải về một phiên bản tương
thích.
Thử nghiệm sau
Listing 1 hiển thị phiên bản đầu tiên của
PerfectNumberFinder:
Listing 1. The test-after
PerfectNumberFinder
public class PerfectNumberFinder1 { public static boolean isPerfect(int number) { // get factors List<Integer> factors = new ArrayList<Integer>(); factors.add(1); factors.add(number); for (int i = 2; i < number; i++) if (number % i == 0) factors.add(i); // sum factors int sum = 0; for (int n : factors) sum += n; // decide if it's perfect return sum - number == number; } }
Đây không phải là mã đặc biệt đẹp, nhưng nó hoàn thành được công việc. Tôi
bắt đầu bằng cách liệt kê tất cả các thừa số dưới dạng một danh sách động
(một
ArrayList). Tôi thêm 1 và số đích vào danh
sách. (Tôi tuân thủ công thức đã cho ở trên và liệt kê tất cả các thừa số,
bao gồm số 1 và chính số đó). Sau đó, tôi duyệt qua các thừa số cho đến
khi gặp chính số đó, kiểm tra lần lượt từng số để xem nó có phải một thừa
số không. Nếu đúng, tôi thêm số đó vào danh sách. Tiếp theo, tôi lấy tổng
tất cả các thừa số và cuối cùng là viết một phiên bản Java của công thức
đã chỉ ra ở trên để xác định số hoàn hảo.
Bây giờ, tôi cần một thử nghiệm đơn vị theo cách thử nghiệm sau để xác định xem chương trình có hoạt động đúng hay không. Tôi cần ít nhất hai thử nghiệm: một để xem báo cáo kết quả các số hoàn hảo có đúng không và thử nghiệm kia sẽ kiểm tra để tôi không nhận được các xác thực sai. Các thử nghiệm đơn vị có trong Listing 2:
Listing 2. Các thử nghiệm đơn vị cho
PerfectNumberFinder
public class PerfectNumberFinderTest { private static Integer[] PERFECT_NUMS = {6, 28, 496, 8128, 33550336}; @Test public void test_perfection() { for (int i : PERFECT_NUMS) assertTrue(PerfectNumberFinder1.isPerfect(i)); } @Test public void test_non_perfection() { List<Integer>expected = new ArrayList<Integer>( Arrays.asList(PERFECT_NUMS)); for (int i = 2; i < 100000; i++) { if (expected.contains(i)) assertTrue(PerfectNumberFinder1.isPerfect(i)); else assertFalse(PerfectNumberFinder1.isPerfect(i)); } } @Test public void test_perfection_for_2nd_version() { for (int i : PERFECT_NUMS) assertTrue(PerfectNumberFinder2.isPerfect(i)); } @Test public void test_non_perfection_for_2nd_version() { List<Integer> expected = new ArrayList<Integer>(Arrays.asList(PERFECT_NUMS)); for (int i = 2; i < 100000; i++) { if (expected.contains(i)) assertTrue(PerfectNumberFinder2.isPerfect(i)); else assertFalse(PerfectNumberFinder2.isPerfect(i)); } assertTrue(PerfectNumberFinder2.isPerfect(PERFECT_NUMS[4])); } }
Mã này cho kết quả đúng là các số hoàn hảo nhưng nó chạy rất chậm với thử nghiệm phủ định do phải kiểm tra quá nhiều số. Các vấn đề hiệu suất có thể xuất hiện từ các thử nghiệm đơn vị đã đưa tôi quay về với mã lệnh để xem xem tôi có thể thực hiện một số cải tiến không. Hiện tại, tôi duyệt qua suốt vòng lặp cho đến khi gặp chính số đó để thu được các thừa số. Nhưng tôi có cần phải đi xa như thế không? Không, nếu như tôi có thể thu hoạch các thừa số theo từng cặp. Tất cả các thừa số đều có cặp (ví dụ, nếu số đích là số 28, khi tôi tìm thấy thừa số 2, tôi cũng có thể lấy luôn thừa số 14). Tôi chỉ cần đi tiếp lên tới căn bậc 2 của số đích là tôi có thể thu được các thừa số theo cặp. Vì mục đích này, tôi cải tiến các thuật toán và cấu trúc lại mã lệnh cho Listing 3:
Listing 3. Phiên bản thuật toán đã cải tiến
public class PerfectNumberFinder2 { public static boolean isPerfect(int number) { // get factors List<Integer> factors = new ArrayList<Integer>(); factors.add(1); factors.add(number); for (int i = 2; i <= sqrt(number); i++) if (number % i == 0) { factors.add(i); factors.add(number / i); } // sum factors int sum = 0; for (int n : factors) sum += n; // decide if it's perfect return sum - number == number; } }
Mã này chạy trong một thời gian khá dài nhưng một số kết quả thử nghiệm không thành công. Té ra là khi bạn thu thập các thừa số theo các cặp, bạn vô tình lấy ra các số hai lần khi đạt đến căn bậc hai của số đích. Ví dụ, đối với số 16, có căn bậc hai là 4, vô tình được thêm vào danh sách hai lần. Điều này rất dễ dàng sửa chữa bằng cách tạo một điều kiện canh giữ trường hợp này, như được hiển thị trong Listing 4:
Listing 4. Thuật toán cải tiến đã sửa lỗi
for (int i = 2; i <= sqrt(number); i++) if (number % i == 0) { factors.add(i); if (number / i != i) factors.add(number / i); }
Bây giờ tôi có một phiên bản kiểm tra sau của trình tìm số hoàn hảo. Nó làm việc được nhưng có một số vấn đề về thiết kế kéo theo. Trước tiên, tôi đã sử dụng các dòng chú thích phân tách các phần của mã lệnh. Đây luôn luôn là hương vị của mã lệnh: nó là một tiếng kêu cứu để cấu trúc lại thành các phương thức riêng. Cái mới mà tôi vừa thêm vào có lẽ cần một chú thích để giải thích những gì mà điều kiện canh giữ bé nhỏ ấy sẽ làm, nhưng bây giờ tôi sẽ để mặc thế đã. Vấn đề lớn nhất nằm ở độ dài của nó. Nguyên tắc ngón tay cái của tôi đối với các dự án Java nói rằng không nên có phương thức nào dài hơn 10 dòng mã. Nếu một phương thức vượt quá con số này, nó gần như chắc chắn là làm nhiều hơn một điều mà nó không nên làm. Phương thức này rõ ràng vi phạm nguyên tắc ấy, do đó tôi sẽ thử một cách khác, lần này sẽ sử dụng TDD.
Thiết kế nổi dần thông qua TDD
Câu thần chú Ấn độ dành cho viết mã TDD là: "Cái điều đơn giản nhất để tôi có thể viết một thử nghiệm cho nó là gì ?". Trong trường hợp này, đó có phải là "là một số hoàn hảo hay là không?". Không — câu trả lời là điều này quá rộng. Tôi phải phân rã bài toán và suy nghĩ "số hoàn hảo" có nghĩa là gì. Tôi có thể dễ dàng đi đến kết quả là một số bước cần thiết để khám phá ra một số hoàn hảo:
- Tôi cần các thừa số của số đang xét.
- Tôi cần phải xác định xem một số có phải là thừa số không.
- Tôi cần phải lấy tổng các thừa số.
Hướng theo ý tưởng tìm điều đơn giản nhất ấy, mục nào trong số các mục trong danh sách trên có vẻ là mục đơn giản nhất ? Tôi nghĩ rằng đó là mục xác định xem một số có phải là thừa số của một số khác không. Vậy đây là phép thử nghiệm đầu tiên của tôi, nó có trong Listing 5:
Listing 5. Kiểm tra xem "một số có phải là thừa số không?"
public class Classifier1Test { @Test public void is_1_a_factor_of_10() { assertTrue(Classifier1.isFactor(1, 10)); } }
Phép kiểm tra đơn giản này là tầm thường đến mức ngớ ngẩn và nó chính là
cái tôi muốn. Để thực hiện thử nghiệm này, bạn phải có một lớp có tên là
Classifier1, với một phương thức
isFactor(). Vì vậy, tôi phải tạo ra một khung
sườn cấu trúc của lớp này trước khi tôi thậm chí có thể nhận được một
thanh màu đỏ. Việc viết các thử nghiệm đơn vị tầm thường quá đỗi này cho
phép bạn dựng lên một kết cấu trước khi bạn cần bắt đầu suy nghĩ về lĩnh
vực của bài toán theo một cách có ý nghĩa. Tôi muốn suy nghĩ về chỉ một
điều ở một thời điểm và điều này cho phép tôi tiếp tục làm việc trên khung
sườn cấu trúc mà không phải lo về các sắc thái của bài toán mà tôi đang
giải quyết. Sau khi biên dịch những thứ trên và thanh màu đỏ xuất hiện,
tôi ở tư thế sẵn sàng để viết mã, hiển thị trong Listing
6:
Listing 6. Lần đầu tiên thông qua thử nghiệm với phương thức thừa số
public class Classifier1 { public static boolean isFactor(int factor, int number) { return number % factor == 0; } }
Tốt rồi, thật đẹp và đơn giản, và nó làm được việc. Bây giờ tôi có thể chuyển sang nhiệm vụ đơn giản nhất tiếp theo: nhận một danh sách các thừa số của một số. Thử nghiệm xuất hiện trong 7:
Listing 7. Thử nghiệm tiếp theo: Các thừa số của một số đã cho
@Test public void factors_for() { int[] expected = new int[] {1}; assertThat(Classifier1.factorsFor(1), is(expected)); }
Listing 7 chứa thử nghiệm đơn giản nhất mà tôi phải cố gắng làm để nhận được các thừa số, vì thế bây giờ tôi có thể viết mã lệnh đơn giản nhất để thông qua được thử nghiệm này (và cấu trúc lại nó sau này để làm cho nó tinh tế hơn). Phương thức tiếp theo xuất hiện trong Listing 8:
Listing 8. Phương thức đơn giản
factorsFor()
public static int[] factorsFor(int number) { return new int[] {number}; }
Mặc dù phương thức này làm việc đúng, nó giữ tôi tạm dừng trên đường đi.
Có vẻ như để cho
isFactor() thành phương thức
tĩnh (static) là một ý tưởng tốt, bởi vì nó chỉ trả về kết quả dựa trên
đầu vào của nó. Tuy nhiên, bây giờ tôi cũng đã để cho
factorsFor() là phương thức tĩnh, có nghĩa là tôi phải chuyển
một tham số được gọi là
number cho cả hai
phương thức. Mã lệnh này trở thành quá thủ tục, đó là hậu quả phụ của việc
lạm dụng phương thức tĩnh. Để sửa chữa điều này, tôi sẽ cấu trúc lại hai
phương thức mà tôi đã có, đây là việc đơn giản là vì cho đến nay mới chỉ
có một ít mã như vậy. Lớp
Classifier đã cấu
trúc lại xuất hiện trong Listing 9:
Listing 9. Lớp
Classifier đã cải tiến
public class Classifier2 { private int _number; public Classifier2(int number) { _number = number; } public boolean isFactor(int factor) { return _number % factor == 0; } }
Tôi đã làm cho number thành một biến thành viên trong lớp
Classifier2, điều này cho phép tôi tránh được
việc chuyển đi chuyển lại nó như một tham số tới một bó các phương thức
tĩnh.
Mục tiếp theo trong danh sách phân rã ở trên nói rằng tôi cần phải tìm ra các thừa số của một số. Vì vậy, thử nghiệm tiếp theo của tôi cần kiểm tra điều này (hiển thị trong Listing 10):
Listing 10. Thử nghiệm tiếp theo: Các thừa số của một số
@Test public void factors_for_6() { int[] expected = new int[] {1, 2, 3, 6}; Classifier2 c = new Classifier2(6); assertThat(c.getFactors(), is(expected)); }
Bây giờ, tôi sẽ thử triển khai thực hiện phương thức trả về một mảng các thừa số của một tham số đã cho, hiển thị trong 11:
Listing 11. Lần đầu tiên thông qua thử nghiệm với phương thức
getFactors()
public int[] getFactors() { List<Integer> factors = new ArrayList<Integer>(); factors.add(1); factors.add(_number); for (int i = 2; i < _number; i++) { if (isFactor(i)) factors.add(i); } int[] intListOfFactors = new int[factors.size()]; int i = 0; for (Integer f : factors) intListOfFactors[i++] = f.intValue(); return intListOfFactors; }
Mã này cho phép vượt qua thử nghiệm, nhưng khi suy nghĩ lại, thật dễ sợ!
Điều này đôi lúc xảy ra khi bạn điều tra tỷ mỉ cách triển khai thực hiện
mã lệnh bằng cách sử dụng các thử nghiệm. Có gì khủng khiếp như vậy về các
mã này? Trước hết, nó rất dài và phức tạp và nó cũng mắc nhược điểm là vấn
đề "làm nhiều hơn một thứ". Bản năng của tôi đã dẫn tôi trở lại với việc
dùng một mảng
int[], nhưng nó sẽ tăng thêm khá
nhiều sự phức tạp vào mã lệnh ở dưới cùng và không đạt được bất cứ thứ gì
cho tôi. Đó là một con đường dốc trơn trượt khó đi khi bắt đầu suy nghĩ
quá nhiều về việc làm cho mọi thứ thuận tiện hơn dành cho các phương thức
tương lai mà có thể gọi phương thức này. Bạn cần phải có một lý do có sức
thuyết phục để thêm một cái gì đó phức tạp như thế vào mối nối này và tôi
còn chưa có một sự biện hộ nào cho việc này. Việc xem xét kỹ mã này gợi ý
rằng có lẽ
các thừa số cũng nên tồn tại như một
trạng thái bên trong của lớp, cho phép tôi tách riêng ra phần chức năng
của phương thức này.
Một trong những đặc điểm có ích mà các thử nghiệm làm nổi lên là các phương thức thực sự kết dính. Kent Beck đã viết về điều này trong một cuốn sách có ảnh hưởng tên là Các mẫu thực tiễn tốt nhất của Smalltalk (Smalltalk Best Practice Patterns ) (xem Tài nguyên). Trong cuốn sách đó, Kent đã định nghĩa một mẫu được gọi là phương thức cấu thành (composed method). Mẫu phương thức cấu thành định nghĩa ba khẳng định then chốt:
- Chia chương trình của bạn thành các phương thức thực hiện một công việc có thể nhận biết được.
- Giữ cho tất cả các phép toán trong một phương thức có cùng một mức độ trừu tượng hóa.
- Điều này sẽ tự nhiên dẫn đến các chương trình với nhiều phương thức nhỏ, mỗi phương thức có độ dài vài dòng.
Phương thức cấu thành là một trong những đặc điểm thiết kế có ích mà
TDD khuyến khích và tôi đã vi phạm rõ ràng mẫu này trong phương thức
getFactors() ở Listing
11. Tôi có thể sửa chữa nó bằng cách thực hiện các bước sau:
- Nâng
các thừa sốlên thành trạng thái bên trong.
- Di chuyển đoạn mã khởi tạo
các thừa sốvào hàm tạo.
- Loại bỏ đoạn mã mạ vàng nhằm chuyển đổi kết quả thành mảng
int[]và xử lý nó sau nếu điều này là có ích.
- Thêm một thử nghiệm khác cho
addFactors().
Bước thứ tư là khá tế nhị, nhưng quan trọng. Việc viết phiên bản mã
có lỗi này đã để lộ ra rằng vòng phân rã đầu tiên của tôi đã không đầy đủ.
Dòng mã
addFactors() giấu vào giữa phương thức
dài này là hành vi thử nghiệm được. Nó tầm thường đến mức mà tôi đã không
nhận thấy điều này khi lần đầu tiên xem xét bài toán, nhưng bây giờ tôi đã
thấy rồi. Điều này thường xuyên xảy ra. Một thử nghiệm có thể dẫn bạn đến
phân rã tiếp tục bài toán thành các đoạn ngày càng nhỏ hơn, mỗi đoạn đều
có thể thử nghiệm.
Tôi sẽ tạm dừng bài toán lớn hơn về
getFactors() vào lúc này và giải quyết bài toán
mới nhỏ nhất của tôi. Như vậy, thử nghiệm tiếp theo của tôi là
addFactors(), được hiển thị trong Listing 12:
Listing 12. Thử nghiệm với
addFactors()
@Test public void add_factors() { Classifier3 c = new Classifier3(6); c.addFactor(2); c.addFactor(3); assertThat(c.getFactors(), is(Arrays.asList(1, 2, 3, 6))); }
Đoạn mã cần thử nghiệm, được hiển thị trong Listing 13, là rất đơn giản:
Listing 13. Mã lệnh đơn giản để cộng các thừa số
public void addFactor(int factor) { _factors.add(factor); }
Tôi chạy thử nghiệm đơn vị của tôi, hoàn toàn tin tưởng rằng tôi sẽ thấy một thanh màu xanh lục, nhưng nó thất bại! Làm thế nào mà một thử nghiệm đơn giản đến như vậy lại thất bại? Nguyên nhân gốc rễ xuất hiện trong Hình 2:
Hình 2. Nguyên nhân gốc rễ của thử nghiệm không thành công
Danh sách mà tôi mong đợi có các giá trị
1, 2, 3,
6 nhưng thực tế trả về là
1, 6, 2,
3. Ôi, đó là vì tôi đã thay đổi mã để thêm 1 và chính số đích vào
hàm tạo. Một giải pháp cho vấn đề này sẽ là luôn viết như tôi mong muốn,
giả sử rằng số 1 và chính số đích luôn luôn được viết trước hết. Nhưng đó
có phải là giải pháp đúng không? Không. Vấn đề ở chỗ căn bản hơn
nhiều. Các thừa số có phải là một danh sách các số không? Không,
chúng là một tập hợp các số. Giả thiết đầu tiên (không đúng) của
tôi dẫn đến việc sử dụng một danh sách các số nguyên dành cho các thừa số,
nhưng đó là một phép trừu tượng hóa tồi. Bằng việc cấu trúc lại mã lệnh,
bây giờ tôi sử dụng các tập hợp thay vì các danh sách, tôi không chỉ khắc
phục được vấn đề này mà còn làm cho giải pháp tổng thể trở nên tốt hơn vì
bây giờ tôi đang sử dụng phép trừu tượng hóa chính xác hơn.
Đây đúng là một kiểu suy nghĩ thiếu sót khi cho rằng các thử nghiệm có thể phơi bày ra, có phải bạn viết các thử nghiệm trước khi bạn viết mã để che giấu việc phán xét bạn. Bây giờ, nhờ thử nghiệm đơn giản này, toàn bộ thiết kế mã lệnh của tôi thành tốt hơn vì tôi đã phát hiện một cách trừu tượng hóa thích hợp hơn.
Kết luận
Cho đến nay, tôi đã thảo luận về thiết kế nổi dần trong bối cảnh của bài toán số hoàn hảo. Nói riêng, lưu ý rằng phiên bản đầu tiên của giải pháp (phiên bản kiểm tra sau) đã phạm cùng một giả thiết sai lầm về các kiểu dữ liệu. "Thử nghiệm sau" kiểm tra các chức năng của mã của bạn ở mức chi tiết thô, chứ không phải ở mức các phần riêng biệt. TDD kiểm tra các khối nền tảng làm nên chức năng ở mức chi tiết thô ấy, phơi bày ra nhiều thông tin hơn trong quá trình làm việc.
Trong bài viết tiếp theo, tôi sẽ tiếp tục bài toán số hoàn hảo, minh họa nhiều ví dụ về các loại thiết kế có thể xuất hiện nếu bạn để lộ ra cách thức của các thử nghiệm của bạn. Khi tôi có phiên bản TDD đầy đủ, tôi sẽ so sánh một vài số liệu thống kê giữa hai cơ sở mã. Tôi cũng sẽ xử lý một số câu hỏi thiết kế khó khăn khác về TDD, ví dụ như có hay không và khi nào thì thử nghiệm các phương thức riêng.
Tài nguyên
Học tập
- Hamcrest matchers: Một thư viện các trình phối hợp đối tượng cho phép bạn định nghĩa thế nào là "khớp" để sử dụng trong các khung công tác khác.
- Test-Driven Development (Kent Beck, Addison-Wesley, 2003): Beck, nhà sáng lập Lập trình đỉnh cao, sử dụng các ví dụ dựa trên tiền tệ để giải thích TDD.
- Smalltalk Best Practice Patterns (Kent Beck, Prentice Hall, 1996): Tìm hiểu thêm về mẫu phương thức cấu thành.
- The Productive Programmer (Neal Ford, O'Reilly Media, 2008): Một phiên bản dài hơn của ví dụ trong bài viết này xuất hiện trong chương "Phát triển dựa vào thử nghiệm” trong cuốn sách gần đây nhất của Neal Ford.
- "Emergent Optimization in Test Driven Design" (Michael Feathers): Thử nghiệm giúp tránh được sự tối ưu hóa quá sớm như thế nào.
- Duyệt qua technology bookstore để tìm các sách về chủ đề kỹ thuật này và các chủ đề kỹ thuật khác.
- developerWorks Java technology zone: Tìm hàng trăm bài viết về mọi khía cạnh của lập trình Java.
Lấy sản phẩm và công nghệ
- JUnit: Tải về JUnit.
Thảo luận
- Xem developerWorks blogs và tham gia vào cộng đồng developerWorks.
Bình luận
-
Vùng dữ liệu trên developerWorks
Khám phá các bài viết xoay quanh lĩnh vực dữ liệu, Quản lý hệ thống thông tin
-
Vùng mã nguồn mở trên developerWorks
Xem các bài viết về HTML, CSS, JavaScript,...
-
Điện toán đám mây
Tìm hiểu về điện toán đám mây

markdown:
Một trong những biện pháp thực tiễn phổ biến để phát triển nhanh là TDD. TDD là một phong cách viết phần mềm có sử dụng các thử nghiệm để giúp bạn hiểu được bước cuối cùng của pha xác định các yêu cầu. Bạn viết các thử nghiệm trước khi bạn viết mã lệnh, củng cố thêm hiểu biết của bạn về những cái mà mã lệnh phải làm.
Hầu hết các nhà phát triển cho rằng lợi ích hàng đầu thu được từ TDD là tập hợp toàn diện các thử nghiệm đơn vị mà bạn nhận được. Tuy nhiên, khi thực hiện đúng, TDD có thể thay đổi thiết kế tổng thể của mã lệnh của bạn thành tốt hơn bởi vì nó trì hoãn các quyết định cho đến thời điểm hợp lý cuối cùng. Bởi vì bạn không thực hiện các quyết định thiết kế từ trước, nó bỏ ngỏ cho bạn các tùy chọn thiết kế tốt hơn hoặc cấu trúc lại để thiết kế tốt hơn. Bài viết này đi từng bước thông qua một ví dụ để minh họa sức mạnh của việc cho phép thiết kế nổi rõ lên từ các quyết định xung quanh các thử nghiệm đơn vị.
## Luồng công việc của TDD
Một từ quan trọng trong thuật ngữ
*phát triển dựa theo thử
nghiệm* là *dựa theo*, báo hiệu rằng việc thử nghiệm điều
khiển quá trình phát triển. Hình 1 cho thấy luồng công việc của TDD:
##### Hình 1. Luồng công việc của TDD
![ Luồng công việc của TDD](figure1.gif)
Luồng công việc trong hình 1 là:
- Viết một thử nghiệm không thành công.
- Viết mã lệnh để làm cho nó thông qua.
- Lặp lại các bước 1 và 2.
- Đồng thời cấu trúc lại quyết liệt.
- Khi bạn không thể nghĩ đến bất kỳ thử nghiệm nào thêm nữa, bạn đã xong việc.
### Dựa theo thử nghiệm so với thử nghiệm sau
Việc phát triển -
* dựa theo* thử nghiệm yêu
cầu các thử nghiệm xuất hiện trước. Chỉ sau khi bạn đã viết các thử nghiệm
(và thất bại) bạn mới viết mã lệnh được thử nghiệm. Nhiều nhà phát triển
sử dụng một biến thể cách làm thử nghiệm được gọi là phát triển thử nghiệm
sau (TAD), ở đó bạn viết mã lệnh và sau đó viết các thử nghiệm đơn vị.
Trong trường hợp này, bạn vẫn nhận được các thử nghiệm, nhưng bạn không
nhận được các khía cạnh thiết kế nổi dần của TDD. Chẳng có gì ngăn cản bạn
viết mã lệnh cực kỳ ghớm guốc và sau đó lúng túng tìm cách để thử nghiệm
nó như thế nào. Khi viết mã lệnh trước, bạn đã nhúng các định kiến của bạn
về cách thức mã sẽ hoạt động ra sao, sau đó thử nghiệm nó. TDD đòi hỏi bạn
phải làm ngược lại: viết các thử nghiệm trước và cho phép nó thông báo cho
bạn cách làm thế nào để viết mã lệnh làm cho thử nghiệm thông qua. Để minh
họa sự khác biệt quan trọng này, tôi sẽ bắt đầu một ví dụ mở rộng.
## Các số hoàn hảo
Để cho thấy các lợi ích thiết kế của TDD, tôi cần một bài
toán để giải quyết. Trong cuốn sách
*Phát triển dựa theo thử nghiệm*
của mình (xem [Tài nguyên](#resources)), Kent Beck sử dụng tiền
tệ làm một ví dụ — một sự minh họa khá tốt về TDD, nhưng
hơi đơn giản thái quá. Thách thức thực sự là phải tìm ra một ví dụ không
phức tạp đến mức mà bạn bị lạc lối trong lĩnh vực của bài toán nhưng đủ
phức tạp để cho thấy giá trị thực sự.
Vì mục đích ấy, tôi đã chọn
*các số hoàn hảo*. Đối với những bạn không theo dõi chuyện tầm
phào toán học, khái niệm này có nguồn gốc từ trước Euclid (người đã thực
hiện một trong các chứng minh sớm nhất về việc tìm ra các số hoàn hảo).
Một số hoàn hảo là một số mà bằng tổng của các thừa số của nó. Ví dụ, 6 là
một số hoàn hảo bởi vì các thừa số của 6 (trừ chính số 6) là 1, 2 và 3 và
1 + 2 + 3 = 6. Một định nghĩa nhiều tính thuật toán hơn cho một số hoàn
hảo là *một số mà tổng các thừa số (trừ chính số đó) bằng chính số
đó*. Trong ví dụ của tôi, phép tính là 1 + 2 + 3 +6 - 6 =
6.
Và đây là lĩnh vực bài toán cần giải quyết: tạo ra một trình tìm kiếm số hoàn hảo. Tôi sẽ thực hiện lời giải cho bài toán này theo hai cách khác nhau. Trước tiên, tôi sẽ tắt một phần của não bộ của tôi muốn thực hiện TDD và chỉ viết giải pháp, sau đó viết các thử nghiệm cho nó. Rồi sau đó, tôi sẽ phát triển một phiên bản TDD của giải pháp để tôi có thể so sánh và đối chiếu cả hai cách tiếp cận.
Đối với ví dụ này, tôi
triển khai thực hiện một trình tìm kiếm một số hoàn hảo bằng ngôn ngữ Java
(phiên bản 5 hoặc mới hơn vì tôi sẽ sử dụng các chú thích trong thử nghiệm
của mình), JUnit 4.x (phiên bản mới nhất) và các trình phối hợp Hamcrest
từ kho mã của Google (xem
[Tài nguyên](#resources)). Các trình
phối hợp Hamcrest cung cấp một cú pháp theo cách giao tiếp của con người
phủ bên trên các trình phối hợp JUnit tiêu chuẩn. Ví dụ, thay cho
assertEquals(expected, actual), bạn có thể viết
assertEquals(actual, is(expected)), đọc lên
nghe giống với một câu nói đời thực hơn. Các trình phối hợp Hamcrest có
kèm theo với JUnit 4.x (chỉ cần dùng lệnh nhập khẩu (import) tĩnh); nếu
bạn vẫn còn sử dụng JUnit 3.x, bạn có thể tải về một phiên bản tương
thích.
### Thử nghiệm sau
Listing 1 hiển thị phiên bản đầu tiên của
PerfectNumberFinder:
##### Listing 1. The test-after
PerfectNumberFinder
public class PerfectNumberFinder1 { public static boolean isPerfect(int number) { // get factors List<Integer> factors = new ArrayList<Integer>(); factors.add(1); factors.add(number); for (int i = 2; i < number; i++) if (number % i == 0) factors.add(i); // sum factors int sum = 0; for (int n : factors) sum += n; // decide if it's perfect return sum - number == number; } }
Đây không phải là mã đặc biệt đẹp, nhưng nó hoàn thành được công việc. Tôi
bắt đầu bằng cách liệt kê tất cả các thừa số dưới dạng một danh sách động
(một
ArrayList). Tôi thêm 1 và số đích vào danh
sách. (Tôi tuân thủ công thức đã cho ở trên và liệt kê tất cả các thừa số,
bao gồm số 1 và chính số đó). Sau đó, tôi duyệt qua các thừa số cho đến
khi gặp chính số đó, kiểm tra lần lượt từng số để xem nó có phải một thừa
số không. Nếu đúng, tôi thêm số đó vào danh sách. Tiếp theo, tôi lấy tổng
tất cả các thừa số và cuối cùng là viết một phiên bản Java của công thức
đã chỉ ra ở trên để xác định số hoàn hảo.
Bây giờ, tôi cần một thử nghiệm đơn vị theo cách thử nghiệm sau để xác định xem chương trình có hoạt động đúng hay không. Tôi cần ít nhất hai thử nghiệm: một để xem báo cáo kết quả các số hoàn hảo có đúng không và thử nghiệm kia sẽ kiểm tra để tôi không nhận được các xác thực sai. Các thử nghiệm đơn vị có trong Listing 2:
##### Listing 2. Các thử nghiệm đơn vị cho
PerfectNumberFinder
public class PerfectNumberFinderTest { private static Integer[] PERFECT_NUMS = {6, 28, 496, 8128, 33550336}; @Test public void test_perfection() { for (int i : PERFECT_NUMS) assertTrue(PerfectNumberFinder1.isPerfect(i)); } @Test public void test_non_perfection() { List<Integer>expected = new ArrayList<Integer>( Arrays.asList(PERFECT_NUMS)); for (int i = 2; i < 100000; i++) { if (expected.contains(i)) assertTrue(PerfectNumberFinder1.isPerfect(i)); else assertFalse(PerfectNumberFinder1.isPerfect(i)); } } @Test public void test_perfection_for_2nd_version() { for (int i : PERFECT_NUMS) assertTrue(PerfectNumberFinder2.isPerfect(i)); } @Test public void test_non_perfection_for_2nd_version() { List<Integer> expected = new ArrayList<Integer>(Arrays.asList(PERFECT_NUMS)); for (int i = 2; i < 100000; i++) { if (expected.contains(i)) assertTrue(PerfectNumberFinder2.isPerfect(i)); else assertFalse(PerfectNumberFinder2.isPerfect(i)); } assertTrue(PerfectNumberFinder2.isPerfect(PERFECT_NUMS[4])); } }
Mã này cho kết quả đúng là các số hoàn hảo nhưng nó chạy rất chậm với thử nghiệm phủ định do phải kiểm tra quá nhiều số. Các vấn đề hiệu suất có thể xuất hiện từ các thử nghiệm đơn vị đã đưa tôi quay về với mã lệnh để xem xem tôi có thể thực hiện một số cải tiến không. Hiện tại, tôi duyệt qua suốt vòng lặp cho đến khi gặp chính số đó để thu được các thừa số. Nhưng tôi có cần phải đi xa như thế không? Không, nếu như tôi có thể thu hoạch các thừa số theo từng cặp. Tất cả các thừa số đều có cặp (ví dụ, nếu số đích là số 28, khi tôi tìm thấy thừa số 2, tôi cũng có thể lấy luôn thừa số 14). Tôi chỉ cần đi tiếp lên tới căn bậc 2 của số đích là tôi có thể thu được các thừa số theo cặp. Vì mục đích này, tôi cải tiến các thuật toán và cấu trúc lại mã lệnh cho Listing 3:
##### Listing 3. Phiên bản thuật toán đã cải tiến
public class PerfectNumberFinder2 { public static boolean isPerfect(int number) { // get factors List<Integer> factors = new ArrayList<Integer>(); factors.add(1); factors.add(number); for (int i = 2; i <= sqrt(number); i++) if (number % i == 0) { factors.add(i); factors.add(number / i); } // sum factors int sum = 0; for (int n : factors) sum += n; // decide if it's perfect return sum - number == number; } }
Mã này chạy trong một thời gian khá dài nhưng một số kết quả thử nghiệm không thành công. Té ra là khi bạn thu thập các thừa số theo các cặp, bạn vô tình lấy ra các số hai lần khi đạt đến căn bậc hai của số đích. Ví dụ, đối với số 16, có căn bậc hai là 4, vô tình được thêm vào danh sách hai lần. Điều này rất dễ dàng sửa chữa bằng cách tạo một điều kiện canh giữ trường hợp này, như được hiển thị trong Listing 4:
##### Listing 4. Thuật toán cải tiến đã sửa lỗi
for (int i = 2; i <= sqrt(number); i++) if (number % i == 0) { factors.add(i); if (number / i != i) factors.add(number / i); }
Bây giờ tôi có một phiên bản kiểm tra sau của trình tìm số hoàn hảo. Nó làm việc được nhưng có một số vấn đề về thiết kế kéo theo. Trước tiên, tôi đã sử dụng các dòng chú thích phân tách các phần của mã lệnh. Đây luôn luôn là hương vị của mã lệnh: nó là một tiếng kêu cứu để cấu trúc lại thành các phương thức riêng. Cái mới mà tôi vừa thêm vào có lẽ cần một chú thích để giải thích những gì mà điều kiện canh giữ bé nhỏ ấy sẽ làm, nhưng bây giờ tôi sẽ để mặc thế đã. Vấn đề lớn nhất nằm ở độ dài của nó. Nguyên tắc ngón tay cái của tôi đối với các dự án Java nói rằng không nên có phương thức nào dài hơn 10 dòng mã. Nếu một phương thức vượt quá con số này, nó gần như chắc chắn là làm nhiều hơn một điều mà nó không nên làm. Phương thức này rõ ràng vi phạm nguyên tắc ấy, do đó tôi sẽ thử một cách khác, lần này sẽ sử dụng TDD.
## Thiết kế nổi dần thông qua TDD
Câu thần chú Ấn độ dành cho viết mã TDD là: "Cái điều đơn giản nhất để tôi có thể viết một thử nghiệm cho nó là gì ?". Trong trường hợp này, đó có phải là "là một số hoàn hảo hay là không?". Không — câu trả lời là điều này quá rộng. Tôi phải phân rã bài toán và suy nghĩ "số hoàn hảo" có nghĩa là gì. Tôi có thể dễ dàng đi đến kết quả là một số bước cần thiết để khám phá ra một số hoàn hảo:
- Tôi cần các thừa số của số đang xét.
- Tôi cần phải xác định xem một số có phải là thừa số không.
- Tôi cần phải lấy tổng các thừa số.
Hướng theo ý tưởng tìm điều đơn giản nhất ấy, mục nào trong số các mục trong danh sách trên có vẻ là mục đơn giản nhất ? Tôi nghĩ rằng đó là mục xác định xem một số có phải là thừa số của một số khác không. Vậy đây là phép thử nghiệm đầu tiên của tôi, nó có trong Listing 5:
##### Listing 5. Kiểm tra xem "một số có phải là thừa số không?"
public class Classifier1Test { @Test public void is_1_a_factor_of_10() { assertTrue(Classifier1.isFactor(1, 10)); } }
Phép kiểm tra đơn giản này là tầm thường đến mức ngớ ngẩn và nó chính là
cái tôi muốn. Để thực hiện thử nghiệm này, bạn phải có một lớp có tên là
Classifier1, với một phương thức
isFactor(). Vì vậy, tôi phải tạo ra một khung
sườn cấu trúc của lớp này trước khi tôi thậm chí có thể nhận được một
thanh màu đỏ. Việc viết các thử nghiệm đơn vị tầm thường quá đỗi này cho
phép bạn dựng lên một kết cấu trước khi bạn cần bắt đầu suy nghĩ về lĩnh
vực của bài toán theo một cách có ý nghĩa. Tôi muốn suy nghĩ về chỉ một
điều ở một thời điểm và điều này cho phép tôi tiếp tục làm việc trên khung
sườn cấu trúc mà không phải lo về các sắc thái của bài toán mà tôi đang
giải quyết. Sau khi biên dịch những thứ trên và thanh màu đỏ xuất hiện,
tôi ở tư thế sẵn sàng để viết mã, hiển thị trong Listing
6:
##### Listing 6. Lần đầu tiên thông qua thử nghiệm với phương thức thừa số
public class Classifier1 { public static boolean isFactor(int factor, int number) { return number % factor == 0; } }
Tốt rồi, thật đẹp và đơn giản, và nó làm được việc. Bây giờ tôi có thể chuyển sang nhiệm vụ đơn giản nhất tiếp theo: nhận một danh sách các thừa số của một số. Thử nghiệm xuất hiện trong 7:
##### Listing 7. Thử nghiệm tiếp theo: Các thừa số của một số đã cho
@Test public void factors_for() { int[] expected = new int[] {1}; assertThat(Classifier1.factorsFor(1), is(expected)); }
Listing 7 chứa thử nghiệm đơn giản nhất mà tôi phải cố gắng làm để nhận được các thừa số, vì thế bây giờ tôi có thể viết mã lệnh đơn giản nhất để thông qua được thử nghiệm này (và cấu trúc lại nó sau này để làm cho nó tinh tế hơn). Phương thức tiếp theo xuất hiện trong Listing 8:
##### Listing 8. Phương thức đơn giản
factorsFor()
public static int[] factorsFor(int number) { return new int[] {number}; }
Mặc dù phương thức này làm việc đúng, nó giữ tôi tạm dừng trên đường đi.
Có vẻ như để cho
isFactor() thành phương thức
tĩnh (static) là một ý tưởng tốt, bởi vì nó chỉ trả về kết quả dựa trên
đầu vào của nó. Tuy nhiên, bây giờ tôi cũng đã để cho
factorsFor() là phương thức tĩnh, có nghĩa là tôi phải chuyển
một tham số được gọi là
number cho cả hai
phương thức. Mã lệnh này trở thành quá thủ tục, đó là hậu quả phụ của việc
lạm dụng phương thức tĩnh. Để sửa chữa điều này, tôi sẽ cấu trúc lại hai
phương thức mà tôi đã có, đây là việc đơn giản là vì cho đến nay mới chỉ
có một ít mã như vậy. Lớp
Classifier đã cấu
trúc lại xuất hiện trong Listing 9:
##### Listing 9. Lớp
Classifier đã cải tiến
public class Classifier2 { private int _number; public Classifier2(int number) { _number = number; } public boolean isFactor(int factor) { return _number % factor == 0; } }
Tôi đã làm cho number thành một biến thành viên trong lớp
Classifier2, điều này cho phép tôi tránh được
việc chuyển đi chuyển lại nó như một tham số tới một bó các phương thức
tĩnh.
Mục tiếp theo trong danh sách phân rã ở trên nói rằng tôi cần phải tìm ra các thừa số của một số. Vì vậy, thử nghiệm tiếp theo của tôi cần kiểm tra điều này (hiển thị trong Listing 10):
##### Listing 10. Thử nghiệm tiếp theo: Các thừa số của một số
@Test public void factors_for_6() { int[] expected = new int[] {1, 2, 3, 6}; Classifier2 c = new Classifier2(6); assertThat(c.getFactors(), is(expected)); }
Bây giờ, tôi sẽ thử triển khai thực hiện phương thức trả về một mảng các thừa số của một tham số đã cho, hiển thị trong 11:
##### Listing 11. Lần đầu tiên thông qua thử nghiệm với phương thức
getFactors()
public int[] getFactors() { List<Integer> factors = new ArrayList<Integer>(); factors.add(1); factors.add(_number); for (int i = 2; i < _number; i++) { if (isFactor(i)) factors.add(i); } int[] intListOfFactors = new int[factors.size()]; int i = 0; for (Integer f : factors) intListOfFactors[i++] = f.intValue(); return intListOfFactors; }
Mã này cho phép vượt qua thử nghiệm, nhưng khi suy nghĩ lại, thật dễ sợ!
Điều này đôi lúc xảy ra khi bạn điều tra tỷ mỉ cách triển khai thực hiện
mã lệnh bằng cách sử dụng các thử nghiệm. Có gì khủng khiếp như vậy về các
mã này? Trước hết, nó rất dài và phức tạp và nó cũng mắc nhược điểm là vấn
đề "làm nhiều hơn một thứ". Bản năng của tôi đã dẫn tôi trở lại với việc
dùng một mảng
int[], nhưng nó sẽ tăng thêm khá
nhiều sự phức tạp vào mã lệnh ở dưới cùng và không đạt được bất cứ thứ gì
cho tôi. Đó là một con đường dốc trơn trượt khó đi khi bắt đầu suy nghĩ
quá nhiều về việc làm cho mọi thứ thuận tiện hơn dành cho các phương thức
tương lai mà có thể gọi phương thức này. Bạn cần phải có một lý do có sức
thuyết phục để thêm một cái gì đó phức tạp như thế vào mối nối này và tôi
còn chưa có một sự biện hộ nào cho việc này. Việc xem xét kỹ mã này gợi ý
rằng có lẽ
các thừa số cũng nên tồn tại như một
trạng thái bên trong của lớp, cho phép tôi tách riêng ra phần chức năng
của phương thức này.
Một trong những đặc điểm có ích mà các thử
nghiệm làm nổi lên là các phương thức thực sự kết dính. Kent Beck đã viết
về điều này trong một cuốn sách có ảnh hưởng tên là
*Các mẫu thực tiễn
tốt nhất của Smalltalk* (Smalltalk Best Practice Patterns ) (xem [Tài nguyên](#resources)). Trong cuốn sách đó, Kent đã định
nghĩa một mẫu được gọi là *phương thức cấu thành* (composed method).
Mẫu phương thức cấu thành định nghĩa ba khẳng định then chốt:
- Chia chương trình của bạn thành các phương thức thực hiện một công việc có thể nhận biết được.
- Giữ cho tất cả các phép toán trong một phương thức có cùng một mức độ trừu tượng hóa.
- Điều này sẽ tự nhiên dẫn đến các chương trình với nhiều phương thức nhỏ, mỗi phương thức có độ dài vài dòng.
Phương thức cấu thành là một trong những đặc điểm thiết kế có ích mà
TDD khuyến khích và tôi đã vi phạm rõ ràng mẫu này trong phương thức
getFactors() ở
[Listing
11](#listing11). Tôi có thể sửa chữa nó bằng cách thực hiện các bước sau:
- Nâng
các thừa sốlên thành trạng thái bên trong.
- Di chuyển đoạn mã khởi tạo
các thừa sốvào hàm tạo.
- Loại bỏ đoạn mã mạ vàng nhằm chuyển đổi kết quả thành mảng
int[]và xử lý nó sau nếu điều này là có ích.
- Thêm một thử nghiệm khác cho
addFactors().
Bước thứ tư là khá tế nhị, nhưng quan trọng. Việc viết phiên bản mã
có lỗi này đã để lộ ra rằng vòng phân rã đầu tiên của tôi đã không đầy đủ.
Dòng mã
addFactors() giấu vào giữa phương thức
dài này là hành vi thử nghiệm được. Nó tầm thường đến mức mà tôi đã không
nhận thấy điều này khi lần đầu tiên xem xét bài toán, nhưng bây giờ tôi đã
thấy rồi. Điều này thường xuyên xảy ra. Một thử nghiệm có thể dẫn bạn đến
phân rã tiếp tục bài toán thành các đoạn ngày càng nhỏ hơn, mỗi đoạn đều
có thể thử nghiệm.
Tôi sẽ tạm dừng bài toán lớn hơn về
getFactors() vào lúc này và giải quyết bài toán
mới nhỏ nhất của tôi. Như vậy, thử nghiệm tiếp theo của tôi là
addFactors(), được hiển thị trong Listing 12:
##### Listing 12. Thử nghiệm với
addFactors()
@Test public void add_factors() { Classifier3 c = new Classifier3(6); c.addFactor(2); c.addFactor(3); assertThat(c.getFactors(), is(Arrays.asList(1, 2, 3, 6))); }
Đoạn mã cần thử nghiệm, được hiển thị trong Listing 13, là rất đơn giản:
##### Listing 13. Mã lệnh đơn giản để cộng các thừa số
public void addFactor(int factor) { _factors.add(factor); }
Tôi chạy thử nghiệm đơn vị của tôi, hoàn toàn tin tưởng rằng tôi sẽ thấy một thanh màu xanh lục, nhưng nó thất bại! Làm thế nào mà một thử nghiệm đơn giản đến như vậy lại thất bại? Nguyên nhân gốc rễ xuất hiện trong Hình 2:
##### Hình 2. Nguyên nhân gốc rễ của thử nghiệm không thành công
![ Nguyên nhân gốc rễ của thử nghiệm không thành công](figure2.jpg)
Danh sách mà tôi mong đợi có các giá trị
1, 2, 3,
6 nhưng thực tế trả về là
1, 6, 2,
3. Ôi, đó là vì tôi đã thay đổi mã để thêm 1 và chính số đích vào
hàm tạo. Một giải pháp cho vấn đề này sẽ là luôn viết như tôi mong muốn,
giả sử rằng số 1 và chính số đích luôn luôn được viết trước hết. Nhưng đó
có phải là giải pháp
*đúng* không? Không. Vấn đề ở chỗ căn bản hơn
nhiều. Các thừa số có phải là một *danh sách* các số không? Không,
chúng là một *tập hợp* các số. Giả thiết đầu tiên (không đúng) của
tôi dẫn đến việc sử dụng một danh sách các số nguyên dành cho các thừa số,
nhưng đó là một phép trừu tượng hóa tồi. Bằng việc cấu trúc lại mã lệnh,
bây giờ tôi sử dụng các tập hợp thay vì các danh sách, tôi không chỉ khắc
phục được vấn đề này mà còn làm cho giải pháp tổng thể trở nên tốt hơn vì
bây giờ tôi đang sử dụng phép trừu tượng hóa chính xác hơn.
Đây đúng là một kiểu suy nghĩ thiếu sót khi cho rằng các thử nghiệm có thể phơi bày ra, có phải bạn viết các thử nghiệm trước khi bạn viết mã để che giấu việc phán xét bạn. Bây giờ, nhờ thử nghiệm đơn giản này, toàn bộ thiết kế mã lệnh của tôi thành tốt hơn vì tôi đã phát hiện một cách trừu tượng hóa thích hợp hơn.
## Kết luận
Cho đến nay, tôi đã thảo luận về thiết kế nổi dần trong bối cảnh của bài toán số hoàn hảo. Nói riêng, lưu ý rằng phiên bản đầu tiên của giải pháp (phiên bản kiểm tra sau) đã phạm cùng một giả thiết sai lầm về các kiểu dữ liệu. "Thử nghiệm sau" kiểm tra các chức năng của mã của bạn ở mức chi tiết thô, chứ không phải ở mức các phần riêng biệt. TDD kiểm tra các khối nền tảng làm nên chức năng ở mức chi tiết thô ấy, phơi bày ra nhiều thông tin hơn trong quá trình làm việc.
Trong bài viết tiếp theo, tôi sẽ tiếp tục bài toán số hoàn hảo, minh họa nhiều ví dụ về các loại thiết kế có thể xuất hiện nếu bạn để lộ ra cách thức của các thử nghiệm của bạn. Khi tôi có phiên bản TDD đầy đủ, tôi sẽ so sánh một vài số liệu thống kê giữa hai cơ sở mã. Tôi cũng sẽ xử lý một số câu hỏi thiết kế khó khăn khác về TDD, ví dụ như có hay không và khi nào thì thử nghiệm các phương thức riêng.
## Tài nguyên
### Học tập
[Hamcrest matchers](http://code.google.com/p/hamcrest/): Một thư viện các trình phối hợp đối tượng cho phép bạn định nghĩa thế nào là "khớp" để sử dụng trong các khung công tác khác. [(Kent Beck, Addison-Wesley, 2003): Beck, nhà sáng lập Lập trình đỉnh cao, sử dụng các ví dụ dựa trên tiền tệ để giải thích TDD.](http://safari5.bvdep.com/0321146530) *Test-Driven Development* [(Kent Beck, Prentice Hall, 1996): Tìm hiểu thêm về mẫu phương thức](http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X) *Smalltalk Best Practice Patterns* *cấu thành*. [(Neal Ford, O'Reilly Media, 2008): Một phiên bản dài hơn của ví dụ trong bài viết này xuất hiện trong chương "Phát triển dựa vào thử nghiệm” trong cuốn sách gần đây nhất của Neal Ford.](http://oreilly.com/catalog/9780596519780/) *The Productive Programmer*
- "
[Emergent Optimization in Test Driven Design](http://www.objectmentor.com/resources/articles/MichaelFeathers--EmergentOptimizationInTestDrivenDesign.pdf)" (Michael Feathers): Thử nghiệm giúp tránh được sự tối ưu hóa quá sớm như thế nào.
- Duyệt qua
[technology bookstore](http://www.ibm.com/developerworks/apps/SendTo?bookstore=safari&S_TACT=105AGY75)để tìm các sách về chủ đề kỹ thuật này và các chủ đề kỹ thuật khác. [developerWorks Java technology zone](http://www.ibm.com/developerworks/java?S_TACT=105AGY75): Tìm hàng trăm bài viết về mọi khía cạnh của lập trình Java.
### Lấy sản phẩm và công nghệ
[JUnit](http://sourceforge.net/project/showfiles.php?group_id=15278&package_id=12472): Tải về JUnit.
### Thảo luận
- Xem
[developerWorks blogs](http://www.ibm.com/developerworks/blogs/?S_TACT=105AGY75)và tham gia vào [cộng đồng developerWorks](http://www.ibm.com/developerworks/community?S_TACT=105AGY75).
## Bình luận
[Vùng dữ liệu trên developerWorks](http://www.ibm.com/developerworks/vn/views/data/libraryview.jsp)
Khám phá các bài viết xoay quanh lĩnh vực dữ liệu, Quản lý hệ thống thông tin
[Vùng mã nguồn mở trên developerWorks](http://www.ibm.com/developerworks/vn/views/opensource/libraryview.jsp)
Xem các bài viết về HTML, CSS, JavaScript,...
[Điện toán đám mây](http://www.ibm.com/developerworks/vn/views/cloud/libraryview.jsp)
Tìm hiểu về điện toán đám mây

Content-Language: en-US

Kp-eeAlive: timeout=10, max=77


text: Được giới thiệu tại CES 2012 vào đầu năm nay, Canon PowerShot G1 X là một trong hai mẫu máy ảnh nhận được sự quan tâm của nhiều người. Hiện tại, đây là mẫu máy ảnh cao cấp nhất trong dòng máy ảnh du lịch của Canon với cảm biến lớn, chip xử lý hình ảnh mới DIGIC 5 cùng với thiết kế sang trọng. Canon G1 X chính hãng được bán ở Việt Nam với giá khoảng 18,5 triệu đồng. Máy ảnh Canon PowerShot G1 X Thiết kế Canon PowerShot G1 X có thiết kế thoạt nhìn na ná giống với chiếc máy thế hệ trước là Canon G12 – đó là sự lai tạo giữa dòng máy ảnh compact nhỏ gọn và dòng máy DSLR. Với kích thước 116,7 x 80,5 x 64,7 mm, trọng lượng 534 g, Canon G1 X to và nặng hơn so với G12. Vì vậy, người sử dụng cần một chiếc túi đủ lớn để đựng chiếc máy này thay vì dễ dàng bỏ vào trong túi quần, túi áo như nhiều máy ảnh compact khác. Chiếc máy này có màu đen bóng, vỏ làm bằng kim loại tạo nên cảm giác chắc chắn và cao cấp. Dường như việc có cảm biến lớn nên vòng ống kính của máy cũng được thiết kế lớn để bổ trợ tốt cho cảm biến, nhằm lấy được nhiều hơn lượng ánh sáng. Tuy nhiên tôi thấy việc thiết kế này làm cho một phần mặt trước của ống ngắm viewfinder bị méo vào, không phải là ô vuông "bất khả xâm phạm" như những máy khác. Do đó, khi ngắm qua viewfinder, bạn sẽ không thấy hết được khung hình do một phần ống kính đã che góc này, tôi thấy không thoải mái khi khung nhìn bị cản trở như vậy và coi đây là một điểm yếu của chiếc máy. Vòng lens lớn che một phần kính ngắmG1 X được trang bị cảm biến CMOS kích thước 1.5 inch (18,7 x 14mm), độ phân giải 14.3 megapixel, chip xử lý hình ảnh DIGIC 5 cùng với dải ISO hỗ trợ từ 100 – 12.800 giúp cho máy có khả năng chụp tốt, giảm thiểu nhiễu trong điều kiện ánh sáng yếu. Phần ngoài ống kính của máy có một vòng nhựa với viền có nhiều rãnh nhỏ nhìn vào khá giống với vòng chỉnh zoom như trên các máy chuyên nghiệp nhưng thực ra không phải, chiếc vòng nhựa này đơn thuần chỉ là lớp áo giáp vừa để trang trí, vừa để bảo vệ hệ thống ống kính bên trong. Người dùng có thể dễ dàng mở chiếc vòng này bằng cách ấn giữ một chốt nhỏ ngay bên dưới góc phải và xoay chiếc vòng này ngược chiều kim đồng hồ. Bên trái ống kính là khu vực báng cầm tay, bề mặt này được phủ một lớp cao su nhiều rãnh để tạo ma sát tốt khi cầm máy. Khu vực này được thiết kế khá góc cạnh theo hình khối chung của máy chứ không phải ôm tròn theo lòng bàn tay như các máy cao cấp hơn. Với bàn tay tôi khi cầm máy, tôi thấy báng cầm có vẻ hơi nhỏ, phía trên có vòng chỉnh tốc độ màn trập, nếu bạn đang cầm máy bằng tay phải, bạn sẽ rất khó điều chỉnh vòng chỉnh tốc độ màn trập. Tất nhiên đây là một chiếc máy thuộc thể loại "bấm là chụp" nên bạn không thể đòi hỏi nhiều hơn. Dù có zoom quang 4x nhưng ống kính của Canon G1 X lại lớn hơn và dài hơn so với G12 với zoom quang 5x. Cơ chế hoạt động của motor trên ống kính hoạt động tương đối ồn. Tuy nhiên với ảnh chụp bình thường ở góc rộng, nếu người sử dụng không zoom, nghĩa là ống kính không hoạt động motor thì máy lại tỏ ra rất êm. Cộng với việc nút lấy nét chụp có hành trình ngắn nên nhiều khi bạn sẽ tưởng như chưa chụp xong nhưng thực ra bức ảnh đã nằm trong máy. Ở phần cạnh trên, các nhà thiết kế đã đưa hết các nút điều chỉnh sang bên phải (theo chiều thuận khi cầm chụp), bên trái là đèn flash dạng pop-up, phân giữa hai bên là cổng giao tiếp có thể gắn đèn flash rời. Canon G1 X không tích hợp nút bấm để bật đèn flash tích hợp mà sử dụng một nút trượt ngang ở ngay sau đèn khi người dùng muốn bật. Đèn flash tích hợp có công suất sáng tương đối tốt so với dòng máy du lịch, người dùng có thể điều chỉnh độ sáng của đèn với ba mức: thấp nhất, trung bình, cao nhất. Trong trường hợp ánh sáng đèn flash tích hợp vẫn chưa thỏa mãn yêu cầu, bạn có thể gắn thêm đèn flash rời bên ngoài (phù hợp với chân cắm, các loại đèn của Canon) để sử dụng. Bố trí nút và vòng xoay điều chỉnh chức năng ở cạnh trênPhần các nút điều khiển ở bên phải nổi bật ở nút bấm chụp với bề mặt sáng bóng của lớp crom. Nút này có hành trình giữ lấy nét hơi ngắn, nên khi chụp cho cảm giác không đầm tay. Một điểm khác nữa ở cạnh trên so với G12 là vòng chỉnh bù trừ sáng. Nếu trên Canon G12, nút này được tách biệt riêng rẽ nằm bên trái thì vị trí đó giờ là của đèn flash trên Canon G1 X (đèn flash của G12 tích hợp bên trong thân máy, nằm ở mặt trước như nhiều máy compact thông thường). Vòng chỉnh bù trừ sáng lúc này được đặt ở dưới, cùng với trục của vòng chỉnh các chế độ chụp – thay cho vị trí của vòng điều chỉnh ISO trên G12. Về hỗ trợ ánh sáng, G1 X có nấc từ -3 đến +3 (so với với -2 đến +2 của G12), dải ISO của G1 X cũng lớn hơn khi hỗ trợ đến 12.800 trong khi G12 chỉ hỗ trợ tới 3200. Mặt sau của máy có màn hình LCD với khớp có thể xoay gập linh hoạt giúp chụp ảnh, quay phim được ở những góc khó. Màn hình của máy có độ lớn 3-inch độ phân giải 922 nghìn điểm ảnh, to hơn và hiển thị sắc nét hơn so với màn hình 2,8-inch, độ phân giải 416 nghìn điểm ảnh của G12. Do màn hình khá nhỏ mà độ phân giải lại khá tốt nên hình ảnh hiển thị trên màn hình cho người dùng cảm thấy sắc nét và sáng sủa hơn khi xem trên máy tính thông thường. Bề mặt của màn hình có khả năng chống chói tương đối tốt nên bạn có thể xem được ngoài trời nắng, tuy nhiên sẽ thấy hơi tối một chút và có độ bóng nhất định. Bên cạnh đó, bạn cần chuẩn bị theo máy một miếng vải mềm trong trường hợp muốn dùng để lau chùi màn hình vì màn hình này bám vân tay khá rõ. Phần kính ngắm viewfinder nằm ngay phía trên, chính giữa so với màn hình. Nếu như ở nhiều mẫu máy cấp thấp có khu vực kính ngắm với xu hướng lõm xuống, phần xung quanh cao hơn một chút như kiểu miệng giếng để khi mắt nhìn vào không bị ảnh hưởng nhiều bởi ánh sáng xung quanh lọt vào thì G1 X lại khác. Hệ thống kính ngắm trên máy được thiết kế lộ thiên, nổi lên hẳn so với khu vực bề mặt xung quanh và không có viền che. Điều này có thể giải thích là do chiếc máy này thuộc dòng du lịch, hơi hướng thiết kế vẫn là sự mỏng gọn tiện dụng nên kính ngắm không thể đưa hết vào bên trong như các mẫu máy dòng cao cấp hơn. G1 X là chiếc máy du lịch cao cấp nên Canon bổ sung thêm kính ngắm với dụng ý đưa người sử dụng đến gần hơn với những mẫu máy ảnh chuyên nghiệp nhưng cũng không quên là muốn người sử dụng thao tác một cách thuận tiện, dễ dàng nhất: PnS - ngắm trực tiếp trên màn hình và chụp. Chính vì vậy mà qua viewfinder, người sử dụng sẽ không quan sát được đầy đủ khung hình thu được do đã bị một phần ống kính che mất. Nếu là một chiếc máy chuyên nghiệp thì điều này là không thể chấp nhận được, nhưng G1 X thực chất hướng đến việc back up cho máy chuyên nghiệp hoặc là bổ sung đối với nhu cầu sử dụng nghiệp dư nên việc này là chấp nhận được. Bên cạnh kính ngắm có một vòng xoay nhỏ để hỗ trợ độ mở/tụ của ảnh phù hợp với người mắt bị cận/viễn. Kính ngắm có vòng xoay chỉnh độ tụ hình ảnh hiển thịHệ thống nút điều khiển ở mặt sau tập trung hầu hết sang khu vực báng cầm bên tay phải với trung tâm là vòng xoay điều chỉnh độ mở của thấu kính. So với các vòng xoay khác, vòng xoay này mỏng và khá nhạy. Chính giữa vòng xoay điều chỉnh này là nút gọi nhanh các tính năng về kiểu ảnh, điều chỉnh cân bằng trắng, tùy chỉnh độ sáng đèn flash… nút này còn có chức năng là xác lập lựa chọn (Ok) khi kết hợp với các nút khác. Xung quanh nút này, nằm trên vòng tròn là các nút vừa có chức năng điều hướng, vừa có chức năng riêng biệt như điều chỉnh ISO, điều chỉnh chế độ chụp macro, lấy nét tay, tắt/bật flash và hiển thị các thông số cài đặt lên màn hình LCD. Bên dưới phím xoay trung tâm là nút Menu và nút lựa chọn phương thức lấy nét. Bên trên là nút giúp căn chỉnh khung hình, canh nét và các chức năng phụ như xóa ảnh, jump đến cài đặt cá nhân. Nổi bật ở mặt sau là nút quay phim có hình tròn màu đỏ, khi bấm nút này chức năng quay phim sẽ được kích hoạt ngay. Khả năng quay phim của Canon G1 X khá tốt, máy có thể quay định dạng Full HD 1080p, nhà sản xuất đã tích hợp một nút chuyên biệt và nhấn mạnh ra ngoài thiết kế của máy. Nút quay phim chuyên biệtVề tổng thể các nút, tôi thấy việc sử dụng khá đơn giản và dễ dàng. Chỉ có một nút chưa hài lòng là nút xem lại ảnh. Nút này được đặt phía trên màn hình, bên phải kính ngắm. Bề mặt khu vực nút này khá thấp so với bề mặt màn hình máy khi gập lại, vì thế hơi vướng khi bạn dùng ngón tay cái để bấm phím này. Nắp che các cổng kết nối ở bên cạnh phải của máy được làm bằng kim loại chứ không phải là cao su như nhiều máy khác. Khi đóng vào phần nắp này tạo sự vừa vặn và liền lạc với các khu vực xung quanh của máy. Máy có cổng kết nối HDMI, jack cắm các thiết bị ngoại vi thông thường và cổng kết nối USB. Cạnh trái của máy có vài lỗ nhỏ là khe phát âm thanh. Bên trên hai cạnh của máy có lỗ xỏ dây để xỏ dây đeo và dây giữ nắp lens. Cạnh đáy máy có khay chứa pin và khe cắm thẻ nhớ. Máy hỗ trợ thẻ nhớ định dạng SD, SDHC, SDXC. Phụ kiện theo máy gồm dây đeo, dây giữ nắp lens, đĩa cài, sách hướng dẫn sử dụng, sạc pin, cáp kết nối. Tính năng Bộ cảm biến lớn 1.5 inch cùng với chip xử lý DIGIC 5 giúp cho máy có khả năng chụp liên tiếp với tốc độ cao, lấy nét tự động ngay cả khi đối tượng đang chuyển động cùng với việc tái tạo màu sắc tốt, hạn chế nhiễu. Dải ISO hỗ trợ lớn kéo dài từ 100 – 12.800. Hệ thống ổn định hình ảnh thông minh trên máy giúp cho hiện tượng rung lắc bị lu mờ. Máy sẽ tự động phân tích chuyển động của máy và đối tượng chụp để đưa ra phương án chổng rung hiệu quả nhất. Người sử dụng sẽ gần gũi hơn với việc sử dụng như một chiếc máy ảnh chuyên nghiệp. G1 X hỗ trợ nhiều phụ kiện tương thích vốn được dùng có các máy EOS DSLR. Ví dụ chân đèn flash gắn ngoài bạn có thể gắn và tương thích tốt với đèn Speedlite của Canon, jack cắm chuẩn phù hợp với bộ điều khiển từ xa… Khả năng quay phim Full HD 1080p lên đến 24 khung hình/giây, cùng với các chế độ quay phim siêu chậm, phim ngắn, chế độ thông minh dành cho phim ngắn. Quá trình quay phim, máy có khả năng thu âm cũng khá tốt. Máy có khả năng chụp ảnh RAW và ảnh đuôi JPEG 14 bit. Màn hình xoay lật linh hoạt như EOS 60D giúp cho việc quan sát, chụp trong các góc khó trở nên dễ dàng. Hỗ trợ chụp ảnh với nhiều phong cách ảnh như: neutral, lanscape, portrait, faithful, monochrome, HDR… hoặc các bộ lọc sáng tạo như: sepia, underwater, black and white, hiệu ứng hoài cổ, hiệu ứng máy ảnh đồ chơi… Hỗ trợ tính năng nhận diện khuôn mặt, cười, hẹn giờ nháy mắt, hẹn giờ lấy nét khuôn mặt. Hiệu năng Canon G1 X có thời gian khởi động nhanh, máy sẵn sàng chụp bức ảnh thứ hai chỉ sau khoảng 1 giây. Ở chế độ chụp liên tiếp, mặc dù độ phân giải bức ảnh ở mức cao (14.3 MP) nhưng máy có thể chụp 4,5 ảnh/giây – tốc độ khá tốt. Chế độ test ISO chúng tôi thiết lập: chế độ chụp chỉnh tay hoàn toàn (M), cân bằng trắng tự động, khẩu độ f2.8, tốc độ 1/125s, tiêu cự 15.1mm (W), flash tắt. Chế độ quay phim của máy khá tốt. Chất lượng hình ảnh rõ ràng cùng với khả năng thu âm. Chụp với các chế độ điều chỉnh ISO: Với bức hình đã được crop tỉ lệ 100%, ở ISO 1600 mới bắt đầu thấy hiện tượng nhiễu. Nhiễu xuất hiện nhiều hơn khi tăng ISO cao hơn so với mức này. Tuy nhiên kết quả như vậy cho thấy Canon G1 X có khả năng khử nhiễu rất tốt. Khi ISO tăng đồng nghĩa với việc hình ảnh nhận được sẽ sáng hơn và khả năng bị nhiễu sẽ xuất hiện rõ hơn, vì vậy người sử dụng cần quan tâm nhiều hơn về việc điều chỉnh thông số ánh sáng dựa trên ISO của máy, đặc biệt là với chiếc máy G1 X này khi có cảm biến và dải ISO lớn. Tôi thử chụp với vật mẫu ở trong phòng kín, mắt thường không nhìn rõ, ISO của máy tăng lên hết cỡ (12800) thì bức ảnh nhận được cho kết quả khá tốt. Ảnh vật thể hiện lên rõ và hiện tượng nhiễu hoàn toàn chấp nhận được. Thậm chí nếu không phóng ảnh hết cỡ mà chỉ xem ở mức nhỏ thì có cảm giác nhiễu là không đáng kể. Hình dưới là hai ảnh đã được crop 100%. Chụp với flash: Flash có 3 mức điều chỉnh từ nhỏ nhất đến trung bình và đến cao nhất. Phạm vi hỗ trợ của flash có thể lên tới 7 m. Tôi thấy so với nhiều máy thông thường, hiệu suất đèn flash tích hợp của máy khá tốt. Thông số thiết lập: chế độ M, tốc độ 1/60s, khẩu độ f2.8, tiêu cự 15.1 mm. Chụp với chế độ zoom: hình dưới là máy khi chụp ở tiêu cự bình thường, chế độ zoom tiêu chuẩn 4x và zoom mở rộng 16x. Thông số thiết lập: chế độ M, tốc độ 1/320s, khẩu độ f7.1, tiêu cự 15.1 mm. Các kiểu ảnh và hiệu ứng chụp: máy hỗ trợ nhiều phong cách ảnh và hiệu ứng chụp giống như trên các máy khác của Canon. Dưới đây chúng tôi đưa ra một vài ví dụ. Người dùng có thể sử dụng sáng tạo với các tiện ích đã được tích hợp trong máy. Thông số thiết lập: chế độ M, tốc độ 1/320s, khẩu độ f5.6, tiêu cự 15.1 mm, ISO 100, flash tắt. Riêng ảnh chế độ Auto của máy thì máy tự thiết lập là: tốc độ 1/640s, ISO 200, các thông số khác thì giống trước. Các hiệu ứng cân bằng trắng: chế độ chụp chỉnh tay hoàn toàn (M), khẩu độ f5.6. tốc độ 1//320s, ISO 100, flash tắt, tiêu cự 15.1mm Thời gian tiêu hao pin: ở chế độ chụp ảnh thông thường, ít dùng đèn flash, thời lượng pin giúp máy chụp được khoảng 250 hình. Ảnh thực tế Thông số thiết lập: chế độ M, tốc độ 1/320s, khẩu độ f7.1, tiêu cự 15.1 mm.Chế độ M, khẩu độ f2.8. tốc độ 1//40s, ISO 800, flash tắt, tiêu cự 15.1mmChế độ Auto, tốc độ 1/640s, khẩu độ f5.6, tiêu cự 15.1 mm, ISO 200, flash tắtKết luận G1 X là mẫu máy ảnh du lịch cao cấp nhất của Canon hiện nay, được trang bị những công nghệ tiên tiến như: hệ thống xử lý ảnh HS, chip xử lý DIGIC 5, cảm biến rất lớn, hỗ trợ ISO cao, khả năng khử nhiễu tốt bên trong thiết kế cứng cáp, sang trọng. Với những người nhiếp ảnh gia chuyên nghiệp, chiếc máy này có thể được coi là phương án dự phòng trong trường hợp cần thiết. Còn với những người nhiếp ảnh nghiệp dư có nhu cầu nâng cao tính chuyên sâu về chụp ảnh, muốn tiến gần với với công nghệ, thiết bị của một chiếc máy ảnh chuyên nghiệp thì chiếc máy này trở thành sự bổ sung tốt cho những nhu cầu của họ. Nguyên Bình

WARC-Type: response

Content-Type: application/http; msgtype=response

Content-Type: text/html; charset=UTF-8

Connection: close

Cache-control: private, max-age=0

X-Frame-Options: SAMEORIGIN

Content-Encoding: gzip

Vary: Accept-Encoding


text:
Trang chủ
Tìm kiếm
Sơ đồ trang
Thứ bảy
, ngày
20
/
12
/
2014
Giới thiệu chung
Chức năng nhiệm vụ
Những thành tựu nổi bật
Quá trình hình thành và phát triển
Các tiềm năng thế mạnh của ngành
Bộ máy tổ chức
Lãnh đạo sở
Các phòng chuyên môn
Đơn vị trực thuộc
Sơ đồ tổ chức
Tin tức - Sự kiện
Tin nội bộ
Tin trong tỉnh
Tin nổi bật
Thông tin phát triển ngành
Định hướng phát triển
Kết quả thực hiện
Thông tin quy hoạch
Quy hoạch công nghiệp
Quy hoạch thương mại
Các dự án kêu gọi đầu tư
Dự án công nghiệp
Dự án thương mại dịch vụ
Thông tin doanh nghiệp
Danh bạ thư điện tử
chi thị - Quyết định
Mục văn bản xin ý kiến
Thông báo
Thông tin mua sắm công
Thủ tục hành chính
Văn bản chỉ đạo
Văn bản mới
Tin nổi bật
Tăng cường hợp tác kinh tế thương mại giữa đoàn đại biểu tỉnh Lào Cai (VN) và đoàn đại biểu tỉnh Vân Nam (TQ)
Chiều ngày 8/11/2014, tại khách sạn Vịnh Tân Hà (huyện Hà Khẩu tỉnh Vân Nam
-
(Trung Quốc) đã diễn ra cuộc Hội đàm hợp tác Kinh tế - Thương mại giữa đoàn đại biểu tỉnh Lào Cai (Việt Nam) và tỉnh Vân Nam (Trung Quốc).
Mường Khương khai mạc Phiên chợ bán lẻ hàng Việt năm 2014
(05/11/2014)
TÌNH HÌNH HOẠT ĐỘNG THƯƠNG MẠI 9 THÁNG ĐẦU NĂM 2014 CỦA TỈNH LÀO CAI
(05/11/2014)
Hội đàm lần 2 bàn về công tác chuẩn bị tổ chức Hội chợ Kinh tế Thương mại Biên giới Trung - Việt (Hà Khẩu) năm 2014
(09/10/2014)
TỔNG KẾT, BẾ MẠC HỘI CHỢ HÀNG CÔNG NGHIỆP, TIỂU THỦ CÔNG NGHIỆP KHU VỰC PHÍA BẮC NĂM 2014 TẠI LÀO CAI
(23/09/2014)
Khai mạc phiên chợ bán lẻ hàng Việt Tại huyện Bảo Yên, tỉnh Lào Cai
(23/09/2014)
Thủ tướng Nguyễn Tấn Dũng phát lệnh thông xe đường cao tốc Nội Bài – Lào Cai
(22/09/2014)
Hội nghị ngành Công Thương 28 tỉnh, thành phố khu vực phía Bắc: Liên kết, hợp tác phát triển khu vực
(19/09/2014)
Hội nghị trực tuyến toàn quốc về công tác kiểm soát thủ tục hành chính
(15/08/2014)
Thủ tướng Nguyễn Tấn Dũng làm việc với lãnh đạo tỉnh Lào Cai
(30/07/2014)
Tin trong tỉnh
Online Friday- Ngày mua sắm trực tuyến 2014
Trong những năm gần đây, khái niệm ngày vàng mua sắm đã dần trở nên quen thuộc với người Việt Nam.
Nếu người Mỹ có Black Friday và Cyber Monday, người Trung Quốc có Single's Day thì giờ đây, người Việt cũng bắt đầu có ngày Online Friday
(ngày mua sắm trực tuyến)
của riêng mình.
Bế mạc Hội chợ Kinh tế - Thương mại biên giới Trung - Việt (Hà Khẩu) năm 2014
(17/11/2014)
19 cặp hợp đồng được ký kết tại Hội chợ kinh tế thương mại biên giới Trung - Việt năm 2014
(17/11/2014)
Khai mạc Hội chợ kinh tế thương mại biên giới Trung - Việt (Hà Khẩu) năm 2014
(17/11/2014)
Đoàn đại biểu tỉnh Lào Cai sang tham dự Hội chợ Kinh tế Thương mại Biên giới Trung - Việt năm 2014
(17/11/2014)
Đánh giá kết quả thực hiện Chương trình xây dựng nông thôn mới
(10/10/2014)
Để người Việt dùng hàng Việt: Tẩy chay hàng ngoại “dởm”
(10/10/2014)
Tin nội bộ
TIN THANH TRA, KIỂM TRA NĂM 2014
BỘ TÀI CHÍNH BAN HÀNH THÔNG TƯ THAY THẾ THÔNG TƯ SỐ 88/2011/TT-BTC
(17/12/2014)
Lào Cai triển khai công tác phòng, chống buôn lậu, gian lận thương mại và hàng giả trên địa bàn
(21/11/2014)
KẾT QUẢ CÔNG TÁC QLTT THÁNG 10/2014
(05/11/2014)
TỔ CHỨC PHIÊN CHỢ BÁN LẺ HÀNG VIỆT TẠI HUYỆN VĂN BÀN, TỈNH LÀO CAI
(01/10/2014)
LÀO CAI THU HỒI 4 DỰ ÁN ĐẦU TƯ DO CHẬM TIẾN ĐỘ
(25/09/2014)
Đề nghị tăng thuế tiêu thụ đặc biệt với thuốc lá, bia, rượu
(25/09/2014)
Thống kê
Số người đang online
9
Tổng số truy cập
2.544.253
Thư viện ảnh
Thư viện phim

Content-Type: text/html; charset=utf-8


text:
Nokia Lumia 920
Điện thoại thông minh sáng tạo nhất thế giới
Điện thoại thông minh sáng tạo nhất thế giới
Chạm để phát, đặt xuống để sạc pin
Nokia Lumia 920
-
Điện thoại Lumia sáng tạo nhất
Thiết kế nguyên khối rực rỡ với ống kính Carl Zeiss, công nghệ PureView với tính năng Ổn định hình ảnh quang học, cùng với công nghệ hiển thị hình ảnh PureMotion HD+ trên màn hình 4.5 inch.
-
Sạc pin không dây
Đặc biệt, Nokia Lumia 920 được tích hợp tính năng sạc pin không dây, tương thích với tất cả các thiết bị sạc chuẩn Qi.
Màn hình PureMotion HD+. Màn hình cảm ứng tốt nhất trên smartphone.
Nokia Pro Camera. Kiểm soát tốt hơn mỗi bức ảnh của bạn.
HERE City Lens. Khám phá địa điểm xung quanh bạn.
Thiết kế mới lạ. Sạc pin không cần cắm giắc.
Đặc điểm kỹ thuật
-
Hiển thị
- Kích cỡ màn hình: 4,5 inch
- Công nghệ màn hình: ClearBlack, IPS LCD
-
Quản lý pin
- Thời gian chờ tối đa (3G): 400 giờ
- Thời gian phát nhạc tối đa: 52 giờ
- Sạc pin không dây: Tích hợp (tiêu chuẩn Qi)
-
Chip xử lý
- Tên chip xử lý: Qualcomm Snapdragon™ S4
- Loại chip xử lý: Lõi kép 1,5 GHz
-
70,8mm
-
130,3mm10,7mm

markdown:
### Nokia Smart Camera. Thỏa sức sáng tạo.
Nokia Smart Camera cho bạn chụp một chuỗi các bức ảnh liên tiếp để thỏa sức sáng tạo câu chuyện của bạn bằng cách chọn bức ảnh đẹp nhất, lưu giữ một chuỗi hành động, loại bỏ các đối tượng không mong muốn hoặc chọn các biểu hiện đẹp nhất để có những bức hình chụp nhóm tuyệt vời nhất.

Cache-Control: private, max-age=1800

Content-Language: vi-VN

Set-Cookie: deviceType=M; expires=Mon, 22-Dec-2014 20:12:23 GMT; path=/

X-CCC: US


text:
http://shipped-roms.com/index.php
Bài viết ngẫu nhiên cùng Box:
- » [RECOVERY] ClockworkMod for HTC...
- » Rom Villain Froyo 1.0.0
- » Froyo chính thức của Wildfire!
- » HTC Wikdfire khởi động không được!
- » Chuyển ứng dụng qua thể không cần root
- » Cách đơn giản chuyển các ứng dụng từ bộ...
- » Root cho HTC Wildfire S chạy Android...
- » Ship ROM cho các loại máy Wildfire
- » HTC Wildfire
- » Sinh Viên kẹt tiền cuối năm bán WILDFIRE
Bài viết ngẫu nhiên trong diễn đàn:
- » [5530XM] CFW C6 V20.0.42 Super...
- » SafeMgr v3.30(972)VI- Quản lý, bảo vệ...
- » ET Desktop v1.5 s60v3v5 En by pkb-hình...
- » Up rom cho HTC Touch ViVa
- » [iPhone-Games] Air Cadets -Nào chúng ta...
- » Đại chiến Xích Bích.
- » [WGZ]EROZ TECH - Pháo Hoa - Quà năm mới...
- » [GAMELOFT] Gangstar Rio: City of Saints...
- » Từ điển Hex v3.0 Pro
- » Thông tin thiết bị số và công nghệ ngày...

markdown:
http://shipped-roms.com/index.php
Bài viết ngẫu nhiên cùng Box:
-
» [[RECOVERY] ClockworkMod for HTC...]
-
» [Rom Villain Froyo 1.0.0]
-
» [Froyo chính thức của Wildfire!]
-
» [HTC Wikdfire khởi động không được!]
-
» [Chuyển ứng dụng qua thể không cần root]
-
» [Cách đơn giản chuyển các ứng dụng từ bộ...]
-
» [Root cho HTC Wildfire S chạy Android...]
-
» [Ship ROM cho các loại máy Wildfire]
-
» [HTC Wildfire]
-
» [Sinh Viên kẹt tiền cuối năm bán WILDFIRE]
Bài viết ngẫu nhiên trong diễn đàn:
-
» [[5530XM] CFW C6 V20.0.42 Super...]
-
» [SafeMgr v3.30(972)VI- Quản lý, bảo vệ...]
-
» [ET Desktop v1.5 s60v3v5 En by pkb-hình...]
-
» [Up rom cho HTC Touch ViVa]
-
» [[iPhone-Games] Air Cadets -Nào chúng ta...]
-
» [Đại chiến Xích Bích.]
-
» [[WGZ]EROZ TECH - Pháo Hoa - Quà năm mới...]
-
» [[GAMELOFT] Gangstar Rio: City of Saints...]
-
» [Từ điển Hex v3.0 Pro]
-
» [Thông tin thiết bị số và công nghệ ngày...]

Server: Apache/2.2.26 (CentOS)

Cache-Control: private

Pragma: private


text:
Quách Phú Thành "lạ - quái" với mái tóc bạch kim, lông mày trắng và
thời trang "xì tin".
Kiểu tóc 2 vương niệm cực độc
(St)
Quách Phú Thành gây sốt với trang phục xuyên thấu
Bạn gái Quách Phú Thành xem… "đàn ông như quần áo"
Quách Phú Thành khoe của quý lồ lộ trên sân khấu sự thật hay chỉ là tin đồn
Sao Hoa ngữ và cảnh nóng "bỏng mắt" trên phim truyền hình
Quách Phú Thành và Hùng Đại Lâm thu hút mọi ánh nhìn khi dạo phố
Không có bài viết nào!
Mạng xã hội dành cho phụ nữ của công ty cổ phần PhunuNet/VOG (Vietnam Online Group).
Công ty cổ phần Vietnam Online Group: Địa chỉ: Tầng 7 - 32 phố Huế - Hà Nội - Email
liên hệ: contact@phununet.com
VP PhunuNet: Phòng 1103, Tầng 11, Tòa nhà Vườn Xuân, 71 Nguyễn Chí Thanh, Q. Đống Đa, Hà Nội - Điện thoại: (+84-4) 6 275 2213
Mã số doanh nghiệp: 0101791319
Giấy phép số 2558/GP-TTĐT do Sở TT-TT HN cấp. GXN cung cấp dịch vụ mạng xã hội số
75/GXN-TTĐT do Cục QLPTTH & TTĐT, Bộ TT-TT cấp.

Server: Apache/2.4.1 (Unix)


text:
Chú thích: Quảng cáo xuất hiện 24/24 ngẫu nhiên trong 3 vị trí bên trái của Google.
Chú thích: Quảng cáo xuất hiện 24/24 ngẫu nhiên trong 3 vị trí bên trái và 3 vị trí bên phải của Google.
Chú thích: Quảng cáo xuất hiện 24/24 ngẫu nhiên trong trang nhất của Google.
Chú thích: Quảng cáo xuất hiện ngẫu nhiên trong trang nhất của Google.
Chú thích: Quý khách được tự chọn vị trí xuất hiện tùy thuộc vào giá thầu của mỗi từ khóa.
Lưu ý:
Quý khách có nhu cầu liên hệ:
Biệt thự số 18/19 Đông Tác, P.Kim Liên, Q.Đống Đa, Tp.Hà Nội
Tel: (04) 35.76.56.45 Fax: (04) 35.76.56.44
Hotline: 097.487.6688 - 093.771.6688 - Mr Quang
Yahoo: quangs3i
Email: quang.buiduc@sptgroup.vn
Phòng 205, Tòa nhà Age, 32 Xô Viết Nghệ Tĩnh, P.19, Q.Bình Thạnh, Tp.HCM
Tel: (08) 35.142.999 Fax: (08) 35.142.866
Hotline: 097.487.6688 - 093.771.6688 - Mr Quang
Website: www.sptgroup.vn Email: quang.buiduc@sptgroup.vn

markdown: [Quảng cáo google](http://www.quangcaotrengoogle.com.vn/)| [Quang cao google](http://quangcaotrengoogle.com.vn//)| [quảng cáo trên google](http://www.quangcaotrengoogle.com.vn/)| [quang cao tren google](http://www.quangcaotrengoogle.com.vn/)| [google adwords](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo google adwords](http://www.quangcaotrengoogle.com.vn/)| [quang cao google adwords](http://www.quangcaotrengoogle.com.vn/)| [dịch vụ quảng cáo google](http://www.quangcaotrengoogle.com.vn/)| [dich vu quang cao google](http://www.quangcaotrengoogle.com.vn/)| [công ty quảng cáo google](http://www.quangcaotrengoogle.com.vn/)| [cong ty quang cao google](http://www.quangcaotrengoogle.com.vn/)| [đưa web lên google](http://www.quangcaotrengoogle.com.vn/)| [dua web len google](http://www.quangcaotrengoogle.com.vn/)| [đẩy web lên google](http://www.quangcaotrengoogle.com.vn/)| [day web len google](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo google giá rẻ](http://www.quangcaotrengoogle.com.vn/)| [quang cao google gia re](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo trực tuyến](http://www.quangcaotrengoogle.com.vn/)| [quang cao truc tuyen](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo online](http://www.quangcaotrengoogle.com.vn/)| [quang cao online](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo website](http://www.quangcaotrengoogle.com.vn/)| [quang cao website](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo web](http://www.quangcaotrengoogle.com.vn/)| [quang cao web](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo từ khóa](http://www.quangcaotrengoogle.com.vn/)| [quang cao tu khoa](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo trên mạng](http://www.quangcaotrengoogle.com.vn/)| [quang cao tren mang](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo trên internet](http://www.quangcaotrengoogle.com.vn/)| [quang cao tren internet](http://www.quangcaotrengoogle.com.vn/)| [quảng cáo điện tử](http://www.quangcaotrengoogle.com.vn/)| [quang cao dien tu](http://www.quangcaotrengoogle.com.vn/)| [quảng bá web](http://www.quangcaotrengoogle.com.vn/)| [quang ba web](http://www.quangcaotrengoogle.com.vn/)| [quảng bá website](http://www.quangcaotrengoogle.com.vn/)| [quang ba website](http://www.quangcaotrengoogle.com.vn/)

Set-Cookie: zt_morbi_tpl=zt_morbi; expires=Wed, 09-Dec-2015 20:11:07 GMT; path=/

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Vary: Accept-Encoding,User-Agent


text:
Bình tập hút Combi (B4)
Được thiết kế phù hợp với khuôn miệng nhỏ của bé, miệng cốc không có phần kiểm soát chất lỏng (núm vú, ống uống, ống hút) vì vậy bé có thể uống thoải mái
Thân cốc có vạch chia ml dập nổi để bố mẹ dễ dàng kiểm soát lượng chất lỏng cho bé uống
--------------------------------
Cốc tập uống bước 3
Màu sắc: xanh ngọc
Tuổi sử dụng: từ 8 tháng tuổi
Chất liệu: nhựa PP, silicon siêu mềm
Xuất xứ: Nhật Bản
Hãng sản xuất: Combi Corporation Japan
Hiện tại chưa có ý kiến đánh giá nào về sản phẩm. Hãy là người đầu tiên chia sẻ cảm nhận của bạn.
-
297.000 VNDBình tập uống cổ rộng Nuk (si) (bpa free) 743392Giá : 297.000
Tình trạng : Còn hàng
Bình tập uống có tay cầm dành cho bé từ 6 tháng trở lên. Sản phẩm chính hãng, NK từ Đức.
50.000 VNDCốc dùng trong lò vi sóng NB015Giá : 50.000
Tình trạng : Còn hàng50.000 VNDCốc giữ nhiệt NB 714 (có nắp)Giá : 50.000
Tình trạng : Liên hệ
Cốc cách nhiệt giúp bạn pha sữa, đựng cháo cho bé nóng lâu hơn
45.000 VNDCốc chia vạch ml 520061 (500ml)Giá : 45.000
Tình trạng : Còn hàng
Cốc có vạch chia ml, thuận tiện cho mẹ khi pha sữa, hoa quả cho bé theo độ chính xác tuyệt đối
Cốc tập uống có quai Inomata (ống hút)Giá : 45.000
Tình trạng : Liên hệ
Cốc có quai, ống hút dành cho bé từ 8 tháng trở lên, giúp bé tập uống nước, sữa, nước hoa quả, giúp bé tập làm quen dần với cốc uống thông thường sau này
Cốc tập uống có quai Inomata (ống hút)Giá : 45.000
Tình trạng : Còn hàng
Cốc có quai, ống hút dành cho bé từ 8 tháng trở lên, giúp bé tập uống nước, sữa, nước hoa quả, giúp bé tập làm quen dần với cốc uống thông thường sau này
45.000 VNDCốc chia vạch ml Happy clover 086Giá : 45.000
Tình trạng : Liên hệ
Cốc có vạch chia ml, thuận tiện cho mẹ khi pha sữa, hoa quả cho bé theo độ chính xác tuyệt đối
130.000 VNDBình tập uống Boon (cam)Giá : 130.000
Tình trạng : Còn hàng
Bình tập uống Boon mang đến cho bạn, cho bé sự an toàn và tiện lợi. Các bộ phận có thể tháo ghép dẽ dàng, dễ súc rửa.

markdown:
# Bình tập hút Combi (B4)
**Kho hàng**: Có hàng **4972990136433**Trong kho : **Còn hàng** ![](/template/default/images/i_stars_0.png)
[Viết đánh giá]|
Sản phẩm yêu thích
![](/template/default/images/icon9.png)
|Chọn lứa tuổi||
|
|Nơi sản xuất||
|
|Nhập khẩu từ||
|
|Chất liệu||
|[[ Hình thức Chấp nhận thanh toán ]](/page/chinh-sach-giao-hang)
Được thiết kế phù hợp với khuôn miệng nhỏ của bé, miệng cốc không có phần kiểm soát chất lỏng (núm vú, ống uống, ống hút) vì vậy bé có thể uống thoải mái
Thân cốc có vạch chia ml dập nổi để bố mẹ dễ dàng kiểm soát lượng chất lỏng cho bé uống
--------------------------------
Cốc tập uống bước 3
Màu sắc: xanh ngọc
Tuổi sử dụng: từ 8 tháng tuổi
Chất liệu: nhựa PP, silicon siêu mềm
Xuất xứ: Nhật Bản
Hãng sản xuất: Combi Corporation Japan
Hiện tại chưa có ý kiến đánh giá nào về sản phẩm. Hãy là người đầu tiên chia sẻ cảm nhận của bạn.
-
297.000 VNDBình tập uống cổ rộng Nuk (si) (bpa free) 743392Giá : 297.000
**Tình trạng**: Còn hàng
Bình tập uống có tay cầm dành cho bé từ 6 tháng trở lên. Sản phẩm chính hãng, NK từ Đức.
50.000 VNDCốc dùng trong lò vi sóng NB015Giá : 50.000
**Tình trạng**: Còn hàng50.000 VNDCốc giữ nhiệt NB 714 (có nắp)Giá : 50.000 **Tình trạng**: Liên hệ
Cốc cách nhiệt giúp bạn pha sữa, đựng cháo cho bé nóng lâu hơn
45.000 VNDCốc chia vạch ml 520061 (500ml)Giá : 45.000
**Tình trạng**: Còn hàng
Cốc có vạch chia ml, thuận tiện cho mẹ khi pha sữa, hoa quả cho bé theo độ chính xác tuyệt đối
Cốc tập uống có quai Inomata (ống hút)Giá : 45.000
**Tình trạng**: Liên hệ
Cốc có quai, ống hút dành cho bé từ 8 tháng trở lên, giúp bé tập uống nước, sữa, nước hoa quả, giúp bé tập làm quen dần với cốc uống thông thường sau này
Cốc tập uống có quai Inomata (ống hút)Giá : 45.000
**Tình trạng**: Còn hàng
Cốc có quai, ống hút dành cho bé từ 8 tháng trở lên, giúp bé tập uống nước, sữa, nước hoa quả, giúp bé tập làm quen dần với cốc uống thông thường sau này
45.000 VNDCốc chia vạch ml Happy clover 086Giá : 45.000
**Tình trạng**: Liên hệ
Cốc có vạch chia ml, thuận tiện cho mẹ khi pha sữa, hoa quả cho bé theo độ chính xác tuyệt đối
130.000 VNDBình tập uống Boon (cam)Giá : 130.000
**Tình trạng**: Còn hàng
Bình tập uống Boon mang đến cho bạn, cho bé sự an toàn và tiện lợi. Các bộ phận có thể tháo ghép dẽ dàng, dễ súc rửa.

WARC-Truncated: length

Server: Apache

Content-Type: text/html


text:
Danh mục Menu
Liên kết website
Thông tin truy cập
Tin nổi bật
Các vấn đề chung
Chính sách người có công
Chính sách xã hội
Văn bản mới ban hành
Chính sách Bảo vệ trẻ em
Chính sách Dạy nghề - Việc làm
Các vấn đề khác
Hình hoạt động
Tin xem nhiều
Những người mẹ anh hùng của dân tộc anh hùng (24 lượt xem) [04/12/2014]
Hưởng ứng “Ngày toàn dân phòng cháy chữa cháy” (12 lượt xem) [18/09/2014]
Hội nghị đánh giá kết quả hoạt động của các trung tâm đào tạo giai đoạn ( 2008- 2013) của Hội người mù Trung Ương tổ chức. (12 lượt xem) [28/08/2014]
Hộ gia đình làm nông nghiệp, ngư nghiệp và diêm nghiệp có mức sống trung bình sẽ được hỗ trợ đóng bảo hiểm y tế. (8 lượt xem) [26/10/2014]
Vĩnh Long xây dựng Nhà bia kỷ niệm thành lập Chi bộ Đảng đầu tiên (4 lượt xem) [04/12/2014]

markdown:
# Danh mục Menu
# Liên kết website
# Thông tin truy cập
|15|
|23|
|98|
|146|
|11399|
# Tin nổi bật
# Các vấn đề chung
| |
| |
| |![]()
# Chính sách người có công
| |
| |
| |![]()
![]()
# Chính sách xã hội
| |
| |![]()
![]()
# Văn bản mới ban hành
# Chính sách Bảo vệ trẻ em
| |
| |
| |![]()
# Chính sách Dạy nghề - Việc làm
| |
| |
| |![]()
# Các vấn đề khác
| |
| |
| |![]()
![]()
# Hình hoạt động
# Tin xem nhiều
![](http://www.sldtbxh.vinhlong.gov.vn/SoLDTBXH-theme/images/custom/arrow.gif)
[Những người mẹ anh hùng của dân tộc anh hùng](/web/guest/tin-tuc/-/journal_content/56_INSTANCE_8t2x2vZjGkUk/240040/242111)(24 lượt xem) [04/12/2014] ![](http://www.sldtbxh.vinhlong.gov.vn/SoLDTBXH-theme/images/custom/arrow.gif)
[Hưởng ứng “Ngày toàn dân phòng cháy chữa cháy”](/web/guest/tin-tuc/-/journal_content/56_INSTANCE_8t2x2vZjGkUk/240040/242191)(12 lượt xem) [18/09/2014] ![](http://www.sldtbxh.vinhlong.gov.vn/SoLDTBXH-theme/images/custom/arrow.gif)
[Hội nghị đánh giá kết quả hoạt động của các trung tâm đào tạo giai đoạn ( 2008- 2013) của Hội người mù Trung Ương tổ chức.](/web/guest/tin-tuc/-/journal_content/56_INSTANCE_8t2x2vZjGkUk/240040/243513)(12 lượt xem) [28/08/2014] ![](http://www.sldtbxh.vinhlong.gov.vn/SoLDTBXH-theme/images/custom/arrow.gif)
[Hộ gia đình làm nông nghiệp, ngư nghiệp và diêm nghiệp có mức sống trung bình sẽ được hỗ trợ đóng bảo hiểm y tế.](/web/guest/tin-tuc/-/journal_content/56_INSTANCE_8t2x2vZjGkUk/240040/242124)(8 lượt xem) [26/10/2014] ![](http://www.sldtbxh.vinhlong.gov.vn/SoLDTBXH-theme/images/custom/arrow.gif)
[Vĩnh Long xây dựng Nhà bia kỷ niệm thành lập Chi bộ Đảng đầu tiên](/web/guest/tin-tuc/-/journal_content/56_INSTANCE_8t2x2vZjGkUk/240040/244608)(4 lượt xem) [04/12/2014]
# Tin mới đăng
| |![]()
| |![]()

X-JAVAX-PORTLET-FACES-NAMESPACED-RESPONSE: true

Liferay-Portal: Liferay Portal Community Edition 6.1.1 CE GA2 (Paton / Build 6101 / July 31, 2012)

X-Powered-By: ASP NET


text:
© Bản quyền thuộc về Tạp chí Cộng Sản.
Địa chỉ: Số 28, Trần Bình Trọng - TP.Hà Nội.
Điện thoại: 04 39429753 - Fax: 04 39429754
Email: baodientu@tccs.org.vn
Designed by ACOMM
Cơ quan Thường trực tại miền Trung - Tây Nguyên:
Số 26 Trần Phú, thành phố Đà Nẵng
Điện thoại: 080 51301; Fax: 080 51 303
Cơ quan Thường trực tại miền Nam:
Số 19 Phạm Ngọc Thạch, phường 6, quận 3, Thành phố Hồ Chí Minh
Điện thoại: 080 84083; Fax: 080 84081
Văn phòng đại diện tại thành phố Cần Thơ
Số 86 Nguyễn Trãi, phường Cái Khế,quận Ninh Kiều, TP Cần Thơ
Điện thoại/Fax: (0710)6250868
Giấy phép số 259/GP-TTĐT ngày 08-12-2010 của Bộ Thông tin và Truyền thông về thiết lập trang thông tin điện tử tổng hợp trên Internet.


text:
Vụ thẩm mỹ viện Cát Tường: “Thi thể nạn nhân Huyền trôi ra biển”
Thứ 5, 31/10/2013 07:21:42- Chuyên mục
Sự Kiện : Thẩm mỹ viện làm chết người phi tang xác
(Tinmoi.vn) Theo đại tá Lê Việt Vùng, nguyên Giám đốc Trung tâm Giám định pháp y Viện Khoa học Hình sự Bộ Công an, rất có thể thi thể chị Huyền - nạn nhân thẩm mỹ viện Cát Tường đã vướng vào tàu, thuyền trên sông trôi ra biển vì nếu loanh quanh ở khu vực sông Hồng thì xác phải nổi lên rồi.
Trao đổi với phóng viên, đại tá, tiến sĩ Lê Việt Vùng, nguyên Giám đốc Trung tâm Giám định pháp y Viện Khoa học Hình sự Bộ Công an cho biết, thông thường thi thể ném xuống sông sẽ nổi lên trong quá trình phân hủy, thời gian bao nhiêu lâu còn phụ thuộc vào các yếu tố như thời tiết, cơ địa từng người nhưng thường là 4-5 ngày.
Với trường hợp nạn nhân bị bác sĩ thẩm mỹ viện Cát Tường phi tang xác, theo ông Vùng, có thể túi bóng buộc thi thể chị Huyền đã vướng vào tàu, thuyền đi trên sông và trôi ra ngoài biển chứ không còn ở loanh quanh khu vực gầm cầu Thanh Trì và tuyến sông đó.
Với giả thiết như một số người đưa ra xác chị Huyền có thể bị ông bác sĩ buộc vật nặng nên bị vùi dưới cát, không thể nổi lên được, ông Vùng cho rằng, trường hợp này cũng có thể xảy ra nhưng trường hợp của chị Huyền ít khả năng xảy ra.
"Có thể xác nạn nhân vụ thẩm mỹ viện Cát Tường đã vướng vào tàu, thuyền trên sông trôi ra biển"
“Có nhiều trường hợp nạn nhân vứt dưới sông không nổi được. Cũng có trường hợp, đối tượng phi tang xác đóng cọc chéo vào nhau rồi ghìm thi thể nạn nhân xuống nhưng sau vẫn nổi lên. Có trường hợp thủ phạm buộc vật nặng hoặc gìm cổ, chân, tay vào cột thì những bộ phận còn lại vẫn có thể nổi lên. Với những trường hợp này cũng khó có thể đưa ra những mốc thời gian cụ thể vì nó còn phụ thuộc vào nhiều yếu tố khác như mùa đông, mùa hè, cơ địa của từng người…Nhưng liệu rằng trong trường hợp nạn nhân thẩm mỹ viện Cát Tường có xảy ra những giả thiết trên vì nếu vật buộc kèm mà nặng qúa thì hai người kia sẽ không thể bê và ném xuống sông được còn nếu bằng hoặc nhỏ hơn trọng lượng cơ thể thì khi phân hủy vẫn có thể nổi. Theo đó, nhiều khả năng thi thể chị này đã bị vướng vào thuyền trôi ra biển” ông Vùng phân tích.
Cũng theo ông Vùng, những ý kiến cho rằng thi thể ông bác sĩ có thể phi tang xác nạn nhân ở chỗ khác hay bằng cách khác chỉ là suy đoán, suy diễn. Cơ quan điều tra đủ nghiệp vụ để có thể thẩm định lời khai của các đối tượng chính xác hay không. Nếu có cơ sở nghi vấn địa điểm phi tang ở chỗ khác, cơ quan chức năng không để phải mất 10 ngày loay hoay, phí sức.
Mặc dù đến thời điểm này công tác tìm kiếm xác chị Huyền vẫn khó khăn nhưng theo ông Vùng, trong trường hợp tìm đuợc cũng khó có thể dựa vào thi thể để xác định nguyên nhân chết cũng như chết trước hay sau khi bị ném vì lục phủ ngũ tạng thối rữa hết, không có hình ảnh ti thể để phân tích và đưa ra kết luận.
Tuy nhiên, bằng các phương pháp nghiệp vụ khác, cơ quan chức năng hoàn toàn có thể đưa ra kết luận, xác định tội danh của đối tượng.
“Kết quả pháp y chỉ là một cơ sở để để đưa ra kết luận về nguyên nhân chết cũng như hành vi phạm tội. Đã có nhiều trường hợp không tìm thấy xác nạn nhân nhưng với nhiều cơ sở căn cứ khác cơ quan điều tra vẫn đưa ra được kết luận”, ông Vùng nói.
Trước đó, sau thông tin thi thể nạn nhân thẩm mỹ viện Cát Tường vẫn chưa được tìm thấy sau 10 ngày bị phi tang, một số ý kiến đặt nghi vấn: Có thể xác nạn nhân bị vướng vào vật gì dưới đáy sông, hay bị cát vùi. Cũng có thể bác sĩ Tường khai không đúng, ông này không ném xác chị Huyền xuống sống mà phi tang xác ở chỗ khác, thậm chí dã man hơn là chặt nhỏ xác để phi tang ở chỗ khác”.
Theo lời khai của ông Nguyễn Mạnh Tường – bác sĩ, chủ cơ sở thẩm mỹ viện Cát Tường, thi thể chị Huyền bị ông ném xuống khu vực sông dưới cầu Thanh Trì tối ngày 19/10. Như vậy, tính đến nay, thi thể chị Huyền đã mất tích 10 ngày.
H.Minh
Tin Mới/Đời sống và pháp luật
- Video: Phẫn nộ bảo mẫu "nhồi" cơm cho trẻ không khác gì nhồi vịt (19/12)
- 12 công nhân được đưa ra khỏi hầm: Niềm vui vỡ òa (19/12)
- Hình ảnh 12 nạn nhân bị mắc kẹt được đưa ra khỏi hầm (19/12)
- Dung dịch dinh dưỡng truyền cho 12 công nhân bị mắc kẹt chứa gì? (19/12)
- Chuyên gia "hiến kế" giải cứu 12 người mắc kẹt vụ sập hầm thủy điện Đạ Dâng (19/12)
- Thiếu nữ 18 tuổi gào khóc nhìn người yêu nhảy cầu sông Hàn tự tử (19/12)
- Bàn giao bé trai 2 tuổi bị mẹ bỏ rơi trên taxi cho trung tâm xã hội (19/12)
- Suýt chết vì nhờ thầy lang chữa rắn lục đuôi đỏ cắn (19/12)
- Hà Nội sẽ xử lý hành vi dừng xe mua bán hàng hóa ở lòng đường, vỉa hè (19/12)
- Rắn lục đuôi đỏ "ẩn náu" dưới yên xe đạp cắn người (19/12)

markdown:
# Vụ thẩm mỹ viện Cát Tường: “Thi thể nạn nhân Huyền trôi ra biển”
###### Thứ 5, 31/10/2013 07:21:42- Chuyên mục
Sự Kiện :
[Thẩm mỹ viện làm chết người phi tang xác](http://www.tinmoi.vn/tham-my-vien-lam-chet-nguoi-phi-tang-xac-e377.html)
**
**
![ ](http://media.tinmoi.vn/block/line_03.png)
**
(Tinmoi.vn) Theo đại tá Lê Việt Vùng, nguyên Giám đốc Trung tâm Giám định pháp y Viện Khoa học Hình sự Bộ Công an, rất có thể thi thể chị Huyền - nạn nhân thẩm mỹ viện Cát Tường đã vướng vào tàu, thuyền trên sông trôi ra biển vì nếu loanh quanh ở khu vực sông Hồng thì xác phải nổi lên rồi. **
Trao đổi với phóng viên, đại tá, tiến sĩ Lê Việt Vùng,
nguyên Giám đốc Trung tâm Giám định pháp y Viện Khoa học Hình sự Bộ Công an cho
biết, thông thường thi thể ném xuống sông sẽ nổi lên trong quá trình phân hủy,
thời gian
[bao](http://www.tinmoi.vn/) nhiêu lâu còn phụ thuộc vào các yếu tố như thời tiết, cơ địa từng
người nhưng thường là 4-5 ngày.
Với trường hợp nạn nhân bị bác sĩ thẩm mỹ viện Cát Tường phi tang xác, theo ông Vùng, có thể túi bóng buộc thi thể chị Huyền đã vướng vào tàu, thuyền đi trên sông và trôi ra ngoài biển chứ không còn ở loanh quanh khu vực gầm cầu Thanh Trì và tuyến sông đó.
Với giả thiết như một số người đưa ra xác chị Huyền có thể bị ông bác sĩ buộc vật nặng nên bị vùi dưới cát, không thể nổi lên được, ông Vùng cho rằng, trường hợp này cũng có thể xảy ra nhưng trường hợp của chị Huyền ít khả năng xảy ra.
## "Có thể xác nạn nhân vụ thẩm mỹ viện Cát Tường đã vướng vào tàu, thuyền trên sông trôi ra biển"
“Có nhiều trường hợp nạn nhân vứt dưới sông không nổi được. Cũng có trường hợp, đối tượng phi tang xác đóng cọc chéo vào nhau rồi ghìm thi thể nạn nhân xuống nhưng sau vẫn nổi lên. Có trường hợp thủ phạm buộc vật nặng hoặc gìm cổ, chân, tay vào cột thì những bộ phận còn lại vẫn có thể nổi lên. Với những trường hợp này cũng khó có thể đưa ra những mốc thời gian cụ thể vì nó còn phụ thuộc vào nhiều yếu tố khác như mùa đông, mùa hè, cơ địa của từng người…Nhưng liệu rằng trong trường hợp nạn nhân thẩm mỹ viện Cát Tường có xảy ra những giả thiết trên vì nếu vật buộc kèm mà nặng qúa thì hai người kia sẽ không thể bê và ném xuống sông được còn nếu bằng hoặc nhỏ hơn trọng lượng cơ thể thì khi phân hủy vẫn có thể nổi. Theo đó, nhiều khả năng thi thể chị này đã bị vướng vào thuyền trôi ra biển” ông Vùng phân tích.
![Vụ thẩm mỹ viện Cát Tường: “Thi thể nạn nhân Huyền trôi ra biển” - ảnh 2 Hình ảnh Vụ thẩm mỹ viện Cát Tường: “Thi thể nạn nhân Huyền trôi ra biển” số 2](http://media.tinmoi.vn/block/suggest-title_15.png)
Cũng theo ông Vùng, những ý kiến cho rằng thi thể ông bác sĩ có thể phi tang xác nạn nhân ở chỗ khác hay bằng cách khác chỉ là suy đoán, suy diễn. Cơ quan điều tra đủ nghiệp vụ để có thể thẩm định lời khai của các đối tượng chính xác hay không. Nếu có cơ sở nghi vấn địa điểm phi tang ở chỗ khác, cơ quan chức năng không để phải mất 10 ngày loay hoay, phí sức.
Mặc dù đến thời điểm này công tác tìm kiếm xác chị Huyền vẫn khó khăn nhưng theo ông Vùng, trong trường hợp tìm đuợc cũng khó có thể dựa vào thi thể để xác định nguyên nhân chết cũng như chết trước hay sau khi bị ném vì lục phủ ngũ tạng thối rữa hết, không có hình ảnh ti thể để phân tích và đưa ra kết luận.
Tuy nhiên, bằng các phương pháp nghiệp vụ khác, cơ quan chức năng hoàn toàn có thể đưa ra kết luận, xác định tội danh của đối tượng.
“Kết quả pháp y chỉ là một cơ sở để để đưa ra kết luận về nguyên nhân chết cũng như hành vi phạm tội. Đã có nhiều trường hợp không tìm thấy xác nạn nhân nhưng với nhiều cơ sở căn cứ khác cơ quan điều tra vẫn đưa ra được kết luận”, ông Vùng nói.
Trước đó, sau thông
[tin](http://www.tinmoi.vn/C/Tin-tuc) thi thể nạn nhân thẩm mỹ viện Cát
Tường vẫn chưa được tìm thấy sau 10 ngày bị phi tang, một số ý kiến đặt nghi
vấn: Có thể xác nạn nhân bị vướng vào vật gì dưới đáy sông, hay bị cát vùi.
Cũng có thể bác sĩ Tường khai không đúng, ông này không ném xác chị Huyền xuống
sống mà phi tang xác ở chỗ khác, thậm chí dã man hơn là chặt nhỏ xác để phi
tang ở chỗ khác”.
Theo lời khai của ông Nguyễn Mạnh Tường – bác sĩ, chủ cơ sở thẩm mỹ viện Cát Tường, thi thể chị Huyền bị ông ném xuống khu vực sông dưới cầu Thanh Trì tối ngày 19/10. Như vậy, tính đến nay, thi thể chị Huyền đã mất tích 10 ngày.
H.Minh
Tin Mới/Đời sống và pháp luật
[Tin tức](http://www.tinmoi.vn/C/Tin-tuc) [>>Xem thêm](http://www.tinmoi.vn/lienquan/vu-tham-my-vien-cat-tuong-thi-the-nan-nhan-huyen-troi-ra-bien-1283927.html)
-
[Video: Phẫn nộ bảo mẫu "nhồi" cơm cho trẻ không khác gì nhồi vịt (19/12)](http://www.tinmoi.vn/video-phan-no-bao-mau-nhoi-com-cho-tre-khong-khac-gi-nhoi-vit-011339258.html)
-
[12 công nhân được đưa ra khỏi hầm: Niềm vui vỡ òa (19/12)](http://www.tinmoi.vn/12-cong-nhan-duoc-dua-ra-khoi-ham-niem-vui-vo-oa-011339256.html)
-
[Hình ảnh 12 nạn nhân bị mắc kẹt được đưa ra khỏi hầm (19/12)](http://www.tinmoi.vn/hinh-anh-12-nan-nhan-bi-mac-ket-duoc-dua-ra-khoi-ham-011339252.html)
-
[Dung dịch dinh dưỡng truyền cho 12 công nhân bị mắc kẹt chứa gì? (19/12)](http://www.tinmoi.vn/dung-dich-dinh-duong-truyen-cho-12-cong-nhan-bi-mac-ket-chua-gi-011339228.html)
-
[Chuyên gia "hiến kế" giải cứu 12 người mắc kẹt vụ sập hầm thủy điện Đạ Dâng (19/12)](http://www.tinmoi.vn/chuyen-gia-hien-ke-giai-cuu-12-nguoi-mac-ket-vu-sap-ham-thuy-dien-da-dang-011339201.html)
-
[Thiếu nữ 18 tuổi gào khóc nhìn người yêu nhảy cầu sông Hàn tự tử (19/12)](http://www.tinmoi.vn/thieu-nu-18-tuoi-gao-khoc-nhin-nguoi-yeu-nhay-cau-song-han-tu-tu-011339187.html)
-
[Bàn giao bé trai 2 tuổi bị mẹ bỏ rơi trên taxi cho trung tâm xã hội (19/12)](http://www.tinmoi.vn/ban-giao-be-trai-2-tuoi-bi-me-bo-roi-tren-taxi-cho-trung-tam-xa-hoi-011339178.html)
-
[Suýt chết vì nhờ thầy lang chữa rắn lục đuôi đỏ cắn (19/12)](http://www.tinmoi.vn/suyt-chet-vi-nho-thay-lang-chua-ran-luc-duoi-do-can-011339173.html)
-
[Hà Nội sẽ xử lý hành vi dừng xe mua bán hàng hóa ở lòng đường, vỉa hè (19/12)](http://www.tinmoi.vn/ha-noi-se-xu-ly-hanh-vi-dung-xe-mua-ban-hang-hoa-o-long-duong-via-he-011339172.html)
-
[Rắn lục đuôi đỏ "ẩn náu" dưới yên xe đạp cắn người (19/12)](http://www.tinmoi.vn/ran-luc-duoi-do-an-nau-duoi-yen-xe-dap-can-nguoi-011339160.html)


text:
Hạnh Phúc Mong Manh
Don't Know Her
- Chất lượng:
- HD
- Đạo diễn:
- Bae Tae Sup
- Diễn viên:
- Kim Ji Ho, Im Ho as, Go Se Won, Chae Min Seo
- Thể loại:
- Tâm Lý
- Quốc gia:
- Hàn Quốc
- Thời lượng:
- 109 Tập
- Lượt xem:
- 15,905
- Thích:
- Share:
-
chúc các bạn xem phim vui vẻ!
-
Tập 7/32HQ
Nữ Thần Lửa Jung YiThe Goddess Of Fire Jung YiTập 7/32 | HQ
Nội dung Phim Nữ Thần Lửa Jung Yi - The Goddess Of Fire Jung Yi Xem phim Nữ Thần Lửa Jung Yi tập 1 2 3 4 5 6 7 8 9 10, Nữ Thần Lửa Jung Yi tập cuối, Nữ Thần Lửa Jung Yi trọn bộ, Nữ Thần Lửa Jung Yi thuyết minh, Nữ Thần Lửa Jung Yi lồng tiếng, Nữ Thần Lửa Jung Yi vietsub, Nữ Thần Lửa Jung Yi full HD, Nữ Thần Lửa ...
-
29 TậpHD
Chiến Binh Baek Dong SooWarrior Baek Dong Soo29 Tập | HD
Warrior Baek Dong Soo là câu chuyện kể về một huyền thoại kiếm khách có thật dưới triều vua Jeongjo thời Chosun. Nhân vật chính của phim là anh hùng Baek Dong Soo, người đứng đầu một nhóm cận vệ thiện xạ bảo vệ hoàng đế và đã sáng lập ra hẳn một bí kíp võ thuật.
-
-
34 TậpHD
Tình Yêu Chân ThậtLove Actually34 Tập | HD
Cô gái có năng khiếu nấu ăn thiên bẩm là Vương Tiểu Hạ cùng cháu trai là Dương Quang nương tựa vào nhau sống qua ngày. Trong một lần gặp sự cố, do sơ suất của nhân viên môi giới nhà đất là Trần Hạo Kiệt khiến Tiểu Hạ bị chủ nhà lừa.Không còn nhà ở, bị dồn vào đường cùng, Tiểu Hạ đành cùng Hạo ...

markdown:
# Hạnh Phúc Mong Manh
## Don't Know Her
- Chất lượng:
- HD
- Đạo diễn:
-
[Bae Tae Sup](tim-kiem/bae+tae+sup.html)
- Diễn viên:
-
[Kim Ji Ho](tim-kiem/kim+ji+ho.html), [Im Ho as](tim-kiem/im+ho+as.html), [Go Se Won](tim-kiem/go+se+won.html), [Chae Min Seo](tim-kiem/chae+min+seo.html)
- Thể loại:
[Tâm Lý](http://www.top1phim.com/the-loai/tam-ly.html)
- Quốc gia:
- Hàn Quốc
- Thời lượng:
- 109 Tập
- Lượt xem:
- 15,905
- Thích:
- Share:
-
**Xem phim "Hạnh Phúc Mong Manh" vietsub, lồng tiếng, thuyết minh, tập 1 2 3 4 5 6 7 8 9, tập cuối, Hạnh Phúc Mong Manh full HD, trọn bộ.**Lee Min Jung trở nên mang thai sau khi phát hiện ngoại tình của chồng mình với Oh Yoo Ran. Một bộ phim về cuộc đời mình như một người mẹ và người đàn ông yêu thương cô ấy vô điều kiện.
chúc các bạn
[xem phim](http://top1phim.com) vui vẻ!
-
Tập 7/32HQ
### Nữ Thần Lửa Jung YiThe Goddess Of Fire Jung YiTập 7/32 | HQ
Nội dung Phim Nữ Thần Lửa Jung Yi - The Goddess Of Fire Jung Yi Xem phim Nữ Thần Lửa Jung Yi tập 1 2 3 4 5 6 7 8 9 10, Nữ Thần Lửa Jung Yi tập cuối, Nữ Thần Lửa Jung Yi trọn bộ, Nữ Thần Lửa Jung Yi thuyết minh, Nữ Thần Lửa Jung Yi lồng tiếng, Nữ Thần Lửa Jung Yi vietsub, Nữ Thần Lửa Jung Yi full HD, Nữ Thần Lửa ...
-
29 TậpHD
### Chiến Binh Baek Dong SooWarrior Baek Dong Soo29 Tập | HD
Warrior Baek Dong Soo là câu chuyện kể về một huyền thoại kiếm khách có thật dưới triều vua Jeongjo thời Chosun. Nhân vật chính của phim là anh hùng Baek Dong Soo, người đứng đầu một nhóm cận vệ thiện xạ bảo vệ hoàng đế và đã sáng lập ra hẳn một bí kíp võ thuật.
-
-
34 TậpHD
### Tình Yêu Chân ThậtLove Actually34 Tập | HD
Cô gái có năng khiếu nấu ăn thiên bẩm là Vương Tiểu Hạ cùng cháu trai là Dương Quang nương tựa vào nhau sống qua ngày. Trong một lần gặp sự cố, do sơ suất của nhân viên môi giới nhà đất là Trần Hạo Kiệt khiến Tiểu Hạ bị chủ nhà lừa.Không còn nhà ở, bị dồn vào đường cùng, Tiểu Hạ đành cùng Hạo ...


text:
Đăng vào lúc 10:10 17/10/2013 bởi Đỗ Thị Hải Yến
Hãy khám phá những điều thú vị hoặc đăng ký thành viên trên Ucan, website học tiếng Anh cực đỉnh!
1. beef /biːf/ - thịt bò
2. ground beef/graʊnd biːf/ - thịt bò xay
3. roast/rəʊst/ - thịt quay
4. stewing meat/stjuːɪŋ miːt/ - thịt kho
5. steak/steɪk/ - thịt để nướng
6. pork/pɔːk/ - thịt lợn
7. sausage/ˈsɒ.sɪdʒ/ - xúc xích
8. roast/rəʊst/ - thịt quay
9. chops/tʃɒps/ - thịt sườn
10. spare ribs/ˈspeə.rɪbz/ - sườn
11. leg/leg/ - thịt bắp đùi
12. lamb/læm/ - thịt cừu non
-sweet: ngọt; có mùi thơm; như mật ong
-sickly: tanh (mùi)
-sour: chua; ôi; thiu
-salty: có muối; mặn
-delicious: thơm tho; ngon miệng
-tasty: ngon; đầy hương vị
-bland: nhạt nhẽo
-poor: chất lượng kém
-horrible: khó chịu (mùi)
(Bạn có thể thấy những từ dưới đây rất hữu ích khi mô tả món ca-ri và thức ăn cay):
-Spicy: cay; có gia vị
-Hot: nóng; cay nồng
-Mild: nhẹ (mùi)
-to boil: đun sôi; nấu sôi; luộc
-to bake: nướng bằng lò
-to roast: quay; nướng
-to fry: rán; chiên
-to grill: nướng
-to steam: hấp
Nếu có thắc mắc, bạn hãy gọi điện đến một trong hai số (di động hoặc cố định) dưới đây.
Tư vấn hỗ trợ trực tiếp qua các kênh trên Internet.
Nếu bạn muốn thanh toán bằng thẻ cào điện thoại.Nạp thẻ điện thoại
Bấm vào nút dưới đây để nhập mã thẻNạp thẻ của Ucan

markdown:
Đăng vào lúc 10:10 17/10/2013 bởi Đỗ Thị Hải Yến
Hãy
[ những điều thú vị hoặc khám phá](/index/demo)
1.
**beef** /biːf/ - thịt bò
2.
**ground beef**/graʊnd biːf/ - thịt bò xay
3.
**roast**/rəʊst/ - thịt quay
4.
**stewing meat**/stjuːɪŋ miːt/ - thịt kho
5.
**steak**/steɪk/ - thịt để nướng
6.
**pork**/pɔːk/ - thịt lợn
7.
**sausage**/ˈsɒ.sɪdʒ/ - xúc xích
8.
**roast**/rəʊst/ - thịt quay
9.
**chops**/tʃɒps/ - thịt sườn
10.
**spare ribs**/ˈspeə.rɪbz/ - sườn
11.
**leg**/leg/ - thịt bắp đùi
12.
**lamb**/læm/ - thịt cừu non
-
**sweet**: ngọt; có mùi thơm; như mật ong
-
**sickly**: tanh (mùi)
-
**sour**: chua; ôi; thiu
-
**salty**: có muối; mặn
-
**delicious**: thơm tho; ngon miệng
-
**tasty**: ngon; đầy hương vị
-
**bland**: nhạt nhẽo
-
**poor**: chất lượng kém
-
**horrible**: khó chịu (mùi)
(Bạn có thể thấy những từ dưới đây rất hữu ích khi mô tả món ca-ri và thức ăn cay):
-
**Spicy**: cay; có gia vị
-
**Hot**: nóng; cay nồng
-
**Mild**: nhẹ (mùi)
-
**to boil**: đun sôi; nấu sôi; luộc
-
**to bake**: nướng bằng lò
-
**to roast**: quay; nướng
-
**to fry**: rán; chiên
-
**to grill**: nướng
-
**to steam**: hấp
Nếu có thắc mắc, bạn hãy gọi điện đến một trong hai số (di động hoặc cố định) dưới đây.
Tư vấn hỗ trợ trực tiếp qua các kênh trên Internet.
Nếu bạn muốn thanh toán bằng thẻ cào điện thoại.
Bấm vào nút dưới đây để nhập mã thẻ

Server: Apache/2.2.25 (Amazon)

Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform


text:
Dầu FO cao su - Nhiên liệu đốt lò - Dầu FO-R - Dầu FO chưng cất từ vỏ xe, lốp xe
ĐẠI LÝ PHÂN PHỐI NHỚT SAIGON PETRO CHÍNH HÃNG
Chuyên cung cấp các mặt hàng dầu nhớt dân dụng và công nghiệp, đặc biệt nhớt Saigon petro.
Dầu nhớt Động cơ xe gắn máy, xe con, xe tải nhẹ , xe tải nặng, xe đầu kéo, ro-mooc , thủy lực, Nhớt cầu & hộp số, nhớt máy nén khí ( trục vít và piston ), nhớt chống gĩ, nhớt lạnh, dầu truyền nhiệt, dầu tẩy rữa, dầu máy biến thế, dầu cắt gọt ( đặc biệt không cháy hàng và không hôi phù hợp môi trường ), dầu bánh răng công nghiệp, dầu dệt kim, dầu tôi kim loại, dầu tuần hoàn, dầu khe trượt, dầu truyền động, mỡ bôi trơn chịu nhiệt từ gốc 00 đến gốc 3 ( No 0 -> No3 ) và các loại dầu đặc chủng khác.
Giá Nhớt Thủy Lực SP Hydraulic VG 68 chỉ có 8.370.000 đ/phuy ( giá đảm bảo đến 31/12/2011 ) và chiết khấu cao cho khách hàng có sản lượng thanh toán lớn và có nhiều mặt hàng khác đảm bảo có giá tốt nhất .
Hãy liên hệ ngay bây giờ để được tư vấn chuyển đổi từ các loại nhớt khác sang sử dụng nhớt Saigon Petro = >
Hotline : 083 5055160 - 06503 745 486 hoặc 0919 196 779
Mỡ nhờn Lithium AP MP Grease 175kg
Dầu chế biến cao su AP24 RPO
Dầu bôi trơn kim dệt AP36 Needle Oil WS
Mỡ Sinopec 180kg
Petroleum resin SK 120 H, Hydrocarbon C9
Petroleum resin
Hoá chất TCCA 90% khử trùng nước hồ bơi, thuỷ sản
Trisodium phosphate (Na3PO4)
Hóa chất polymer cation C 525 H
Enzyme (NeoBates C) cắt tảo và xử lý nước
Sodium Bicarbonate Bicar Z Solvay
Soda Ash Light (Sodium Carbonate)
Natri hydroxit NaOH 98%
Grasim Poly Aluminium Chloride - PAC (Phèn nhôm) màu trắng (Ấn Độ)
Cautic soda 32 - 45%
Dung môi hòa tan hương liệu PG40
Hạt thủy tinh GB13
Hạt thủy tinh GB12
Hạt thủy tinh GB11
Hạt thủy tinh GB10
Hạt thủy tinh GB9
Hạt thủy tinh GB8
Hạt thủy tinh GB7
Hạt thủy tinh GB6
Hạt thủy tinh GB5
Hạt thủy tinh GB4
Hạt thủy tinh GB3
Axit Formic (Hàn Quốc)
Bột đá Calcium Carbonate TC 1015
Xút lỏng 32-45%
Potassium Dichromate 99.7%
Bột nở AC Blowing agent 3000F
Chất tẩy rửa dầu mỡ kim loại, khuôn Taiho Kohzai JIP 598
Chất lỏng Silicone ngành chỉ may, tháo khuôn, đánh bóng - Element14 PDMS 350
Dầu tăng bóng cho nhựa
DẦU NHỚT NGÀNH GIA CÔNG CƠ KHÍ
DẦU NHỚT CÁC KHU CÔNG NGHIỆP VŨNG TÀU
DẦU NHỚT CÁC KHU CÔNG NGHIỆP TPHCM
DẦU NHỚT HCM
DẦU NHỚT LÂM ĐỒNG ĐÀ LẠT
Dầu Nhớt Long An
Dầu Nhớt Biên Hòa Đồng Nai

markdown:
Dầu FO cao su - Nhiên liệu đốt lò - Dầu FO-R - Dầu FO chưng cất từ vỏ xe, lốp xe
|Siêu VIP còn trống
|
Liên hệ Q.Cáo
0949.300.134
|Siêu VIP còn trống
|
Liên hệ Q.Cáo
0949.300.134
|Siêu VIP còn trống
|
Liên hệ Q.Cáo
0949.300.134
|Siêu VIP còn trống
|
Liên hệ Q.Cáo
0949.300.134
|Siêu VIP còn trống
|
Liên hệ Q.Cáo
0949.300.134
|Siêu VIP còn trống
|
Liên hệ Q.Cáo
0949.300.134
|Siêu VIP còn trống
|
Liên hệ Q.Cáo
0949.300.134
|
|
Tin rao vặt này đã hết hạn! Tin lưu trữ..
Bạn hãy vào mục
|
|
|
|
|
|
|Đăng bởi :||
|![]()
|Thông tin chung||
|
|Dùng trong|
|Thông tin chi tiết||
|**ĐẠI LÝ PHÂN PHỐI NHỚT SAIGON PETRO CHÍNH HÃNG **
Chuyên cung cấp các mặt hàng dầu nhớt dân dụng và công nghiệp, đặc biệt nhớt Saigon petro.
Dầu nhớt Động cơ xe gắn máy, xe con, xe tải nhẹ , xe tải nặng, xe đầu kéo, ro-mooc , thủy lực, Nhớt cầu & hộp số, nhớt máy nén khí ( trục vít và piston ), nhớt chống gĩ, nhớt lạnh, dầu truyền nhiệt, dầu tẩy rữa, dầu máy biến thế, dầu cắt gọt ( đặc biệt không cháy hàng và không hôi phù hợp môi trường ), dầu bánh răng công nghiệp, dầu dệt kim, dầu tôi kim loại, dầu tuần hoàn, dầu khe trượt, dầu truyền động, mỡ bôi trơn chịu nhiệt từ gốc 00 đến gốc 3 ( No 0 -> No3 ) và các loại dầu đặc chủng khác.
Giá Nhớt Thủy Lực SP Hydraulic VG 68 chỉ có 8.370.000 đ/phuy ( giá đảm bảo đến 31/12/2011 ) và chiết khấu cao cho khách hàng có sản lượng thanh toán lớn và có nhiều mặt hàng khác đảm bảo có giá tốt nhất .
Hãy liên hệ ngay bây giờ để được tư vấn chuyển đổi từ các loại nhớt khác sang sử dụng nhớt Saigon Petro = >
Hotline : 083 5055160 - 06503 745 486 hoặc 0919 196 779
Mỡ nhờn Lithium AP MP Grease 175kg
Dầu chế biến cao su AP24 RPO
Dầu bôi trơn kim dệt AP36 Needle Oil WS
Mỡ Sinopec 180kg
Petroleum resin SK 120 H, Hydrocarbon C9
Petroleum resin
Hoá chất TCCA 90% khử trùng nước hồ bơi, thuỷ sản
Trisodium phosphate (Na3PO4)
Hóa chất polymer cation C 525 H
Enzyme (NeoBates C) cắt tảo và xử lý nước
Sodium Bicarbonate Bicar Z Solvay
Soda Ash Light (Sodium Carbonate)
Natri hydroxit NaOH 98%
Grasim Poly Aluminium Chloride - PAC (Phèn nhôm) màu trắng (Ấn Độ)
Cautic soda 32 - 45%
Dung môi hòa tan hương liệu PG40
Hạt thủy tinh GB13
Hạt thủy tinh GB12
Hạt thủy tinh GB11
Hạt thủy tinh GB10
Hạt thủy tinh GB9
Hạt thủy tinh GB8
Hạt thủy tinh GB7
Hạt thủy tinh GB6
Hạt thủy tinh GB5
Hạt thủy tinh GB4
Hạt thủy tinh GB3
Axit Formic (Hàn Quốc)
Bột đá Calcium Carbonate TC 1015
Xút lỏng 32-45%
Potassium Dichromate 99.7%
Bột nở AC Blowing agent 3000F
Chất tẩy rửa dầu mỡ kim loại, khuôn Taiho Kohzai JIP 598
Chất lỏng Silicone ngành chỉ may, tháo khuôn, đánh bóng - Element14 PDMS 350
Dầu tăng bóng cho nhựa
DẦU NHỚT NGÀNH GIA CÔNG CƠ KHÍ
DẦU NHỚT CÁC KHU CÔNG NGHIỆP VŨNG TÀU
DẦU NHỚT CÁC KHU CÔNG NGHIỆP TPHCM
DẦU NHỚT HCM
DẦU NHỚT LÂM ĐỒNG ĐÀ LẠT
Dầu Nhớt Long An
Dầu Nhớt Biên Hòa Đồng Nai

Set-Cookie: history_raovat=1853268%7C0; path=/


text:
Thể loại phim
Xem Phim TV - Trang xem phim online hay, xem phim
miễn phí chất lượng tốt, Xem phim TV luôn cập nhật các bộ phim hành
động, phim chiếu rạp mới nhất với các thể loại phim tâm lý , phim hài ..v. Xem phim tại Xem phim
Tv sẽ luôn có phụ đề việt hoặc phim lồng tiếng đem đến sự thoải mái cho
các bạn khi xem phim. Xem phim tv sẽ hạn chế tối đa quảng cáo để luôn
là 1 sự lựa chọn phim online tốt nhất cho các bạn

Cache-Control: max-age=0, no-cache, no-store, must-revalidate, post-check=0, pre-check=0

Server: cloudflare-nginx